RE: Use of CVS on large scales

[Thornley, David]

> -----Original Message-----
> From: Bob Bowen [mailto:address@hidden
> Sent: Monday, June 11, 2001 8:20 PM
> To: John Minnihan
> Cc: address@hidden
> Subject: Re: Use of CVS on large scales
> 
> 
> John Minnihan wrote:
> > Do you have specific experience with CVS 'breaking down and 
> becoming unusable'?
> > If so, please share that experience here so others may 
> learn from it.
> 
> I think there are two obvious areas where CVS doesn't scale well:
> 
> 1) Working with branches - the interface is just too primitive and
> clumsy for large numbers of users to do the right thing. It's not too
> bad if you have just a few branches and a couple of people 
> that know how
> to use them, but even then it's tedious. 
> 
Yeah, but in a large project you can afford some administrative
work to automate this.  Given a consistent naming scheme, it's not
difficult to write a script that will do the merge.

Basically, it has to determine what branch the current file is checked
out on, what it was last merged to (maintaining, say, a BRANCH_1
and BRANCH_1_MERGED tag), and doing the merge and keeping the merge
tag up-to-date.

Figure out what you're going to do with branches and how you're
going to do it, and write scripts to do it.  I use Perl.

> I would say the biggest deficiency is having to keep track of what's
> already been merged, but it's also a pain to figure out what 
> has changed
> on a branch and making sure you've merged what's necessary without
> always having the entire repository checked out (time consuming in
> itself for large projects).
> 
I have several copies of a fairly large repository checked out right
now, and I keep them handy.  Disk space is fairly cheap nowadays, and
it's usually better to keep the repository checked out than to check
it out only when you need it.

As far as determining what has changed, this can be done with a little
process discipline.  Whenever creating a branch, create the branch tag
(BRANCH_1), a merge tag to keep track of what has been merged to wherever
you merge to (BRANCH_1_MERGED), and a start tag to record where the branch
started (BRANCH_1_START).

> 2) Building a unified development process on top of CVS; e.g. 
> enforcing
> conventions and policies which are inevitable as the size of 
> the project
> grows. The hooks again are too primitive and each script 
> shouldn't have
> to be called for every directory involved. The interfaces to the hooks
> are all different and not enough information is available, e.g. what
> branch is this on? I'm continually frustrated by the holes in the
> support for the checkin templates in the client/server methods as well
> as the lack of interactivity with the callout scripts.
>
This is a problem; it is not necessarily possible for the verify
scripts to enforce policies.  How necessary it is to enforce the
policies (as opposed to, say, detecting violations and talking to the
violator) is itself a matter of policy, and some projects may need
to enforce them.  In this case, I'd suggest some sort of approach where
checkin or tag approval is granted separately, in another sort of
system, and a simply verifymsg (for checkin) script checks that.
It's not ideal, but I don't have experience with anything that is.
That's what we're planning to do.
 
The standard answer is that CVS is intended for source code management,
not development process control.  It wouldn't be suited for development
process control, as all such tools I've seen tend to assume a certain
process, and CVS is intended as a generally useful tool.  The hooks
could indeed be improved, and there's been discussion of that in the past.
> 
> My sense is that CVS is adequate for small, fairly 
> independent projects
> (even large numbers of small, independent projects ala 
> sourceforge), but
> it's certainly not industrial strength. Unfortunately, nothing else is
> either, so most commercial efforts end up growing their own.
> 
It seems to work well on larger projects, although I have no experience
with it on really large projects.  Do you mean that most efforts grow
their own process on top of an existing SCM system like CVS?  It seems
to me that growing a SCM system is not a trivial thing, and that it
would be best to start with something like CVS and grow from there.

There are other available systems.  ClearCase is frequently mentioned
as superior to CVS in many ways.  The Subversion project at www.tigris.org
is designed as an improved CVS.  It will feature better branch and merge
handling, although I don't know anything offhand about its hooks.