Download GNU Emacs Manual - Programming Systems Lab

Chapter 15: File Handling
127
Meta-CVS is another attempt to solve problems arising in CVS. It supports directory
structure versioning, improved branching and merging, and use of symbolic links and metadata in repositories.
SCCS is a proprietary but widely used version control system. In terms of capabilities, it
is the weakest of the six that VC supports. VC compensates for certain features missing in
SCCS (snapshots, for example) by implementing them itself, but some other VC features,
such as multiple branches, are not available with SCCS. Since SCCS is non-free, not respecting its users freedom, you should not use it; use its free replacement CSSC instead. But
you should use CSSC only if for some reason you cannot use RCS, or one of the higher-level
systems such as CVS or GNU Arch.
In the following, we discuss mainly RCS, SCCS and CVS. Nearly everything said about
CVS applies to GNU Arch, Subversion and Meta-CVS as well.
15.7.1.2 Concepts of Version Control
When a file is under version control, we also say that it is registered in the version control
system. Each registered file has a corresponding master file which represents the file’s
present state plus its change history—enough to reconstruct the current version or any
earlier version. Usually the master file also records a log entry for each version, describing
in words what was changed in that version.
The file that is maintained under version control is sometimes called the work file corresponding to its master file. You edit the work file and make changes in it, as you would
with an ordinary file. (With SCCS and RCS, you must lock the file before you start to
edit it.) After you are done with a set of changes, you check the file in, which records the
changes in the master file, along with a log entry for them.
With CVS, there are usually multiple work files corresponding to a single master file—
often each user has his own copy. It is also possible to use RCS in this way, but this is not
the usual way to use RCS.
A version control system typically has some mechanism to coordinate between users who
want to change the same file. One method is locking (analogous to the locking that Emacs
uses to detect simultaneous editing of a file, but distinct from it). The other method is to
merge your changes with other people’s changes when you check them in.
With version control locking, work files are normally read-only so that you cannot change
them. You ask the version control system to make a work file writable for you by locking it;
only one user can do this at any given time. When you check in your changes, that unlocks
the file, making the work file read-only again. This allows other users to lock the file to
make further changes. SCCS always uses locking, and RCS normally does.
The other alternative for RCS is to let each user modify the work file at any time. In
this mode, locking is not required, but it is permitted; check-in is still the way to record a
new version.
CVS normally allows each user to modify his own copy of the work file at any time, but
requires merging with changes from other users at check-in time. However, CVS can also
be set up to require locking. (see section “CVS Options” in Specialized Emacs Features).