Re: Use of CVS on large scales

[John Minnihan]

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 
to
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 
projects

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 
and

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 
as
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 
with

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 
they

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 
projects

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

- The extremely delicate nature of the VOB makes me shutter.  Virtually any 
event
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 
hours,

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

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 
of
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.