Chapter 12: Concurrent Versions System

---

Overview

The Concurrent Versions System (CVS) is a member of a class of tools known variously as change management tools, software and configuration management (SCM) tools, and a few other names. CVS acts as a repository that houses a master copy of a software project, and allows developers to "check out" their own copies (known as sandboxes) as one might check out a book from a library. Acting as the repository, CVS also records, tracks, and manages changes to the software as they are made by the developers.

CVS is a next-generation version of a more primitive class of similar tools. The original Unix tool in this space was called the Source Code Control System (SCCS). SCCS also acted as a repository and allowed developers to check out and commit changes, but it was rather more restrictive in what it allowed developers to do. For example, only one developer could edit a given file at a time, and the repository had to be located on a local disk. The GNU project implemented a functionally similar tool known as the Revision Control System (RCS). CVS is based on RCS and uses it at the core, but provides enhanced capabilities.

CVS' major claim to fame is its ability to handle asynchronous development. Recall that SCCS and RCS allow only one developer at a time to edit a file, such as a header file. If this header file is a common one shared by all aspects of the software, then it becomes hard for multiple developers to work on different parts of the software at the same time. The approach CVS takes is to keep each developer's sandbox completely dissociated from the master repository, until the developer commits a change. At that point, the sandbox is synchronized with the repository, and any discrepancies are merged. CVS can handle and merge most types of discrepancies, but for a small set of cases it requires human intervention to resolve conflicts. (Actually, it's generally good practice to review any merges that CVS does even automatically, since no software is perfect.)

In addition to the major productivity gains provided by CVS, it also offers a few extra conveniences. CVS operates in several different modes, including both a client-server mode (and in fact, several such modes), as well as the traditional local repository mode used by SCCS. These features make CVS extremely useful as a tool for coordinating the changes of a far-flung team of developers; thus, CVS is extremely popular with open source development projects, and is even becoming increasingly common within large global corporations as a way to share projects across the world.

CVS is most commonly used for software development, as a repository for source code. However, nothing about CVS is specific to programming languages or source code. In fact, CVS can be used to manage any type of project. It works best for projects that consist of text-based files, but it can also be used with binary files (such as images or photos), at the expense of some of its ability to merge changes. Thus CVS is commonly used to manage nonsource code items such as the HTML files for web sites, XML data, text configuration files, and so on.

CVS' main strengths are its decentralized model (since developers aren't bound to the repository, but rather insulated until they commit their changes) and its support for asynchronous development. However, explaining how to use CVS as part of a successful software project management methodology is a topic large enough for its own book. Interested readers should consult the excellent CVS reference manual by Per Cederqvist at http://www.cvshome.org/docs/manual/cvs.html.

Like many of the other examples in the preceding installation chapters, CVS is included with most distributions. However, they typically only install CVS in its client mode, rather than its server mode. This makes sense, because setting up a CVS server (or even just a simple CVS repository) is only useful to software developers.

This chapter will detail how to install CVS in its server capacity as an inetd service. By reading this chapter, you'll also gain good insight into how to install any inetd-based service, as well as being able to set up your own functioning CVS repository. CVS is a classic example of an inetd service, so even nondevelopers should consider reviewing this chapter.

Just the Facts: Concurrent Versions System

Purpose: The Concurrent Versions System is a tool that provides software developers with the ability to manage changes to their products.

Authors: Many!

Web site: http://www.cvshome.org

Description: CVS is a change management tool designed to aid software developers (or other teams that collectively produce a body of work) in organizing, tracking, and managing their work. CVS helps developers collaborate without getting in each other's way or destroying each other's work. CVS improves on a variety of older tools in the same area.

---