CVS Product Overview

• Client/server CVS enables developers scattered by geography or slow modems to function as a single team. The version history is stored on a single central server and the client machines have a copy of all the files that the developers are working on. Therefore, the network between the client and the server must be up to perform CVS operations (such as checkins or updates) but need not be up to edit or manipulate the current versions of the files. Clients can perform all the same operations which are available locally.
• CVS' basic version control functionality maintains a history of all changes made to each directory tree it manages, operating on entire directory trees, not just single files.
• CVS supports branches allowing several lines of development to occur in parallel and providing mechanisms for merging branches back together when desired.
• CVS can tag the state of the directory tree at a given point, recreate that state and display the differences between tags or revisions in the standard diff formats.
• CVS runs scripts which you supply to log operations or enforce site-specific policies.
• CVS has Unreserved Checkouts allowing more than one developer to work on the same files at the same time.
• CVS provides a flexible modules database that provides a symbolic mapping of names to components of a larger software distribution. It applies names to collections of directories and files. A single command can manipulate the entire collection.
• 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.
• The 'rcsinfo' and 'editinfo' configuration files allow CVS to interface to external bug tracking systems.
• 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, Windows NT, OS/2 and VMS. See the Downloads page for source code and binaries.

  Memory Requirements

  Any client with enough capacity to run the operating system should have little trouble. 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. If you are starting without a version history, 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).

  System Requirements

  Server: most unix variants
  Non-client/server CVS: most unix variants, Windows NT/95
  Client: most unix variants, Windows NT/95, OS/2, VMS
  Modest CPU and memory requirements