How data is stored in the working directory

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.

Root

This file contains the current cvsnt root, as described in the section called “Telling CVS where your repository is”.

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; 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.

Entries

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.

Entries.Log

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.

Entries.Backup

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.

Entries.Old

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.

Entries.Static

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.

Entries.Extra

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.

Entries.Extra.Old

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.

Rename

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'.

Tag

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.

Notify

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.

Notify.tmp

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.

Base

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.

Template

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.