If you are setting up a new cvs server, spend a few extra minutes to configure CVS using the client-server ("pserver") mode, instead of the older file system mode. This will save you pain later and may keep you out of hot water. Pain, because moving the repository (your old one dies, your company IPO's and your boss wants to buy a big fancy server farm, you want to hide the repository behind a firewall) is matter of changing an environment variable. You get immedieate access control (developers can be protected from updating the production environment). CVS in file system mode can "hang" because it leaves a lock file around for each file and directory. Then you need a cvs guru to dive in and fix it. One note: you can't live in a mixed environment. It is either one mode or the other.
An expert tip on using client server: CVS uses gzip for compressing data across the network. The default setting is -z3 which is a pitiful waste of time. Recompile CVS to use -z9 by default (the network is the bottleneck, not CPU resources), or add it to everyone's .cvsrc configuration file (it lives in the users' home directory).
I've had some extremely painful experiences with CVS and large binary files. (Large is +32Mb) When CVS checks a file out of the repository, even if it is doing nothing more than a straight copy (no diff'ing, merging, etc.) the program brings the whole file into contiguous memory. This bloats the CVS process resident set size to at least the size of the file, +6Mb for the program, give or take. The process is inefficient, so subsequent large files don't reusue the space well. CVS bloats even more. Make sure that your server is configured with a lot of swap space (it should have a lot of memory anyway). Even so, performance will drag down into the ground until CVS is finished (could be 30 minutes for a large working set), then things will "mysteriously" return to normal.
-- Ken Mayer, July 23, 1999
Your proposed once per day automatic check-in of everything is a nice idea for a group such as your ArsDigita companay with it's fairly non standard mission statement.In more mundane companies however you usually have at least one mid-lewel manager who will see the amount of code checked-in every day as a measurement of individual emplye efficiency, and wrech all sorts of havoc with this misguided "knowledge".
I'm sure some of you have expierenced mid-level managers who were too dump to even figure out how to do this, but I have never been that unlucky ;-)Apart from this your proposed method sounds remarkely similar to what I have been doing for various db backed websites over the last few years. It has proven itself to me to be a great time saver and I don't even want to calculate how many near disasters with their associated all night fix-up sessions it has saved me or my co-workers from.
The pserver is surely the only way to share CVS among a group of people without running into all sorts of non-interesting problems with nfs etc. You can also tunnel it through ssh for secure over-the-net operations.
-- Kristian Elof Sxrensen, July 24, 1999
Regarding putting the stuff in /parameters - the .ini files - under CVS, and requiring different .ini files for your three servers: this is a darn good reason to use Tcl configuration files in AOLserver 3.0 instead of .ini files. Then config file can use Tcl to determine whether it's a production, dev, or staging server (based on an environment variable, or the server home, etc.), and use the appropriate config values.
-- Rob Mayoff, February 26, 2000
Although my company does not use CVS, we have used Microsoft's Visual Source Safe and Intersolv's PVCS Version Manager. Both were a pain to setup and have people use them. All complains usually go away after the first time that version control saves your day after some screwup.As for the managers, they usually don't care. Obviously some misguided soul is going to use this tool to gather information on who worked on what and for how long, but around the office 99% of the people are interested in it because it saves us from many headaches.
I don't think I ever want to work on a project without some kind of version control.
-- Pedro Vera-Perez, March 14, 2000
When dealing with large teams of developers using CVS can be a real headache. One alternative would be BitKeeper which solves most (if not all) CVS's problems. It was written by the guys that did SUN's TeamWare's source management system.
-- Petru Paler, April 18, 2000
I know the above is 7 years old, and version control has been gaining acceptance all the time, so what I want to add may already be obvious to most readers.First, everything I do that is worth saving is under version control, either in CVS, or (preferably) in Subversion, which is short for "CVS with the glaring problems fixed". A version control server is best regarded as part of the regular IT infrastructure, like a file server, a webserver or a mail server. The university department where I work (Math & CS) maintains a Subversion server for all employees to use; it's very popular and works very well. Used mainly for source code, websites, and scientific papers.
Second, version control can be thought of as a tool for collaboration, but I use it more for structuring my own work. I commit my changes into version control whenever they represent some meaningful unit of change: not sooner, not later. So my commits usually correspond to specific tasks, with specific objectives that the changes were designed to achieve, and specific results - objectives met, objectives failed, new issues found. To get a task-oriented overview of the work I did on a project in the past year, I just read back the log of messages I typed with each commit. To refresh my memory on why a particular change was made, I look it up in version control and read the accompanying commit message.
It also works the other way: I can set objectives and start making the necessary changes until I have acceptable results, knowing that if half way through things turn out uglier than expected, I'll just revert to the last committed version and start over, or postpone the objective in question.
So version control really helps me structure my work. It structures my work into transactions. This benefit is lost with automated commits. The one conceptual hurdle to learning how to work with CVS or Subversion is that users must learn to think of all their edits as being parts of transactions that need to be explicitly committed or rolled back. Once they learn this it can be a big asset.
-- Reinier Post, June 17, 2006