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

Answer 1

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

Answer 2

When you do a merge, you specify the target. You can merge the differences of TreeA and TreeB to TreeC if you like. As Chris implies, your question doesn't really make that much sense. If you merge your branch into the trunk, the branch remains untouched. If the branch isn't needed afterwards, you could delete it.

Answer 3

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.

Answer 4

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.