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"

Relevant Pages

  • RE: Procedural Issues
    ... Our core development is largely on ASP/ or D2K though I don't think it matters when it comes to choosing a CVS repository server. ... 2.The ability to introduce security or financial reporting holes into production with unauthorized code changes. ... I have heard auditors argue that a lack of segregation of duties presents an "unbounded risk" or one that cannot be adequtely measured. ... Detect Malicious Web Content and Exploits in Real-Time. ...
  • RE: [PHP] Re: An appeal to your better nature
    ... good IT professionals work on dev servers and migrate to test, ... I use CVS all the way from dev to production with staging in between ...
  • Re: Generic Development/Production Question
    ... +1 for CVS, or better yet, Subversion. ... If you need to change production code, ... We can't roll out our development code as ... the local folder, rebuild and pray that paths don't cross. ...
  • Re: something suddenly went wrong with my project ?
    ... There is something wrong with my J2EE project sources (the production ... server is fine). ... Did you try rolling back via CVS to your code a month ago, and seeing if that still works? ...