SVN merge doubt

Question

Hi,

I have a directory under subversion control. I created a branch out of it just to test merging stuff. I took a file, modified line X in the trunk as "abc" and modified the same line X as "def" in its branch.

Then, from the branch working dir I did:

svn merge branchURL trunkURL .

It updated the file with the content as "abc" at that line number, i.e. it did not give me a conflict at the same line number as svn update would have given me if I had done it in the same working dir and someone had commited the "def" in the repository.

So does the svn merge just replace the content while merging and not bring any conflicts?

Kindly clear the doubt!

and if so the very reason of branching out a proj dir out of main trunk would be useless when one can't merge in a way so as to keep both the changes in trunk and branch.

Thanks.

Answer 1

so does the svn merge just replaces the content while merging and not bring any conflicts?

Well, no. I can't really point what you did wrong, but merging flags conflicts the same as update.

Answer 2

I may be missing something, but when I've used svn merge, I've always had to get the revision numbers right if I wanted it to work correctly.

So, if you branched (or last merged) at revision 100, the trunk is currently at 200, and you want to merge changes from the trunk into your branch, then in the branch working directory you do:

svn merge -r 100:200 trunkURL

Then I think you'll see a conflict, which you resolve and check in. You do a similar thing in the trunk working directory to merge from your branch back into the trunk.

svn merge without -r diffs the two locations you specify and applies that diff to the working directory. So I speculate that what has happened is that there is no conflict, because your working dir matches the head of the branch. So the difference between the head of the branch and the head of the trunk can be applied to your working directory without any problems. This isn't what you want to do: all it does is change your working directory to match the trunk. Try making another change on the branch, check in, and repeat the process. If the merge undoes that change (because it isn't on the trunk), then I'm right about this form of svn merge, but as I say I haven't used it.

[Edit: prior to svn version 1.5...]

Working directories and branches are not the same thing in SVN, and annoying as it is, you have to account for the differences. SVN needs more information to do the branch merge you want, than to do an update or checkin, because afaik it doesn't automatically take account of where the branch occurred in the way that it always accounts for where a working directory was checked out. I'm sure there's a reason for that, I just don't know for sure what it is: possibly because svn copy is for more things than just branches.

[Edit ... but as per Joshua McKinnon's comment to this answer, as of 1.5 svn supports proper branch merges, which do what you want automatically. Specify the URL you're merging from, and run the command in the working directory of whatever you're merging to. So in this case, try

svn merge trunkURL

and you should see the conflict. You might have to revert the working directory first.]

Answer 3

You do realize what

svn merge branchUrl trunkUrl branchWorkingCopy

Actually does, yes?

Here's a translation:

Figure out the set of changes necessary to make the contents of branchUrl identical to those of trunkUrl. Now perform those changes on the branchWorkingCopy.

You won't get any conflicts merging this way. When you check in your branchWorkingCopy, however, you will have made your branch identical to your trunk, which is almost certainly not what you want.

If you just want to copy selected changes from trunk to branch, you'll need to tell Subversion which changes you want to copy and use a different form of the merge command:

svn merge -r100:103 trunkUrl branchWorkingCopy

Which means: Determine the set of changes necessary to get from r100 to r103 on trunk. Perform those changes on the working copy (of branch). Note that this "set of changes" will not include the changes made by r100, as those are captured by the set of changes necessary to get from r99 to r100. Revision ranges in Subversion are half open.

Also, consider reading the fine manual, if you haven't yet.