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 section The CVSROOT/config configuration file) 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.
Go to the first, previous, next, last section, table of contents.