|
CVS uses a client-server architecture: a server stores the current version(s) of a
project and
its history, and clients connect to the server in order to "check out" a
complete copy of the project, work on this copy and then later "check in" their
changes.
A D V E R T I S E M E N T
Typically, the client and server connect over a
LAN or over the
Internet,
but client and server may both run on the same machine if CVS has the task of
keeping track of the version history of a project with only local developers.
The server software normally runs on
Unix (although at
least the CVSNT
server supports various flavors of
Microsoft Windows and
Linux), while CVS
clients may run on any major
operating-system platform.
Several developers may work on the same project concurrently, each one
editing files within their own "working copy" of the project, and sending (or
checking in) their modifications to the server. To avoid the possibility of
people stepping on each other's toes, the server will only accept changes made
to the most recent
version of a
file. Developers are therefore expected to keep their working copy up-to-date by
incorporating other people's changes on a regular basis. This task is mostly
handled automatically by the CVS client, requiring manual intervention only when
a conflict arises between a checked-in modification and the yet-unchecked
local version of a file.
If the check-in operation succeeds, then the version numbers of all files
involved automatically increment, and the CVS-server writes a user-supplied
description line, the date and the author's name to its
log
files. CVS can also run external, user-specified log processing scripts
following each commit. These scripts are installed by an entry in CVS's
loginfo file, which can trigger email notification or convert the log data
into a Web-based format.
Clients can also compare versions, request a complete history of changes, or
check out a historical snapshot of the project as of a given date or as of a
revision number. Many
open-source projects allow "anonymous read access", a feature pioneered by
OpenBSD. This
means that clients may check out and compare versions with either a blank or
simple published password (e.g., "anoncvs"); only the check-in of changes
requires a personal account and password in these scenarios.
Clients can also use the "update" command in order to bring their local
copies up-to-date with the newest version on the server. This eliminates the
need for repeated downloading of the whole project.
CVS can also maintain different "branches" of a project. For instance, a
released version of the software project may form one branch, used for bug
fixes, while a version under current development, with major changes and new
features, can form a separate branch.
CVS uses
delta compression for efficient storage of different versions of the same
file. The implementation favors files with many lines (usually text files) - in
extreme cases the system may store individual copies of each version rather than
deltas.
|
