[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
news:address@hidden
>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