RE: Branch & Merge strategies

[Keith Beattie]

> -----Original Message-----
> From: Kenn Humborg [mailto:address@hidden
> Sent: Monday, January 08, 2001 2:38 PM
> 
> Linux doesn't use CVS.  Linus/Alan/DaveM/et al act as human 
> CVS servers :-)

yea, I'd heard that too. :/  So when they refer to the dev and stable
branches these are just "virtual" branches and they just use patch to
maintain their "repository", never really merging just patching one into one
or both places?  And when a release happens they just make a copy of dev,
call it stable and archive the old stable?

> 
> > Anyone have some references or willing to explain how a 
> specific (open or
> > closed source) project solves this problem?
> 
> Take a look at http://www.mozilla.org/roadmap.html.

Yea this looks pretty straightforward too, but it appears that their point
release branches don't overlap.  I think I need to explain my situation a
little more...

We have quite frequent releases (updating a Web application), about every 6
weeks.  Dev time is longer such that we have a development pipeline that is
at least 3 releases deep at any given point in time.  Currently I create a
release branch for each of these releases and preserve the Trunk for merges
from certified or very stable code (so another release branch can safely be
created).   Additionally I create project branches (from the Trunk ideally)
to land to their release vehicle.  Things get really complicated when
successive releases depend on each other not to mention projects which span
multiple releases.

I'm just looking for examples of how other projects deal with this problem
of release cycles being shorter that dev time and the overlap that that
causes in the source tree.  One consideration is to create three permanent
branches: Alpha, Beta and Live and have the releases move through these
branches (via merges) rather than having release branches start and die.
Though I'm not convinced that that will make things much easier...

Thanks again,
Keith