Why does TortoiseSVN (1.5.3) try to merge 1-Head when I pull from trunk?

Question

I use TortoiseSVN 1.5.3 and VisualSVN 1.5.3 (Subversion 1.5.2)

Suppose that I create a new branch (/branches/branch1) of the trunk(/trunk) then someone (also using TortoiseSVN 1.5.3) merges their branch back into the trunk.

I try to merge from the trunk into the branch (to aquire all changes which might have beemn merged into the trunk by others)

I do not specify any particular revision(s) because I want the merge-tracking to determine which revisions I need to merge. I expect these to be revisions after the one in which I created the branch.

When I start the merge, the output dialog seems to merge every revision back to revision 1. this causes everything in the repository to be 'added'.

What a I doing wrong?.... I expected a single revision to be targeted and for this to be a very quick operation.

I have tried...

SVNAdmin Upgrade <MyRepoPath>

This resulted in a an instantaneous success message after which I repeated my experiment with no change in results

Update: I have noticed that the TortoiseSVN dialog says "To merge all revisions, leave the box empty."... does this mean that TortoiseSVN is adding the 1-Head explicity and that there is no way to use Merge-Tracking? That would seem a bit strange.

Answer 1

I think you need to use the Branch as your from URL. The reason is that your Trunk revision is now higher than your Branch, and so you need to start with the lowest revision.

Answer 2

SOLVED: The answer appears to be down to a workaround we implemented here for some previous bugs in Subversion.

The workaround involved the use of SomeUserName@ being placed in the url. thus

http://SomeUsername@Myserver:8080/myrepo/trunk

...was being used instead of...

http://Myserver:8080/myrepo/trunk

It seems that the working copy of the branch was retrieved without this addition and the Merge was being done to a url with this addtion. this led Subversion to deduce that they were 2 different urls and naturally(ish) deduced they had no common history from which to locate the startpoint to merge from.

Thus the solution is to ensure the format of the 'from' url used for the merge matches the format of the url used by the working copy.