Volume Number: 16 (2000)
Issue Number: 10
Column Tag: MacTech Online
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.
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".
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.
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.
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.
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.)
