The CVSROOT/config configuration file

The administrative file config contains various miscellaneous settings which affect the behavior of cvsnt. 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:

SystemAuth=value

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 the section called “Direct connection with password authentication”.

TopLevelAdmin=value

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 (the section called “How data is stored in the working directory”).

AclMode=value

Select the access control list mode. One of 3 values:

  • none - No extra access control is done on this repository.

  • compat (default) - Default access mode is to allow access.

  • normal - Default access mode is to deny access.

LockDir=directory

This option is ignored unless the lockserver is disabled. It is accepted only for compatibility with older systems. This option will be removed in the near future.

Put cvsnt 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. You need to create directory, but cvsnt will create subdirectories of directory as it needs them. For information on cvsnt locks, see the section called “Several developers simultaneously attempting to run CVS”.

Before enabling the LockDir option, make sure that you have tracked down and removed any copies of cvsnt 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 cvsnt 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.

LockServer=hostname[:port]

Uses the cvsnt lock server to handle locking rather than using files 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. For information on cvsnt locks, see the section called “Several developers simultaneously attempting to run CVS”. cvsnt 2.0.15 and above use the LockServer by default and other methods of locking are depreciated. You can override this behaviour by using the line LockServer=none. Note however that future versions may not allow this override. See also the section called “The CVSNT lockserver”

LogHistory=value

Control what is logged to the CVSROOT/history file. Default of TOFEWGCMAR (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.)

RereadLogAfterVerify=value

If enabled the log message parsed by verifymsg is reread after the script has run. The default behavoiur is to not reread this file.

Watcher=name

Set a watcher who sees all edit/unedit/commit notifications via the CVSROOT/notify script. The watcher sees all notificaitons regardless of an existing edit/watch on the file, which for a large commit could be a lot of files. It is therefore recommended that the notify script completes as fast a possible. Using a custom trigger library or COM interface is recommended for best efficiency.