CVS records file changes during a project’s development. Project files are added to the repository as they are created, and developers check out a personal sandbox — a personal copy of the project’s files — to work from. Each developer works in her own sandbox and regularly commits her changes to the repository. Developers also update the contents of their sandboxes regularly to ensure that changes to the repository are reflected in each sandbox.
The term project can take on many different meanings. The stereotypical CVS project is a programming project in which files contain source code for the various programs written as part of the project. But that’s a narrow view of what a CVS project can be. CVS can be used in many other settings as well, as the next few sections demonstrate.
CVS can store configuration files, mail
aliases, domain records, and other files for which changes should be
tracked. Import the files (or all of /etc) into
a repository and require administrators to check them out into a
sandbox to make changes. Commit the files back to the repository and
export the changes to the server. If the changes fail, rolling back
to the previous state is easy.
Multiple servers with varied but similar configurations can be maintained using different branches of the same files. Changes to any given branch can be merged into other branches selectively.
Every change made through CVS is recorded in a file history, along with the username of the person making the change, the date the change was made, and any notes recorded with the change. All this information can help, for example, when trying to spot which change to which configuration file broke the mail server.
Both the CVS server and the client run on all Unix and Linux operating systems. Third-party graphical clients are available for Unix, Linux, Windows, and Macintosh systems, and for the Java runtime environment. The CVSNT CVS server is available for Windows NT or later. This makes CVS particularly useful for cross-platform environments.
Program development is perhaps the most common use for version control systems. After the initial release of a program, two versions usually need to be maintained: the new version that will eventually be the next release and the bugfix version for the current release. CVS allows you to split the development into two or more parts, called a trunk and a branch. Typically, the branch is used for bug fixes, while the main trunk is used for new feature development. Both versions of the program, the bugfix branch and the main trunk, are stored in the same repository. This allows the changes from the bugfix branch to ultimately be merged into the main trunk, ensuring that all bugfixes get rolled into the next release of the program.
A CVS repository can be hosted on the machine that most developers will be using, or you can host the repository on a machine that developers access via a local or wide-area network. A repository can be accessed simultaneously by multiple computers. If you need to authenticate your CVS users, there are a variety of authentication mechanisms available.
When multiple developers are trying to work on the same project, it’s likely that two or more developers will eventually want to work with the same file at the same time. Without version control, this would lead to problems, as developers would soon find themselves overwriting one another’s changes. One way that some version control systems prevent such conflicts is to enable developers to lock whatever files they are working on, so that no one else can make changes at the same time.
Instead of locking files to prevent
conflicts, CVS simply allows multiple developers to work on the same
file. CVS’s file-merging feature then allows you to
merge all changes into one file. File merging aids development across
remote time zones, as developers can work on different sections of
the same file, regardless of the lock status. In fact, there is no
lock status, because there is no locking. With a file-locking system,
a developer may have to email someone and then wait until that person
wakes up, reads his email, and unlocks the needed file. The CVS
approach prevents one developer from blocking another, thus
increasing productivity. However, if your project team needs file
locking, you can use the cvs
watch
command to
emulate it.
The cvs diff
command
displays the differences between any two revisions of a file (or set
of files) in the repository. A variation of the command creates a
Unix standard patch file to update one revision to another, which is
useful when sending patches or updates to customers.
CVS can be configured to record commit messages in bug-tracking systems. Chapter 7 explains how to use the administrative files to provide message templates and run scripts automatically during commits. This does not necessarily record the stage of each change (completed, tested, etc.). Unless you rigorously enforce a requirement to write meaningful commit messages, you should maintain a separate change log.
Store your build and installation scripts in CVS to maintain a record of changes and to ensure that such scripts are kept with the project files. Releases should always be built from a freshly checked-out sandbox and tagged with a human-friendly name.
CVS does not include build or installation tools, though
cvs export should be part of the installation
process for your project. I like to use make for
build and installation scripts.
Many people use CVS to maintain web sites and other file servers, and they use scripts to automatically publish updates to those servers. Some people use scripts to distribute and apply patch files on remote machines, saving bandwidth by distributing only the changes. A variety of such scripts are available at http://www.cvshome.org, and some are discussed in Appendix B.
Get Essential CVS now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
