Thoughts on Recycling SCM Branches

Hey guys,

Chuck Walrad and Darrel Strom wrote an article on what they call “branch-by-purpose” model of branching: “The Importance of Branching Models in SCM”.

It is an excellent article that outlines a very useful mechanism/strategy for branching in SCM models.

The basic idea of 'branch by purpose' is to use a branch to satify a specific purpose. For example, a release is a 'purpose', so is a hot-fix, so is the need to do system testing, etc.

It's a very nice model that corresponds well to many development methodologies.

However, it is becoming more commons for organizations to do very frequent releases. During my time as the Team Foundation Server Product Manager, we worked with a very popular social networking site that released twice a day. That is probably an extreme example, but it is not uncommon fo organizations - consumer facing and otherwise - to do weekly or bi-weekly releases. That type of release model does magnify a side effect of 'branch by purpose' - you can end up with a lot of branches :)

Of course, Team Foundation Server has excellent support for renaming, deleting and moving, so you could easily just move release-branches into archive directories or just delete them altogether. I've suggested that to several customers in the past and it's never been all that well received. That's understandable - Team Foundation Server does support these operations, and it is very good about not storing too much overhead per branch, but it does feel strange to do this on a weekly or bi-weekly basis.

I've seen a lot of customers use labels instead to represent their releases. That works fine - but I'll admit, I've never been an extensive user of labels so I don't normally recommend it. It's a bias not really based on any bad experiences, just one of those things :)

Another option that combines the clarity of branch-by-purpose with the perceived efficiency of labels is to use a fix number of branches and recycle them.

This is something that I saw mentioned in an excellent presentation from Laura Wingerd of Perforce.

Based on ideas from that presentation, a reasonable initial set of branches would be:

• Main - based on your initial check-in of source code
• QA - created by branching from Main
• Beta - created by branching from QA
• Live - created by branching from Beta

What we will do is recycle QA, Beta and Live so that we can release as often as we would like, but never increase the number of branches that we have.

When we decide that whatever our developers have been working on is ready for a full test pass from QA, the code is merged from the Main into QA. The merge in this case is really basically a copy - anything coming from Main takes precendence over what is in QA. From QA, the code will be merged into Beta when it is deemed ready, and so on.

Once QA has been merged into Beta, it can be recycled. That means it is ready to take changes from Main again as soon as Main is ready. The same is true of Beta and Live. Beta can be recycled as soon as it is merged with Live and Live can be recycled as soon as that code has been delivered to customers.

To recycle a branch, we could literally delete every file and folder under that branch.

Laura's paper pointed out some 'rules of the road' for branching and merging. In this case, one rule would be that changes can only be merged 'up'. That is from Main 'up to' QA and from QA 'up to' Beta and so on.

One way to enforce a rule like this is through check-in policy. I'm making some harware changes right now, but as soon as I'm back up and going, I think I'll post a sample check-in policy that checks for proper merge direction.

In any case, using a recycling model like this, these 3 branches can accomodate an unlimited number of releases.

Laura's paper has a wealth of other really good ideas - I'm going to explore them in future posts.

Thanks!

Eric.