[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Use of CVS on large scales
Re: Use of CVS on large scales
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
- 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
> 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
Re: Use of CVS on large scales, Greg A. Woods, 2001/06/08
- Use of CVS on large scales, Lucas Chan, 2001/06/07
- Re: Use of CVS on large scales, John Minnihan, 2001/06/07
- Re: Use of CVS on large scales, Mike Castle, 2001/06/07
- Re: Use of CVS on large scales, Jim Ray, 2001/06/08
- Re: Use of CVS on large scales, Donald Sharp, 2001/06/08
- Re: Use of CVS on large scales, Bob Bowen, 2001/06/11
- Re: Use of CVS on large scales, Greg A. Woods, 2001/06/12