To Branch or Not To Branch (and Merge/Test)

while release 2 of the database is still undergoing substantial change (unless, perhaps, you're doing a major rewrite of the database). On the other hand, if you are doing a major rewrite in release 3, you might want to start work on it well before release 2 starts to gel. You might even want to put some hooks into release 2 to help support the eventual transition to release 3. Because the model is simple, your CM tool just needs to know that it's targeting the change to a specific release stream, and it can tell you when you need to branch, and even where to branch from.

Weeding out the Branches

So, we're going to get more branches - one per release stream. What else do we use branching for? Well, ideally, nothing! Sounds idealistic, but is it practical? It comes down to your tools. What do they support?

If you want to group a set of files together, rather than creating a branch and labeling it with your change identifier, use a change package (a.k.a change, a.k.a. update). The change should identify the files within it. You don't need a branch, so that you can label the branch with the change identifier.

What about branching for a release - so that you can label a baseline? Well, better yet, use a tool that has baselines as a first order object, and not just an algorithm or a label. The baseline should contain the items collected into the baseline.

OK. Do you still need branches for promoting changes? If your CM tool allows you to promote the actual changes (i.e. the first order objects) and if it can draw configuration threads through changes based on promotion level, whether for baseline purposes or just for your context view, then you don't need promotion branches.

There may be a number of other reasons you branch. But if the reason is basically because there's a lack of functionality in your CM tool, this is a big issue. Minimizing branch complexity is important.

A Good Question

David Baird, moderator of the General CM Forum at CM Crossroads raised a good question at the ALM Expo 2005:

"How do I handle engineer groups who want to work in isolation on a change, want to share their work with each other, reconcile their work with changes on the mainline, and promote their work at the end of their isolated effort? My current solution is a task branch pattern."

In the limited response time, I didn't give this question full justice. There are a number of approaches here. The first thing to notice is that it is a long, somewhat complex implementation task. It should be targeted to a future release perhaps, or if possible, planned well in advance, both because it could be disruptive, requiring multiple reconciliations on the part of the group, and because it can cause some instability, seeing that it is complex. This is how I would approach the problem.

First, I would look at the task and break it up into logical changes (or sub-tasks). In doing so, I would first look to see if any part of the implementation should be done in the current development stream to help with future migration to the new/revised feature. Then I would look at other changes for the task that could cause instability. I would schedule those changes for the next release which is not yet in full flight, if schedule permits. I would also add structure so that the remaining changes could be enabled or disabled from run-time if possible. Now all