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:
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.
| 
