Next: Intro administrative files, Previous: Repository storage, Up: Repository [Contents][Index]
While we are discussing CVS internals which may
become visible from time to time, we might as well talk
about what CVS puts in the CVS directories
in the working directories. As with the repository,
CVS handles this information and one can usually
access it via CVS commands. But in some cases it
may be useful to look at it, and other programs, such
as the jCVS graphical user interface or the
VC package for emacs, may need to look at it.
Such programs should follow the recommendations in this
section if they hope to be able to work with other
programs which use those files, including future
versions of the programs just mentioned and the
command-line CVS client.
The CVS directory contains several files. Programs which are reading this directory should silently ignore files which are in the directory but which are not documented here, to allow for future expansion.
The files are stored according to the text file convention for the system in question. This means that working directories are not portable between systems with differing conventions for storing text files. This is intentional, on the theory that the files being managed by CVS probably will not be portable between such systems either.
This file contains the current CVS root, as described in Specifying a repository.
This file contains the directory within the repository which the current directory corresponds with. It can be either an absolute pathname or a relative pathname; CVS has had the ability to read either format since at least version 1.3 or so. The relative pathname is relative to the root, and is the more sensible approach, but the absolute pathname is quite common and implementations should accept either. For example, after the command
cvs -d :local:/usr/local/cvsroot checkout yoyodyne/tc
Root will contain
:local:/usr/local/cvsroot
and Repository will contain either
/usr/local/cvsroot/yoyodyne/tc
or
yoyodyne/tc
If the particular working directory does not correspond to a directory in the repository, then Repository should contain CVSROOT/Emptydir.
This file lists the files and directories in the working directory. The first character of each line indicates what sort of line it is. If the character is unrecognized, programs reading the file should silently skip that line, to allow for future expansion.
If the first character is ‘/’, then the format is:
/name/revision/timestamp[+conflict]/options/tagdate
where ‘[’ and ‘]’ are not part of the entry, but instead indicate that the ‘+’ and conflict marker are optional. name is the name of the file within the directory. revision is the revision that the file in the working derives from, or ‘0’ for an added file, or ‘-’ followed by a revision for a removed file. timestamp is the timestamp of the file at the time that CVS created it; if the timestamp differs with the actual modification time of the file it means the file has been modified. It is stored in the format used by the ISO C asctime() function (for example, ‘Sun Apr 7 01:29:26 1996’). One may write a string which is not in that format, for example, ‘Result of merge’, to indicate that the file should always be considered to be modified. This is not a special case; to see whether a file is modified a program should take the timestamp of the file and simply do a string compare with timestamp. If there was a conflict, conflict can be set to the modification time of the file after the file has been written with conflict markers (see Conflicts example). Thus if conflict is subsequently the same as the actual modification time of the file it means that the user has obviously not resolved the conflict. options contains sticky options (for example ‘-kb’ for a binary file). tagdate contains ‘T’ followed by a tag name, or ‘D’ for a date, followed by a sticky tag or date. Note that if timestamp contains a pair of timestamps separated by a space, rather than a single timestamp, you are dealing with a version of CVS earlier than CVS 1.5 (not documented here).
The timezone on the timestamp in CVS/Entries (local or universal) should be the same as the operating system stores for the timestamp of the file itself. For example, on Unix the file’s timestamp is in universal time (UT), so the timestamp in CVS/Entries should be too. On VMS, the file’s timestamp is in local time, so CVS on VMS should use local time. This rule is so that files do not appear to be modified merely because the timezone changed (for example, to or from summer time).
If the first character of a line in Entries is ‘D’, then it indicates a subdirectory. ‘D’ on a line all by itself indicates that the program which wrote the Entries file does record subdirectories (therefore, if there is such a line and no other lines beginning with ‘D’, one knows there are no subdirectories). Otherwise, the line looks like:
D/name/filler1/filler2/filler3/filler4
where name is the name of the subdirectory, and
all the filler fields should be silently ignored,
for future expansion. Programs which modify
Entries files should preserve these fields.
The lines in the Entries file can be in any order.
This file does not record any information beyond that in Entries, but it does provide a way to update the information without having to rewrite the entire Entries file, including the ability to preserve the information even if the program writing Entries and Entries.Log abruptly aborts. Programs which are reading the Entries file should also check for Entries.Log. If the latter exists, they should read Entries and then apply the changes mentioned in Entries.Log. After applying the changes, the recommended practice is to rewrite Entries and then delete Entries.Log. The format of a line in Entries.Log is a single character command followed by a space followed by a line in the format specified for a line in Entries. The single character command is ‘A’ to indicate that the entry is being added, ‘R’ to indicate that the entry is being removed, or any other character to indicate that the entire line in Entries.Log should be silently ignored (for future expansion). If the second character of the line in Entries.Log is not a space, then it was written by an older version of CVS (not documented here).
Programs which are writing rather than reading can safely ignore Entries.Log if they so choose.
This is a temporary file. Recommended usage is to write a new entries file to Entries.Backup, and then to rename it (atomically, where possible) to Entries.
The only relevant thing about this file is whether it
exists or not. If it exists, then it means that only
part of a directory was gotten and CVS will
not create additional files in that directory. To
clear it, use the update command with the
‘-d’ option, which will get the additional files
and remove Entries.Static.
This file contains per-directory sticky tags or dates. The first character is ‘T’ for a branch tag, ‘N’ for a non-branch tag, or ‘D’ for a date, or another character to mean the file should be silently ignored, for future expansion. This character is followed by the tag or date. Note that per-directory sticky tags or dates are used for things like applying to files which are newly added; they might not be the same as the sticky tags or dates on individual files. For general information on sticky tags and dates, see Sticky tags.
This file stores notifications (for example, for
edit or unedit) which have not yet been
sent to the server. Its format is not yet documented
here.
This file is to Notify as Entries.Backup is to Entries. That is, to write Notify, first write the new contents to Notify.tmp and then (atomically where possible), rename it to Notify.
If watches are in use, then an edit command
stores the original copy of the file in the Base
directory. This allows the unedit command to
operate even if it is unable to communicate with the
server.
The file lists the revision for each of the files in the Base directory. The format is:
Bname/rev/expansion
where expansion should be ignored, to allow for future expansion.
This file is to Baserev as Entries.Backup is to Entries. That is, to write Baserev, first write the new contents to Baserev.tmp and then (atomically where possible), rename it to Baserev.
This file contains the template specified by the rcsinfo file (see rcsinfo). It is only used by the client; the non-client/server CVS consults rcsinfo directly.
Next: Intro administrative files, Previous: Repository storage, Up: Repository [Contents][Index]