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,
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
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
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
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
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,
vc-mistrust-permissions affects SCCS use, but
vc-consult-headers does not.