18.1. Introduction

What is the point of using a version control system? A version control system is an efficient way to track changes in documents and to preserve a complete history of a project. It's like having a time machine; months later, you can easily roll back to an earlier system configuration, or code block, or manuscript version.

Version control systems are useful for all sorts of things: source code, binary files, configuration files, scripts, articles and books, songs, inventories, indexes any kind of text document. You can keep your shopping lists in a version control repository, if you like. Because a version control repository keeps track of every change ever made, you can easily go back to any point in the lifetime of a particular project. And the version control system does the work you don't have to depend on users to create and store copies of the different versions of documents. This is quite handy when you want to retrieve that brilliant code you wrote months ago, or that perfect configuration file, or that astonishingly fine arugula recipe.

Version control systems allow teams of users to work on a single project in a controlled manner. For example, you can break up a project into separate branches, which can later be merged. You can also merge different versions of files, though you need to be aware that the software doesn't know what the files mean and cannot intelligently resolve conflicts it only knows how files differ, so merging files sometimes requires some human intervention to be managed correctly.

There are whole lot of free/open source version control programs out there. Here are the more popular ones:

• RCS (Revision Control System)

• CVS (Concurrent Versions System)

• Subversion

• GNU Arch

• Monotone

Commercial products include:

• BitKeeper

• Visual SourceSafe

• OpenCM

• CMSynergy

• Perforce

• ClearCase

RCS and CVS are the oldest and most widely used. They are fairly simple to set up and use, and they have been around long enough to be thoroughly torture-tested.

Subversion, GNU Arch, and Monotone all offer features not present in CVS: you can set up distributed repositories, as opposed to the central-server model of CVS, and they support atomic commits. With an atomic commit, changes happen all at once. When a user commits a change to the repository, the whole change is applied, and it is visible to other users only once completed. CVS applies changes a file at a time, so if a network outage interrupts the commit, the changes will be only partially applied.

While this feature is quite cool and useful, Subversion, GNU Arch, and Monotone are still somewhat immature. GNU Arch and Subversion are difficult to install and configure and not that easy to learn to use. Monotone has an interestingly different architecture one major difference is it transfers files via an embedded network protocol, netsync, rather than using HTTP, NNTP, or SMTP. This eliminates a lot of gnarly setup steps and means that every installation of Monotone is ready to function either as a client or a server.

A forward-thinking person might set up some of these on some test machines, keep an eye on their development, and get the hang of using them, because these are the version control systems of the future.

BitKeeper is one of the more popular commercial products. Linux kernel development is done on BitKeeper. You can test-drive BitKeeper for free; its makers offer both a free 30-day evaluation and a somewhat dumbed-down free-of-cost version for personal use.

Although there are numerous alternatives, this chapter concentrates on RCS and CVS, the most mature and widely used version control systems. RCS is the backend to CVS, so it's easy to learn both of them. RCS is perfect for a single user with simple needs; CVS is good both for a single user, and to support teams of users working on complex projects.

Essential CVS (O'Reilly), by Jennifer Vesperman is an excellent CVS howto and command reference. If you have the budget for only one CVS book, this is the one you should buy.