How does one manage multiple release branches in subversion?

Question

At the company I work for we use subversion and TortoiseSVN to manage our source code. Each project is branched off the trunk. When we need to integrate the different projects for a release, we create a release branch that contains the code that will be integrated, tested, and deployed to production. Typically we only have one release branch.

Recently, however, some of the items in one of the projects got delayed and were scheduled to go into the next release. As a result, someone requested that a second release branch be created to hold the delayed changes and prevent them from getting merged into the current release.

So far this has caused us a lot of grief and lots of tree conflicts since some items in the future release branch are dependent on items in the current release branch. The only way we were able to solve these issues was to wait until the current release was deployed, merge the release branch into the trunk, merge the trunk into the future release branch, and then merge the changes from project branch into the future release branch.

As a result of this issue we have had to recommend that we should never have more than one release branch because it causes merge issues.

However, I am wondering if this is the correct way to go. Does anyone know if it is possible to manage multiple release branches in subversion? Surely it must be possible to manage features that get delayed without compromising one's ability to do merges.

Does anyone out there have any experience concerning the scenario I've presented that you'd be willing to share? I'd just like to know how I can improve the way releases are managed at my workplace so this doesn't happen again.

Answer 1

This is not where tortoise excels. To do complicated merge and branch scenarios you need something like clearcase config spec to do your version control.

If you use tortoise you are best keeping the trunk as so, and then either run continuous integration on the trunk, or to create branches for each feature, merging them back in when the feature development is complete. If you do this then you will only have code on the trunk which is tested. Then you choose a release point, do your integration and bring back required fixes into your trunk, but also allowing your teams to continue their development.

Answer 2

I think you want merge tracking, either through svnmerge.py, or through the builtin merge tracking from Subversion 1.5. This allows you to block certain changes from being merged into a branch, which then could be done to all changes related to features that you only want to incorporate into the next release.

Answer 3

You would almost always want changes on first delayed branch to be present in second. So second release branch should be made from first release branch, and changes from first should periodically be merged up. Ideally by the same people who made them in the first place.

Spepladder(?) branching will work good in this case -- just abandon trunk and climb up.

Answer 4

To be honest, I'm not entirely sure how your system is working from the description. However, I have had to manage projects with several live versions in the past. The way we did this was:

1. Nothing gets released that isn't in trunk first.
2. Each version gets its own version branch.
3. The only way of updating a version branch is to merge from trunk.

This way we could cherry pick which features were in which version. Using merge-tracking, it also let us build a web page that showed us graphically what went were.

The crucial thing is having one fully integrated branch that you can pick from - this is my definition of trunk.

Not a perfect system, if you skipped versions then dependencies made things tricky, and we really needed the graphical thing to show us what was where, but overall appeared to work well.

Also see my answer here.

Answer 5

My company has had similar issues.

We had a project delay one release -- we'll call it 2.0 -- by several months. In the meantime, we had production issues on the current branch -- let's call that 1.5 -- that warranted more releases. We couldn't use trunk, because it had the embargoed features, so we started branching from branches. Our release 1.6 branched from 1.5, not trunk. Other than naming convention the 1.6 release is really nothing more than 1.5.1. Since this is not SOP, we've been very careful to document what we're doing.

And I am not looking forward to the merge point, where we finally bring together the 1.6 branch and 2.0. We're unable to merge changes on 1.6 back onto trunk or 2.0, because that just makes QA on the 2.0 problems all the worse. We're running Subversion 1.4.6, so no help from the software -- it will be all manual merging.