When to branch

There is a prevailing attitude in the industry that branching is unessecary if the process is right, and when branching is performed it is always costly. Both are fallacies. First of all branching is a tool that can be misused, and I think to a degree is misunderstood. But to start some tools, eg. Clearcase force a degree of branching particularly with dynamic views. In the world of CVS and Subversion a kind of branching is hidden, it happens in the the sandbox. What happens in the sandbox is what might happen in a sandbox in other systems.

That is by-the-by, in Subversion branching is lightweight. I think a decription in the context of the tool is nessecary. For example if a customer wanted a change to a previous release--- a critical change, then you'd want to change as little as possible. In subversion tagging has not technical difference from branching--- it just follows slightly different conventions: it's not considered good practice to modify the tag after release. This changes the SCM Basline; that is the identification of the release.

I think a conversation about branching only really makes sense in context of:

* The types of deliverable you can get away with
* How may varients you might have
* How much legacy is there in the field and the commercial cost for the buisness in upgrading these systems to the HEAD.
* Development practice wrt. Tasks, Integeration and Releasing.

To me the question is not whether to branch or not but is it clear how SCM is going to be performed. It's not the technology that is interesting it's the practical solution or application.

What I find interesting about decisions of this nature is there is not a unique source, sometimes the decision is a development one and sometimes it is a project/product decision.

Also SCM may be going through a period of great change, risk is being reduced by techniques like Continous Integration--- which I think is where Kent was coming from--- but branching to release (or similar) was only one reason why you might branch. This complexity may point to a future of decentralisation, which has great implications for Agile.

I understand the idea of branching little, I wrote it up as a principle once for my previous employer. We begun to implement it--- with a great many developers--- and it ended up being a poor model. For that organisation at least. It appeared like the Tradegy of the Commons where everyone wanted to do what they wanted in the simplest way, but that ended up being detrimental to the whole. But that might have been an indication of other issues.