[Top][All Lists]

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

Re: beginner's question on use

From: Dennis Jones
Subject: Re: beginner's question on use
Date: Thu, 21 Jun 2007 20:40:24 GMT

"NeoAlchemy" <address@hidden> wrote in message 
>I am not sure if this is the totally right place for the question, so
> please redirect me if so.
> I am using CVS at work.  The way it is being used bothers me.  We
> create a branch 'a' for development.  If a new release is needed to be
> made we make a branch 'b'.  If we are still having changes go on for
> branch 'a' we post the changes to branch 'a' and branch 'b'.  The
> cycle continues where we make make another branch, branch 'c' for
> development off of branch 'b'.  This doesn't seem like a responsible
> way to use CVS.  No one else on the team knows any better.  What would
> be the appropriate way to handle a sequential release cycle?

Business requirements usually dictate how CVS is used.  My personal prefence 
is to have normal, on-going development occur on the main trunk.  This 
includes new features, enhancement, etc., and then I create a branch when it 
is time for a release.  Some people suggest branching before the release, 
and others suggest waiting until afterward.  The difference between the two 
depends on whether or not new development should be allowed to continue 
while a release is pending.  Personally, I usually wait to branch until the 
release happens, or just shortly before (to allow time for fixes).

So, for example, let's say you are working on a product, adding new 
features, enhancements, etc.  This work would occur on the main trunk.  Then 
your company annouces that all the work you've been doing is going to be 
released soon.  You can:

A) Freeze all *new* development on the main trunk and only allow feature 
completion and bug fixes to occur until the release happens, at which time 
you create a branch.  At that point, new development can resume on the main 
trunk.  If bugs are detected on the release, you can apply fixes to the 
branch and rebuild the branch code to get a new release.  Then merge those 
fixes into the main trunk so that the next time you branch, the fixes will 
already be there.

B) Branch immediately.  In this case, new development (any new features and 
enhancements) can continue on the main trunk immediately.  For some 
businesses, this may be essential, as they may have separate teams for 
future development and current (or pending) releases, and wouldn't want to 
stop future development while a release is being finished up.  Work on the 
branch is then limited to the completion of features that were already 
scheduled for that release, unless otherwise approved (by someone like a 
project manager).  When the release happens, merge everything from the 
branch back into the main trunk.

There are probably lots of other ways to handle branching, but I think these 
two are the most common.

- Dennis 

reply via email to

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