Subversion branch reintegration

Question

When a branch is reintegrated to the trunk, is that branch effectively dead?

Can you make modifications to the branch after the reintegration and merge those back into the trunk at a later date?

Solution 1

You can do it technically, you branch is not dead nor disabled, but it is not recommended to merge from branch to trunk after reintegration.

You can find a full discussion about the reason for that, here: Subversion merge reintegrate

Basically, it says, that it is possible to merge your changes again to the trunk, but since reintegration forces you to merge from trunk to branch prior to the reintegrate operation you'll be facing Reflective/Cyclic Merge which is very problematic in Subversion 1.5.
According to the article, it is recommended to delete your reintegrated branch immediately after reintegration and create a new one with the same (or different) name instead.

This is a known Subversion behavior which will be addressed in future version (probably in 1.6)

---

Solution 2

Actually, you need to do a --record-only merge from trunk into your branch of the revision that was created by the --reintegrate commit:

$ cd trunk
$ svn merge --reintegrate ^my-branch 
$ svn commit

Committed revision 555. 
# This revision is ^^^^ important

And now you record it

$ cd my-branch
$ svn merge --record-only -c 555 ^trunk 
$ svn commit

You are happy to keep the branch now

More information is in Chapter 4. Branching and Merging, Advanced Merging.

Solution 3

After you reintegrate from a branch into the trunk, you should do one of two things:

• Delete your branch. This is the easiest, but it makes it harder to see the branch's history.

• Tell your branch not to merge the reintegrate commit. If you reintegrate to the trunk, and commit it as revision X, you can run this command on your branch: svn merge --record-only -c X url-to-trunk. However, you shouldn't do this if you made any changes as part of the commit, other than the merge itself. Any other changes will never make it back into your branch.

Solution 4

Some advice on merging the changes back if someone makes changes to the branch multiple times (pre 1.5): Remember at which revision you did the merge! Either write the revision numbers down somewhere, or (which is easier) make a tag. (You can of course find it out later, but that's a PITA.)

Example:

You have a repository layout like this:

/your_project
  /trunk
  /branches
  /tags

Let's say it is a web application, and you have planned to make a release. You would create a tag, and from that (or from trunk) a branch in which you do the bugfixes:

/your_project
  /trunk
  /branches
    /1.0.0-bugfixes
  /tags
    /1.0.0

Doing it this way, you can integrate the new features in the trunk. All bugfixes would happen only within the bugfix branch and before each release you make a tag of the current version (now from the bugfix branch).

Let's assume you did a fair amount of bugfixing and released those to the production server and you need one of those features desperately in the current trunk:

/your_project
  /trunk
  /branches
    /1.0.0-bugfixes
  /tags
    /1.0.0
    /1.0.1
    /1.0.2

You can now just integrate the changes between 1.0.0 and 1.0.2 in your trunk (assuming you are in your working copy):

svn merge http://rep/your_project/tag/1.0.0 http://rep/your_project/tag/1.0.2 .

This is what you should remember. You already merged the changes between 1.0.0 and 1.0.2 upon the trunk. Let's assume there are more changes in the current production release:

/your_project
  /trunk
  /branches
    /1.0.0-bugfixes
  /tags
    /1.0.0
    /1.0.1
    /1.0.2
    /1.0.3
    /1.0.4

You are now ready to release the new version from trunk, but the last changes of your bugfixes are still missing:

svn merge http://rep/your_project/tag/1.0.2 http://rep/your_project/tag/1.0.4 .

Now you have all changes merged on your trunk, and you can make your release (don't forget to test it first).

/your_project
  /trunk
  /branches
    /1.0.0-bugfixes
    /1.1.0-bugfixes
  /tags
    /1.0.0
    /1.0.1
    /1.0.2
    /1.0.3
    /1.0.4
    /1.1.0

Solution 5

As everyone has already said it here: the branch isn't dead and commits to the branch can continue just fine.

Sometimes though you want to kill the branch after the merge. The only reliably solution is to delete the branch. The downside is that then it's harder to find the branch again if you wanted to have a look at it, say, for historical reasons. So, many people leave the "important" branches lying around and having an agreement of not changing them. I wish there was a way to mark a branch dead/readonly, thus ensuring nobody can commit to it until further notice.

View more solutions

Comments

[tilanka kulatunge]

Does anybody know if the reintegrate problem was resolved in Subversion 1.6 ?

[Namal159]

Please see the answer from Pini Reznik and the article referenced therein, for the reason why you should not continue to use the branch (even though it is technically possible).

[detly]

Seriously, don't do it. It'll cause you a world of pain. Delete the branch, recreate it. I will send you a sealed jar of my tears of grief from two weeks ago if you don't believe me.

[Andres Jaan Tack]

I've addressed svn v1.6 in stackoverflow.com/questions/3309602. The short version: Yes, you can reintegrate multiple times. :)

[Kaitsu]

Pini, your link to "Subversion merge reintegrate" seems to be broken or at least require some authentication to collabnet. Do you know if the article can be accessed somewhere else without authentication?

[Pini Reznik]

I think this is the original article: blogs.collab.net/subversion/2008/07/subversion-merg and this is the earlier discussion: svn.haxx.se/dev/archive-2007-11/0729.shtml

[Jerome Baum]

svn mv ^/branches/foo ^/branches/.dead/foo

[bahrep]

Downvoting because the answer is not actual anymore.

[bahrep]

The answer is outdated.