Re: Use of CVS

On 2007-01-11 11:35, Doug Hardie <bc979@xxxxxxxx> 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.


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

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

freebsd-questions@xxxxxxxxxxx mailing list
To unsubscribe, send any mail to "freebsd-questions-unsubscribe@xxxxxxxxxxx"