Fundamentals of SVN merge

Question

My question relates to some fundamentals of SVN merging mechanism. I am not reporting a merge problem here. Moreover I have gone through SVN book's merge chapter (not a newbie).

I have 10 revisions on trunk and I would like to merge revisions 5,6,7,8,9 and 10 to a particular tag.

I could do a successful merge in tortoise SVN by running merge operation 6 times. Each time I only specified a single revision (i.e. 5,6,7,8,9,10).

If my understanding of SVN revisions is right, revision 10 (the HEAD revision) has all the fixes of previous revisions i.e. 5,6,7 and 9. Therefore I could have saved time by running merge operation only once i.e. by specifying revision 10.

The obvious reaction to my question would be that I should specify a "range of revision".

My question is why even specify a range when revision 10 would contain all the changes of previous revisions anyway (http://svnbook.red-bean.com/en/1.7/svn-book.html#svn.basic.in-action)? Can not I just do a merge by specifying a single revision (no. 10) and expect SVN to do right merge?

Answer 1

Actually, the svn merge command is taking a diff (or changeset) as argument. So when you are merging using a command like this:

svn merge -c10 URL

it's in fact the same as:

svn merge -r9:10 URL

and is merging the changes brought by the 10th commit to the repository.

Moreover, the svn:mergeinfo property will then indicate that the changeset corresponding to the revision 10 has already been merged, so that the subsequent merges will be smarter and won't try to merge that changeset a second time.

So, to answer your question specifically, you specify a range of revision to the svn merge command when you want to merge the changes corresponding to that specific range.

There is a notice about changes and changesets in the documentation:

In Subversion, a global revision number N names a tree in the repository: it's the way the repository looked after the Nth commit. It's also the name of an implicit changeset: if you compare tree N with tree N-1, you can derive the exact patch that was committed. For this reason, it's easy to think of revision N as not just a tree, but a changeset as well. If you use an issue tracker to manage bugs, you can use the revision numbers to refer to particular patches that fix bugs—for example, “this issue was fixed by r9238.” Somebody can then run svn log -r 9238 to read about the exact changeset that fixed the bug, and run svn diff -c 9238 to see the patch itself. And (as you'll see shortly) Subversion's svn merge command is able to use revision numbers. You can merge specific changesets from one branch to another by naming them in the merge arguments: passing -c 9238 to svn merge would merge changeset r9238 into your working copy.