GNU Info

Info Node: (cvs.info)Working directory storage

(cvs.info)Working directory storage


Next: Intro administrative files Prev: Repository storage Up: Repository
Enter node , (file) or (file)node

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 Note:
     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 (Note: 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 Note: Sticky tags.

`Checkin.prog'
`Update.prog'
     These files store the programs specified by the `-i' and `-u'
     options in the modules file, respectively.

`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
     (Note: rcsinfo).  It is only used by the client; the
     non-client/server CVS consults `rcsinfo' directly.


automatically generated by info2www version 1.2.2.9