How to manage trunk/branches/tags in the project while bug fixing and regular development?

Recently I’ve come across some problems on managing trunk/branches/tags. As a result of manual merging two branches I’ve ended up with hours spent on editing conflicts and checking the system. It’s obvious this was not a good sign as new bugs might have been introduced.

I’ve decided to organise the way the revision control system is used. Below you can find descriptions of two most common scenarios.

All team members work only on current release

dev1 350x177 How to manage trunk/branches/tags in the project while bug fixing and regular development?

As you see in the picture above the whole team works only on current release (nobody implements features for upcoming releases).

  • When system testing cycle starts a new tag is created so that there’s a snapshot of the current state of the application.
  • If bugs are found fixes are implemented and checked in to (main) development branch/trunk.
  • When new system test cycle starts a new tag is created.
  • The whole process is repeated until there’s no bug found or the state of the application is satisfactory.

Part of the team works on bug fixing and others implement features for next release

dev2 349x250 How to manage trunk/branches/tags in the project while bug fixing and regular development?

This is a more complicated scenario when part of the team is responsible for fixing bugs found in the system test cycles whereas the rest works on implementation of features that should be released after the current one.

  • When first system test cycle starts a new tag is created so that there’s a snapshot of the current state of the application.
  • Work on next release can be performed. Code is checked in to the main dev branch/trunk.
  • If there were no bugs found (good joke…) that’s it – you can stop reading here.
  • In real life some bugs will be found though; they must be fixed. A new branch should be created from just created tag and any bug fixes should be committed to that branch. This way two parts of the development team don’t interfere each others’ work
  • Whenever a new system test cycle starts a new tag is created from the branch used for bug fixing and that’s repeated until there’s no bug found or the state of the application is satisfactory.
  • Bug fixes need to finally be included also in main dev branch. This can be done by merging dev branch with branch used for bug fixing in two ways: (i) when final version of current release is ready (one big merge at the end); (ii) when bug fix is committed to the branch (several small merges). You need to choose which option is better for you – sometimes one big merge is enough, but you can end up with loads of files that need merging and possible conflicts might arise.

Final remark – not a single check in should be made to a tag.

Please bear in mind these are my thoughts, which can be not perfect. If you use a different approach and you believe it’s better, don’t hesitate to share it with me (us).

Maybe anyone can recommend some articles/books on how to administrate IT pojects with regards to revision control system?

 How to manage trunk/branches/tags in the project while bug fixing and regular development?

11 Responses to “How to manage trunk/branches/tags in the project while bug fixing and regular development?”


  • Clóvis Valadares Jr

    Seems to me that you don’t use git. A ‘git rebase’ should work very well for you.

  • Sounds good. I don’t think you have to worry about there being a “better” method.

    Just be aware that you will want to modify this approach in other scenarios.

    This works when one group is working on the “bug fix” branch and one group is working on the “next release” branch. What happens if you have a third group that is making changes for a much later release? In this case, you will probably want to create a separate branch for long term changes. Now you have two different branches and the trunk – it probably will happen to your project. Merging code can be even more challenging when this happens. So be prepared for that.

    What about a scenario when you have already cut a “soon to be released” branch, but you get a request to make an “emergency fix” in the previous release? In this scenario, your team need to go back to the previous branch, fix the bugs in there and deploy that release. But you also need to merge those fixes back in to the trunk AND you need to merge those fixes to your “soon to be released” branch. Your setup will work fine for this scenario, just be prepared for it.

    This may be out of scope of what you had in mind. You have a bug fix branch and the main line (the next release). Does that mean you have two different environments so that QA can test the bug fix version and the next release separately?

  • John,

    Thanks for useful scenarios!

    The former is indeed complicated :)

    Let’s focus on the latter, which I deal with from time to time…

    What about a scenario when you have already cut a ?soon to be released? branch, but you get a request to make an ?emergency fix? in the previous release?[...]

    How I handle this is similar to what you have described:

    • I switch to the branch with the release which is currently LIVE and make a fix there
    • When the patch is ready I create a new tag as a snapshot of the system with this patch and push the patch LIVE
    • Finally I switch back to the trunk (or the current branch) and merge it with the changes made for purpose of the fix

    As you said the approach suggested by my is helpful there.

    Answering your question, at a point in time trunk is current development branch, and in Subversion there are branches names ReleaseX (past releases). Also whenever something is pushed LIVE (a full build or a patch with some fixes) I create a tag so that I can easily check out the same code that is/was running LIVE.
    Does it answer your question?

    Cheers,
    Jarek

  • Greg, thanks for the presentation!

  • you _really_ need a dvcs. try mercurial or git.

  • Jarosław: you’re quite welcome, that presentation is one of the clearest things I’ve read about branching in version control and helped me clarify a lot of my thinking about how to do it “correctly.”

  • Jarosław,

    Your process definitely works. I’ve had to take on a release manager role for several years (until we can hire a dedicated RM), and I’ve found a lot of release management is just common sense. The hard part is making sure the execution is right.

    I’ve found it helpful to try to minimize the # of branches you need to maintain. No matter which version control system you use, merging is always tricky. In the case where you have to work on a new feature that should not go for several releases, it might be worthwhile to code things in such a way you can turn on the feature in development, but disable it in QA and production.

  • There is one distinct advantage to merging each commit to both the bug branch(es) and the feature branch(es) at the time of the commit (several small merges):

    That way the merge is the responsibility of the developer who knows the fix, and (hopefully) has better understanding of how to deal with conflicts on the other branches.

    OTOH – that advantage is more relevant when the person building is not familiar with the code. Which (I guess) is more a corporate scenario.

  • John,

    Thanks for your input too!

    Jarek

  • What about Compact Framework? I’m facing the same issue and custom cert policy is not solving the issue?

Leave a Reply