GNU Info

(cvsbook.info)The checkoutlist File

---

Prev: The notify File Up: The CVSROOT/ Administrative Directory

---

Enter node , (file) or (file)node

The checkoutlist File
---------------------

If you look inside CVSROOT/, you'll see that working copies of the files
exist side by side with their RCS revision files:

     floss$ ls /usr/local/newrepos/CVSROOT
     checkoutlist     config,v       history     notify     taginfo
     checkoutlist,v   cvswrappers    loginfo     notify,v   taginfo,v
     commitinfo       cvswrappers,v  loginfo,v   passwd     verifymsg
     commitinfo,v     editinfo       modules     rcsinfo    verifymsg,v
     config           editinfo,v     modules,v   rcsinfo,v
     
     floss$

CVS only pays attention to the working versions, not the RCS files, when
it's looking for guidance on how to behave.  Therefore, whenever you
commit your working copy of CVSROOT/ (which might, after all, even be
checked out to a different machine), CVS automatically updates any
changed files in the repository itself.  You will know that this has
happened because CVS will print a message at the end of such commits:

     floss$ cvs ci -m "added mp and asub modules" modules
     Checking in modules;
     /usr/local/newrepos/CVSROOT/modules,v  <--  modules
     new revision: 1.2; previous revision: 1.1
     done
     cvs commit: Rebuilding administrative file database

CVS automatically knows about the standard administrative files, and
will rebuild them in CVSROOT/ as necessary.  If you decide to put custom
files in CVSROOT/ (such as programs or rcsinfo template files), you'll
have to tell CVS explicitly to treat them the same way.

That's the purpose of the checkoutlist file.  It has a different format
from most of the files we've looked at so far

     FILENAME     ERROR_MESSAGE_IF_FILE_CANNOT_BE_CHECKED_OUT

for example,

     log.pl           unable to check out / update log.pl in CVSROOT
     
     bugfix.tmpl      unable to check out / update bugfix.tmpl in CVSROOT

Certain files in CVSROOT are traditionally not kept under revision
control.  One such is the "history" file, which keeps a running record
of all actions in the repository, for use by the `cvs history' command
(which lists checkout, update, and tag activity for a given file or
project directory).  Incidentally, if you just remove the `history'
file, CVS will obligingly stop keeping that log.

Note: sometimes the history file is the cause of permission problems,
and the easiest way to solve them is to either make it world-writeable
or just remove it.

Another `unrevisioned' administrative file is passwd, the assumption
being that having it checked out over the network might compromise the
passwords (even though they're encrypted).  You'll have to decide based
on your own security situation whether you want to add passwd to
checkoutlist or not; by default, it is not in checkoutlist.

Two final notes about the CVSROOT/ directory: It is possible, if you
make a big enough mistake, to commit an administrative file that is
broken in such a way as to prevent any commits from happening at all.
If you do that, naturally you won't be able to commit a fixed version of
the administrative file!  The solution is to go in and hand-edit the
repository's working copy of the administrative file to correct the
problem; the whole repository may stay inaccessible until you do that.

Also, for security's sake, make sure your CVSROOT/ directory is only
writeable by users you trust (by `trust', I mean you trust both their
intentions and their ability not to compromise their password).  The
`*info' files give people the ability to invoke arbitrary programs, so
anyone who can commit or edit files in the CVSROOT/ directory can
essentially run any command on the system.  That's something you should
always keep in mind.