Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

What are the differences between merging a range of revisions vs. reintegrate in SVN?

Tags:

svn

People also ask

What is merging in svn?

In Subversion terminology, the general act of replicating changes from one branch to another is called merging, and it is performed using various invocations of the svn merge subcommand. In the examples that follow, we're assuming that both your Subversion client and server are running Subversion 1.7 (or later).

How to merge two revisions in svn?

To merge a range of revisions, use svn merge -r start:end from to where start and end are revision IDs. This will merge all revisions starting at start+1 up to and INCLUDING end . Note: it will NOT include the first revision (ex: -r3:45 will merge 4 through 45).

What is merge in Tortoise svn?

TortoiseSVN helps you through this process by showing the merge conflict dialog. Figure 4.58. The Merge Conflict Dialog. It is likely that some of the changes will have merged smoothly, while other local changes conflict with changes already committed to the repository. All changes which can be merged are merged.


For one thing, the way that SVN calculates the differences to apply is different between the two methods. Normally, when you apply a range of revisions X to Y from a trunk to the branch in cherry-picking fashion, for example, SVN calculates the differences between the revisions of X to Y in the trunk, and applies those to the branch. You could also do the same thing in the other direction, applying changes from the branch to trunk this way.

When you reintegrate a branch into the trunk, however, SVN does a different sort of calculation. Instead of calculating the difference between revisions X to Y in a branch and applying those changes to the trunk, SVN merely calculates the difference between the entire branch and trunk. Assuming that you've been diligent about keeping the branch up-to-date with changes made in the trunk, then the difference of the reintegration calculation between the trunk and branch will be exactly all of the changes made in the branch that are not yet in the trunk.

From the SVN 1.6 documentation (Reintegrating a Branch):

When merging your branch back to the trunk, however, the underlying mathematics is quite different. Your feature branch is now a mishmash of both duplicated trunk changes and private branch changes, so there's no simple contiguous range of revisions to copy over. By specifying the --reintegrate option, you're asking Subversion to carefully replicate only those changes unique to your branch. (And in fact, it does this by comparing the latest trunk tree with the latest branch tree: the resulting difference is exactly your branch changes!)

I'm not entirely sure (I've forgotten over the years), but I think in previous versions of SVN (like prior to 1.5?), there was no merge-tracking and no branch reintegration option, so if you wanted to merge a completed branch into the trunk, you had to do it manually using the range of revisions method instead. I'm trying to look this up in the docs, but I haven't found a reference about it yet.

Additional Reading

See also Re: Why is --reintegrate needed for svn 1.5 merging?, which was pointed out in this comment.


reintegrate is meant to be used when you were working on a feature branch, and are done. The next step should be deleting the branch. Before reintegrating, you should merge the destination (most often trunk) to the branch using "range of revisions" merge to merge all eligible revisions to the branch. This is described slightly above the reintegrate paragraph.

The "range of revisions" merge is meant for cherry picking revisions that should go to a certain branch, for example for fixing bugs in a stable release branch.