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.
cvs -d :local:/usr/local/cvsroot checkout yoyodyne/tc`Root' will contain
:local:/usr/local/cvsrootand `Repository' will contain either
/usr/local/cvsroot/yoyodyne/tcor
yoyodyne/tcIf the particular working directory does not correspond to a directory in the repository, then `Repository' should contain `CVSROOT/Emptydir'.
/name/revision/timestamp[+conflict]/options/tagdatewhere `[' 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 section 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/filler4where 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.
update
command with the
`-d' option, which will get the additional files
and remove `Entries.Static'.
edit
or unedit
) which have not yet been
sent to the server. Its format is not yet documented
here.
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.
Bname/rev/expansionwhere expansion should be ignored, to allow for future expansion.
Go to the first, previous, next, last section, table of contents.