Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Mail Systems
Eclipse Documentation

How To Guides
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Problem Solutions
Privacy Policy




[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

C.11 The CVSROOT/config configuration file

The administrative file `config' contains various miscellaneous settings which affect the behavior of CVS. The syntax is slightly different from the other administrative files. Variables are not expanded. Lines which start with `#' are considered comments. Other lines consist of a keyword, `=', and a value. Note that this syntax is very strict. Extraneous spaces or tabs are not permitted.

Currently defined keywords are:


For CVS 1.9.12 through 1.9.18, this setting told CVS to look for RCS programs in the bindir directory. Current versions of CVS do not run RCS programs; for compatibility this setting is accepted, but it does nothing.


If value is `yes', then pserver should check for users in the system's user database if not found in `CVSROOT/passwd'. If it is `no', then all pserver users must exist in `CVSROOT/passwd'. The default is `yes'. For more on pserver, see Direct connection with password authentication.


Modify the `checkout' command to create a `CVS' directory at the top level of the new working directory, in addition to `CVS' directories created within checked-out directories. The default value is `no'.

This option is useful if you find yourself performing many commands at the top level of your working directory, rather than in one of the checked out subdirectories. The `CVS' directory created there will mean you don't have to specify CVSROOT for each command. It also provides a place for the `CVS/Template' file (see section How data is stored in the working directory).


Put CVS lock files in directory rather than directly in the repository. This is useful if you want to let users read from the repository while giving them write access only to directory, not to the repository. It can also be used to put the locks on a very fast in-memory file system to speed up locking and unlocking the repository. You need to create directory, but CVS will create subdirectories of directory as it needs them. For information on CVS locks, see Several developers simultaneously attempting to run CVS.

Before enabling the LockDir option, make sure that you have tracked down and removed any copies of CVS 1.9 or older. Such versions neither support LockDir, nor will give an error indicating that they don't support it. The result, if this is allowed to happen, is that some CVS users will put the locks one place, and others will put them another place, and therefore the repository could become corrupted. CVS 1.10 does not support LockDir but it will print a warning if run on a repository with LockDir enabled.


Control what is logged to the `CVSROOT/history' file (see section history—Show status of files and users). Default of `TOEFWUPCGMAR' (or simply `all') will log all transactions. Any subset of the default is legal. (For example, to only log transactions that modify the `*,v' files, use `LogHistory=TMAR'.)


Modify the `commit' command such that CVS will reread the log message after running the program specified by `verifymsg'. value may be one of `yes' or `always', indicating that the log message should always be reread; `no' or `never', indicating that it should never be reread; or value may be `stat', indicating that the file should be checked with the file system `stat()' function to see if it has changed (see warning below) before rereading. The default value is `always'.

The `stat' mode can cause CVS to pause for up to one extra second per directory committed. This can be less IO and CPU intensive but is not recommended for use with large repositories

See section Verifying log messages, for more information on how verifymsg may be used.

  Published under the terms of the GNU General Public License Design by Interspire