Options for RCS and SCCS
By default, RCS uses locking to coordinate the activities of several
users, but there is a mode called non-strict locking in which
you can check-in changes without locking the file first. Use
rcs -U to switch to non-strict locking for a particular file,
see the rcs manual page for details.
When deducing the version control state of an RCS file, VC first
looks for an RCS version header string in the file (see Version Headers). If there is no header string, VC normally looks at the
file permissions of the work file; this is fast. But there might be
situations when the file permissions cannot be trusted. In this case
the master file has to be consulted, which is rather expensive. Also
the master file can only tell you if there's any lock on the
file, but not whether your work file really contains that locked
version.
You can tell VC not to use version headers to determine the file
status by setting vc-consult-headers to nil. VC then
always uses the file permissions (if it is supposed to trust them), or
else checks the master file.
You can specify the criterion for whether to trust the file
permissions by setting the variable vc-mistrust-permissions.
Its value can be t (always mistrust the file permissions and
check the master file), nil (always trust the file
permissions), or a function of one argument which makes the decision.
The argument is the directory name of the RCS subdirectory. A
non-nil value from the function says to mistrust the file
permissions. If you find that the file permissions of work files are
changed erroneously, set vc-mistrust-permissions to t.
Then VC always checks the master file to determine the file's status.
VC determines the version control state of files under SCCS much as
with RCS. It does not consider SCCS version headers, though. Thus,
the variable vc-mistrust-permissions affects SCCS use, but
vc-consult-headers does not.
|
