(cvs.info.gz) Working directory storage
Info Catalog
(cvs.info.gz) Repository storage
(cvs.info.gz) Repository
(cvs.info.gz) Intro administrative files
2.3 How data is stored in the working directory
===============================================
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.
`Root'
This file contains the current CVS root, as described in
Specifying a repository.
`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'.
`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 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 ( 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.
`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 CVS (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.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 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'.
`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 Sticky tags.
`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.
`Baserev'
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.
`Baserev.tmp'
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'.
`Template'
This file contains the template specified by the `rcsinfo' file
( rcsinfo). It is only used by the client; the
non-client/server CVS consults `rcsinfo' directly.
Info Catalog
(cvs.info.gz) Repository storage
(cvs.info.gz) Repository
(cvs.info.gz) Intro administrative files
automatically generated byinfo2html