Previous: The notify File, Up: The CVSROOT/ Administrative Directory

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

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
     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


for example,           unable to check out / update 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.

Karl Fogel wrote this book. Buy a printed copy via his homepage at

copyright  ©  September 22 2020 sean dreilinger url: