Oct 00 Online
Volume Number: 16
Issue Number: 10
Column Tag: MacTech Online
CVS: Version Control is Your Friend
by Jeff Clites < online@mactech.com>
CVS, the Concurrent Versions System, is the standard in version control systems in
the Unix world. Traditional Mac users may not have used CVS before, and in fact may
not have used any version control system, but it can save you numerous headaches
during your development projects, and with the arrival of Mac OS X there is no longer
any excuse-CVS is free and may even come preinstalled with your developer tools.
So what is a version control system? In short, it allows you to manage and track
changes to the files of a project. From an operational standpoint, most systems
(including CVS) are based on a central repository which contains all of the files of
your project, and individual developers "check out" copies of these files, make changes
to their local copies, and then "check in" their changes to the central repository. In the
process, the system does three basic things for you: it helps coordinate a team of
developers working on the same project (so that programmers don't interfere with
other programmers working on the same files); it tracks what changes were made to
what file, when they were made, why they were made, and who made them (this helps
you identify the cause of a newly introduced bug and helps enforce developer
accountability); and it allows you to revert to a version of your project that existed at
some previous point in time (this allows you to test compatibility with previous
versions or to undo destabilizing changes). Version control isn't a magic bullet or a
substitute for communication between developers, but it does go a long way toward
preventing common (and annoying) problems. Version control is a must when multiple
developers are involved in a project, but even a single developer working alone will
benefit.
The main advantage that CVS has over most if its competitors is that it uses optimistic
locking rather than pessimistic locking for checked-out file. With pessimistic
locking, only one developer can check out and modify a given file at one time, in order
to prevent two users from stepping on each others changes in the same file. This
sounds like a good idea on the surface, but in practice it can become a major
impediment if users keep files checked out for long periods of time, as they would
naturally do when editing them, or as they may accidentally do if they forget to check
them backing in before leaving for lunch, for the day, or for vacation. Ultimately,
users will resort to circumventing the system to obtain a copy of a "locked" file so that
they can get some work done, and they'll have to manually reconcile their changes with
the user who originally checked out the file. CVS takes a completely different
approach-it doesn't lock access to files at all. Multiple users are free to check out and
work on the same files at the same time, and the system takes care of merging changes
together as users commit their modifications back into the central repository. The
majority of the time, users don't actually end up editing the same files at the same
time (even though they may have checked them out, for instance to look them over for
needed changes), and even when they do CVS is able to merge these changes together
automatically. In the rare case in which two users have both modified the same line of
code between check-ins, CVS notifies the user of a conflict so that he can resolve it
manually. This sound like it could cause a mess, but in practice it usually does just
what you would have wanted, and it only makes you spend your time resolving the rare
conflict when it actually does occur, rather than causing ongoing interruptions in
order to ward off potential problems that never actually arise.
CVS has many strong points in addition to the above-mentioned "non-locking
behavior. For instance, it is open source and licensed under the GPL, and therefore is
available free of charge. Also, despite its Unix heritage, there are GUI-based clients
available for the classic Mac OS and for Windows. On the other hand, CVS is far from
perfect-it has been said that it's terrible but it's the best thing around. Many if its
flaws are merely nits, but they can add up to a noticeable inconvenience. To begin with,
CVS shares a problem which is unfortunately common among open-source projects,
namely that it has a significant amount of documentation yet it is often difficult to find
the exact information you are looking for. For example, a very nice feature of CVS is
that it can be configure to run over SSH, so that passwords and data are encrypted
during transmission. It's hard to find a complete discussion of this feature, and the
setup is such that it's easy to think that you've enabled this feature when in fact you
haven't. (There also doesn't appear to be a way to force the use of SSH from the server
side, i.e. to ensure that clients cannot connect insecurely.)
A second annoyance is the somewhat inconvenient handling of directories. CVS
fundamentally works on a per-directory basis, and in each directory it places a "CVS
subdirectory with configuration information. This can cause problems if you duplicate
a directory and forget to remove the duplicate CVS information. Under Mac OS X there
are many types of "files" which are actually directories, and tools which manipulate
these need to be CVS-aware so that they don't remove the CVS information when saving.
Some of these "magic directories" (for instance InterfaceBuilder's .nib files) are best
thought of as opaque binary files, whose contents should not be manipulated by merge
tools, and there is a "wrappers" facility which allows you to treat them as such but,
inexplicably, this feature is not compatible with client-server operation.
Fortunately, Codefab maintains a modified version of CVS which does support both of
these features, although it's a shame that the CVS maintainers don't seem to be
interested in merging this back into the core distribution. This still doesn't solve the
problem for "magic directories" which you don't want to treat as binary (such as
EOModeler's .eomodeld files), but fortunately the latest incarnations of Apple's
developer tools seem to handle the CVS directories correctly. For older version, the
Omni Group has plug-ins which fix this problem, for both EOModeler and
InterfaceBuilder. The directory-centric nature of CVS also has the unpleasant
side-effect that you can't really remove a directory from you project - you can only
remove the files which it contains. There is a workaround in that there is a setting
which tells CVS not to create empty directories during a checkout, but this has the side
effect that you can't place an empty directory under version control. (It's rare that
you would need to, but it's important to keep in mind in case you ever do.) On a related
note, you can place binary files (such as images) under version control, but you have
to go through a bit of special configuration to flag them as binary so that CVS doesn't
corrupt them, for instance by doing line-ending conversion. Often, these types of files
do not really need to be under version-control per se, but it's very convenient to place
them in your repository nonetheless so that you can maintain a complete copy of your
project, especially in web development projects which tend to contain a large number
of image files.
• Codefab CVS with Wrapper and Client/Server Support
<http://www.codefab.com/cvs.html>
• Omni Group Plug-ins
<http://www.omnigroup.com/community/developer/eomodeler/>
<http://www.omnigroup.com/community/developer/interfacebuilder/>
Documentation
Apple itself uses CVS for some of its internal development projects, and in fact Mac OS
X Server shipped with it pre-installed. In particular it is used with the Darwin
project, and there is a page on their Public Source site which serves as a good
jumping-off point to find documentation and other information about CVS. Here you'll
find a brief introduction to CVS concepts, by Apple's Wilfredo Sánchez. A good next stop
is Jim Blandy's "Introduction to CVS", which goes into a bit more detail. Next up is
"Open Source Development with CVS", a book by Karl Fogel. Generously, although this
is a commercial book, the chapters on CVS itself are available for free in a variety of
electronic formats. It is extensive, well-written, and a pleasant read. Finally, there is
the core CVS manual, "Version Management with CVS", colloquially referred to as "the
Cederqvist", for the name of its original author. It is large and complete, but it may
not be the best place to start out. Finally, for an account of using CVS specifically with
web development projects, take a look at "CVS Version Control for Web Site Projects".
• Apple - Open Source - CVS - Docs
[TOKEN:15560]http://www.publicsource.apple.com/tools/cvs/docs.html>
• CVS Concepts
<http://www.publicsource.apple.com/tools/cvs/concepts/>
• Introduction to CVS
<http://www.cvshome.org/docs/blandy.html>
• Open Source Development with CVS
[TOKEN:15560]http://cvsbook.red-bean.com/>
• CVS Manual: Version Management with CVS
<http://www.cvshome.org/docs/manual/index.html>
• CVS Version Control for Web Site Projects
<http://durak.org/cvswebsites/>
Much of the core documentation is located on the main CVS site, CVShome.org, and it's a
good place to look for additional information and to download CVS itself, despite the
somewhat inconvenient organization of the site. Their documentation page has links to
the most important references, including overviews of CVS and of version control, and
a CVS commands quick reference. (O'Reilly has also just published their CVS Pocket
Reference, if you'd like something a little more extensive and in printed form.) Also
check out the CVS Bubbles site, and especially its documentation page, which has links
to a number of tutorials and to other CVS sites.
• CVS Home - Documentation
<http://www.cvshome.org/docs/index.html>
• CVS Overviews
<http://www.cvshome.org/docs/overview.html>
<http://www.cvshome.org/docs/version.html>
• CVS Quick Reference
<http://www.cvshome.org/docs/ref.html>
• CVS Pocket Reference
<http://www.oreilly.com/catalog/cvspr/>
• CVS Bubbles
<http://www.loria.fr/~molli/cvs-index.html>
Alternatives
If you're a classic Mac OS user, you'll have to run the CVS server on a Unix machine,
but there are several different clients that you can run: MacCVS Pro, MacCvs, and
MacCVSClient. Despite their similar names, these are separate applications. The first
of these, MacCVS Pro, is sponsored by the Mozilla project, and appears to be the most
current version.
• MacCVS Pro
<http://www.maccvs.org/>
• MacCvs
<http://www.wincvs.org/>
• MacCVSClient
<http://www.glink.net.hk/~jb/MacCVSClient/>
Under Mac OS X, CVS should work "out of the box" thanks to the BSD layer. If you don't
like the command-line version (which really is quite easy to use), there is a GUI front
end, CVL (Concurrent Versions Librarian) by Sen:te. CVL works on top of the standard
CVS rather than replacing it. This is nice, because it should be forward-compatible,
and it also means that you can resort to the command-line version if there is some
additional feature you need to use which CVL doesn't support, and you can do this
without worrying that you might "mess up" any of the locally-stored administrative
information.
• Concurrent Versions Librarian
[TOKEN:15560]http://www.sente.ch/software/cvl/>
Finally, if CVS isn't to your liking after you've tried it out, there are several
alternatives, and you might want to use one of the commercial systems. For the classic
Mac OS there is VOODOO (Versions of Outdated Documents Organized Orthogonally). If
you need support for multiple platforms, take a look at Perforce, which seems to be
well liked and is available for a wide range of operating systems, although there don't
appear to be any GUI-based clients for it. (While visiting Perforce's site you might
also want to check out JAM, which is a build system designed as an alternative to make,
and which is used as the build system under Mac OS X's ProjectBuilder.)
• VOODOO
<http://www.unisoftwareplus.com/products/products.html>
• Perforce
<http://www.perforce.com/>
• Jam - Make(1) Redux
<http://www.perforce.com/jam/jam.html>