{ "mode": "man", "parameter": "cvs", "section": "5", "url": "https://www.chedong.com/phpMan.php/man/cvs/5/json", "generated": "2026-05-30T07:08:25Z", "synopsis": "", "sections": { "NAME": { "content": "cvs - Concurrent Versions System support files\n", "subsections": [] }, "NOTE": { "content": "This documentation may no longer be up to date. Please consult the Cederqvist (CVS Manual)\nas specified in cvs(1).\n\n", "subsections": [] }, "SYNOPSIS": { "content": "", "subsections": [ { "name": "$CVSROOT/CVSROOT/commitinfo,v", "content": "" }, { "name": "$CVSROOT/CVSROOT/cvsignore,v", "content": "" }, { "name": "$CVSROOT/CVSROOT/cvswrappers,v", "content": "" }, { "name": "$CVSROOT/CVSROOT/editinfo,v", "content": "" }, { "name": "$CVSROOT/CVSROOT/history", "content": "" }, { "name": "$CVSROOT/CVSROOT/loginfo,v", "content": "" }, { "name": "$CVSROOT/CVSROOT/modules,v", "content": "" }, { "name": "$CVSROOT/CVSROOT/rcsinfo,v", "content": "" }, { "name": "$CVSROOT/CVSROOT/taginfo,v", "content": "" } ] }, "DESCRIPTION": { "content": "cvs is a system for providing source control to hierarchical collections of source directo‐\nries. Commands and procedures for using cvs are described in cvs(1).\n\ncvs manages source repositories, the directories containing master copies of the revision-\ncontrolled files, by copying particular revisions of the files to (and modifications back\nfrom) developers' private working directories. In terms of file structure, each individual\nsource repository is an immediate subdirectory of $CVSROOT.\n\nThe files described here are supporting files; they do not have to exist for cvs to operate,\nbut they allow you to make cvs operation more flexible.\n\nYou can use the `modules' file to define symbolic names for collections of source maintained\nwith cvs. If there is no `modules' file, developers must specify complete path names (abso‐\nlute, or relative to $CVSROOT) for the files they wish to manage with cvs commands.\n\nYou can use the `commitinfo' file to define programs to execute whenever `cvs commit' is\nabout to execute. These programs are used for ``pre-commit'' checking to verify that the\nmodified, added, and removed files are really ready to be committed. Some uses for this\ncheck might be to turn off a portion (or all) of the source repository from a particular per‐\nson or group. Or, perhaps, to verify that the changed files conform to the site's standards\nfor coding practice.\n\nYou can use the `cvswrappers' file to record cvs wrapper commands to be used when checking\nfiles into and out of the repository. Wrappers allow the file or directory to be processed\non the way in and out of CVS. The intended uses are many, one possible use would be to re‐\nformat a C file before the file is checked in, so all of the code in the repository looks the\nsame.\n\nYou can use the `loginfo' file to define programs to execute after any commit, which writes a\nlog entry for changes in the repository. These logging programs might be used to append the\nlog message to a file. Or send the log message through electronic mail to a group of devel‐\nopers. Or, perhaps, post the log message to a particular newsgroup.\n\nYou can use the `taginfo' file to define programs to execute after any tagorrtag operation.\nThese programs might be used to append a message to a file listing the new tag name and the\nprogrammer who created it, or send mail to a group of developers, or, perhaps, post a message\nto a particular newsgroup.\n\nYou can use the `rcsinfo' file to define forms for log messages.\n\nYou can use the `editinfo' file to define a program to execute for editing/validating `cvs\ncommit' log entries. This is most useful when used with a `rcsinfo' forms specification, as\nit can verify that the proper fields of the form have been filled in by the user committing\nthe change.\n\nYou can use the `cvsignore' file to specify the default list of files to ignore during up‐‐\ndate.\n\nYou can use the `history' file to record the cvs commands that affect the repository. The\ncreation of this file enables history logging.\n", "subsections": [] }, "FILES": { "content": "", "subsections": [ { "name": "modules", "content": "The `modules' file records your definitions of names for collections of source code.\ncvs will use these definitions if you use cvs to check in a file with the right format\nto `$CVSROOT/CVSROOT/modules,v'.\n\nThe `modules' file may contain blank lines and comments (lines beginning with `#') as\nwell as module definitions. Long lines can be continued on the next line by specify‐\ning a backslash (``\\'') as the last character on the line.\n\nA module definition is a single line of the `modules' file, in either of two formats.\nIn both cases, mname represents the symbolic module name, and the remainder of the\nline is its definition.\n\nmname -a aliases...\nThis represents the simplest way of defining a module mname. The `-a' flags the defi‐\nnition as a simple alias: cvs will treat any use of mname (as a command argument) as\nif the list of names aliases had been specified instead. aliases may contain either\nother module names or paths. When you use paths in aliases, `cvs checkout' creates\nall intermediate directories in the working directory, just as if the path had been\nspecified explicitly in the cvs arguments.\n\nmname [ options ] dir [ files... ] [ &module... ]\n\nIn the simplest case, this form of module definition reduces to `mname dir'. This de‐\nfines all the files in directory dir as module mname. dir is a relative path (from\n$CVSROOT) to a directory of source in one of the source repositories. In this case,\non checkout, a single directory called mname is created as a working directory; no in‐\ntermediate directory levels are used by default, even if dir was a path involving sev‐\neral directory levels.\n\nBy explicitly specifying files in the module definition after dir, you can select par‐\nticular files from directory dir. The sample definition for modules is an example of\na module defined with a single file from a particular directory. Here is another ex‐\nample:\n\nm4test unsupported/gnu/m4 foreach.m4 forloop.m4\n\nWith this definition, executing `cvs checkout m4test' will create a single working di‐\nrectory `m4test' containing the two files listed, which both come from a common direc‐\ntory several levels deep in the cvs source repository.\n\nA module definition can refer to other modules by including `&module' in its defini‐\ntion. checkout creates a subdirectory for each such module, in your working directo‐\nry.\nNew in cvs 1.3; avoid this feature if sharing module definitions with older versions\nof cvs.\n\nFinally, you can use one or more of the following options in module definitions:\n\n`-d name', to name the working directory something other than the module name.\nNew in cvs 1.3; avoid this feature if sharing module definitions with older versions\nof cvs.\n\n`-i prog' allows you to specify a program prog to run whenever files in a module are\ncommitted. prog runs with a single argument, the full pathname of the affected direc‐\ntory in a source repository. The `commitinfo', `loginfo', and `editinfo' files pro‐\nvide other ways to call a program on commit.\n\n`-o prog' allows you to specify a program prog to run whenever files in a module are\nchecked out. prog runs with a single argument, the module name.\n\n`-e prog' allows you to specify a program prog to run whenever files in a module are\nexported. prog runs with a single argument, the module name.\n\n`-t prog' allows you to specify a program prog to run whenever files in a module are\ntagged. prog runs with two arguments: the module name and the symbolic tag specified\nto rtag.\n\n`-u prog' allows you to specify a program prog to run whenever `cvs update' is execut‐\ned from the top-level directory of the checked-out module. prog runs with a single\nargument, the full path to the source repository for this module.\n\ncommitinfo, loginfo, rcsinfo, editinfo\nThese files all specify programs to call at different points in the `cvs commit'\nprocess. They have a common structure. Each line is a pair of fields: a regular ex‐\npression, separated by whitespace from a filename or command-line template. Whenever\none of the regular expression matches a directory name in the repository, the rest of\nthe line is used. If the line begins with a # character, the entire line is consid‐\nered a comment and is ignored. Whitespace between the fields is also ignored.\n\nFor `loginfo', the rest of the line is a command-line template to execute. The tem‐\nplates can include not only a program name, but whatever list of arguments you wish.\nIf you write `%s' somewhere on the argument list, cvs supplies, at that point, the\nlist of files affected by the commit. The first entry in the list is the relative\npath within the source repository where the change is being made. The remaining argu‐\nments list the files that are being modified, added, or removed by this commit invoca‐\ntion.\n\nFor `taginfo', the rest of the line is a command-line template to execute. The argu‐\nments passed to the command are, in order, the tagname , operation (i.e. add for\n`tag', mov for `tag -F', and del for `tag -d`), repository , and any remaining are\npairs of filename revision . A non-zero exit of the filter program will cause the tag\nto be aborted.\n\nFor `commitinfo', the rest of the line is a command-line template to execute. The\ntemplate can include not only a program name, but whatever list of arguments you wish.\nThe full path to the current source repository is appended to the template, followed\nby the file names of any files involved in the commit (added, removed, and modified\nfiles).\n\nFor `rcsinfo', the rest of the line is the full path to a file that should be loaded\ninto the log message template.\n\nFor `editinfo', the rest of the line is a command-line template to execute. The tem‐\nplate can include not only a program name, but whatever list of arguments you wish.\nThe full path to the current log message template file is appended to the template.\n\nYou can use one of two special strings instead of a regular expression: `ALL' speci‐\nfies a command line template that must always be executed, and `DEFAULT' specifies a\ncommand line template to use if no regular expression is a match.\n\nThe `commitinfo' file contains commands to execute before any other commit activity,\nto allow you to check any conditions that must be satisfied before commit can proceed.\nThe rest of the commit will execute only if all selected commands from this file exit\nwith exit status 0.\n\nThe `rcsinfo' file allows you to specify log templates for the commit logging session;\nyou can use this to provide a form to edit when filling out the commit log. The field\nafter the regular expression, in this file, contains filenames (of files containing\nthe logging forms) rather than command templates.\n\nThe `editinfo' file allows you to execute a script before the commit starts, but after\nthe log information is recorded. These \"edit\" scripts can verify information recorded\nin the log file. If the edit script exits with a non-zero exit status, the commit is\naborted.\n\nThe `loginfo' file contains commands to execute at the end of a commit. The text\nspecified as a commit log message is piped through the command; typical uses include\nsending mail, filing an article in a newsgroup, or appending to a central file.\n\ncvsignore, .cvsignore\nThe default list of files (or sh(1) file name patterns) to ignore during `cvs update'.\nAt startup time, cvs loads the compiled in default list of file name patterns (see\ncvs(1)). Then the per-repository list included in $CVSROOT/CVSROOT/cvsignore is load‐\ned, if it exists. Then the per-user list is loaded from `$HOME/.cvsignore'. Finally,\nas cvs traverses through your directories, it will load any per-directory `.cvsignore'\nfiles whenever it finds one. These per-directory files are only valid for exactly the\ndirectory that contains them, not for any sub-directories.\n" }, { "name": "history", "content": "Create this file in $CVSROOT/CVSROOT to enable history logging (see the description of\n`cvs history').\n" } ] }, "SEE ALSO": { "content": "cvs(1),\n", "subsections": [] }, "COPYING": { "content": "Copyright © 1992 Cygnus Support, Brian Berliner, and Jeff Polk\n\nPermission is granted to make and distribute verbatim copies of this manual provided the\ncopyright notice and this permission notice are preserved on all copies.\n\nPermission is granted to copy and distribute modified versions of this manual under the con‐\nditions for verbatim copying, provided that the entire resulting derived work is distributed\nunder the terms of a permission notice identical to this one.\n\nPermission is granted to copy and distribute translations of this manual into another lan‐\nguage, under the above conditions for modified versions, except that this permission notice\nmay be included in translations approved by the Free Software Foundation instead of in the\noriginal English.\n\n\n\n12 February 1992 cvs(5)", "subsections": [] } }, "summary": "cvs - Concurrent Versions System support files", "flags": [], "examples": [], "see_also": [] }