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

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 d开发者_开发知识库ifference 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?

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.

--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...