It can run scripts which you can supply to log CVS operations or enforce
site-specific polices.
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.
In cases where several developers or teams want to each maintain
their own version of the files, because of geography and/or policy,
CVS's vendor branches can import a version from another team
(even if they don't use CVS), and then CVS can merge the changes from
the vendor branch with the latest files if that is what is desired.
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 servers run on most unix variants, and clients for Windows
NT/95, OS/2 and VMS are also available. CVS will also operate
in what is sometimes called server mode against local repositories on Windows
95/NT.