Home/ Questions/Q 6336785
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-24T19:07:28+00:00

If you always synchronise a feature branch before you merge it back. Why do

  • 0

If you always synchronise a feature branch before you merge it back. Why do you really have to use the --reintegrate option?

The Subversion book says:

When merging your branch back to the trunk, however, the underlying mathematics is quite different. Your feature branch is now a mishmosh 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!)

So the --reintegrate option only merges the changes that are unique to the feature branch. But if you always synchronise before merge (which is a recommended practice, in order to deal with any conflicts on the feature branch), then the only changes between the branches are the changes that are unique to the feature branch, right? And if Subversion tries to merge code that is already on the target branch, it will just do nothing, right?

In a blog post, Mark Phippard writes:

If we include those synched revisions, then we merge back changes that already exist in trunk. This yields unnecessary and confusing conflicts.

Is there an example of when dropping reintegrate gives me unnecessary conflicts?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Let me explain when --reintegrate is absolutely necessary.

    Consider the following use case.

    1. you have project p1 under p1/trunk. The project has a file, readme.txt, with one line “line1″<
    2. Create a new branch, p1/branches/br1
    3. Stay in trunk. Add line “line2” to readme.txt and commit it to trunk
    4. Switch to the p1/branches/br1 branch. Update to HEAD.
    5. Merge from trunk to this branch (to pick up trunk changes).
    6. You should have line1 and line2 in readme.txt
    7. Commit merge the result to p1/branches/br1 branch
    8. Switch to trunk. Update to HEAD.
    9. Merge from p1/branches/br1 to trunk.
      1. You’ll see line1, line2 and line2 in readme.txt. So, you have “line2” two times which is incorrect. SVN does not show any conflicts. So, it is very dangerous because merge performed with no errors and you are under impression that everything is fine.

    The solution here is that the step 9 merge should be done using the --reintegrate option. The reintegrate option tells SVN to compare br1 with trunk and apply only br1 changes to trunk. In this particular case we have not done any changes in br1. The result in trunk should be two lines “line1” and “line2”.

    Another useful remark. Branch p1/branches/br1 should not be used for development after step 9 anymore. If you want to continue development in branches, create a new branch, for example, p1/branches/br2. Another merge from trunk to p1/branches/br1 causes lots of conflicts.

    • 0