Re: Use of CVS on large scales

[Ralph Mack]

[Quoth Donald Sharp...]
> 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.

If you deploy all of your source control for a large project through
one repository, your concerns may be true, but there is an alternative
when this becomes a problem: Put major divisions of the projects in
different repositories to distribute the load. Even ClearCase uses
multiple vobs on multiple servers, but ClearCase doesn't require the
users to know what server their vob is on. They do have to know what
vob they are using, though, when creating branches and labels.

> Another good advantage of Clearcase is the multisite capabilities.
> If you have developers working at a large number of remote
> sites, you might want to think seriously about this.

Here I might suggest that the first strategy should be to serve
repositories closest to the majority of people that are using them.
If a few people have to snarf sources over a distance, it generally
isn't a major problem. FWIW, you run into these issues with ClearCase
multisite as well. It isn't as seamless a distributed VOB as one would
hope - the term "VOB mastership" may ring a bell with some.

> Especially if they are connected at a relatively slow ethernet speeds
> or their connection can be unreliable

The source pool for even a large body of code is surprisingly small.
Development-time binaries like icons and bitmaps likewise tend to be small.
What gets big are the binaries built from these little bits and pieces.
Solution - don't store derivative files under source control. In extremis,
tarballs of nightly builds on appropriate platforms can save a lot of time
once the interfaces between components are relatively stable. But don't
store these under source control - put them in a directory somewhere.

Ralph A. Mack