Builds
Top
CVS commands
In normal circumstances, CVS works only with regular files. Every file in a project is assumed to be persistent; it must be possible to open, read and close them; and so on. CVS also ignores file permissions and ownerships, leaving such issues to be resolved by the developer at installation time. In other words, it is not possible to "check in" a device into a repository; if the device file cannot be opened, CVS will refuse to handle it. Files also lose their ownerships and permissions during repository transactions.
If the configuration variable PreservePermissions
(see config) is set in the repository, CVS will
save the following file characteristics in the
repository:
Using the PreservePermissions option affects the
behavior of CVS in several ways. First, some of the
new operations supported by CVS are not accessible to
all users. In particular, file ownership and special
file characteristics may only be changed by the
superuser. When the PreservePermissions
configuration variable is set, therefore, users will
have to be `root' in order to perform CVS operations.
When PreservePermissions is in use, some CVS
operations (such as `cvs status') will not
recognize a file's hard link structure, and so will
emit spurious warnings about mismatching hard links.
The reason is that CVS's internal structure does not
make it easy for these operations to collect all the
necessary data about hard links, so they check for file
conflicts with inaccurate data.
A more subtle difference is that CVS considers a file
to have changed only if its contents have changed
(specifically, if the modification time of the working
file does not match that of the repository's file).
Therefore, if only the permissions, ownership or hard
linkage have changed, or if a device's major or minor
numbers have changed, CVS will not notice. In order to
commit such a change to the repository, you must force
the commit with `cvs commit -f'. This also means
that if a file's permissions have changed and the
repository file is newer than the working copy,
performing `cvs update' will silently change the
permissions on the working copy.
Changing hard links in a CVS repository is particularly
delicate. Suppose that file `foo' is linked to
file `old', but is later relinked to file
`new'. You can wind up in the unusual situation
where, although `foo', `old' and `new'
have all had their underlying link patterns changed,
only `foo' and `new' have been modified, so
`old' is not considered a candidate for checking
in. It can be very easy to produce inconsistent
results this way. Therefore, we recommend that when it
is important to save hard links in a repository, the
prudent course of action is to touch any file
whose linkage or status has changed since the last
checkin. Indeed, it may be wise to touch *
before each commit in a directory with complex hard
link structures.
It is worth noting that only regular files may
be merged, for reasons that hopefully are obvious. If
`cvs update' or `cvs checkout -j' attempts to
merge a symbolic link with a regular file, or two
device files for different kinds of devices, CVS will
report a conflict and refuse to perform the merge. At
the same time, `cvs diff' will not report any
differences between these files, since no meaningful
textual comparisons can be made on files which contain
no text.
The PreservePermissions features do not work
with client/server CVS. Another limitation is
that hard links must be to other files within the same
directory; hard links across directories are not
supported.
Builds
Top
CVS commands