Version control, or revision control, is the idea of keeping track of revisions of data (software, a file, just about anything) and tracking them (and the changes). Most packages allow you to rollback to a specific point, track changes, run diff between revisions, and add comments.
I currently use two systems - CVS and RCS. RCS is a lightweight system that runs locally and stores changes in a file, either in the current directory or in an RCS subdirectory. It is simple and easy to use, though somewhat limited. I still have most of my web site under RCS, but plan on migrating to CVS. My main use for RCS is for configuration and text files stored locally, so that I can track changes, add comments, and rollback to a previous version. CVS, on the other hand, runs as a server daemon. It is quite a bit more complex, but has features to manage large software projects. Its data is stored in a central repository and then checked in or out (to a local temporary "working" directory) via the cvs commands. It has the advantage of being able to be run over a network, so the code can stay on one central repository machine, while work is done on a development machine. It is also much easier to move code between boxen.
Basically, I would recommend CVS (or another of the more advanced systems) for any project being worked on by more than one person, and for any large software project. RCS is adequate for configuration file management and small projects (read: kludges). One other main advantage of CVS, as mentioned in this article on O'ReillyNet SysAdmin, is keeping administrative code consistent across a network.
Lightweight, easy to use, not too good for anything important or anything that's being worked on on multiple machines.
Great, server-based. Can be checked out from any remote machine with access, and even has a few web-based interfaces that are wonderfully easy to use.
Read about it at: CVS.
Subversion, or SVN, is a new version control system that was created with the intent of fixing the problems in CVS. Supposedly, it has done it well, though I have no direct experience with SVN. From what I've heard, I would highly recommend it, and plan on moving to it myself, eventually.
There are a few popular web-based interfaces to CVS and SVN. I personally use ViewVC, which is run as a CGI script and is extremely simple to configure. There is also Bonsai, started by the Mozilla project, which is a pretty heavy-weight web interface to CVS intended for large projects. It uses Perl and a MySQL backend.
There are a few notes that I have about ViewVC. Overall, however, it is extremely easy to install and get running.
- ViewVC accesses the repository directly. As a result, you must have repository access on the machine (web server) that ViewVC is running on. I just mounted my repository directory via NFS. ViewVC runs as a cgi script, so you need a web server (Apache) already running.
- ViewVC has no access control mechanism, nor does CVS. As a result, when using ViewVC, anyone who can see the web page can browse, download, and view files in the entire CVS repository. While I initially loved this, as I used CVS only for GPL'd projects and snippets of useful code, after a while I decided to put some admin scripts in CVS. Most of them aren't really sensitive, but provide a bit more of a look at the workings of my systems than I had hoped. I tried unsuccessfully to implement Apache Auth on the URL. After sitting around for a while, I hit upon a wonderfully simply (yes, inelegent) solution. Being that ViewVC runs as a CGI script, it runs as the user and group of the webserver - in my case, user 'www' and group 'wwwrun'. How to protect one directory in the repository from being viewed with viewvc? Well, the CVS user 'cvsuser' runs as a member of group 'users'. My main username, 'jantman', owns all of the files in the repo. Simply chown the directory you want to access-protect to 'username:users' and chmod it so only user and group have permissions - nothing for other. When you try and view it under ViewVC, you get a read error, since neither 'www' nor 'wwwrun' have permissions to read.