Why put a set of files into CVS?

So, why would you want to use CVS for a given project or set of files? Well, there are a number of different reasons.

One is so that information is never lost. Just because you change something doesn't mean you'll never again want to know what it was like before it was changed, but keeping lots of old versions around just in case is ugly and potentially confusing. CVS takes care of all that for you. It will squirrel all those old versions away in its repository, stored in a fairly succinct and standard file structure, and can get back anything you end up needing later as well as give you reports on what's changed and why. So if you write some code in version 1.4, decide it was a mistake and take it out in version 1.7, and then in the process of writing version 1.34 decide you really want that code again, you can just go grab the older version out of CVS.

A side benefit of this is that not only do you not have to keep tons of old copies of things around, you also don't have to keep large blocks of commented-out code around just in case you need to use it again later. CVS can keep it for you. (But of course you still can, if you want to.)

CVS also will keep track of who made a change, without having to always note that information in the file itself. That means that if you don't expect people to normally care who made a change, but just want to keep that information somewhere, you can relax and let CVS take care of it.

The CVS repository stores all of the log messages that people entered when they changed things, as well as the exact dates and times when the changes were committed, so CVS can also give you a very accurate revision history. Often knowing why something was changed a couple years later is quite valuable, but putting that in parenthetical notes, comments, and the like gets tedious, is hard to keep current, and can make the file hard to read. CVS stores that information "out of band" for you.

CVS can produce nice reports for you showing things like the last time each line in a file changed, the differences between any two versions of a file, and the differences between your current copy and the last committed copy. Once you get used to having that information available, it makes it much easier to keep track of what's changing and why.

Our CVS setup will also send out notifications whenever changes are committed, at least to leland.cvs-commits and to other addresses as well if it's configured to do so. This means that by putting files under CVS you automatically get the benefit of a notification system. If there are a group of people all working on the same files, the CVS commit notices will tell them what other people are changing and why, and it helps a team of people working together to feel more on top of how a project as a whole is going. And CVS will make sure you don't forget to notify people when you change something (provided you remember to use CVS).

The CVS repository is in AFS, and therefore is backed up, always available, and survives machine rebuilds. This means that one way of managing a bunch of machine configuration, particularly if it's all in a single directory or can be made to be, is to put it into CVS. Then, after rebuilding the machine, a simple "cvs checkout" restores all of the configuration exactly as it was before.

Finally, this sounds strange, but CVS can make you feel more productive. I've had independent confirmation of this from a few different people. Once you get used to working with CVS, you start thinking in terms of commits and revisions, and CVS gives you a framework to finish off a change and call it "done" by committing it and feel like you've accomplished something solid. It helps in breaking up a large project into a set of reachable goals. This is particularly true if you subscribe (as I do) to the philosophy of committing changes early and often.