Fog Creek Software
Discussion Board

Selection for early branching vs. lazy branching

I want to decide between Early Branching & Lazy Branching

I am defining the policy for a large group of developer using a source code control system Clearcase from Rational, (Though, I prefer CVS more :-)). I have been familier with two strategies.

1. Early Branching.
Where each developer for his work, creates a branch from main line stream & works on that from the very start of the project itself. & the main line stream is never touched till the project is in the development stage. & the developers have to merge & do some unit testing at the end to go back & join the main stream. Note that This is different from creating branch for different tasks or releases.

2. lazy branching.

where each developer works on the main stream only & the developer has to update the dependant code using the SCM tools to get the latest checked in code written by other developers. In this case , You create branches only for major tasks or releases or when supporting the DRs.

From my point of view, lazy branching is more preferred since it requires less communication with fellow mates to get the latest copy .Also you come to know immediately if you brake the build by following daily build strategy .There is less effort required for merging the codebase.

But again, this is my understanding.

I want to decide which is preferred , Early Branching or Lazy Branching.

Can any one please post comments on this?, please correct me , if I am wrong or please suggest any other strategy if it is more useful.

My team size if 150 + & we will be mostly working on Unix machines. Chances of working on the same file is very less but chances of using dependant code is very high. So we need to ensure that, always we use the latest & the greatest code.

Please help me

Thanx in advance


Wednesday, February 20, 2002

I guess if you do early branching you won't be able to do real daily builds. Therefore you won't score much in JoelTest :-)

Roman Eremin
Wednesday, February 20, 2002

I agree. I don't really see how early branching would be useful except at the very beginnings of a project and at that point, I would argue that an SCM tool is just getting in the way. There's too much volitility at the very beginning of a project to really make effective long term use of code control without cluttering things down the road. However, if after you've got _something_ working you put it into source control and then do "lazy branching" then you can get a better feel for what's actually happening by using your SCM system.

Which is after all supposed to manage source code so you don't have to. Besides, having people more responsive to the main line helps with figuring out who broke what and how so that it can be avoided in the future.

Alex Russell
Wednesday, February 20, 2002

ClearCase has a "configuration spec" concept. There you specify what branches/labels you want to use. So either approach should work fine. However, the danger with the first one is that branches never get merged to the main line, and you'll see the ugly-ugly version trees with more branches than a rainforest! :)

Marat Zborovskiy
Wednesday, February 20, 2002

"I guess if you do early branching you won't be able to do real daily builds."

Nonsense.  Your check-ins and updates just become merges instead.  There is no reason you shouldn't stay just as sync'ed to the main line as you would with a main branch only.

And you get the advantage of allowing sync'ing of code across multiple platforms (or, say, home and work sandboxes) without disturbing the main line.  I think that is the main advantage of personal branches.

The danger is that people get in the habit of considering their personal branch the main branch, and then it gets increasingly difficult to integrate with the main line.

And this all depends on how painful merges are for your SCM system.  Some are much better than others.


Robert W. Anderson
Wednesday, February 20, 2002

A 'best' policy IMO is to do early branching ('never' alter the mainstream directly): it needs to be coded and built *and tested* before it's in the mainstream; QA can't happen if people are working with files checked-out from the mainstream: because, QA can't see the changed files until they are checked in, but the files shouldn't be checked in until after QA have seen them...

So instead, you: 1) Make a branch; 2) edit files; 3) check-in to the branch; 4) QA the branch; 5) merge branch to mainstream.

Combined with that, two more strategies: 1) 'snowball' or 'iterative' development, where you do several small projects instead of one big one... this gives you a greater number of opportunities for everyone to reach a milestone, merge to mainstream, and start again in new branches from the common mainstream; 2) even if my branch has a long lifespan, I can "resynch" it with the mainstream whenever I like... to do this: a) make branch A from mainstream; b) work in branch A for a while ... meanwhile, other people are updating the mainstream; c) make a new branch B from mainstream, and merge branch A into branch B (I haven't touched the mainstream, but now I work in branch B which contains my changes based on the current mainstream).

What I'm not sure about is: if I'm working in a branch, should my branch be based on some version of the mainstream (e.g. a label-based snapshot of the mainstream taken on the day when the branch was first created), or should it be based on the current mainstream whatever that is. In the latter case, work in my branch is disturbed if ever someone checks changes into the mainstream that are incompatible with changes that I've made in my branch... but the 'benefit' is that I become aware of this incompatible change to the mainstream as soon as it happens (instead of my not finding out until I try to merge/integrate my changes some time in the future).

Christopher Wells
Wednesday, February 20, 2002

*  Recent Topics

*  Fog Creek Home