Subversion branch reintegration

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