CVS is a version tracking system. It maintains records of files throughout their development, allows retrieval of any stored version of a file, and supports production of multiple versions. CVS enables multiple developers to work simultaneously on a single file without loss of data. Each developer works on her own copy of a file, and all changes are later merged into a single master copy. CVS can be integrated with bug-tracking and feature-tracking systems, and it provides features that can assist a project manager by tracking changes to a project over time.
CVS can be used in many environments for many purposes. It is used
for maintaining configuration files, mail aliases, source code, FAQ
files, art, music, articles, essays, and books. Some system
administrators keep everything in the
directory under CVS in order to track system configuration changes
over time. CVS is also used to store and automatically publish
content to web sites and FTP servers.
CVS follows the Unix ethos of small programs doing what they do well. The RCS (Revision Control System) program handles revision control of single files, so CVS uses RCS to store file data. CVS adds features to RCS, most notably the abilities to work over collections of files, and to work out of a repository that may be local or remote.
Version control is the process of recording and retrieving changes in a project. A version control system can enable you to retrieve an old version to fix bugs or update features, branch development to allow the project to progress along multiple tracks simultaneously, and generate reports that show the changes between any two arbitrary stages of a project.
Most version control systems store notes with each change, and many provide tools that allow a project leader to analyze the changes. Most also include the ability to retrieve differences between arbitrary versions of files, which makes it easier to create patches or locate bugs.
The benefits of a version control system such as CVS include:
Any stored revision of a file can be retrieved to be viewed or changed.
The differences between any two revisions can be displayed.
Patches can be created automatically.
Multiple developers can work simultaneously on the same project or file without loss of data.
The project can be branched to allow simultaneous development along varied tracks. These branches can be merged back into the main line of development.
Distributed development is supported across large or small networks. (CVS offers a variety of authentication mechanisms.)
Using version control for a project requires some extra work on an ongoing basis. In addition, previous versions of files, or records of changes to the various files in a project, occupy disk space that you might otherwise use for something else. However, the features that a good version control system makes available are well worth the investment of time and disk space. For example, without version control, project backups typically are timestamped copies of an entire project, hopefully stored together in a logical fashion. Version control provides organized storage and retrieval of the complete record of project changes, rather than whichever copies someone gets a chance to make.
Version control systems store files as the files are created and updated, in a way that allows any saved version of a file, or related versions of a set of files, to be retrieved at any given time. Many version control systems, including CVS, encourage a project’s files to be stored together, which means that backups are easy to produce.
The ability to recover any earlier version of a given file allows you to roll back to support feature requests for previous releases and is critical when you create a bugfix branch of the project. CVS (and some other version control systems) allows simultaneous storage of the bugfix branch of a project and its main trunk code.
Many version control systems, including CVS, can display the
differences between versions in a computer-readable format. The
format CVS uses produces a file that allows the Unix
program to automatically convert one version of a file (or set of
files) to another.
Version control often allows multiple projects to use the same files, which helps divide a larger project among smaller teams. You can give each team a version-controlled copy of the section they’re working on, as well as the latest stable version of the files they need to use to test their section.
Sometimes, two or more developers may make changes to the same file. Those changes may be in different parts of the file, and they may be made in such a way as not to conflict with each other. Other times, two or more developers may make conflicting changes to the same portion of a file. In such a case, CVS does its best to merge conflicting changes, but it only knows which lines of a file have been changed. It doesn’t know what the changes mean. CVS provides tools to display changes between arbitrary revisions, which can help locate and resolve problems.
Version control is not a substitute for team members communicating with each other. File updates should be passed through CVS, but the meaning of the changes must be passed to other team members by actually discussing them. If one developer needs to change the arguments to a function or the chapter numbering of a book, that must somehow be communicated to the other developers.
Versioning systems are most commonly used for programming, but they are also useful for writing (I used CVS to write this book), system administration (configuration files), and anything else that requires files that change, where you might want to retrieve older versions of those files, or for situations where several people may be working on the same files. One family I know uses CVS to store their shopping list, to keep them from overwriting each other’s entries.
 Computer scientists define version control, source control, and change management as different but overlapping tasks. The term version control is the best fit for the aspects of the field that apply to CVS.