Merging problem using svn merge

**amorgovsky** · 12-01-2006, 08:47 AM

Let us say I have a file in branch a which has the text:

Alex
is
here

The same file in the trunk has the text:

Alex
has
been
there

When I do the merge from the branch to the trunk, the file in the trunk gets completely overwritten with (which is the content of the branch file):

Alex
is
here

and there are no conflicts reported, but there definetely are conflicts with lines 2 and 3.

I do the merge like this:

svn merge http://<url of trunk> http://<url of branch> <working copy of trunk>

I expected .diff and .original .working files to be created by svn merge, but none where. Please help if you may, I would really appreciate it.

**lmop** · 12-02-2006, 01:55 AM

This is a fairly common mistake to make. The svn merge syntax is not to specify the from_branch and to_branch like other revision control systems (for example, Perforce). The thing to remember is that svn merge is effectively just svn diff, the only difference being that instead of showing you the diffs, it applies them directly to your working copy.

So you need to specify how to generate the changes you wish to merge into your working copy. You do this by naming the path@revision for the two end-points which would generate the diffs you are interested in. The common case is to merge the differences from one branch to another (as you are doing), in which case the command is:

Code:

svn checkout <url_of_trunk> working_copy_name
cd working_copy_name

svn merge -r<start_revision>:<end_revision> <url_of_branch>

The first two commands just get you a copy of trunk, which I am sure you are familiar with. The svn merge command diffs your branch at revision start_revision and end_revision and applies those changes to your working copy, which is trunk. If you are happy with the changes you then svn commit to actually apply those changes to trunk in the repository.

So, if you reread your original command what you actually said was "how do I take trunk and convert it to look like branch? Then make those changes in my working copy". So you ended up with an exact copy of branch rather than attempting to apply the changes made on your branch which is what you really wanted.

Good luck with the merge - conflicts aren't usually much fun!

**amorgovsky** · 12-03-2006, 11:58 AM

Thanks for the reply. I have a question please. I use the svn log --stop-on-copy command to get the ranges of the when the branch was worked with. Should I use the start and end revisions in the -r parameters or should i increase or decrease these numbers by +-1? Also, when I run the command for merging, I don't get any U or other SVN status symbols from the output, as if nothing was merged. Does SVN output the status of the files which it has merged on the screen, or is there no output on the screen? If there is no ouput on the screen, how do I found out what has actually been merged? Thanks.

**lmop** · 12-04-2006, 12:44 AM

Use the revision numbers as they are, no need to increment them. The first revision of svn log --stop-on-copy gives the revision where the branch was brand new and identical to where you copied it from. The current revision is what it looks like now that you've finished. So you want to "diff" those two versions of the branch tree.

You should get an svn status-like output from svn merge as it processes changes. It uses the G marker to show that it has merGed changes into your working copy. Remember that your working copy should be the destination branch (probably trunk), not the branch you are merging from. You can also use the --dry-run option with svn merge so you can see what it would do without it actually doing it.

**amorgovsky** · 12-04-2006, 06:44 AM

Thanks for the reply. May I use the revision HEAD for the second parameter in the start:end -revision argument always? This way, I just need to be concerned about the starting revision and could just use HEAD as the final revision, because if nothing changes from the actual final revision to HEAD, then there is no problem doing it like this, I think. Please let me know if this thinking is correct. Thanks again.

**lmop** · 12-05-2006, 01:01 AM

HEAD is fine, although it helps to put the revision numbers you are merging into the log message so you know not to integrate them in the next merge you do. (Subversion doesn't track which changes have been merged and, whilst a double merge doesn't do any harm, it may generate more conflicts for you to deal with than necessary.)