Use of CVS

[Giorgos Keramidas]

On 2007-01-11 11:35, Doug Hardie <bc979 at lafn.org> wrote:
> I have a medium sized application where the source is all in a CVS
> repository.  Basically it works great as I am able to retrieve any
> previous version of a module when needed.  Most of the changes to the
> application are quickly resolved, CVS committed and the production
> system updated in less than a day.  Recently, I made a fairly large
> update to the application that took about 4 weeks to complete.  During
> that time I was not able to fix small problems as there was no way to
> update the production system without incorporating a large number of
> changes from the new update that were just not working yet.  Basically
> all small corrections were made to the new system but not incorporated
> into the production system until the new stuff was completed.  There
> were no real problems from this, but it was not really convenient.
>
> Now I am going to be embarking on a revision that will take about 6
> months to complete.  Obviously I will not be able to wait till the
> completion to fix minor problems.  So I am going to need to do
> something with branches.  I have dug through the man pages and believe
> that is the best approach.

Indeed.  Branching and inter-branch merges can be a huge pain in the
ass with CVS though.  It may be worth investigating if one of the more
modern SCM systems -- with better support for merges and merge
tracking -- can help you keep the two 'branches' in sync.

If you plan to heavily use branches, my personal preference would be
Mercurial[1].  It takes a short while to get acquainted with a
_distributed_ SCM, if you have been using CVS for a long time, but IMHO
the benefits of offline development and excellent merging support
(including merge-history tracking, rename tracking, and a few other
goodies), far outweighs the cost of migration.

[1] http://www.selenic.com/mercurial/

> However, given that I need to maintain the current version with a
> probably small number of fixes during the development process what
> is the best approach?  Should I branch off the production version as
> a new branch and keep the main one for the new development or the
> other way around.

There are two 'models' of work you can use with CVS:

    * The mainline model.

    * The promotion model.

In the "mainline" model, all development happens in the "HEAD" branch
of CVS, and when you are about to release a production version you
spin off a 'release branch' off the main trunk of development.

In the "feature branch" model, you branch early, and develop features
*within* a feature branch.  Some time later, these features branches get
'promoted' from feature branch, to testing branch, and eventually to
release branch.

Which model you will use depends on a lot of factors, not the least of
which is how often you will be developing many features in parallel, how
long you will have to maintain 'release branches' after you have shipped
from them, etc.

> Will it be easier to merge the fixes to the production branch back in
> to the new system later or should those fixes be made to both branches
> at the same time?  Any suggestions on these approaches will be
> appreciated.

In general, with CVS it's a lot easier to use the "mainline" model,
where all development happens in HEAD.

This doesn't mean that you cannot or that you should not evne consider
the "promotion" model of feature branches though.

- Giorgos