Historically, three VCSs have been of major significance in the
Unix world, and we'll survey them here. For an extended introduction
and tutorial, consult Applying RCS and SCCS [Bolinger-Bronson].
Source Code Control System (SCCS)
The first was SCCS, the original
Source Code Control System developed by Bell Labs around 1980 and
featured in System III Unix. SCCS
seems to have been the first serious attempt at a unified source-code
management system; concepts that it pioneered are still found at some
level in all later ones, including commercial Unix and Windows
products such as ClearCase.
SCCS itself is, however, now
obsolete; it was proprietary Bell Labs software. Superior open-source
alternatives have since been developed, and most of the Unix world has
converted to those. SCCS is still in use to
manage old projects at some commercial vendors, but can no longer be
recommended for new projects.
No complete open-source implementation of
SCCS exists. A clone called CSSC
(Compatibly Stupid Source Control) is in development under the
sponsorship of the FSF.
Revision Control System (RCS)
The superior open-source alternatives began with RCS (Revision
Control System), born at Purdue University a few years after
SCCS and originally distributed with 4.3BSD
Unix. It is
logically similar to SCCS but has a cleaner
command interface, and good facilities for grouping together entire
project releases under symbolic names.
RCS is currently the most widely
used version control system in the Unix world. Some other Unix
version-control systems use it as a back end or underlayer. It is well
suited for single-developer or small-group projects hosted at a single
developmentshop.
The RCS sources are maintained and
distributed by the FSF. Free ports are available for
Microsoft operating systems and VAX VMS.
Concurrent Version System (CVS)
CVS (Concurrent Version System) began life as a front end to
RCS developed in the early 1990s, but the
model of version control it uses was different enough that it
immediately qualified as a new design. Modern implementations don't
rely on RCS.
Unlike RCS and
SCCS, CVS
doesn't exclusively lock files when they're checked out. Instead, it
tries to reconcile nonconflicting changes mechanically when they're
checked back in, and requests human help on conflicts. The design
works because patch conflicts are much less common than one might
intuitively think.
The interface of CVS is significantly
more complex than that of RCS, and it needs
a lot more disk space. These properties make it a poor choice for small
projects. On the other hand, CVS is well
suited to large multideveloper efforts distributed across several
development sites connected by the
Internet. CVS tools on a client machine can
easily be told to direct their operations to a repository located on a
different host.
The open-source community makes heavy use of
CVS for projects such as GNOME and
Mozilla. Typically, such CVS repositories
allow anyone to check out sources remotely. Anyone can, therefore,
make a local copy of a project, modify it, and mail change patches to
the project maintainers. Actual write access to the repository is more
limited and has to be explicitly granted by the project maintainers. A
developer who has such access can perform a commit option from his
modified local copy, which will cause the local changes to get made
directly to the remote repository.
You can see an example of a well-run
CVS repository, accessible over the
Internet, at the GNOME CVS
site. This site illustrates the use of
CVS-aware browsing tools such as Bonsai,
which are useful in helping a large and decentralized group of
developers coordinate their work.
The social machinery and philosophy accompanying the use of
CVS is as important as the details of the
tools. The assumption is that projects
will
be
open and decentralized, with code subject to peer review and
inspection even by developers who are not officially members of the
project group.
Just as importantly, CVS's
nonlocking philosophy means that projects can't be blocked by a lock
if a programmer disappears in the middle of making some changes.
CVS thus allows developers to avoid the
“single person point of failure” problem; in turn, this
means that project boundaries can be fluid, casual contributions are
relatively easy, and projects are not required to have an elaborate
hierarchy of control.
The CVS sources are maintained and
distributed by the FSF.
CVS has significant problems. Some
are merely implementation bugs, but one basic problem is that your
project's file namespace is not versioned in the same way changes to
files themselves are. Thus, CVS is easily
confused by file renamings, deletions, and additions. Also,
CVS records changes on a per-file basis,
rather than as
sets
of changes made to files. This
makes it harder to back out to specific versions, and harder to handle
partial check-ins. Fortunately, none of these problems are intrinsic
to the nonlocking style, and they have been successfully addressed by
newer version-control systems.
Other Version-Control Systems
CVS's design problems are sufficient
to have created demand for a better open-source VCS. Several such
efforts are under way as of 2003. The most notable of these are
Aegis and
Subversion.
Aegis
has the longest history of any of these alternatives, has hosted
its own development since 1991, and is a mature production system.
It features a heavy emphasis on regression-testing and
validation.
Subversion is
positioned as “CVS done right”, with the known design
problems fully addressed, and in 2003 probably has the best
near-term prospect of replacing CVS.
The BitKeeper project
explores some interesting design ideas related to change-sets and
multiple distributed code repositories. Linus Torvalds uses Bitkeeper
for the Linux kernel sources. Its non-open-source license
is, however, controversial, and has significantly retarded the
acceptance of the product.
