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

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 where.

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

This is 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 2

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.