GNU Info

(cvsbook.info)The Working Copy Administrative Area

---

Next: Repository Permissions Up: The Usual Suspects

---

Enter node , (file) or (file)node

The Working Copy Administrative Area
------------------------------------

You've already seen the basics of working copy structure in Note: An
Overview of CVS; in this section, we'll go into a bit more detail.
Most of the details concern the files in the CVS/ administrative
subdirectories.  You already know about Entries, Root, and Repository,
but the CVS/ subdirectory can also contain other files, depending on the
circumstances.  I'll describe those other files here, partly so they
don't surprise you when you encounter them, and partly so you can fix
them if they ever cause trouble.

`CVS/Entries.Log'
=================

Sometimes, a file named `CVS/Entries.Log' will mysteriously appear.
The sole purpose of this file is to temporarily cache minor changes to
CVS/Entries, until some operation significant enough to be worth
rewriting the entire Entries file comes along.  CVS has no ability to
edit the Entries file in place; it must read the entire file in and
write it back out to make any change.  To avoid this effort, CVS
sometimes records small changes in Entries.Log, until the next time it
needs to rewrite Entries.

The format of Entries.Log is like Entries, except for an extra letter at
the beginning of each line. `A' means that the line is to be added to
the main Entries file, and `R' means it is to be removed.

For the most part, you can ignore Entries.Log; it's rare that a human
has to understand the information it contains.  However, if you're
reading over an Entries file to debug some problem in a working copy,
you should also examine Entries.Log.

`CVS/Entries.Backup'
====================

The CVS/Entries.Backup file is where CVS actually writes out a new
Entries file, before renaming it to `Entries' (similar to the way it
writes to temporary RCS files in the repository and then moves them to
their proper name when they're complete).  Because it becomes Entries
when it's complete, you'll rarely see an Entries.Backup file; if you do
see one, it probably means CVS got interrupted in the middle of some
operation.

`CVS/Entries.Static'
====================

If the CVS/Entries.Static file exists, it means that the entire
directory has not been fetched from the repository.  (When CVS knows a
working directory is in an incomplete state, it will not bring
additional files into that directory.)

The Entries.Static file is present during checkouts and updates and
removed immediately when the operation is complete.  If you see
Entries.Static, it means that CVS was interrupted, and its presence
prevents CVS from creating any new files in the working copy.  (Often,
running `cvs update -d' solves the problem and removes Entries.Static.)

The absence of Entries.Static does not necessarily imply that the
working copy contains all of the project's files.  Whenever a new
directory is created in the project's repository, and someone updates
their working copy without passing the -d flag to update, the new
directory will not be created in the working copy.  Locally, CVS is
unaware that there is a new directory in the repository, so it goes
ahead and removes the Entries.Static file when the update is complete,
even though the new directory is not present in the working copy.

`CVS/Tag'
=========

If the CVS/Tag file is present, it names a tag associated, in some
sense, with the directory.  I say "in some sense" because, as you know,
CVS does not actually keep any revision history for directories and,
strictly speaking, cannot attach tags to them.  Tags are attached to
regular files only or, more accurately, to particular revisions in
regular files.

However, if every file in a directory is on a particular tag, CVS likes
to think of the entire directory as being on the tag, too.  For example,
if you were to check out a working copy on a particular branch:

     floss$ cvs co -r Bugfix_Branch_1

and then add a file inside it, you'd want the new file's initial
revision to be on that branch, too.  For similar reasons, CVS also needs
to know if the directory has a nonbranch sticky tag or date set on it.

Tag files contain one line.  The first character on the line is a
single-letter code telling what kind of tag it is, and the rest of the
line is the tag's name.  Currently, CVS uses only these three
single-letter codes:

   * T - A branch tag

   * N - A nonbranch (regular) tag

   * D - A sticky date, which occurs if a command such as

          floss$ cvs checkout -D 1999-05-15 myproj

     or

          floss$ cvs update -D 1999-05-15 myproj

     is run.


(If you see some other single-letter code, it just means that CVS has
added a new tag type since this chapter was written.)

You should not remove the Tag file manually; instead, use
`cvs update -A'.

Rarities
========

There are a few other files you may occasionally find in a CVS/
subdirectory:

   * CVS/Checkin.prog, CVS/Update.prog

   * CVS/Notify, CVS/Notify.tmp

   * CVS/Base/, CVS/Baserev, CVS/Baserev.tmp

   * CVS/Template

These files are usually not the cause of problems, so I'm just listing
them (see Note: CVS Reference for their full descriptions).

Portability And Future Extension
================================

As features are added to CVS, new files (not listed here) may appear in
working copy administrative areas.  As new files are added, they'll
probably be documented in the Cederqvist manual, in the node `Working
Directory Storage'.  You can also start looking in src/cvs.h in the
source distribution, if you prefer to learn from code.

Finally, note that all CVS/* files - present and future - use whatever
line-ending convention is appropriate for the working copy's local
system (for example, LF for Unix or CRLF for Windows).  This means that
if you transport a working copy from one kind of machine to the other,
CVS won't be able to handle it (but then, you'd have other problems,
because the revision-controlled files themselves would have the wrong
line-end conventions for their new location).