[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Use of CVS on large scales

From: John Minnihan
Subject: Re: Use of CVS on large scales
Date: Fri, 08 Jun 2001 09:30:16 -0700

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.

'Developing at the same time' is a misnomer in this context.

CVS' transitory file locking (the # files that get left hanging around after a
transient network blip) occurs during commit only (right Larry or Derek?), and
thus would be a factor if and only if all developers were attempting to commit 
the same file at the same time.

In practice, this isn't going to occur on large projects.  In fact, as projects
grow, the likelihood of [read this as Risk of] commit time contention decreases.
This is due to the naturally-occuring segmentation of work that occurs as 

scale up.  If multiple developers are committing against the same file(s) -
especially at the same time - the project is operating in a communication void 

is doomed for reasons that have nothing to do with version control.

I argue that CVS scales very well.  I have yet to see or hear concrete evidence
that contradicts this.  My personal experience with CVS shows that it performs 
expected up to 70 developers.  I have yet to encounter a project that was larger
[in number of developers].  In contrast, I have seen Clearcase perform poorly 

as few as three developers.  Why is this?

- CC's system overhead [mvfs, view server process, vob server comm] makes
otherwise trivial operations time consuming.   This frustrates developers and 

then try to circumvent the system.

- The concept of views is poorly understood.  It is confusing and misleading to
NOT see changes that have been committed to the repository as soon as they are
committed (or when you do an update).  This particular 'feature' has cost 

untold man hours in lost productivity.  Your version control system should 
you to make better decisions, not force you to behave in unnatural ways to 
accurate information.

- The extremely delicate nature of the VOB makes me shutter.  Virtually any 
outside my control - network transients, power spikes, dips, or loss, disk drive
latency - could damage the VOB's structure during a write operation.  You then
have to manually weave together a restore of the VOB (and maybe views, if they
were stored on the VOB server) etc. etc. etc.  This process takes hours and 

and maybe days.  I have specific experience with exactly this nightmare - twice 

six years.  Losing a VOB is a reality.  That's why the cottage industry of CC
administration has developed.  As a manager, you want your crack team of hired
guns ready to deal with this when it happens.

These are the main reasons I recommend against CC.  Please notice I mentioned
nothing about the cost of CC here - these are real, non-FUD product oriented
reasons that exist whether CC costs $4000 per seat or were given away in a bag 
Crunky Pop-joy.

address@hidden wrote:

> What's large scale for your team?
> Go with Clearcase if you have 100+ developers.
> CVS starts to break down( ie become unuseable ) with
> over a 100 developers actively developing at a single time.
> This is related to how cvs does file locking inside of
> the repository when people commit/update/checkout in the
> repository.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]