On Wed, 9 Oct 2002, Ralph Jocham wrote: > Date: Wed, 9 Oct 2002 16:49:07 -0700 (PDT) > From: Ralph Jocham <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > 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 _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
