At 02:08 PM 11/14/2003 +0000, Robin Charlton wrote:

You only need a branch for a release that will be actively maintained and from which you will make further releases that will be maintained. The leaves of the code tree can be milestones along a branch rather than having their own branches.

If you do this everybody has to be a conscientious branch manager, doing whatever merging is needed to pull from the parent branch before each submit. I make it clear that every has a sandbox in which this can be done, but it's not part of the normal development scheme.

Make a branch only when it's necessary to isolate groups that would get in each others' way. The more project branches you have, the more work you're going to have to do to stabilize the main line after each code delivery from a project branch and the more opportunities there'll be for mistakes to be introduced by incorrect merges.

One practice that I've seen work well is to have a shadow main branch that receives code from the project branches. Changes aren't moved to the stable main branch until they've proved themselves on the shadow main and until the product managers have approved the feature or fix for the upcoming release.

The goal is to always have the main line be stable and releasable. Some people would choose to merge code deliveries from the project branches directly into main, to avoid doing baseless merges. This has the disadvantage that the main line is usually in an unstable state, making it difficult to pull new branches from it and making it difficult to integrate changes through it for the benefit of the maintenance branches.