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).
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).
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.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With