Subversion branch reintegration

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?

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)

---

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.

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.

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

No, the branch is still alive, but, at that moment, it is exactly the same as the trunk. If you keep developing on the branch, you are free to re-merge with the trunk later on.

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.

You can merge from a branch to trunk, or trunk to a branch, as many times as you want.

First of all, you should upgrade your Subversion client and server if you still use Subversion 1.7 or older. There is no reason to be using very old Subversion releases. As of 2016, the current version is Subversion 1.9. SVN 1.8 is also supported now and still receives bug fixes.

The problem you ask about was solved in Subversion 1.8. Beginning with SVN 1.8, --reintegrate option has been deprecated. Reintegrate merges are now performed automatically. See Subversion 1.8 Release Notes entry related to the improvement.

Read SVNBook 1.8 | Reintegrating a branch:

> If you choose not to delete your branch after reintegrating it to the > trunk you may continue to perform sync merges from the trunk and then > reintegrate the branch again. If you do this, only the changes made on > your branch after the first reintegrate are merged to the trunk. > ...

> Only Subversion 1.8 supports this reuse of a feature branch. Earlier > versions require some special handling before a feature branch can be > reintegrated more than once. See the earlier version of this chapter > for more information: > http://svnbook.red-bean.com/en/1.7/svn.branchmerge.basicmerging.html#svn.branchemerge.basicmerging.reintegrate

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.

You can keep on developing on the branch, the feature you will need is merge-tracking which is in Subversion 1.5, this means that additional merges from the branch only include new changes.