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

Question

I have read some documentation and blogs about the difference between merge a range of revisions and reintegrate but I didn't get one thing.

What is a difference in merging if I choose one or other way for merging from branch to trunk? Why merge a range of revisions doesn't work in some cases but reintegrate successfully merges branch to trunk?

Anent

Good question actually. I've read that manual chapter many times and I never really get it. (In my case, it's merge reintegrate the one that tends to fail.) – Proclamation

Answer 1

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.

Utility

I wish you gave an explanation by figures (visual explanation). I still don't get it. – Beaubeauchamp

@Emerald214 if it helps, try checking out the contents in this comment. – Utility

Gonna throw this out there in case someone goes looking for this with a newer version of SVN: --reintegrate :deprecated – Whitewall

Answer 2

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.

Wittie

As I said, I read these things in documentation. My question is why "range of revisions" is not recommended for merging back from branch to trunk? – Anent

@SanderRijken you should summarize the content of that link, I think it contains very helpful information about why --reintegrate is even necessary instead of a simple merge of a range of revisions. I think doing so will improve your answer a lot. – Utility

@SanderRijken: Hello Sir, could you please take a look at my question here? Thanks in advance ... :) – Acarpous

Answer 3

--reintegrate should be the default; if there really is any reason you would want to do a sync merge any different than --reintegrat, they could simply supply a --sync instead. --reintegrate is what you would want almost all the time anyways, except in cases where you want to cherry pick. (This is just my 2 cents - I don't consider myself a merging expert, nor do I understand why their sync math would be different than their reintegrate math) -- when I merge, I almost always want and only want the changes in the source branch, which have not yet been merged into the target branch...

Pincas

I think defaulting to reintegrate is quite dangerous. Suppose you have TRUNK and FEATURE_X branches. IIUC if you forget to do a TRUNK -> FEATURE_X merge before reintegrating FEATURE_X back to TRUNK, OR you do, but between the two steps a change has been committed to TRUNK, you just delete changes made on TRUNK. – Fulfillment

It is very important to use --reintegrate only with branch that is fully up-to-date with all changes of the trunk. As @Cupcake says, the diff applied is calculated in a totally different way. Due to this, it is not suitable for any other merge operation and not the default operation. – Macula