Concurrent Versions System (CVS)

The Concurrent Versions System (CVS) provides network-transparent source control for groups of developers.

• CVS maintains a history of all changes made to each directory tree it manages. Using this history, CVS can recreate past states of the tree, or show a developer when, why, and by whom a given change was made. CVS supports branches, which help manage long-term changes and bug-fix releases.
• CVS provides hooks to support process control and change control.
• CVS provides reliable access to its directory trees from remote hosts, using Internet protocols. Developers at remote sites can perform all the same operations available locally. Access can be authenticated using the Kerberos network security system.
• CVS supports parallel development, allowing more than one developer to work on the same sources at the same time.

Version Control

• Each developer uses cvs checkout to create her own copy of the source tree from the CVS repository. The command can operate on a directory tree, on a single file, or on a module; a module groups several files or directories into one entity, which can be operated on as a unit. One defines modules by editing the `modules' file.
• The developer modifies, compiles, and tests the code in her copy of the source tree (called a working directory) with whatever editors and tools she chooses -- Emacs, make, etags, etc. She uses cvs add and cvs remove to add and remove files.
• When the changes are complete, the developer uses cvs commit to merge her changes back into the repository. This makes her changes available to other developers.
• At any point, the developer may use cvs update to merge changes committed by others into her working directory. If there are uncommitted changes to files in her working directory, CVS prints a message and attempts to merge the changes from the repository with her changes in the working directory. If the merge fails, CVS indicates a conflict, which she resolves manually with a text editor.
• The developer can show the differences between two revisions with cvs diff; show the log of changes to a particular file with cvs log; show the history of each line of a file with cvs annotate; and show who has used cvs checkout, cvs tag, and several other CVS commands, using cvs history.
• CVS supports watches, allowing developers to request notification when someone begins editing a file, or obtain a list of developers currently working on a file.
• The user can record the state of the repository at a particular point with the cvs tag command, and can then use that tag as an argument to most CVS commands, for example to retrieve the files as of the tagged point.
• The developer can create a new development branch with cvs tag -b, and manipulate branches with cvs update -r and cvs checkout -r. Subsequent operations in that working directory apply to that branch. To return to the main branch, the developer can use cvs update -A. The cvs update -j command merges changes made on another branch into the working directory.
• The existence or nonexistence of a file is itself version controlled, so that files can exist on some but not all branches and users can reproduce the state of the files at any given point in time.
• The developer can mark a file as binary, which prohibits merging and line terminator conversions, using cvs admin -kb.

Process Control

CVS gives project managers fine control over the development process.

• The `commitinfo' configuration file tells CVS how to screen changes. When a developer tries to commit a change, CVS will run a script to determine whether the change is acceptable.
• The `loginfo' configuration file can tell CVS to run a script after a developer commits a change. For example, CVS can send E-mail to other developers, notifying them of the change.
• The `rcsinfo' configuration file can specify a template for log messages, presented to developers when they commit a change. For example, the template could prompt for a bug number.
• The `editinfo' configuration file tells CVS how to screen developers' log messages. For example, the script could ensure that a bug number mentioned in the log message is valid.

Change Control

The `rcsinfo' and `editinfo' configuration files (described in the Process Control section above) allow CVS to interface to external bug tracking systems.

Network Transparency

CVS provides reliable repository access to remote hosts using Internet protocols, facilitating collaboration with distant employees and contractors.

• All CVS operations can be performed over the network. A developer on a remote host can check out a local copy of the sources, make changes, update her local copy with changes made by others, and commit her changes back into the repository.
• Remote operation is efficient, transmitting only those files which have changed. When appropriate, CVS transmits patches to files and verifies the results, rather than sending entire files. CVS can compress the text it transmits.
• Remote operation is reliable. CVS holds no internal locks while waiting for communications to complete, so network troubles will not disrupt others' access to the repository. It uses reliable transport mechanisms, not NFS, making it well-adapted for use over wide-area networks.
• Remote operation is authenticated. CVS can use the industry standard Kerberos protocols to verify the identity of the remote user. Kerberos is much more secure than the source-address authentication provided by the ordinary rlogin and rsh protocols. CVS can also work with ssh, a secure replacement for rsh, or use straight password authentication.
• Remote operation supports portable computers. While a developer's portable computer is connected to the network, she can update her working copy of the source code. While disconnected, she can develop her working copy. The next time she connects to the network, she can commit her changes.

Supported Platforms

The CVS client and server run on most Unix variants (although the more exotic ones might require minor porting effort). The CVS client also runs on Windows NT, OS/2 and VMS. Other ports are in progress, but the progress of those ports may depend on funding and/or volunteer effort.

CPU and memory requirements are modest--any client with enough capacity to run the operating system in question should have little trouble and a server with 32M of memory or even less can handle a fairly large source tree with a fair amount of activity. To estimate disk space requirements, if you are importing RCS files from another system, the size of those files is the approximate initial size of your repository, or if you are starting without any version history, a rule of thumb is to allow for the server approximately three times the size of the code to be under CVS for the repository (you will eventually outgrow this, but not for a while). On the machines on which the developers will be working, you'll want disk space for approximately one working directory for each developer (either the entire tree or a portion of it, depending on what each developer uses).