Re: Is CVS usable for big companies/projects (HELP!!!)

[Kaz Kylheku]

On Wed, 9 Oct 2002, Ralph Jocham wrote:

> Date: Wed, 9 Oct 2002 16:49:07 -0700 (PDT)
> From: Ralph Jocham <address@hidden>
> To: address@hidden
> Subject: [info-cvs] Is CVS usable for big companies/projects (HELP!!!)
> 
> Hi All,
> I am trying to convince upper level management that
> CVS is a good
> choice as a version control system. Their main contra
> argument is that
> it does not scale.

My argument would be that CVS is used by open source projects which
provide mass *public* access to their repositories.  That is one
situation in which you need scalability; lots of customers coming in
over the network to access your database.

For in-house use, if scalability becomes an issue, it means you are
doing something wrong, and your software project probably has bigger
issues to worry about. Why do you need to worry about scalability?
Probably because there are too many developers who put too much stuff
into one single repository, and it has turned into a behemoth.

Huge software needs to be divided into chunks to be manageable.  Each
chunk can have its own independent version control managed by the team
responsible for that chunk, and that team can use its own repository.

Look at the way a GNU/Linux distribution is put together. Someone
working on a mail application does not put the kernel and glibc into
his repository, and does not share the same repository with someone
else working on an X window manager or compiler. These things are
independently versioned, and their customers see only a high level,
relevant view of the CM process: some version number for the entire
component, having three integers separated by dots. In the end, you can
say that the system is made up of these versions; you don't have to
have some big repository in which you apply a single symbolic tag over
every single piece of source code that goes into the OS distribution.

So it's just not *useful* to be able to put a million source files into
the same repository, and then worry whether a change to one of them
breaks any of the 999,999 others. That's not going to scale no matter
what, because the development tools and methods themselves won't scale
to that. So it's completely irrelevant whether a version control system
can handle it and how fast. What's relevant is whether it has the
semantics so that you can practice useful CM on a component level.
You want to work on your piece of the puzzle, and have stable, known
versions of the other pieces you need to make your stuff run. Moreover,
your stuff might have to run with several different versions of the
other pieces; so it would be useless to be in the same repository and
symbolically tag your stuff together with the other stuff.

Imagine if, say, Mozilla and the GNU C Library shared the same
repository.  What good would that do? Okay, so you could apply a
release tag to both of them at the same time. Great, so now all the
users will have to upgrade their glibc together with their browser,
because you only cared about developing them in combination, and have
just one single combined configuration that works.  But hey, your
version control system *scaled* up to it, like the manager wanted after
listening to the salesman from the proprietary version control company.

That being said, some people claim to have good results for over a
gigabyte sized CVS repositories.  In my experience, CVS works okay for
repositories that are at least a few hundred megabytes, under one
big tree that is checked out by everyone.

-- 
Meta-CVS: directory structure versioning; versioned symbolic links;
versioned execute permission; versioned property lists; easy branching
and merging and third party code tracking; all implemented over the
standard CVS command line client -- http://freshmeat.net/projects/mcvs