While we are discussing cvsnt internals which may become visible from time to time, we might as well talk about what cvsnt puts in the CVS directories in the working directories. As with the repository, cvsnt handles this information and one can usually access it via cvsnt 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 cvsnt 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 cvsnt probably will not be portable between such systems either.
This file contains the current cvsnt root, as described in the section called “Telling CVS where your repository is”.
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; cvsnt 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 cvsnt 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 (the section called “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 cvsnt earlier than cvsnt 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 cvsnt 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 cvsnt (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.
This is the previous generation of the 'Entries' file. If your program modifies the 'Entries' file rename the existing file to 'Entries.Old' so that frontends are able to find out what has changed.
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 cvsnt 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 holds extra information about the file that was not recorded by the original CVS client. If this file exists there is a line for each file in the Entries file. The lines can be in any order.
The format of the lines is:
/name/saved mergepoint/filler1/rcstime/edit_revision/edit_tag/edit_bugid/
If there are any extra fields after rcstime these should be ignored.
The second field is the saved tag from an update -j, which is recorded the next time the file is committed to store the mergepoint data.
The third field is unused (and reserved) at present.
The fourth field is the last checkin time of the file, expressed as a time_t. Do not assume that this value will fit into a 32bit variable, as this will cause problems in 2038.
The fifth, sixth and seventh fields define the revision, tag/branch and bug identifier of the last cvs edit that was invoked by the client.
This is the previous generation of the 'Entries.Extra' file. If your program modifies the 'Entries' file rename the existing file to 'Entries.Extra.Old' so that frontends are able to find out what has changed.
This file contains information about any renames that have not yet been committed to the repository. The file is stored as pairs of filenames within the directory, with a blank meaning 'removed'.
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 the section called “Sticky tags”.
CVSNT also stores the directory revision in this file, as a numeric tag.
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.
This file contains the template specified by the rcsinfo file (the section called “rcsinfo”). It is only used by the client; the non-client/server cvsnt consults rcsinfo directly.