info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Multiple streams of development? A feasible branching approach?


From: Tony Byrne
Subject: Re: Multiple streams of development? A feasible branching approach?
Date: Fri, 08 Dec 2000 17:15:05 +0000

On Fri, 8 Dec 2000 10:03:21 -0600, you wrote:

>Would anyone care to comment on whether the following branching scheme
>will work:
>
>The trunk would be used for building the current stable release and
>doing relatively simple bug fixes. Call this release X. We would create
>a branch for release X+1 off of the trunk. Bugfixes would be merged
>perioically from X to X+1. When code for X+2 is ready to be checked in,
>we would branch off of X+1. Periodically, bug fixes (originating on the
>trunk) and new code would be merged from X+1 to X+2. If a new concurrent
>release starts up, X+3, we would branch off of X+2 and merge perioically
>from it to X+3. And, heaven help us, so on. So far, notice that merging
>is always from a lower to the next higher release. 

The following document may help...

http://www.enteract.com/~bradapp/acme/branching/

It isn't CVS specific but there are a number of suggested good and bad
branching schemes and it may give you some ideas for a suitable
branching scheme for your project.  

The problem that I see with your approach is that there is no closure to
your branches and each branch is a branch of a branched branch and so
on.  They could get out of control.  I think it is an instance of this
branching pattern:

http://www.enteract.com/~bradapp/acme/branching/branch-structs.html#ParallelRelDev

I prefer not to branch for the most evolved code, preferring instead to
reserve the trunk for the most 'evolved' and current code.  I tend to
branch from the trunk during the latter stages of Engineering a specific
release to provide a space for the stabilization of the codebase before
release.  Once a release has been made from one of these Release
Engineering branches, the branch then dies for active development.  Only
commits for bugfixes are allowed to these branches after release.  Any
bugfixes are then merged into the trunk, unless the problem has
previously been fixed in the current code.  This is the suggested
solution to the main problem of the Parallel Release branching pattern.

This model forces people to merge changes at the appropriate times and
everyone knows that the trunk is where the most evolved code should go.
Without this focus the release branches could bifurcate out of control.

Is there somewhere where the more general issues surrounding branching
and patterns are discussed? 

Hope this helps...

Regards,

Tony.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]