diff options
Diffstat (limited to 'doc/cvs.info-2')
| -rw-r--r-- | doc/cvs.info-2 | 6139 |
1 files changed, 6139 insertions, 0 deletions
diff --git a/doc/cvs.info-2 b/doc/cvs.info-2 new file mode 100644 index 0000000..f95903c --- /dev/null +++ b/doc/cvs.info-2 @@ -0,0 +1,6139 @@ +This is cvs.info, produced by makeinfo version 4.8 from cvs.texinfo. + +INFO-DIR-SECTION GNU Packages +START-INFO-DIR-ENTRY +* CVS: (cvs). Concurrent Versions System +END-INFO-DIR-ENTRY +INFO-DIR-SECTION Individual utilities +START-INFO-DIR-ENTRY +* cvs: (cvs)CVS commands. Concurrent Versions System +END-INFO-DIR-ENTRY + + +File: cvs.info, Node: commit options, Next: commit examples, Up: commit + +A.10.1 commit options +--------------------- + +These standard options are supported by `commit' (*note Common +options::, for a complete description of them): + +`-l' + Local; run only in current working directory. + +`-R' + Commit directories recursively. This is on by default. + +`-r REVISION' + Commit to REVISION. REVISION must be either a branch, or a + revision on the main trunk that is higher than any existing + revision number (*note Assigning revisions::). You cannot commit + to a specific revision on a branch. + + `commit' also supports these options: + +`-c' + Refuse to commit files unless the user has registered a valid edit + on the file via `cvs edit'. This is most useful when `commit -c' + and `edit -c' have been placed in all `.cvsrc' files. A commit + can be forced anyways by either regestering an edit retroactively + via `cvs edit' (no changes to the file will be lost) or using the + `-f' option to commit. Support for `commit -c' requires both + client and a server versions 1.12.10 or greater. + +`-F FILE' + Read the log message from FILE, instead of invoking an editor. + +`-f' + Note that this is not the standard behavior of the `-f' option as + defined in *Note Common options::. + + Force CVS to commit a new revision even if you haven't made any + changes to the file. As of CVS version 1.12.10, it also causes + the `-c' option to be ignored. If the current revision of FILE is + 1.7, then the following two commands are equivalent: + + $ cvs commit -f FILE + $ cvs commit -r 1.8 FILE + + The `-f' option disables recursion (i.e., it implies `-l'). To + force CVS to commit a new revision for all files in all + subdirectories, you must use `-f -R'. + +`-m MESSAGE' + Use MESSAGE as the log message, instead of invoking an editor. + + +File: cvs.info, Node: commit examples, Prev: commit options, Up: commit + +A.10.2 commit examples +---------------------- + +A.10.2.1 Committing to a branch +............................... + +You can commit to a branch revision (one that has an even number of +dots) with the `-r' option. To create a branch revision, use the `-b' +option of the `rtag' or `tag' commands (*note Branching and merging::). +Then, either `checkout' or `update' can be used to base your sources +on the newly created branch. From that point on, all `commit' changes +made within these working sources will be automatically added to a +branch revision, thereby not disturbing main-line development in any +way. For example, if you had to create a patch to the 1.2 version of +the product, even though the 2.0 version is already under development, +you might do: + + $ cvs rtag -b -r FCS1_2 FCS1_2_Patch product_module + $ cvs checkout -r FCS1_2_Patch product_module + $ cd product_module + [[ hack away ]] + $ cvs commit + +This works automatically since the `-r' option is sticky. + +A.10.2.2 Creating the branch after editing +.......................................... + +Say you have been working on some extremely experimental software, +based on whatever revision you happened to checkout last week. If +others in your group would like to work on this software with you, but +without disturbing main-line development, you could commit your change +to a new branch. Others can then checkout your experimental stuff and +utilize the full benefit of CVS conflict resolution. The scenario might +look like: + + [[ hacked sources are present ]] + $ cvs tag -b EXPR1 + $ cvs update -r EXPR1 + $ cvs commit + + The `update' command will make the `-r EXPR1' option sticky on all +files. Note that your changes to the files will never be removed by the +`update' command. The `commit' will automatically commit to the +correct branch, because the `-r' is sticky. You could also do like +this: + + [[ hacked sources are present ]] + $ cvs tag -b EXPR1 + $ cvs commit -r EXPR1 + +but then, only those files that were changed by you will have the `-r +EXPR1' sticky flag. If you hack away, and commit without specifying +the `-r EXPR1' flag, some files may accidentally end up on the main +trunk. + + To work with you on the experimental change, others would simply do + + $ cvs checkout -r EXPR1 whatever_module + + +File: cvs.info, Node: diff, Next: export, Prev: commit, Up: CVS commands + +A.11 diff--Show differences between revisions +============================================= + + * Synopsis: diff [-lR] [-k kflag] [format_options] [(-r rev1[:date1] + | -D date1) [-r rev2[:date2] | -D date2]] [files...] + + * Requires: working directory, repository. + + * Changes: nothing. + + The `diff' command is used to compare different revisions of files. +The default action is to compare your working files with the revisions +they were based on, and report any differences that are found. + + If any file names are given, only those files are compared. If any +directories are given, all files under them will be compared. + + The exit status for diff is different than for other CVS commands; +for details *Note Exit status::. + +* Menu: + +* diff options:: diff options +* diff examples:: diff examples + + +File: cvs.info, Node: diff options, Next: diff examples, Up: diff + +A.11.1 diff options +------------------- + +These standard options are supported by `diff' (*note Common options::, +for a complete description of them): + +`-D DATE' + Use the most recent revision no later than DATE. See `-r' for how + this affects the comparison. + +`-k KFLAG' + Process keywords according to KFLAG. See *Note Keyword + substitution::. + +`-l' + Local; run only in current working directory. + +`-R' + Examine directories recursively. This option is on by default. + +`-r TAG[:DATE]' + Compare with revision specified by TAG or, when DATE is specified + and TAG is a branch tag, the version from the branch TAG as it + existed on DATE. Zero, one or two `-r' options can be present. + With no `-r' option, the working file will be compared with the + revision it was based on. With one `-r', that revision will be + compared to your current working file. With two `-r' options + those two revisions will be compared (and your working file will + not affect the outcome in any way). + + One or both `-r' options can be replaced by a `-D DATE' option, + described above. + + The following options specify the format of the output. They have +the same meaning as in GNU diff. Most options have two equivalent +names, one of which is a single letter preceded by `-', and the other +of which is a long name preceded by `--'. + +`-LINES' + Show LINES (an integer) lines of context. This option does not + specify an output format by itself; it has no effect unless it is + combined with `-c' or `-u'. This option is obsolete. For proper + operation, `patch' typically needs at least two lines of context. + +`-a' + Treat all files as text and compare them line-by-line, even if they + do not seem to be text. + +`-b' + Ignore trailing white space and consider all other sequences of + one or more white space characters to be equivalent. + +`-B' + Ignore changes that just insert or delete blank lines. + +`--binary' + Read and write data in binary mode. + +`--brief' + Report only whether the files differ, not the details of the + differences. + +`-c' + Use the context output format. + +`-C LINES' +`--context[=LINES]' + Use the context output format, showing LINES (an integer) lines of + context, or three if LINES is not given. For proper operation, + `patch' typically needs at least two lines of context. + +`--changed-group-format=FORMAT' + Use FORMAT to output a line group containing differing lines from + both files in if-then-else format. *Note Line group formats::. + +`-d' + Change the algorithm to perhaps find a smaller set of changes. + This makes `diff' slower (sometimes much slower). + +`-e' +`--ed' + Make output that is a valid `ed' script. + +`--expand-tabs' + Expand tabs to spaces in the output, to preserve the alignment of + tabs in the input files. + +`-f' + Make output that looks vaguely like an `ed' script but has changes + in the order they appear in the file. + +`-F REGEXP' + In context and unified format, for each hunk of differences, show + some of the last preceding line that matches REGEXP. + +`--forward-ed' + Make output that looks vaguely like an `ed' script but has changes + in the order they appear in the file. + +`-H' + Use heuristics to speed handling of large files that have numerous + scattered small changes. + +`--horizon-lines=LINES' + Do not discard the last LINES lines of the common prefix and the + first LINES lines of the common suffix. + +`-i' + Ignore changes in case; consider upper- and lower-case letters + equivalent. + +`-I REGEXP' + Ignore changes that just insert or delete lines that match REGEXP. + +`--ifdef=NAME' + Make merged if-then-else output using NAME. + +`--ignore-all-space' + Ignore white space when comparing lines. + +`--ignore-blank-lines' + Ignore changes that just insert or delete blank lines. + +`--ignore-case' + Ignore changes in case; consider upper- and lower-case to be the + same. + +`--ignore-matching-lines=REGEXP' + Ignore changes that just insert or delete lines that match REGEXP. + +`--ignore-space-change' + Ignore trailing white space and consider all other sequences of + one or more white space characters to be equivalent. + +`--initial-tab' + Output a tab rather than a space before the text of a line in + normal or context format. This causes the alignment of tabs in + the line to look normal. + +`-L LABEL' + Use LABEL instead of the file name in the context format and + unified format headers. + +`--label=LABEL' + Use LABEL instead of the file name in the context format and + unified format headers. + +`--left-column' + Print only the left column of two common lines in side by side + format. + +`--line-format=FORMAT' + Use FORMAT to output all input lines in if-then-else format. + *Note Line formats::. + +`--minimal' + Change the algorithm to perhaps find a smaller set of changes. + This makes `diff' slower (sometimes much slower). + +`-n' + Output RCS-format diffs; like `-f' except that each command + specifies the number of lines affected. + +`-N' +`--new-file' + In directory comparison, if a file is found in only one directory, + treat it as present but empty in the other directory. + +`--new-group-format=FORMAT' + Use FORMAT to output a group of lines taken from just the second + file in if-then-else format. *Note Line group formats::. + +`--new-line-format=FORMAT' + Use FORMAT to output a line taken from just the second file in + if-then-else format. *Note Line formats::. + +`--old-group-format=FORMAT' + Use FORMAT to output a group of lines taken from just the first + file in if-then-else format. *Note Line group formats::. + +`--old-line-format=FORMAT' + Use FORMAT to output a line taken from just the first file in + if-then-else format. *Note Line formats::. + +`-p' + Show which C function each change is in. + +`--rcs' + Output RCS-format diffs; like `-f' except that each command + specifies the number of lines affected. + +`--report-identical-files' +`-s' + Report when two files are the same. + +`--show-c-function' + Show which C function each change is in. + +`--show-function-line=REGEXP' + In context and unified format, for each hunk of differences, show + some of the last preceding line that matches REGEXP. + +`--side-by-side' + Use the side by side output format. + +`--speed-large-files' + Use heuristics to speed handling of large files that have numerous + scattered small changes. + +`--suppress-common-lines' + Do not print common lines in side by side format. + +`-t' + Expand tabs to spaces in the output, to preserve the alignment of + tabs in the input files. + +`-T' + Output a tab rather than a space before the text of a line in + normal or context format. This causes the alignment of tabs in + the line to look normal. + +`--text' + Treat all files as text and compare them line-by-line, even if they + do not appear to be text. + +`-u' + Use the unified output format. + +`--unchanged-group-format=FORMAT' + Use FORMAT to output a group of common lines taken from both files + in if-then-else format. *Note Line group formats::. + +`--unchanged-line-format=FORMAT' + Use FORMAT to output a line common to both files in if-then-else + format. *Note Line formats::. + +`-U LINES' +`--unified[=LINES]' + Use the unified output format, showing LINES (an integer) lines of + context, or three if LINES is not given. For proper operation, + `patch' typically needs at least two lines of context. + +`-w' + Ignore white space when comparing lines. + +`-W COLUMNS' +`--width=COLUMNS' + Use an output width of COLUMNS in side by side format. + +`-y' + Use the side by side output format. + +* Menu: + +* Line group formats:: Line group formats +* Line formats:: Line formats + + +File: cvs.info, Node: Line group formats, Next: Line formats, Up: diff options + +A.11.1.1 Line group formats +........................... + +Line group formats let you specify formats suitable for many +applications that allow if-then-else input, including programming +languages and text formatting languages. A line group format specifies +the output format for a contiguous group of similar lines. + + For example, the following command compares the TeX file `myfile' +with the original version from the repository, and outputs a merged +file in which old regions are surrounded by `\begin{em}'-`\end{em}' +lines, and new regions are surrounded by `\begin{bf}'-`\end{bf}' lines. + + cvs diff \ + --old-group-format='\begin{em} + %<\end{em} + ' \ + --new-group-format='\begin{bf} + %>\end{bf} + ' \ + myfile + + The following command is equivalent to the above example, but it is a +little more verbose, because it spells out the default line group +formats. + + cvs diff \ + --old-group-format='\begin{em} + %<\end{em} + ' \ + --new-group-format='\begin{bf} + %>\end{bf} + ' \ + --unchanged-group-format='%=' \ + --changed-group-format='\begin{em} + %<\end{em} + \begin{bf} + %>\end{bf} + ' \ + myfile + + Here is a more advanced example, which outputs a diff listing with +headers containing line numbers in a "plain English" style. + + cvs diff \ + --unchanged-group-format='' \ + --old-group-format='-------- %dn line%(n=1?:s) deleted at %df: + %<' \ + --new-group-format='-------- %dN line%(N=1?:s) added after %de: + %>' \ + --changed-group-format='-------- %dn line%(n=1?:s) changed at %df: + %<-------- to: + %>' \ + myfile + + To specify a line group format, use one of the options listed below. +You can specify up to four line group formats, one for each kind of +line group. You should quote FORMAT, because it typically contains +shell metacharacters. + +`--old-group-format=FORMAT' + These line groups are hunks containing only lines from the first + file. The default old group format is the same as the changed + group format if it is specified; otherwise it is a format that + outputs the line group as-is. + +`--new-group-format=FORMAT' + These line groups are hunks containing only lines from the second + file. The default new group format is same as the changed group + format if it is specified; otherwise it is a format that outputs + the line group as-is. + +`--changed-group-format=FORMAT' + These line groups are hunks containing lines from both files. The + default changed group format is the concatenation of the old and + new group formats. + +`--unchanged-group-format=FORMAT' + These line groups contain lines common to both files. The default + unchanged group format is a format that outputs the line group + as-is. + + In a line group format, ordinary characters represent themselves; +conversion specifications start with `%' and have one of the following +forms. + +`%<' + stands for the lines from the first file, including the trailing + newline. Each line is formatted according to the old line format + (*note Line formats::). + +`%>' + stands for the lines from the second file, including the trailing + newline. Each line is formatted according to the new line format. + +`%=' + stands for the lines common to both files, including the trailing + newline. Each line is formatted according to the unchanged line + format. + +`%%' + stands for `%'. + +`%c'C'' + where C is a single character, stands for C. C may not be a + backslash or an apostrophe. For example, `%c':'' stands for a + colon, even inside the then-part of an if-then-else format, which + a colon would normally terminate. + +`%c'\O'' + where O is a string of 1, 2, or 3 octal digits, stands for the + character with octal code O. For example, `%c'\0'' stands for a + null character. + +`FN' + where F is a `printf' conversion specification and N is one of the + following letters, stands for N's value formatted with F. + + `e' + The line number of the line just before the group in the old + file. + + `f' + The line number of the first line in the group in the old + file; equals E + 1. + + `l' + The line number of the last line in the group in the old file. + + `m' + The line number of the line just after the group in the old + file; equals L + 1. + + `n' + The number of lines in the group in the old file; equals L - + F + 1. + + `E, F, L, M, N' + Likewise, for lines in the new file. + + + The `printf' conversion specification can be `%d', `%o', `%x', or + `%X', specifying decimal, octal, lower case hexadecimal, or upper + case hexadecimal output respectively. After the `%' the following + options can appear in sequence: a `-' specifying + left-justification; an integer specifying the minimum field width; + and a period followed by an optional integer specifying the + minimum number of digits. For example, `%5dN' prints the number + of new lines in the group in a field of width 5 characters, using + the `printf' format `"%5d"'. + +`(A=B?T:E)' + If A equals B then T else E. A and B are each either a decimal + constant or a single letter interpreted as above. This format + spec is equivalent to T if A's value equals B's; otherwise it is + equivalent to E. + + For example, `%(N=0?no:%dN) line%(N=1?:s)' is equivalent to `no + lines' if N (the number of lines in the group in the new file) is + 0, to `1 line' if N is 1, and to `%dN lines' otherwise. + + +File: cvs.info, Node: Line formats, Prev: Line group formats, Up: diff options + +A.11.1.2 Line formats +..................... + +Line formats control how each line taken from an input file is output +as part of a line group in if-then-else format. + + For example, the following command outputs text with a one-column +change indicator to the left of the text. The first column of output +is `-' for deleted lines, `|' for added lines, and a space for +unchanged lines. The formats contain newline characters where newlines +are desired on output. + + cvs diff \ + --old-line-format='-%l + ' \ + --new-line-format='|%l + ' \ + --unchanged-line-format=' %l + ' \ + myfile + + To specify a line format, use one of the following options. You +should quote FORMAT, since it often contains shell metacharacters. + +`--old-line-format=FORMAT' + formats lines just from the first file. + +`--new-line-format=FORMAT' + formats lines just from the second file. + +`--unchanged-line-format=FORMAT' + formats lines common to both files. + +`--line-format=FORMAT' + formats all lines; in effect, it sets all three above options + simultaneously. + + In a line format, ordinary characters represent themselves; +conversion specifications start with `%' and have one of the following +forms. + +`%l' + stands for the contents of the line, not counting its trailing + newline (if any). This format ignores whether the line is + incomplete. + +`%L' + stands for the contents of the line, including its trailing newline + (if any). If a line is incomplete, this format preserves its + incompleteness. + +`%%' + stands for `%'. + +`%c'C'' + where C is a single character, stands for C. C may not be a + backslash or an apostrophe. For example, `%c':'' stands for a + colon. + +`%c'\O'' + where O is a string of 1, 2, or 3 octal digits, stands for the + character with octal code O. For example, `%c'\0'' stands for a + null character. + +`Fn' + where F is a `printf' conversion specification, stands for the + line number formatted with F. For example, `%.5dn' prints the + line number using the `printf' format `"%.5d"'. *Note Line group + formats::, for more about printf conversion specifications. + + + The default line format is `%l' followed by a newline character. + + If the input contains tab characters and it is important that they +line up on output, you should ensure that `%l' or `%L' in a line format +is just after a tab stop (e.g. by preceding `%l' or `%L' with a tab +character), or you should use the `-t' or `--expand-tabs' option. + + Taken together, the line and line group formats let you specify many +different formats. For example, the following command uses a format +similar to `diff''s normal format. You can tailor this command to get +fine control over `diff''s output. + + cvs diff \ + --old-line-format='< %l + ' \ + --new-line-format='> %l + ' \ + --old-group-format='%df%(f=l?:,%dl)d%dE + %<' \ + --new-group-format='%dea%dF%(F=L?:,%dL) + %>' \ + --changed-group-format='%df%(f=l?:,%dl)c%dF%(F=L?:,%dL) + %<--- + %>' \ + --unchanged-group-format='' \ + myfile + + +File: cvs.info, Node: diff examples, Prev: diff options, Up: diff + +A.11.2 diff examples +-------------------- + +The following line produces a Unidiff (`-u' flag) between revision 1.14 +and 1.19 of `backend.c'. Due to the `-kk' flag no keywords are +substituted, so differences that only depend on keyword substitution +are ignored. + + $ cvs diff -kk -u -r 1.14 -r 1.19 backend.c + + Suppose the experimental branch EXPR1 was based on a set of files +tagged RELEASE_1_0. To see what has happened on that branch, the +following can be used: + + $ cvs diff -r RELEASE_1_0 -r EXPR1 + + A command like this can be used to produce a context diff between +two releases: + + $ cvs diff -c -r RELEASE_1_0 -r RELEASE_1_1 > diffs + + If you are maintaining ChangeLogs, a command like the following just +before you commit your changes may help you write the ChangeLog entry. +All local modifications that have not yet been committed will be +printed. + + $ cvs diff -u | less + + +File: cvs.info, Node: export, Next: history, Prev: diff, Up: CVS commands + +A.12 export--Export sources from CVS, similar to checkout +========================================================= + + * Synopsis: export [-flNnR] (-r rev[:date] | -D date) [-k subst] [-d + dir] module... + + * Requires: repository. + + * Changes: current directory. + + This command is a variant of `checkout'; use it when you want a copy +of the source for module without the CVS administrative directories. +For example, you might use `export' to prepare source for shipment +off-site. This command requires that you specify a date or tag (with +`-D' or `-r'), so that you can count on reproducing the source you ship +to others (and thus it always prunes empty directories). + + One often would like to use `-kv' with `cvs export'. This causes +any keywords to be expanded such that an import done at some other site +will not lose the keyword revision information. But be aware that +doesn't handle an export containing binary files correctly. Also be +aware that after having used `-kv', one can no longer use the `ident' +command (which is part of the RCS suite--see ident(1)) which looks for +keyword strings. If you want to be able to use `ident' you must not +use `-kv'. + +* Menu: + +* export options:: export options + + +File: cvs.info, Node: export options, Up: export + +A.12.1 export options +--------------------- + +These standard options are supported by `export' (*note Common +options::, for a complete description of them): + +`-D DATE' + Use the most recent revision no later than DATE. + +`-f' + If no matching revision is found, retrieve the most recent + revision (instead of ignoring the file). + +`-l' + Local; run only in current working directory. + +`-n' + Do not run any checkout program. + +`-R' + Export directories recursively. This is on by default. + +`-r TAG[:DATE]' + Export the revision specified by TAG or, when DATE is specified + and TAG is a branch tag, the version from the branch TAG as it + existed on DATE. See *Note Common options::. + + In addition, these options (that are common to `checkout' and +`export') are also supported: + +`-d DIR' + Create a directory called DIR for the working files, instead of + using the module name. *Note checkout options::, for complete + details on how CVS handles this flag. + +`-k SUBST' + Set keyword expansion mode (*note Substitution modes::). + +`-N' + Only useful together with `-d DIR'. *Note checkout options::, for + complete details on how CVS handles this flag. + + +File: cvs.info, Node: history, Next: import, Prev: export, Up: CVS commands + +A.13 history--Show status of files and users +============================================ + + * Synopsis: history [-report] [-flags] [-options args] [files...] + + * Requires: the file `$CVSROOT/CVSROOT/history' + + * Changes: nothing. + + CVS can keep a history log that tracks each use of most CVS +commands. You can use `history' to display this information in various +formats. + + To enable logging, the `LogHistory' config option must be set to +some value other than the empty string and the history file specified by +the `HistoryLogPath' option must be writable by all users who may run +the CVS executable (*note config::). + + To enable the `history' command, logging must be enabled as above and +the `HistorySearchPath' config option (*note config::) must be set to +specify some number of the history logs created thereby and these files +must be readable by each user who might run the `history' command. + + Creating a repository via the `cvs init' command will enable logging +of all possible events to a single history log file +(`$CVSROOT/CVSROOT/history') with read and write permissions for all +users (*note Creating a repository::). + + *Note_ `history' uses `-f', `-l', `-n', and `-p' in ways that +conflict with the normal use inside CVS (*note Common options::).* + +* Menu: + +* history options:: history options + + +File: cvs.info, Node: history options, Up: history + +A.13.1 history options +---------------------- + +Several options (shown above as `-report') control what kind of +report is generated: + +`-c' + Report on each time commit was used (i.e., each time the + repository was modified). + +`-e' + Everything (all record types). Equivalent to specifying `-x' with + all record types. Of course, `-e' will also include record types + which are added in a future version of CVS; if you are writing a + script which can only handle certain record types, you'll want to + specify `-x'. + +`-m MODULE' + Report on a particular module. (You can meaningfully use `-m' + more than once on the command line.) + +`-o' + Report on checked-out modules. This is the default report type. + +`-T' + Report on all tags. + +`-x TYPE' + Extract a particular set of record types TYPE from the CVS + history. The types are indicated by single letters, which you may + specify in combination. + + Certain commands have a single record type: + + `F' + release + + `O' + checkout + + `E' + export + + `T' + rtag + + One of five record types may result from an update: + + `C' + A merge was necessary but collisions were detected (requiring + manual merging). + + `G' + A merge was necessary and it succeeded. + + `U' + A working file was copied from the repository. + + `P' + A working file was patched to match the repository. + + `W' + The working copy of a file was deleted during update (because + it was gone from the repository). + + One of three record types results from commit: + + `A' + A file was added for the first time. + + `M' + A file was modified. + + `R' + A file was removed. + + The options shown as `-flags' constrain or expand the report without +requiring option arguments: + +`-a' + Show data for all users (the default is to show data only for the + user executing `history'). + +`-l' + Show last modification only. + +`-w' + Show only the records for modifications done from the same working + directory where `history' is executing. + + The options shown as `-options ARGS' constrain the report based on +an argument: + +`-b STR' + Show data back to a record containing the string STR in either + the module name, the file name, or the repository path. + +`-D DATE' + Show data since DATE. This is slightly different from the normal + use of `-D DATE', which selects the newest revision older than + DATE. + +`-f FILE' + Show data for a particular file (you can specify several `-f' + options on the same command line). This is equivalent to + specifying the file on the command line. + +`-n MODULE' + Show data for a particular module (you can specify several `-n' + options on the same command line). + +`-p REPOSITORY' + Show data for a particular source repository (you can specify + several `-p' options on the same command line). + +`-r REV' + Show records referring to revisions since the revision or tag + named REV appears in individual RCS files. Each RCS file is + searched for the revision or tag. + +`-t TAG' + Show records since tag TAG was last added to the history file. + This differs from the `-r' flag above in that it reads only the + history file, not the RCS files, and is much faster. + +`-u NAME' + Show records for user NAME. + +`-z TIMEZONE' + Show times in the selected records using the specified time zone + instead of UTC. + + +File: cvs.info, Node: import, Next: log, Prev: history, Up: CVS commands + +A.14 import--Import sources into CVS, using vendor branches +=========================================================== + + * Synopsis: import [-options] repository vendortag releasetag... + + * Requires: Repository, source distribution directory. + + * Changes: repository. + + Use `import' to incorporate an entire source distribution from an +outside source (e.g., a source vendor) into your source repository +directory. You can use this command both for initial creation of a +repository, and for wholesale updates to the module from the outside +source. *Note Tracking sources::, for a discussion on this subject. + + The REPOSITORY argument gives a directory name (or a path to a +directory) under the CVS root directory for repositories; if the +directory did not exist, import creates it. + + When you use import for updates to source that has been modified in +your source repository (since a prior import), it will notify you of +any files that conflict in the two branches of development; use +`checkout -j' to reconcile the differences, as import instructs you to +do. + + If CVS decides a file should be ignored (*note cvsignore::), it does +not import it and prints `I ' followed by the filename (*note import +output::, for a complete description of the output). + + If the file `$CVSROOT/CVSROOT/cvswrappers' exists, any file whose +names match the specifications in that file will be treated as packages +and the appropriate filtering will be performed on the file/directory +before being imported. *Note Wrappers::. + + The outside source is saved in a first-level branch, by default +1.1.1. Updates are leaves of this branch; for example, files from the +first imported collection of source will be revision 1.1.1.1, then +files from the first imported update will be revision 1.1.1.2, and so +on. + + At least three arguments are required. REPOSITORY is needed to +identify the collection of source. VENDORTAG is a tag for the entire +branch (e.g., for 1.1.1). You must also specify at least one +RELEASETAG to uniquely identify the files at the leaves created each +time you execute `import'. The RELEASETAG should be new, not +previously existing in the repository file, and uniquely identify the +imported release, + + Note that `import' does _not_ change the directory in which you +invoke it. In particular, it does not set up that directory as a CVS +working directory; if you want to work with the sources import them +first and then check them out into a different directory (*note Getting +the source::). + +* Menu: + +* import options:: import options +* import output:: import output +* import examples:: import examples + + +File: cvs.info, Node: import options, Next: import output, Up: import + +A.14.1 import options +--------------------- + +This standard option is supported by `import' (*note Common options::, +for a complete description): + +`-m MESSAGE' + Use MESSAGE as log information, instead of invoking an editor. + + There are the following additional special options. + +`-b BRANCH' + See *Note Multiple vendor branches::. + +`-k SUBST' + Indicate the keyword expansion mode desired. This setting will + apply to all files created during the import, but not to any files + that previously existed in the repository. See *Note Substitution + modes::, for a list of valid `-k' settings. + +`-I NAME' + Specify file names that should be ignored during import. You can + use this option repeatedly. To avoid ignoring any files at all + (even those ignored by default), specify `-I !'. + + NAME can be a file name pattern of the same type that you can + specify in the `.cvsignore' file. *Note cvsignore::. + +`-W SPEC' + Specify file names that should be filtered during import. You can + use this option repeatedly. + + SPEC can be a file name pattern of the same type that you can + specify in the `.cvswrappers' file. *Note Wrappers::. + +`-X' + Modify the algorithm used by CVS when importing new files so that + new files do not immediately appear on the main trunk. + + Specifically, this flag causes CVS to mark new files as if they + were deleted on the main trunk, by taking the following steps for + each file in addition to those normally taken on import: creating + a new revision on the main trunk indicating that the new file is + `dead', resetting the new file's default branch, and placing the + file in the Attic (*note Attic::) directory. + + Use of this option can be forced on a repository-wide basis by + setting the `ImportNewFilesToVendorBranchOnly' option in + CVSROOT/config (*note config::). + + +File: cvs.info, Node: import output, Next: import examples, Prev: import options, Up: import + +A.14.2 import output +-------------------- + +`import' keeps you informed of its progress by printing a line for each +file, preceded by one character indicating the status of the file: + +`U FILE' + The file already exists in the repository and has not been locally + modified; a new revision has been created (if necessary). + +`N FILE' + The file is a new file which has been added to the repository. + +`C FILE' + The file already exists in the repository but has been locally + modified; you will have to merge the changes. + +`I FILE' + The file is being ignored (*note cvsignore::). + +`L FILE' + The file is a symbolic link; `cvs import' ignores symbolic links. + People periodically suggest that this behavior should be changed, + but if there is a consensus on what it should be changed to, it is + not apparent. (Various options in the `modules' file can be used + to recreate symbolic links on checkout, update, etc.; *note + modules::.) + + +File: cvs.info, Node: import examples, Prev: import output, Up: import + +A.14.3 import examples +---------------------- + +See *Note Tracking sources::, and *Note From files::. + + +File: cvs.info, Node: log, Next: ls & rls, Prev: import, Up: CVS commands + +A.15 log--Print out log information for files +============================================= + + * Synopsis: log [options] [files...] + + * Requires: repository, working directory. + + * Changes: nothing. + + Display log information for files. `log' used to call the RCS +utility `rlog'. Although this is no longer true in the current +sources, this history determines the format of the output and the +options, which are not quite in the style of the other CVS commands. + + The output includes the location of the RCS file, the "head" +revision (the latest revision on the trunk), all symbolic names (tags) +and some other things. For each revision, the revision number, the +date, the author, the number of lines added/deleted, the commitid and +the log message are printed. All dates are displayed in local time at +the client. This is typically specified in the `$TZ' environment +variable, which can be set to govern how `log' displays dates. + + *Note_ `log' uses `-R' in a way that conflicts with the normal use +inside CVS (*note Common options::).* + +* Menu: + +* log options:: log options +* log examples:: log examples + + +File: cvs.info, Node: log options, Next: log examples, Up: log + +A.15.1 log options +------------------ + +By default, `log' prints all information that is available. All other +options restrict the output. Note that the revision selection options +(`-d', `-r', `-s', and `-w') have no effect, other than possibly +causing a search for files in Attic directories, when used in +conjunction with the options that restrict the output to only `log' +header fields (`-b', `-h', `-R', and `-t') unless the `-S' option is +also specified. + +`-b' + Print information about the revisions on the default branch, + normally the highest branch on the trunk. + +`-d DATES' + Print information about revisions with a checkin date/time in the + range given by the semicolon-separated list of dates. The date + formats accepted are those accepted by the `-D' option to many + other CVS commands (*note Common options::). Dates can be + combined into ranges as follows: + + `D1<D2' + `D2>D1' + Select the revisions that were deposited between D1 and D2. + + `<D' + `D>' + Select all revisions dated D or earlier. + + `D<' + `>D' + Select all revisions dated D or later. + + `D' + Select the single, latest revision dated D or earlier. + + The `>' or `<' characters may be followed by `=' to indicate an + inclusive range rather than an exclusive one. + + Note that the separator is a semicolon (;). + +`-h' + Print only the name of the RCS file, name of the file in the + working directory, head, default branch, access list, locks, + symbolic names, and suffix. + +`-l' + Local; run only in current working directory. (Default is to run + recursively). + +`-N' + Do not print the list of tags for this file. This option can be + very useful when your site uses a lot of tags, so rather than + "more"'ing over 3 pages of tag information, the log information is + presented without tags at all. + +`-R' + Print only the name of the RCS file. + +`-rREVISIONS' + Print information about revisions given in the comma-separated + list REVISIONS of revisions and ranges. The following table + explains the available range formats: + + `REV1:REV2' + Revisions REV1 to REV2 (which must be on the same branch). + + `REV1::REV2' + The same, but excluding REV1. + + `:REV' + `::REV' + Revisions from the beginning of the branch up to and + including REV. + + `REV:' + Revisions starting with REV to the end of the branch + containing REV. + + `REV::' + Revisions starting just after REV to the end of the branch + containing REV. + + `BRANCH' + An argument that is a branch means all revisions on that + branch. + + `BRANCH1:BRANCH2' + `BRANCH1::BRANCH2' + A range of branches means all revisions on the branches in + that range. + + `BRANCH.' + The latest revision in BRANCH. + + A bare `-r' with no revisions means the latest revision on the + default branch, normally the trunk. There can be no space between + the `-r' option and its argument. + +`-S' + Suppress the header if no revisions are selected. + +`-s STATES' + Print information about revisions whose state attributes match one + of the states given in the comma-separated list STATES. + Individual states may be any text string, though CVS commonly only + uses two states, `Exp' and `dead'. See *Note admin options:: for + more information. + +`-t' + Print the same as `-h', plus the descriptive text. + +`-wLOGINS' + Print information about revisions checked in by users with login + names appearing in the comma-separated list LOGINS. If LOGINS is + omitted, the user's login is assumed. There can be no space + between the `-w' option and its argument. + + `log' prints the intersection of the revisions selected with the +options `-d', `-s', and `-w', intersected with the union of the +revisions selected by `-b' and `-r'. + + +File: cvs.info, Node: log examples, Prev: log options, Up: log + +A.15.2 log examples +------------------- + +Since `log' shows dates in local time, you might want to see them in +Coordinated Universal Time (UTC) or some other timezone. To do this +you can set your `$TZ' environment variable before invoking CVS: + + $ TZ=UTC cvs log foo.c + $ TZ=EST cvs log bar.c + + (If you are using a `csh'-style shell, like `tcsh', you would need +to prefix the examples above with `env'.) + + +File: cvs.info, Node: ls & rls, Next: rdiff, Prev: log, Up: CVS commands + +A.16 ls & rls +============= + + * ls [-e | -l] [-RP] [-r tag[:date]] [-D date] [path...] + + * Requires: repository for `rls', repository & working directory for + `ls'. + + * Changes: nothing. + + * Synonym: `dir' & `list' are synonyms for `ls' and `rdir' & `rlist' + are synonyms for `rls'. + + The `ls' and `rls' commands are used to list files and directories +in the repository. + + By default `ls' lists the files and directories that belong in your +working directory, what would be there after an `update'. + + By default `rls' lists the files and directories on the tip of the +trunk in the topmost directory of the repository. + + Both commands accept an optional list of file and directory names, +relative to the working directory for `ls' and the topmost directory of +the repository for `rls'. Neither is recursive by default. + +* Menu: + +* ls & rls options:: ls & rls options +* rls examples: rls examples + + +File: cvs.info, Node: ls & rls options, Next: rls examples, Up: ls & rls + +A.16.1 ls & rls options +----------------------- + +These standard options are supported by `ls' & `rls': + +`-d' + Show dead revisions (with tag when specified). + +`-e' + Display in CVS/Entries format. This format is meant to remain + easily parsable by automation. + +`-l' + Display all details. + +`-P' + Don't list contents of empty directories when recursing. + +`-R' + List recursively. + +`-r TAG[:DATE]' + Show files specified by TAG or, when DATE is specified and TAG is + a branch tag, the version from the branch TAG as it existed on + DATE. See *Note Common options::. + +`-D DATE' + Show files from date. + + +File: cvs.info, Node: rls examples, Prev: ls & rls options, Up: ls & rls + +A.16.2 rls examples +------------------- + + $ cvs rls + cvs rls: Listing module: `.' + CVSROOT + first-dir + + $ cvs rls CVSROOT + cvs rls: Listing module: `CVSROOT' + checkoutlist + commitinfo + config + cvswrappers + loginfo + modules + notify + rcsinfo + taginfo + verifymsg + + +File: cvs.info, Node: rdiff, Next: release, Prev: ls & rls, Up: CVS commands + +A.17 rdiff--'patch' format diffs between releases +================================================= + + * rdiff [-flags] [-V vn] (-r tag1[:date1] | -D date1) [-r + tag2[:date2] | -D date2] modules... + + * Requires: repository. + + * Changes: nothing. + + * Synonym: patch + + Builds a Larry Wall format patch(1) file between two releases, that +can be fed directly into the `patch' program to bring an old release +up-to-date with the new release. (This is one of the few CVS commands +that operates directly from the repository, and doesn't require a prior +checkout.) The diff output is sent to the standard output device. + + You can specify (using the standard `-r' and `-D' options) any +combination of one or two revisions or dates. If only one revision or +date is specified, the patch file reflects differences between that +revision or date and the current head revisions in the RCS file. + + Note that if the software release affected is contained in more than +one directory, then it may be necessary to specify the `-p' option to +the `patch' command when patching the old sources, so that `patch' is +able to find the files that are located in other directories. + +* Menu: + +* rdiff options:: rdiff options +* rdiff examples:: rdiff examples + + +File: cvs.info, Node: rdiff options, Next: rdiff examples, Up: rdiff + +A.17.1 rdiff options +-------------------- + +These standard options are supported by `rdiff' (*note Common +options::, for a complete description of them): + +`-D DATE' + Use the most recent revision no later than DATE. + +`-f' + If no matching revision is found, retrieve the most recent + revision (instead of ignoring the file). + +`-k KFLAG' + Process keywords according to KFLAG. See *Note Keyword + substitution::. + +`-l' + Local; don't descend subdirectories. + +`-R' + Examine directories recursively. This option is on by default. + +`-r TAG' + Use the revision specified by TAG, or when DATE is specified and + TAG is a branch tag, the version from the branch TAG as it existed + on DATE. See *Note Common options::. + + In addition to the above, these options are available: + +`-c' + Use the context diff format. This is the default format. + +`-s' + Create a summary change report instead of a patch. The summary + includes information about files that were changed or added + between the releases. It is sent to the standard output device. + This is useful for finding out, for example, which files have + changed between two dates or revisions. + +`-t' + A diff of the top two revisions is sent to the standard output + device. This is most useful for seeing what the last change to a + file was. + +`-u' + Use the unidiff format for the context diffs. Remember that old + versions of the `patch' program can't handle the unidiff format, + so if you plan to post this patch to the net you should probably + not use `-u'. + +`-V VN' + Expand keywords according to the rules current in RCS version VN + (the expansion format changed with RCS version 5). Note that this + option is no longer accepted. CVS will always expand keywords the + way that RCS version 5 does. + + +File: cvs.info, Node: rdiff examples, Prev: rdiff options, Up: rdiff + +A.17.2 rdiff examples +--------------------- + +Suppose you receive mail from foo@example.net asking for an update from +release 1.2 to 1.4 of the tc compiler. You have no such patches on +hand, but with CVS that can easily be fixed with a command such as this: + + $ cvs rdiff -c -r FOO1_2 -r FOO1_4 tc | \ + $$ Mail -s 'The patches you asked for' foo@example.net + + Suppose you have made release 1.3, and forked a branch called +`R_1_3fix' for bug fixes. `R_1_3_1' corresponds to release 1.3.1, +which was made some time ago. Now, you want to see how much +development has been done on the branch. This command can be used: + + $ cvs patch -s -r R_1_3_1 -r R_1_3fix module-name + cvs rdiff: Diffing module-name + File ChangeLog,v changed from revision 1.52.2.5 to 1.52.2.6 + File foo.c,v changed from revision 1.52.2.3 to 1.52.2.4 + File bar.h,v changed from revision 1.29.2.1 to 1.2 + + +File: cvs.info, Node: release, Next: server & pserver, Prev: rdiff, Up: CVS commands + +A.18 release--Indicate that a Module is no longer in use +======================================================== + + * release [-d] directories... + + * Requires: Working directory. + + * Changes: Working directory, history log. + + This command is meant to safely cancel the effect of `cvs checkout'. +Since CVS doesn't lock files, it isn't strictly necessary to use this +command. You can always simply delete your working directory, if you +like; but you risk losing changes you may have forgotten, and you leave +no trace in the CVS history file (*note history file::) that you've +abandoned your checkout. + + Use `cvs release' to avoid these problems. This command checks that +no uncommitted changes are present; that you are executing it from +immediately above a CVS working directory; and that the repository +recorded for your files is the same as the repository defined in the +module database. + + If all these conditions are true, `cvs release' leaves a record of +its execution (attesting to your intentionally abandoning your +checkout) in the CVS history log. + +* Menu: + +* release options:: release options +* release output:: release output +* release examples:: release examples + + +File: cvs.info, Node: release options, Next: release output, Up: release + +A.18.1 release options +---------------------- + +The `release' command supports one command option: + +`-d' + Delete your working copy of the file if the release succeeds. If + this flag is not given your files will remain in your working + directory. + + *WARNING: The `release' command deletes all directories and files + recursively. This has the very serious side-effect that any + directory that you have created inside your checked-out sources, + and not added to the repository (using the `add' command; *note + Adding files::) will be silently deleted--even if it is non-empty!* + + +File: cvs.info, Node: release output, Next: release examples, Prev: release options, Up: release + +A.18.2 release output +--------------------- + +Before `release' releases your sources it will print a one-line message +for any file that is not up-to-date. + +`U FILE' +`P FILE' + There exists a newer revision of this file in the repository, and + you have not modified your local copy of the file (`U' and `P' + mean the same thing). + +`A FILE' + The file has been added to your private copy of the sources, but + has not yet been committed to the repository. If you delete your + copy of the sources this file will be lost. + +`R FILE' + The file has been removed from your private copy of the sources, + but has not yet been removed from the repository, since you have + not yet committed the removal. *Note commit::. + +`M FILE' + The file is modified in your working directory. There might also + be a newer revision inside the repository. + +`? FILE' + FILE is in your working directory, but does not correspond to + anything in the source repository, and is not in the list of files + for CVS to ignore (see the description of the `-I' option, and + *note cvsignore::). If you remove your working sources, this file + will be lost. + + +File: cvs.info, Node: release examples, Prev: release output, Up: release + +A.18.3 release examples +----------------------- + +Release the `tc' directory, and delete your local working copy of the +files. + + $ cd .. # You must stand immediately above the + # sources when you issue `cvs release'. + $ cvs release -d tc + You have [0] altered files in this repository. + Are you sure you want to release (and delete) directory `tc': y + $ + + +File: cvs.info, Node: server & pserver, Next: update, Prev: release, Up: CVS commands + +A.19 server & pserver--Act as a server for a client on stdin/stdout +=================================================================== + + * pserver [-c path] + + server [-c path] + + * Requires: repository, client conversation on stdin/stdout + + * Changes: Repository or, indirectly, client working directory. + + The CVS `server' and `pserver' commands are used to provide +repository access to remote clients and expect a client conversation on +stdin & stdout. Typically these commands are launched from `inetd' or +via `ssh' (*note Remote repositories::). + + `server' expects that the client has already been authenticated +somehow, typically via SSH, and `pserver' attempts to authenticate the +client itself. + + Only one option is available with the `server' and `pserver' +commands: + +`-c path' + Load configuration from PATH rather than the default location + `$CVSROOT/CVSROOT/config' (*note config::). PATH must be + `/etc/cvs.conf' or prefixed by `/etc/cvs/'. This option is + supported beginning with CVS release 1.12.13. + + +File: cvs.info, Node: update, Prev: server & pserver, Up: CVS commands + +A.20 update--Bring work tree in sync with repository +==================================================== + + * update [-ACdflPpR] [-I name] [-j rev [-j rev]] [-k kflag] [-r + tag[:date] | -D date] [-W spec] files... + + * Requires: repository, working directory. + + * Changes: working directory. + + After you've run checkout to create your private copy of source from +the common repository, other developers will continue changing the +central source. From time to time, when it is convenient in your +development process, you can use the `update' command from within your +working directory to reconcile your work with any revisions applied to +the source repository since your last checkout or update. Without the +`-C' option, `update' will also merge any differences between the local +copy of files and their base revisions into any destination revisions +specified with `-r', `-D', or `-A'. + +* Menu: + +* update options:: update options +* update output:: update output + + +File: cvs.info, Node: update options, Next: update output, Up: update + +A.20.1 update options +--------------------- + +These standard options are available with `update' (*note Common +options::, for a complete description of them): + +`-D date' + Use the most recent revision no later than DATE. This option is + sticky, and implies `-P'. See *Note Sticky tags::, for more + information on sticky tags/dates. + +`-f' + Only useful with the `-D' or `-r' flags. If no matching revision + is found, retrieve the most recent revision (instead of ignoring + the file). + +`-k KFLAG' + Process keywords according to KFLAG. See *Note Keyword + substitution::. This option is sticky; future updates of this + file in this working directory will use the same KFLAG. The + `status' command can be viewed to see the sticky options. See + *Note Invoking CVS::, for more information on the `status' command. + +`-l' + Local; run only in current working directory. *Note Recursive + behavior::. + +`-P' + Prune empty directories. See *Note Moving directories::. + +`-p' + Pipe files to the standard output. + +`-R' + Update directories recursively (default). *Note Recursive + behavior::. + +`-r TAG[:DATE]' + Retrieve the revisions specified by TAG or, when DATE is specified + and TAG is a branch tag, the version from the branch TAG as it + existed on DATE. This option is sticky, and implies `-P'. See + *Note Sticky tags::, for more information on sticky tags/dates. + Also see *Note Common options::. + + These special options are also available with `update'. + +`-A' + Reset any sticky tags, dates, or `-k' options. See *Note Sticky + tags::, for more information on sticky tags/dates. + +`-C' + Overwrite locally modified files with clean copies from the + repository (the modified file is saved in `.#FILE.REVISION', + however). + +`-d' + Create any directories that exist in the repository if they're + missing from the working directory. Normally, `update' acts only + on directories and files that were already enrolled in your + working directory. + + This is useful for updating directories that were created in the + repository since the initial checkout; but it has an unfortunate + side effect. If you deliberately avoided certain directories in + the repository when you created your working directory (either + through use of a module name or by listing explicitly the files + and directories you wanted on the command line), then updating + with `-d' will create those directories, which may not be what you + want. + +`-I NAME' + Ignore files whose names match NAME (in your working directory) + during the update. You can specify `-I' more than once on the + command line to specify several files to ignore. Use `-I !' to + avoid ignoring any files at all. *Note cvsignore::, for other + ways to make CVS ignore some files. + +`-WSPEC' + Specify file names that should be filtered during update. You can + use this option repeatedly. + + SPEC can be a file name pattern of the same type that you can + specify in the `.cvswrappers' file. *Note Wrappers::. + +`-jREVISION' + With two `-j' options, merge changes from the revision specified + with the first `-j' option to the revision specified with the + second `j' option, into the working directory. + + With one `-j' option, merge changes from the ancestor revision to + the revision specified with the `-j' option, into the working + directory. The ancestor revision is the common ancestor of the + revision which the working directory is based on, and the revision + specified in the `-j' option. + + Note that using a single `-j TAGNAME' option rather than `-j + BRANCHNAME' to merge changes from a branch will often not remove + files which were removed on the branch. *Note Merging adds and + removals::, for more. + + In addition, each `-j' option can contain an optional date + specification which, when used with branches, can limit the chosen + revision to one within a specific date. An optional date is + specified by adding a colon (:) to the tag: + `-jSYMBOLIC_TAG:DATE_SPECIFIER'. + + *Note Branching and merging::. + + + +File: cvs.info, Node: update output, Prev: update options, Up: update + +A.20.2 update output +-------------------- + +`update' and `checkout' keep you informed of their progress by printing +a line for each file, preceded by one character indicating the status +of the file: + +`U FILE' + The file was brought up to date with respect to the repository. + This is done for any file that exists in the repository but not in + your working directory, and for files that you haven't changed but + are not the most recent versions available in the repository. + +`P FILE' + Like `U', but the CVS server sends a patch instead of an entire + file. This accomplishes the same thing as `U' using less + bandwidth. + +`A FILE' + The file has been added to your private copy of the sources, and + will be added to the source repository when you run `commit' on + the file. This is a reminder to you that the file needs to be + committed. + +`R FILE' + The file has been removed from your private copy of the sources, + and will be removed from the source repository when you run + `commit' on the file. This is a reminder to you that the file + needs to be committed. + +`M FILE' + The file is modified in your working directory. + + `M' can indicate one of two states for a file you're working on: + either there were no modifications to the same file in the + repository, so that your file remains as you last saw it; or there + were modifications in the repository as well as in your copy, but + they were merged successfully, without conflict, in your working + directory. + + CVS will print some messages if it merges your work, and a backup + copy of your working file (as it looked before you ran `update') + will be made. The exact name of that file is printed while + `update' runs. + +`C FILE' + A conflict was detected while trying to merge your changes to FILE + with changes from the source repository. FILE (the copy in your + working directory) is now the result of attempting to merge the + two revisions; an unmodified copy of your file is also in your + working directory, with the name `.#FILE.REVISION' where REVISION + is the revision that your modified file started from. Resolve the + conflict as described in *Note Conflicts example::. (Note that + some systems automatically purge files that begin with `.#' if + they have not been accessed for a few days. If you intend to keep + a copy of your original file, it is a very good idea to rename + it.) Under VMS, the file name starts with `__' rather than `.#'. + +`? FILE' + FILE is in your working directory, but does not correspond to + anything in the source repository, and is not in the list of files + for CVS to ignore (see the description of the `-I' option, and + *note cvsignore::). + + +File: cvs.info, Node: Invoking CVS, Next: Administrative files, Prev: CVS commands, Up: Top + +Appendix B Quick reference to CVS commands +****************************************** + +This appendix describes how to invoke CVS, with references to where +each command or feature is described in detail. For other references +run the `cvs --help' command, or see *Note Index::. + + A CVS command looks like: + + cvs [ GLOBAL_OPTIONS ] COMMAND [ COMMAND_OPTIONS ] [ COMMAND_ARGS ] + + Global options: + +`--allow-root=ROOTDIR' + Specify legal CVSROOT directory (server only) (not in CVS 1.9 and + older). See *Note Password authentication server::. + +`-a' + Authenticate all communication (client only) (not in CVS 1.9 and + older). See *Note Global options::. + +`-b' + Specify RCS location (CVS 1.9 and older). See *Note Global + options::. + +`-d ROOT' + Specify the CVSROOT. See *Note Repository::. + +`-e EDITOR' + Edit messages with EDITOR. See *Note Committing your changes::. + +`-f' + Do not read the `~/.cvsrc' file. See *Note Global options::. + +`-H' +`--help' + Print a help message. See *Note Global options::. + +`-n' + Do not change any files. See *Note Global options::. + +`-Q' + Be really quiet. See *Note Global options::. + +`-q' + Be somewhat quiet. See *Note Global options::. + +`-r' + Make new working files read-only. See *Note Global options::. + +`-s VARIABLE=VALUE' + Set a user variable. See *Note Variables::. + +`-T TEMPDIR' + Put temporary files in TEMPDIR. See *Note Global options::. + +`-t' + Trace CVS execution. See *Note Global options::. + +`-v' + +`--version' + Display version and copyright information for CVS. + +`-w' + Make new working files read-write. See *Note Global options::. + +`-x' + Encrypt all communication (client only). See *Note Global + options::. + +`-z GZIP-LEVEL' + Set the compression level (client only). See *Note Global + options::. + + Keyword expansion modes (*note Substitution modes::): + + -kkv $Id: file1,v 1.1 1993/12/09 03:21:13 joe Exp $ + -kkvl $Id: file1,v 1.1 1993/12/09 03:21:13 joe Exp harry $ + -kk $Id$ + -kv file1,v 1.1 1993/12/09 03:21:13 joe Exp + -ko no expansion + -kb no expansion, file is binary + + Keywords (*note Keyword list::): + + $Author: joe $ + $Date: 1993/12/09 03:21:13 $ + $CVSHeader: files/file1,v 1.1 1993/12/09 03:21:13 joe Exp harry $ + $Header: /home/files/file1,v 1.1 1993/12/09 03:21:13 joe Exp harry $ + $Id: file1,v 1.1 1993/12/09 03:21:13 joe Exp harry $ + $Locker: harry $ + $Name: snapshot_1_14 $ + $RCSfile: file1,v $ + $Revision: 1.1 $ + $Source: /home/files/file1,v $ + $State: Exp $ + $Log: file1,v $ + Revision 1.1 1993/12/09 03:30:17 joe + Initial revision + + Commands, command options, and command arguments: + +`add [OPTIONS] [FILES...]' + Add a new file/directory. See *Note Adding files::. + + `-k KFLAG' + Set keyword expansion. + + `-m MSG' + Set file description. + +`admin [OPTIONS] [FILES...]' + Administration of history files in the repository. See *Note + admin::. + + `-b[REV]' + Set default branch. See *Note Reverting local changes::. + + `-cSTRING' + Set comment leader. + + `-kSUBST' + Set keyword substitution. See *Note Keyword substitution::. + + `-l[REV]' + Lock revision REV, or latest revision. + + `-mREV:MSG' + Replace the log message of revision REV with MSG. + + `-oRANGE' + Delete revisions from the repository. See *Note admin + options::. + + `-q' + Run quietly; do not print diagnostics. + + `-sSTATE[:REV]' + Set the state. See *Note admin options:: for more + information on possible states. + + `-t' + Set file description from standard input. + + `-tFILE' + Set file description from FILE. + + `-t-STRING' + Set file description to STRING. + + `-u[REV]' + Unlock revision REV, or latest revision. + +`annotate [OPTIONS] [FILES...]' + Show last revision where each line was modified. See *Note + annotate::. + + `-D DATE' + Annotate the most recent revision no later than DATE. See + *Note Common options::. + + `-F' + Force annotation of binary files. (Without this option, + binary files are skipped with a message.) + + `-f' + Use head revision if tag/date not found. See *Note Common + options::. + + `-l' + Local; run only in current working directory. *Note + Recursive behavior::. + + `-R' + Operate recursively (default). *Note Recursive behavior::. + + `-r TAG[:DATE]' + Annotate revisions specified by TAG or, when DATE is specified + and TAG is a branch tag, the version from the branch TAG as it + existed on DATE. See *Note Common options::. + +`checkout [OPTIONS] MODULES...' + Get a copy of the sources. See *Note checkout::. + + `-A' + Reset any sticky tags/date/options. See *Note Sticky tags:: + and *Note Keyword substitution::. + + `-c' + Output the module database. See *Note checkout options::. + + `-D DATE' + Check out revisions as of DATE (is sticky). See *Note Common + options::. + + `-d DIR' + Check out into DIR. See *Note checkout options::. + + `-f' + Use head revision if tag/date not found. See *Note Common + options::. + + `-j TAG[:DATE]' + Merge in the change specified by TAG, or when DATE is + specified and TAG is a branch tag, the version from the + branch TAG as it existed on DATE. See *Note checkout + options::. + + `-k KFLAG' + Use KFLAG keyword expansion. See *Note Substitution modes::. + + `-l' + Local; run only in current working directory. *Note + Recursive behavior::. + + `-N' + Don't "shorten" module paths if -d specified. See *Note + checkout options::. + + `-n' + Do not run module program (if any). See *Note checkout + options::. + + `-P' + Prune empty directories. See *Note Moving directories::. + + `-p' + Check out files to standard output (avoids stickiness). See + *Note checkout options::. + + `-R' + Operate recursively (default). *Note Recursive behavior::. + + `-r TAG[:DATE]' + Checkout the revision already tagged with TAG or, when DATE is + specified and TAG is a branch tag, the version from the + branch TAG as it existed on DATE. This . See *Note Common + options::. + + `-s' + Like -c, but include module status. See *Note checkout + options::. + +`commit [OPTIONS] [FILES...]' + Check changes into the repository. See *Note commit::. + + `-c' + Check for valid edits before committing. Requires a CVS + client and server both version 1.12.10 or greater. + + `-F FILE' + Read log message from FILE. See *Note commit options::. + + `-f' + Force the file to be committed; disables recursion. See + *Note commit options::. + + `-l' + Local; run only in current working directory. See *Note + Recursive behavior::. + + `-m MSG' + Use MSG as log message. See *Note commit options::. + + `-n' + Do not run module program (if any). See *Note commit + options::. + + `-R' + Operate recursively (default). *Note Recursive behavior::. + + `-r REV' + Commit to REV. See *Note commit options::. + +`diff [OPTIONS] [FILES...]' + Show differences between revisions. See *Note diff::. In + addition to the options shown below, accepts a wide variety of + options to control output style, for example `-c' for context + diffs. + + `-D DATE1' + Diff revision for date against working file. See *Note diff + options::. + + `-D DATE2' + Diff REV1/DATE1 against DATE2. See *Note diff options::. + + `-l' + Local; run only in current working directory. See *Note + Recursive behavior::. + + `-N' + Include diffs for added and removed files. See *Note diff + options::. + + `-R' + Operate recursively (default). *Note Recursive behavior::. + + `-r TAG1[:DATE1]' + Diff the revisions specified by TAG1 or, when DATE1 is + specified and TAG1 is a branch tag, the version from the + branch TAG1 as it existed on DATE1, against the working file. + See *Note diff options:: and *Note Common options::. + + `-r TAG2[:DATE2]' + Diff the revisions specified by TAG2 or, when DATE2 is + specified and TAG2 is a branch tag, the version from the + branch TAG2 as it existed on DATE2, against REV1/DATE1. See + *Note diff options:: and *Note Common options::. + +`edit [OPTIONS] [FILES...]' + Get ready to edit a watched file. See *Note Editing files::. + + `-a ACTIONS' + Specify actions for temporary watch, where ACTIONS is `edit', + `unedit', `commit', `all', or `none'. See *Note Editing + files::. + + `-c' + Check edits: Edit fails if someone else is already editting + the file. Requires a CVS client and server both of version + 1.12.10 or greater. + + `-f' + Force edit; ignore other edits. Added in CVS 1.12.10. + + `-l' + Local; run only in current working directory. See *Note + Recursive behavior::. + + `-R' + Operate recursively (default). *Note Recursive behavior::. + +`editors [OPTIONS] [FILES...]' + See who is editing a watched file. See *Note Watch information::. + + `-l' + Local; run only in current working directory. See *Note + Recursive behavior::. + + `-R' + Operate recursively (default). *Note Recursive behavior::. + +`export [OPTIONS] MODULES...' + Export files from CVS. See *Note export::. + + `-D DATE' + Check out revisions as of DATE. See *Note Common options::. + + `-d DIR' + Check out into DIR. See *Note export options::. + + `-f' + Use head revision if tag/date not found. See *Note Common + options::. + + `-k KFLAG' + Use KFLAG keyword expansion. See *Note Substitution modes::. + + `-l' + Local; run only in current working directory. *Note + Recursive behavior::. + + `-N' + Don't "shorten" module paths if -d specified. See *Note + export options::. + + `-n' + Do not run module program (if any). See *Note export + options::. + + `-R' + Operate recursively (default). *Note Recursive behavior::. + + `-r TAG[:DATE]' + Export the revisions specified by TAG or, when DATE is + specified and TAG is a branch tag, the version from the + branch TAG as it existed on DATE. See *Note Common options::. + +`history [OPTIONS] [FILES...]' + Show repository access history. See *Note history::. + + `-a' + All users (default is self). See *Note history options::. + + `-b STR' + Back to record with STR in module/file/repos field. See + *Note history options::. + + `-c' + Report on committed (modified) files. See *Note history + options::. + + `-D DATE' + Since DATE. See *Note history options::. + + `-e' + Report on all record types. See *Note history options::. + + `-l' + Last modified (committed or modified report). See *Note + history options::. + + `-m MODULE' + Report on MODULE (repeatable). See *Note history options::. + + `-n MODULE' + In MODULE. See *Note history options::. + + `-o' + Report on checked out modules. See *Note history options::. + + `-p REPOSITORY' + In REPOSITORY. See *Note history options::. + + `-r REV' + Since revision REV. See *Note history options::. + + `-T' + Produce report on all TAGs. See *Note history options::. + + `-t TAG' + Since tag record placed in history file (by anyone). See + *Note history options::. + + `-u USER' + For user USER (repeatable). See *Note history options::. + + `-w' + Working directory must match. See *Note history options::. + + `-x TYPES' + Report on TYPES, one or more of `TOEFWUPCGMAR'. See *Note + history options::. + + `-z ZONE' + Output for time zone ZONE. See *Note history options::. + +`import [OPTIONS] REPOSITORY VENDOR-TAG RELEASE-TAGS...' + Import files into CVS, using vendor branches. See *Note import::. + + `-b BRA' + Import to vendor branch BRA. See *Note Multiple vendor + branches::. + + `-d' + Use the file's modification time as the time of import. See + *Note import options::. + + `-k KFLAG' + Set default keyword substitution mode. See *Note import + options::. + + `-m MSG' + Use MSG for log message. See *Note import options::. + + `-I IGN' + More files to ignore (! to reset). See *Note import + options::. + + `-W SPEC' + More wrappers. See *Note import options::. + +`init' + Create a CVS repository if it doesn't exist. See *Note Creating a + repository::. + +`kserver' + Kerberos authenticated server. See *Note Kerberos authenticated::. + +`log [OPTIONS] [FILES...]' + Print out history information for files. See *Note log::. + + `-b' + Only list revisions on the default branch. See *Note log + options::. + + `-d DATES' + Specify dates (D1<D2 for range, D for latest before). See + *Note log options::. + + `-h' + Only print header. See *Note log options::. + + `-l' + Local; run only in current working directory. See *Note + Recursive behavior::. + + `-N' + Do not list tags. See *Note log options::. + + `-R' + Only print name of RCS file. See *Note log options::. + + `-rREVS' + Only list revisions REVS. See *Note log options::. + + `-s STATES' + Only list revisions with specified states. See *Note log + options::. + + `-t' + Only print header and descriptive text. See *Note log + options::. + + `-wLOGINS' + Only list revisions checked in by specified logins. See + *Note log options::. + +`login' + Prompt for password for authenticating server. See *Note Password + authentication client::. + +`logout' + Remove stored password for authenticating server. See *Note + Password authentication client::. + +`pserver' + Password authenticated server. See *Note Password authentication + server::. + +`rannotate [OPTIONS] [MODULES...]' + Show last revision where each line was modified. See *Note + annotate::. + + `-D DATE' + Annotate the most recent revision no later than DATE. See + *Note Common options::. + + `-F' + Force annotation of binary files. (Without this option, + binary files are skipped with a message.) + + `-f' + Use head revision if tag/date not found. See *Note Common + options::. + + `-l' + Local; run only in current working directory. *Note + Recursive behavior::. + + `-R' + Operate recursively (default). *Note Recursive behavior::. + + `-r TAG[:DATE]' + Annotate the revision specified by TAG or, when DATE is + specified and TAG is a branch tag, the version from the + branch TAG as it existed on DATE. See *Note Common options::. + +`rdiff [OPTIONS] MODULES...' + Show differences between releases. See *Note rdiff::. + + `-c' + Context diff output format (default). See *Note rdiff + options::. + + `-D DATE' + Select revisions based on DATE. See *Note Common options::. + + `-f' + Use head revision if tag/date not found. See *Note Common + options::. + + `-l' + Local; run only in current working directory. See *Note + Recursive behavior::. + + `-R' + Operate recursively (default). *Note Recursive behavior::. + + `-r TAG[:DATE]' + Select the revisions specified by TAG or, when DATE is + specified and TAG is a branch tag, the version from the + branch TAG as it existed on DATE. See *Note diff options:: + and *Note Common options::. + + `-s' + Short patch - one liner per file. See *Note rdiff options::. + + `-t' + Top two diffs - last change made to the file. See *Note diff + options::. + + `-u' + Unidiff output format. See *Note rdiff options::. + + `-V VERS' + Use RCS Version VERS for keyword expansion (obsolete). See + *Note rdiff options::. + +`release [OPTIONS] DIRECTORY' + Indicate that a directory is no longer in use. See *Note + release::. + + `-d' + Delete the given directory. See *Note release options::. + +`remove [OPTIONS] [FILES...]' + Remove an entry from the repository. See *Note Removing files::. + + `-f' + Delete the file before removing it. See *Note Removing + files::. + + `-l' + Local; run only in current working directory. See *Note + Recursive behavior::. + + `-R' + Operate recursively (default). *Note Recursive behavior::. + +`rlog [OPTIONS] [FILES...]' + Print out history information for modules. See *Note log::. + + `-b' + Only list revisions on the default branch. See *Note log + options::. + + `-d DATES' + Specify dates (D1<D2 for range, D for latest before). See + *Note log options::. + + `-h' + Only print header. See *Note log options::. + + `-l' + Local; run only in current working directory. See *Note + Recursive behavior::. + + `-N' + Do not list tags. See *Note log options::. + + `-R' + Only print name of RCS file. See *Note log options::. + + `-rREVS' + Only list revisions REVS. See *Note log options::. + + `-s STATES' + Only list revisions with specified states. See *Note log + options::. + + `-t' + Only print header and descriptive text. See *Note log + options::. + + `-wLOGINS' + Only list revisions checked in by specified logins. See + *Note log options::. + +`rtag [OPTIONS] TAG MODULES...' + Add a symbolic tag to a module. See *Note Revisions:: and *Note + Branching and merging::. + + `-a' + Clear tag from removed files that would not otherwise be + tagged. See *Note Tagging add/remove::. + + `-b' + Create a branch named TAG. See *Note Branching and merging::. + + `-B' + Used in conjunction with -F or -d, enables movement and + deletion of branch tags. Use with extreme caution. + + `-D DATE' + Tag revisions as of DATE. See *Note Tagging by date/tag::. + + `-d' + Delete TAG. See *Note Modifying tags::. + + `-F' + Move TAG if it already exists. See *Note Modifying tags::. + + `-f' + Force a head revision match if tag/date not found. See *Note + Tagging by date/tag::. + + `-l' + Local; run only in current working directory. See *Note + Recursive behavior::. + + `-n' + No execution of tag program. See *Note Common options::. + + `-R' + Operate recursively (default). *Note Recursive behavior::. + + `-r TAG[:DATE]' + Tag the revision already tagged with TAG or, when DATE is + specified and TAG is a branch tag, the version from the + branch TAG as it existed on DATE. See *Note Tagging by + date/tag:: and *Note Common options::. + +`server' + Rsh server. See *Note Connecting via rsh::. + +`status [OPTIONS] FILES...' + Display status information in a working directory. See *Note File + status::. + + `-l' + Local; run only in current working directory. See *Note + Recursive behavior::. + + `-R' + Operate recursively (default). *Note Recursive behavior::. + + `-v' + Include tag information for file. See *Note Tags::. + +`tag [OPTIONS] TAG [FILES...]' + Add a symbolic tag to checked out version of files. See *Note + Revisions:: and *Note Branching and merging::. + + `-b' + Create a branch named TAG. See *Note Branching and merging::. + + `-c' + Check that working files are unmodified. See *Note Tagging + the working directory::. + + `-D DATE' + Tag revisions as of DATE. See *Note Tagging by date/tag::. + + `-d' + Delete TAG. See *Note Modifying tags::. + + `-F' + Move TAG if it already exists. See *Note Modifying tags::. + + `-f' + Force a head revision match if tag/date not found. See *Note + Tagging by date/tag::. + + `-l' + Local; run only in current working directory. See *Note + Recursive behavior::. + + `-R' + Operate recursively (default). *Note Recursive behavior::. + + `-r TAG[:DATE]' + Tag the revision already tagged with TAG, or when DATE is + specified and TAG is a branch tag, the version from the + branch TAG as it existed on DATE. See *Note Tagging by + date/tag:: and *Note Common options::. + +`unedit [OPTIONS] [FILES...]' + Undo an edit command. See *Note Editing files::. + + `-l' + Local; run only in current working directory. See *Note + Recursive behavior::. + + `-R' + Operate recursively (default). *Note Recursive behavior::. + +`update [OPTIONS] [FILES...]' + Bring work tree in sync with repository. See *Note update::. + + `-A' + Reset any sticky tags/date/options. See *Note Sticky tags:: + and *Note Keyword substitution::. + + `-C' + Overwrite locally modified files with clean copies from the + repository (the modified file is saved in `.#FILE.REVISION', + however). + + `-D DATE' + Check out revisions as of DATE (is sticky). See *Note Common + options::. + + `-d' + Create directories. See *Note update options::. + + `-f' + Use head revision if tag/date not found. See *Note Common + options::. + + `-I IGN' + More files to ignore (! to reset). See *Note import + options::. + + `-j TAG[:DATE]' + Merge in changes from revisions specified by TAG or, when + DATE is specified and TAG is a branch tag, the version from + the branch TAG as it existed on DATE. See *Note update + options::. + + `-k KFLAG' + Use KFLAG keyword expansion. See *Note Substitution modes::. + + `-l' + Local; run only in current working directory. *Note + Recursive behavior::. + + `-P' + Prune empty directories. See *Note Moving directories::. + + `-p' + Check out files to standard output (avoids stickiness). See + *Note update options::. + + `-R' + Operate recursively (default). *Note Recursive behavior::. + + `-r TAG[:DATE]' + Checkout the revisions specified by TAG or, when DATE is + specified and TAG is a branch tag, the version from the + branch TAG as it existed on DATE. See *Note Common options::. + + `-W SPEC' + More wrappers. See *Note import options::. + +`version' + Display the version of CVS being used. If the repository is + remote, display both the client and server versions. + +`watch [on|off|add|remove] [OPTIONS] [FILES...]' + on/off: turn on/off read-only checkouts of files. See *Note + Setting a watch::. + + add/remove: add or remove notification on actions. See *Note + Getting Notified::. + + `-a ACTIONS' + Specify actions for temporary watch, where ACTIONS is `edit', + `unedit', `commit', `all', or `none'. See *Note Editing + files::. + + `-l' + Local; run only in current working directory. See *Note + Recursive behavior::. + + `-R' + Operate recursively (default). *Note Recursive behavior::. + +`watchers [OPTIONS] [FILES...]' + See who is watching a file. See *Note Watch information::. + + `-l' + Local; run only in current working directory. See *Note + Recursive behavior::. + + `-R' + Operate recursively (default). *Note Recursive behavior::. + + + +File: cvs.info, Node: Administrative files, Next: Environment variables, Prev: Invoking CVS, Up: Top + +Appendix C Reference manual for Administrative files +**************************************************** + +Inside the repository, in the directory `$CVSROOT/CVSROOT', there are a +number of supportive files for CVS. You can use CVS in a limited +fashion without any of them, but if they are set up properly they can +help make life easier. For a discussion of how to edit them, see *Note +Intro administrative files::. + + The most important of these files is the `modules' file, which +defines the modules inside the repository. + +* Menu: + +* modules:: Defining modules +* Wrappers:: Specify binary-ness based on file name +* Trigger Scripts:: Launch scripts in response to server events +* rcsinfo:: Templates for the log messages +* cvsignore:: Ignoring files via cvsignore +* checkoutlist:: Adding your own administrative files +* history file:: History information +* Variables:: Various variables are expanded +* config:: Miscellaneous CVS configuration + + +File: cvs.info, Node: modules, Next: Wrappers, Up: Administrative files + +C.1 The modules file +==================== + +The `modules' file records your definitions of names for collections of +source code. CVS will use these definitions if you use CVS to update +the modules file (use normal commands like `add', `commit', etc). + + The `modules' file may contain blank lines and comments (lines +beginning with `#') as well as module definitions. Long lines can be +continued on the next line by specifying a backslash (`\') as the last +character on the line. + + There are three basic types of modules: alias modules, regular +modules, and ampersand modules. The difference between them is the way +that they map files in the repository to files in the working +directory. In all of the following examples, the top-level repository +contains a directory called `first-dir', which contains two files, +`file1' and `file2', and a directory `sdir'. `first-dir/sdir' contains +a file `sfile'. + +* Menu: + +* Alias modules:: The simplest kind of module +* Regular modules:: +* Ampersand modules:: +* Excluding directories:: Excluding directories from a module +* Module options:: Regular and ampersand modules can take options +* Module program options:: How the modules ``program options'' programs + are run. + + +File: cvs.info, Node: Alias modules, Next: Regular modules, Up: modules + +C.1.1 Alias modules +------------------- + +Alias modules are the simplest kind of module: + +`MNAME -a ALIASES...' + This represents the simplest way of defining a module MNAME. The + `-a' flags the definition as a simple alias: CVS will treat any + use of MNAME (as a command argument) as if the list of names + ALIASES had been specified instead. ALIASES may contain either + other module names or paths. When you use paths in aliases, + `checkout' creates all intermediate directories in the working + directory, just as if the path had been specified explicitly in + the CVS arguments. + + For example, if the modules file contains: + + amodule -a first-dir + +then the following two commands are equivalent: + + $ cvs co amodule + $ cvs co first-dir + +and they each would provide output such as: + + cvs checkout: Updating first-dir + U first-dir/file1 + U first-dir/file2 + cvs checkout: Updating first-dir/sdir + U first-dir/sdir/sfile + + +File: cvs.info, Node: Regular modules, Next: Ampersand modules, Prev: Alias modules, Up: modules + +C.1.2 Regular modules +--------------------- + +`MNAME [ options ] DIR [ FILES... ]' + In the simplest case, this form of module definition reduces to + `MNAME DIR'. This defines all the files in directory DIR as + module mname. DIR is a relative path (from `$CVSROOT') to a + directory of source in the source repository. In this case, on + checkout, a single directory called MNAME is created as a working + directory; no intermediate directory levels are used by default, + even if DIR was a path involving several directory levels. + + For example, if a module is defined by: + + regmodule first-dir + +then regmodule will contain the files from first-dir: + + $ cvs co regmodule + cvs checkout: Updating regmodule + U regmodule/file1 + U regmodule/file2 + cvs checkout: Updating regmodule/sdir + U regmodule/sdir/sfile + $ + + By explicitly specifying files in the module definition after DIR, +you can select particular files from directory DIR. Here is an example: + + regfiles first-dir/sdir sfile + +With this definition, getting the regfiles module will create a single +working directory `regfiles' containing the file listed, which comes +from a directory deeper in the CVS source repository: + + $ cvs co regfiles + U regfiles/sfile + $ + + +File: cvs.info, Node: Ampersand modules, Next: Excluding directories, Prev: Regular modules, Up: modules + +C.1.3 Ampersand modules +----------------------- + +A module definition can refer to other modules by including `&MODULE' +in its definition. + MNAME [ options ] &MODULE... + + Then getting the module creates a subdirectory for each such module, +in the directory containing the module. For example, if modules +contains + + ampermod &first-dir + +then a checkout will create an `ampermod' directory which contains a +directory called `first-dir', which in turns contains all the +directories and files which live there. For example, the command + + $ cvs co ampermod + +will create the following files: + + ampermod/first-dir/file1 + ampermod/first-dir/file2 + ampermod/first-dir/sdir/sfile + + There is one quirk/bug: the messages that CVS prints omit the +`ampermod', and thus do not correctly display the location to which it +is checking out the files: + + $ cvs co ampermod + cvs checkout: Updating first-dir + U first-dir/file1 + U first-dir/file2 + cvs checkout: Updating first-dir/sdir + U first-dir/sdir/sfile + $ + + Do not rely on this buggy behavior; it may get fixed in a future +release of CVS. + + +File: cvs.info, Node: Excluding directories, Next: Module options, Prev: Ampersand modules, Up: modules + +C.1.4 Excluding directories +--------------------------- + +An alias module may exclude particular directories from other modules +by using an exclamation mark (`!') before the name of each directory to +be excluded. + + For example, if the modules file contains: + + exmodule -a !first-dir/sdir first-dir + +then checking out the module `exmodule' will check out everything in +`first-dir' except any files in the subdirectory `first-dir/sdir'. + + +File: cvs.info, Node: Module options, Next: Module program options, Prev: Excluding directories, Up: modules + +C.1.5 Module options +-------------------- + +Either regular modules or ampersand modules can contain options, which +supply additional information concerning the module. + +`-d NAME' + Name the working directory something other than the module name. + +`-e PROG' + Specify a program PROG to run whenever files in a module are + exported. PROG runs with a single argument, the module name. + +`-o PROG' + Specify a program PROG to run whenever files in a module are + checked out. PROG runs with a single argument, the module name. + See *Note Module program options:: for information on how PROG is + called. + +`-s STATUS' + Assign a status to the module. When the module file is printed + with `cvs checkout -s' the modules are sorted according to + primarily module status, and secondarily according to the module + name. This option has no other meaning. You can use this option + for several things besides status: for instance, list the person + that is responsible for this module. + +`-t PROG' + Specify a program PROG to run whenever files in a module are + tagged with `rtag'. PROG runs with two arguments: the module name + and the symbolic tag specified to `rtag'. It is not run when + `tag' is executed. Generally you will find that the `taginfo' + file is a better solution (*note taginfo::). + + You should also see *note Module program options:: about how the +"program options" programs are run. + + +File: cvs.info, Node: Module program options, Prev: Module options, Up: modules + +C.1.6 How the modules file "program options" programs are run +------------------------------------------------------------- + +For checkout, rtag, and export, the program is server-based, and as +such the following applies:- + + If using remote access methods (pserver, ext, etc.), CVS will +execute this program on the server from a temporary directory. The path +is searched for this program. + + If using "local access" (on a local or remote NFS file system, i.e. +repository set just to a path), the program will be executed from the +newly checked-out tree, if found there, or alternatively searched for +in the path if not. + + The programs are all run after the operation has effectively +completed. + + +File: cvs.info, Node: Wrappers, Next: Trigger Scripts, Prev: modules, Up: Administrative files + +C.2 The cvswrappers file +======================== + +Wrappers refers to a CVS feature which lets you control certain +settings based on the name of the file which is being operated on. The +settings are `-k' for binary files, and `-m' for nonmergeable text +files. + + The `-m' option specifies the merge methodology that should be used +when a non-binary file is updated. `MERGE' means the usual CVS +behavior: try to merge the files. `COPY' means that `cvs update' will +refuse to merge files, as it also does for files specified as binary +with `-kb' (but if the file is specified as binary, there is no need to +specify `-m 'COPY''). CVS will provide the user with the two versions +of the files, and require the user using mechanisms outside CVS, to +insert any necessary changes. + + *WARNING: do not use `COPY' with CVS 1.9 or earlier - such versions +of CVS will copy one version of your file over the other, wiping out +the previous contents.* The `-m' wrapper option only affects behavior +when merging is done on update; it does not affect how files are +stored. See *Note Binary files::, for more on binary files. + + The basic format of the file `cvswrappers' is: + + wildcard [option value][option value]... + + where option is one of + -m update methodology value: MERGE or COPY + -k keyword expansion value: expansion mode + + and value is a single-quote delimited value. + + For example, the following command imports a directory, treating +files whose name ends in `.exe' as binary: + + cvs import -I ! -W "*.exe -k 'b'" first-dir vendortag reltag + + +File: cvs.info, Node: Trigger Scripts, Next: rcsinfo, Prev: Wrappers, Up: Administrative files + +C.3 The Trigger Scripts +======================= + +Several of the administrative files support triggers, or the launching +external scripts or programs at specific times before or after +particular events, during the execution of CVS commands. These hooks +can be used to prevent certain actions, log them, and/or maintain +anything else you deem practical. + + All the trigger scripts are launched in a copy of the user sandbox +being committed, on the server, in client-server mode. In local mode, +the scripts are actually launched directly from the user sandbox +directory being committed. For most intents and purposes, the same +scripts can be run in both locations without alteration. + +* Menu: + +* syntax:: The common syntax +* Trigger Script Security:: Trigger script security + +* commit files:: The commit support files (commitinfo, + verifymsg, loginfo) +* commitinfo:: Pre-commit checking +* verifymsg:: How are log messages evaluated? +* loginfo:: Where should log messages be sent? + +* postadmin:: Logging admin commands +* taginfo:: Verifying/Logging tags +* posttag:: Logging tags +* postwatch:: Logging watch commands + +* preproxy:: Launch a script on a secondary server prior + to becoming a write proxy +* postproxy:: Launch a script on a secondary server after + completing proxy operations + + +File: cvs.info, Node: syntax, Next: Trigger Script Security, Up: Trigger Scripts + +C.3.1 The common syntax +----------------------- + +The administrative files such as `commitinfo', `loginfo', `rcsinfo', +`verifymsg', etc., all have a common format. The purpose of the files +are described later on. The common syntax is described here. + + Each line contains the following: + + * A regular expression or the literal string `DEFAULT'. Some script + hooks also support the literal string `ALL'. Other than the `ALL' + and `DEFAULT' keywords, this is a basic regular expression in the + syntax used by GNU emacs. See the descriptions of the individual + script hooks for information on whether the `ALL' keyword is + supported (*note Trigger Scripts::). + + * A whitespace separator--one or more spaces and/or tabs. + + * A file name or command-line template. + +Blank lines are ignored. Lines that start with the character `#' are +treated as comments. Long lines unfortunately can _not_ be broken in +two parts in any way. + + The first regular expression that matches the current directory name +in the repository or the first line containing `DEFAULT' in lieu of a +regular expression is used and all lines containing `ALL' is used for +the hooks which support the `ALL' keyword. The rest of the line is +used as a file name or command-line template as appropriate. See the +descriptions of the individual script hooks for information on whether +the `ALL' keyword is supported (*note Trigger Scripts::). + +_Note: The following information on format strings is valid as long as +the line `UseNewInfoFmtStrings=yes' appears in your repository's config +file (*note config::). Otherwise, default format strings may be +appended to the command line and the `loginfo' file, especially, can +exhibit slightly different behavior. For more information, *Note +Updating Commit Files::._ + + In the cases where the second segment of the matched line is a +command line template (e.g. `commitinfo', `loginfo', & `verifymsg'), +the command line template may contain format strings which will be +replaced with specific values before the script is run. + + Format strings can represent a single variable or one or more +attributes of a list variable. An example of a list variable would be +the list available to scripts hung on the loginfo hooks - the list of +files which were just committed. In the case of loginfo, three +attributes are available for each list item: file name, precommit +version, and postcommit version. + + Format strings consist of a `%' character followed by an optional +`{' (required in the multiple list attribute case), a single format +character representing a variable or a single attribute of list +elements or multiple format characters representing attributes of list +elements, and a closing `}' when the open bracket was present. + + _Flat format strings_, or single format characters which get replaced +with a single value, will generate a single argument to the called +script, regardless of whether the replacement variable contains white +space or other special characters. + + _List attributes_ will generate an argument for each attribute +requested for each list item. For example, `%{sVv}' in a `loginfo' +command template will generate three arguments (file name, precommit +version, postcommit version, ...) for each file committed. As in the +flat format string case, each attribute will be passed in as a single +argument regardless of whether it contains white space or other special +characters. + + `%%' will be replaced with a literal `%'. + + The format strings available to all script hooks are: + +c + The canonical name of the command being executed. For instance, + in the case of a hook run from `cvs up', CVS would replace `%c' + with the string `update' and, in the case of a hook run from `cvs + ci', CVS would replace `%c' with the string `commit'. + +n + The null, or empty, string. + +p + The name of the directory being operated on within the repository. + +r + The name of the repository (the path portion of `$CVSROOT'). + +R + On a server, the name of the referrer, if any. The referrer is + the CVSROOT the client reports it used to contact a server which + then referred it to this server. Should usually be set on a + primary server with a write proxy setup. + + Other format strings are file specific. See the docs on the +particular script hooks for more information (*note Trigger Scripts::). + + As an example, the following line in a `loginfo' file would match +only the directory `module' and any subdirectories of `module': + + ^module\(/\|$\) (echo; echo %p; echo %{sVv}; cat) >>$CVSROOT/CVSROOT/commitlog + + Using this same line and assuming a commit of new revisions 1.5.4.4 +and 1.27.4.1 based on old revisions 1.5.4.3 and 1.27, respectively, of +file1 and file2 in module, something like the following log message +should be appended to commitlog: + + + module + file1 1.5.4.3 1.5.4.4 file2 1.27 1.27.4.1 + Update of /cvsroot/module + In directory localhost.localdomain:/home/jrandom/work/module + + Modified Files: + file1 file2 + Log Message: + A log message. + + +File: cvs.info, Node: Trigger Script Security, Next: commit files, Prev: syntax, Up: Trigger Scripts + +C.3.2 Security and the Trigger Scripts +-------------------------------------- + +Security is a huge subject, and implementing a secure system is a +non-trivial task. This section will barely touch on all the issues +involved, but it is well to note that, as with any script you will be +allowing an untrusted user to run on your server, there are measures +you can take to help prevent your trigger scripts from being abused. + + For instance, since the CVS trigger scripts all run in a copy of the +user's sandbox on the server, a naively coded Perl trigger script which +attempts to use a Perl module that is not installed on the system can +be hijacked by any user with commit access who is checking in a file +with the correct name. Other scripting languages may be vulnerable to +similar hacks. + + One way to make a script more secure, at least with Perl, is to use +scripts which invoke the `-T', or "taint-check" switch on their `#!' +line. In the most basic terms, this causes Perl to avoid running code +that may have come from an external source. Please run the `perldoc +perlsec' command for more on Perl security. Again, other languages may +implement other security verification hooks which look more or less +like Perl's "taint-check" mechanism. + + +File: cvs.info, Node: commit files, Next: commitinfo, Prev: Trigger Script Security, Up: Trigger Scripts + +C.3.3 The commit support files +------------------------------ + +The `-i' flag in the `modules' file can be used to run a certain +program whenever files are committed (*note modules::). The files +described in this section provide other, more flexible, ways to run +programs whenever something is committed. + + There are three kinds of programs that can be run on commit. They +are specified in files in the repository, as described below. The +following table summarizes the file names and the purpose of the +corresponding programs. + +`commitinfo' + The program is responsible for checking that the commit is + allowed. If it exits with a non-zero exit status the commit will + be aborted. *Note commitinfo::. + +`verifymsg' + The specified program is used to evaluate the log message, and + possibly verify that it contains all required fields. This is + most useful in combination with the `rcsinfo' file, which can hold + a log message template (*note rcsinfo::). *Note verifymsg::. + +`loginfo' + The specified program is called when the commit is complete. It + receives the log message and some additional information and can + store the log message in a file, or mail it to appropriate + persons, or maybe post it to a local newsgroup, or... Your + imagination is the limit! *Note loginfo::. + +* Menu: + +* Updating Commit Files:: Updating legacy repositories to stop using + deprecated command line template formats + + +File: cvs.info, Node: Updating Commit Files, Up: commit files + +C.3.3.1 Updating legacy repositories to stop using deprecated command line template formats +........................................................................................... + +New repositories are created set to use the new format strings by +default, so if you are creating a new repository, you shouldn't have to +worry about this section. + + If you are attempting to maintain a legacy repository which was +making use of the `commitinfo', `editinfo', `verifymsg', `loginfo', +and/or `taginfo' script hooks, you should have no immediate problems +with using the current CVS executable, but your users will probably +start to see deprecation warnings. + + The reason for this is that all of the script hooks have been +updated to use a new command line parser that extensibly supports +multiple `loginfo' & `notify' style format strings (*note syntax::) and +this support is not completely compatible with the old style format +strings. + + The quick upgrade method is to stick a `1' after each format string +in your old `loginfo' file. For example: + + DEFAULT (echo ""; id; echo %{sVv}; date; cat) >> $CVSROOT/CVSROOT/commitlog + + would become: + + DEFAULT (echo ""; id; echo %1{sVv}; date; cat) >> $CVSROOT/CVSROOT/commitlog + + If you were counting on the fact that only the first `%' in the line +was replaced as a format string, you may also have to double up any +further percent signs on the line. + + If you did this all at once and checked it in, everything should +still be running properly. + + Now add the following line to your config file (*note config::): + UseNewInfoFmtStrings=yes + + Everything should still be running properly, but your users will +probably start seeing new deprecation warnings. + + Dealing with the deprecation warnings now generated by `commitinfo', +`editinfo', `verifymsg', and `taginfo' should be easy. Simply specify +what are currently implicit arguments explicitly. This means appending +the following strings to each active command line template in each file: +`commitinfo' + ` %r/%p %s' + +`editinfo' + ` %l' + +`taginfo' + ` %t %o %p %{sv}' + +`verifymsg' + ` %l' + + If you don't desire that any of the newly available information be +passed to the scripts hanging off of these hooks, no further +modifications to these files should be necessary to insure current and +future compatibility with CVS's format strings. + + Fixing `loginfo' could be a little tougher. The old style `loginfo' +format strings caused a single space and comma separated argument to be +passed in in place of the format string. This is what will continue to +be generated due to the deprecated `1' you inserted into the format +strings. + + Since the new format separates each individual item and passes it +into the script as a separate argument (for a good reason - arguments +containing commas and/or white space are now parsable), to remove the +deprecated `1' from your `loginfo' command line templates, you will +most likely have to rewrite any scripts called by the hook to handle +the new argument format. + + Also note that the way `%' followed by unrecognized characters and by +`{}' was treated in past versions of CVS is not strictly adhered to as +there were bugs in the old versions. Specifically, `%{}' would eat the +next character and unrecognized strings resolved only to the empty +string, which was counter to what was stated in the documentation. +This version will do what the documentation said it should have (if you +were using only some combination of `%{sVv}', e.g. `%{sVv}', `%{sV}', or +`%v', you should have no troubles). + + On the bright side, you should have plenty of time to do this before +all support for the old format strings is removed from CVS, so you can +just put up with the deprecation warnings for awhile if you like. + + +File: cvs.info, Node: commitinfo, Next: verifymsg, Prev: commit files, Up: Trigger Scripts + +C.3.4 Commitinfo +---------------- + +The `commitinfo' file defines programs to execute whenever `cvs commit' +is about to execute. These programs are used for pre-commit checking +to verify that the modified, added and removed files are really ready +to be committed. This could be used, for instance, to verify that the +changed files conform to to your site's standards for coding practice. + + The `commitinfo' file has the standard form for script hooks (*note +Trigger Scripts::), where each line is a regular expression followed by +a command to execute. It supports only the DEFAULT keywords. + + In addition to the common format strings (*note syntax::), +`commitinfo' supports: + +{s} + a list of the names of files to be committed + + Currently, if no format strings are specified, a default string of ` +%r/%p %{s}' will be appended to the command line template before +replacement is performed, but this feature is deprecated. It is simply +in place so that legacy repositories will remain compatible with the +new CVS application. For information on updating, *note Updating +Commit Files::. + + The first line with a regular expression matching the directory +within the repository will be used. If the command returns a non-zero +exit status the commit will be aborted. + + The command will be run in the root of the workspace containing the +new versions of any files the user would like to modify (commit), _or +in a copy of the workspace on the server (*note Remote +repositories::)_. If a file is being removed, there will be no copy of +the file under the current directory. If a file is being added, there +will be no corresponding archive file in the repository unless the file +is being resurrected. + + Note that both the repository directory and the corresponding Attic +(*note Attic::) directory may need to be checked to locate the archive +file corresponding to any given file being committed. Much of the +information about the specific commit request being made, including the +destination branch, commit message, and command line options specified, +is not available to the command. + + +File: cvs.info, Node: verifymsg, Next: loginfo, Prev: commitinfo, Up: Trigger Scripts + +C.3.5 Verifying log messages +---------------------------- + +Once you have entered a log message, you can evaluate that message to +check for specific content, such as a bug ID. Use the `verifymsg' file +to specify a program that is used to verify the log message. This +program could be a simple script that checks that the entered message +contains the required fields. + + The `verifymsg' file is often most useful together with the +`rcsinfo' file, which can be used to specify a log message template +(*note rcsinfo::). + + The `verifymsg' file has the standard form for script hooks (*note +Trigger Scripts::), where each line is a regular expression followed by +a command to execute. It supports only the DEFAULT keywords. + + In addition to the common format strings (*note syntax::), +`verifymsg' supports: + +l + the full path to the file containing the log message to be verified + +{sV} + File attributes, where: + s + file name + + V + old version number (pre-checkin) + + Currently, if no format strings are specified, a default string of ` +%l' will be appended to the command line template before replacement is +performed, but this feature is deprecated. It is simply in place so +that legacy repositories will remain compatible with the new CVS +application. For information on updating, *note Updating Commit +Files::. + + One thing that should be noted is that the `ALL' keyword is not +supported. If more than one matching line is found, the first one is +used. This can be useful for specifying a default verification script +in a directory, and then overriding it in a subdirectory. + + If the verification script exits with a non-zero exit status, the +commit is aborted. + + In the default configuration, CVS allows the verification script to +change the log message. This is controlled via the RereadLogAfterVerify +CVSROOT/config option. + + When `RereadLogAfterVerify=always' or `RereadLogAfterVerify=stat', +the log message will either always be reread after the verification +script is run or reread only if the log message file status has changed. + + *Note config::, for more on CVSROOT/config options. + + It is NOT a good idea for a `verifymsg' script to interact directly +with the user in the various client/server methods. For the `pserver' +method, there is no protocol support for communicating between +`verifymsg' and the client on the remote end. For the `ext' and +`server' methods, it is possible for CVS to become confused by the +characters going along the same channel as the CVS protocol messages. +See *Note Remote repositories::, for more information on client/server +setups. In addition, at the time the `verifymsg' script runs, the CVS +server has locks in place in the repository. If control is returned to +the user here then other users may be stuck waiting for access to the +repository. + + This option can be useful if you find yourself using an rcstemplate +that needs to be modified to remove empty elements or to fill in +default values. It can also be useful if the rcstemplate has changed +in the repository and the CVS/Template was not updated, but is able to +be adapted to the new format by the verification script that is run by +`verifymsg'. + + An example of an update might be to change all occurrences of +'BugId:' to be 'DefectId:' (which can be useful if the rcstemplate has +recently been changed and there are still checked-out user trees with +cached copies in the CVS/Template file of the older version). + + Another example of an update might be to delete a line that contains +'BugID: none' from the log message after validation of that value as +being allowed is made. + +* Menu: + +* verifymsg example:: Verifymsg example + + +File: cvs.info, Node: verifymsg example, Up: verifymsg + +C.3.5.1 Verifying log messages +.............................. + +The following is a little silly example of a `verifymsg' file, together +with the corresponding `rcsinfo' file, the log message template and a +verification script. We begin with the log message template. We want +to always record a bug-id number on the first line of the log message. +The rest of log message is free text. The following template is found +in the file `/usr/cvssupport/tc.template'. + + BugId: + + The script `/usr/cvssupport/bugid.verify' is used to evaluate the +log message. + + #!/bin/sh + # + # bugid.verify filename + # + # Verify that the log message contains a valid bugid + # on the first line. + # + if sed 1q < $1 | grep '^BugId:[ ]*[0-9][0-9]*$' > /dev/null; then + exit 0 + elif sed 1q < $1 | grep '^BugId:[ ]*none$' > /dev/null; then + # It is okay to allow commits with 'BugId: none', + # but do not put that text into the real log message. + grep -v '^BugId:[ ]*none$' > $1.rewrite + mv $1.rewrite $1 + exit 0 + else + echo "No BugId found." + exit 1 + fi + + The `verifymsg' file contains this line: + + ^tc /usr/cvssupport/bugid.verify %l + + The `rcsinfo' file contains this line: + + ^tc /usr/cvssupport/tc.template + + The `config' file contains this line: + + RereadLogAfterVerify=always + + +File: cvs.info, Node: loginfo, Next: postadmin, Prev: verifymsg, Up: Trigger Scripts + +C.3.6 Loginfo +------------- + +The `loginfo' file is used to control where log information is sent +after versioned changes are made to repository archive files and after +directories are added ot the repository. *Note posttag:: for how to +log tagging information and *Note postadmin:: for how to log changes +due to the `admin' command. + + The `loginfo' file has the standard form for script hooks (*note +Trigger Scripts::), where each line is a regular expression followed by +a command to execute. It supports the ALL and DEFAULT keywords. + + Any specified scripts are called: + +`commit' + Once per directory, immediately after a successfully completing + the commit of all files within that directory. + +`import' + Once per import, immediately after completion of all write + operations. + +`add' + Immediately after the successful `add' of a directory. + + Any script called via `loginfo' will be fed the log information on +its standard input. Note that the filter program *must* read *all* of +the log information from its standard input or CVS may fail with a +broken pipe signal. + + In addition to the common format strings (*note syntax::), `loginfo' +supports: + +{stVv} + File attributes, where: + s + file name + + T + tag name of destination, or the empty string when there is no + associated tag name (this usually means the trunk) + + V + old version number (pre-checkin) + + v + new version number (post-checkin) + + For example, some valid format strings are `%%', `%s', `%{s}', and +`%{stVv}'. + + Currently, if `UseNewInfoFmtStrings' is not set in the `config' +administration file (*note config::), the format strings will be +substituted as they were in past versions of CVS, but this feature is +deprecated. It is simply in place so that legacy repositories will +remain compatible with the new CVS application. For information on +updating, please see *Note Updating Commit Files::. + + As an example, if `/u/src/master/yoyodyne/tc' is the repository, `%p' +and `%{sVv}' are the format strings, and three files (ChangeLog, +Makefile, foo.c) were modified, the output might be: + + yoyodyne/tc ChangeLog 1.1 1.2 Makefile 1.3 1.4 foo.c 1.12 1.13 + + Note: when CVS is accessing a remote repository, `loginfo' will be +run on the _remote_ (i.e., server) side, not the client side (*note +Remote repositories::). + +* Menu: + +* loginfo example:: Loginfo example +* Keeping a checked out copy:: Updating a tree on every checkin + + +File: cvs.info, Node: loginfo example, Next: Keeping a checked out copy, Up: loginfo + +C.3.6.1 Loginfo example +....................... + +The following `loginfo' file, together with the tiny shell-script +below, appends all log messages to the file +`$CVSROOT/CVSROOT/commitlog', and any commits to the administrative +files (inside the `CVSROOT' directory) are also logged in +`/usr/adm/cvsroot-log'. Commits to the `prog1' directory are mailed to +ceder. + + ALL /usr/local/bin/cvs-log $CVSROOT/CVSROOT/commitlog $USER + ^CVSROOT\(/\|$\) /usr/local/bin/cvs-log /usr/adm/cvsroot-log $USER + ^prog1\(/\|$\) Mail -s "%p %s" ceder + + The shell-script `/usr/local/bin/cvs-log' looks like this: + + #!/bin/sh + (echo "------------------------------------------------------"; + echo -n "$2 "; + date; + echo; + cat) >> $1 + + +File: cvs.info, Node: Keeping a checked out copy, Prev: loginfo example, Up: loginfo + +C.3.6.2 Keeping a checked out copy +.................................. + +It is often useful to maintain a directory tree which contains files +which correspond to the latest version in the repository. For example, +other developers might want to refer to the latest sources without +having to check them out, or you might be maintaining a web site with +CVS and want every checkin to cause the files used by the web server to +be updated. + + The way to do this is by having loginfo invoke `cvs update'. Doing +so in the naive way will cause a problem with locks, so the `cvs update' +must be run in the background. Here is an example for unix (this +should all be on one line): + + ^cyclic-pages\(/\|$\) (date; cat; (sleep 2; cd /u/www/local-docs; + cvs -q update -d) &) >> $CVSROOT/CVSROOT/updatelog 2>&1 + + This will cause checkins to repository directory `cyclic-pages' and +its subdirectories to update the checked out tree in +`/u/www/local-docs'. + + +File: cvs.info, Node: postadmin, Next: taginfo, Prev: loginfo, Up: Trigger Scripts + +C.3.7 Logging admin commands +---------------------------- + +The `postadmin' file defines programs to execute after an `admin' +command modifies files. The `postadmin' file has the standard form for +script hooks (*note Trigger Scripts::), where each line is a regular +expression followed by a command to execute. It supports the ALL and +DEFAULT keywords. + + The `postadmin' file supports no format strings other than the common +ones (*note syntax::), + + +File: cvs.info, Node: taginfo, Next: posttag, Prev: postadmin, Up: Trigger Scripts + +C.3.8 Taginfo +------------- + +The `taginfo' file defines programs to execute when someone executes a +`tag' or `rtag' command. The `taginfo' file has the standard form for +script hooks (*note Trigger Scripts::), where each line is a regular +expression followed by a command to execute. It supports the ALL and +DEFAULT keywords. + + In addition to the common format strings (*note syntax::), `taginfo' +supports: + +b + tag type (`T' for branch, `N' for not-branch, or `?' for unknown, + as during delete operations) + +o + operation (`add' for `tag', `mov' for `tag -F', or `del' for `tag + -d') + +t + new tag name + +{sTVv} + file attributes, where: + s + file name + + T + tag name of destination, or the empty string when there is no + associated tag name (this usually means the trunk) + + V + old version number (for a move or delete operation) + + v + new version number (for an add or move operation) + + For example, some valid format strings are `%%', `%p', `%t', `%s', +`%{s}', and `%{sVv}'. + + Currently, if no format strings are specified, a default string of ` +%t %o %p %{sv}' will be appended to the command line template before +replacement is performed, but this feature is deprecated. It is simply +in place so that legacy repositories will remain compatible with the +new CVS application. For information on updating, *note Updating +Commit Files::. + + A non-zero exit of the filter program will cause the tag to be +aborted. + + Here is an example of using `taginfo' to log `tag' and `rtag' +commands. In the `taginfo' file put: + + ALL /usr/local/cvsroot/CVSROOT/loggit %t %b %o %p %{sVv} + +Where `/usr/local/cvsroot/CVSROOT/loggit' contains the following script: + + #!/bin/sh + echo "$@" >>/home/kingdon/cvsroot/CVSROOT/taglog + + +File: cvs.info, Node: posttag, Next: postwatch, Prev: taginfo, Up: Trigger Scripts + +C.3.9 Logging tags +------------------ + +The `posttag' file defines programs to execute after a `tag' or `rtag' +command modifies files. The `posttag' file has the standard form for +script hooks (*note Trigger Scripts::), where each line is a regular +expression followed by a command to execute. It supports the ALL and +DEFAULT keywords. + + The `posttag' admin file supports the same format strings as the +`taginfo' file (*note taginfo::), + + +File: cvs.info, Node: postwatch, Next: preproxy, Prev: posttag, Up: Trigger Scripts + +C.3.10 Logging watch commands +----------------------------- + +The `postwatch' file defines programs to execute after any command (for +instance, `watch', `edit', `unedit', or `commit') modifies any +`CVS/fileattr' file in the repository (*note Watches::). The +`postwatch' file has the standard form for script hooks (*note Trigger +Scripts::), where each line is a regular expression followed by a +command to execute. It supports the ALL and DEFAULT keywords. + + The `postwatch' file supports no format strings other than the common +ones (*note syntax::), but it is worth noting that the `%c' format +string may not be replaced as you might expect. Client runs of `edit' +and `unedit' can sometimes skip contacting the CVS server and cache the +notification of the file attribute change to be sent the next time the +client contacts the server for whatever other reason, + + +File: cvs.info, Node: preproxy, Next: postproxy, Prev: postwatch, Up: Trigger Scripts + +C.3.11 Launch a Script before Proxying +-------------------------------------- + +The `preproxy' file defines programs to execute after a secondary +server receives a write request from a client, just before it starts up +the primary server and becomes a write proxy. This hook could be used +to dial a modem, launch an SSH tunnel, establish a VPN, or anything +else that might be necessary to do before contacting the primary server. + + `preproxy' scripts are called once, at the time of the write +request, with the repository argument (if requested) set from the +topmost directory sent by the client. + + The `preproxy' file has the standard form for script hooks (*note +Trigger Scripts::), where each line is a regular expression followed by +a command to execute. It supports the ALL and DEFAULT keywords. + + In addition to the common format strings, the `preproxy' file +supports the following format string: + +P + the CVSROOT string which specifies the primary server + + +File: cvs.info, Node: postproxy, Prev: preproxy, Up: Trigger Scripts + +C.3.12 Launch a Script after Proxying +------------------------------------- + +The `postproxy' file defines programs to execute after a secondary +server notes that the connection to the primary server has shut down +and before it releases the client by shutting down the connection to +the client. This could hook could be used to disconnect a modem, an +SSH tunnel, a VPN, or anything else that might be necessary to do after +contacting the primary server. This hook should also be used to pull +updates from the primary server before allowing the client which did +the write to disconnect since otherwise the client's next read request +may generate error messages and fail upon encountering an out of date +repository on the secondary server. + + `postproxy' scripts are called once per directory. + + The `postproxy' file has the standard form for script hooks (*note +Trigger Scripts::), where each line is a regular expression followed by +a command to execute. It supports the ALL and DEFAULT keywords. + + In addition to the common format strings, the `postproxy' file +supports the following format string: + +P + the CVSROOT string which specifies the primary server + + +File: cvs.info, Node: rcsinfo, Next: cvsignore, Prev: Trigger Scripts, Up: Administrative files + +C.4 Rcsinfo +=========== + +The `rcsinfo' file can be used to specify a form to edit when filling +out the commit log. The `rcsinfo' file has a syntax similar to the +`verifymsg', `commitinfo' and `loginfo' files. *Note syntax::. Unlike +the other files the second part is _not_ a command-line template. +Instead, the part after the regular expression should be a full +pathname to a file containing the log message template. + + If the repository name does not match any of the regular expressions +in this file, the `DEFAULT' line is used, if it is specified. + + All occurrences of the name `ALL' appearing as a regular expression +are used in addition to the first matching regular expression or +`DEFAULT'. + + The log message template will be used as a default log message. If +you specify a log message with `cvs commit -m MESSAGE' or `cvs commit -f +FILE' that log message will override the template. + + *Note verifymsg::, for an example `rcsinfo' file. + + When CVS is accessing a remote repository, the contents of `rcsinfo' +at the time a directory is first checked out will specify a template. +This template will be updated on all `cvs update' commands. It will +also be added to new directories added with a `cvs add new-directory' +command. In versions of CVS prior to version 1.12, the `CVS/Template' +file was not updated. If the CVS server is at version 1.12 or higher an +older client may be used and the `CVS/Template' will be updated from +the server. + + +File: cvs.info, Node: cvsignore, Next: checkoutlist, Prev: rcsinfo, Up: Administrative files + +C.5 Ignoring files via cvsignore +================================ + +There are certain file names that frequently occur inside your working +copy, but that you don't want to put under CVS control. Examples are +all the object files that you get while you compile your sources. +Normally, when you run `cvs update', it prints a line for each file it +encounters that it doesn't know about (*note update output::). + + CVS has a list of files (or sh(1) file name patterns) that it should +ignore while running `update', `import' and `release'. This list is +constructed in the following way. + + * The list is initialized to include certain file name patterns: + names associated with CVS administration, or with other common + source control systems; common names for patch files, object files, + archive files, and editor backup files; and other names that are + usually artifacts of assorted utilities. Currently, the default + list of ignored file name patterns is: + + RCS SCCS CVS CVS.adm + RCSLOG cvslog.* + tags TAGS + .make.state .nse_depinfo + *~ #* .#* ,* _$* *$ + *.old *.bak *.BAK *.orig *.rej .del-* + *.a *.olb *.o *.obj *.so *.exe + *.Z *.elc *.ln + core + + * The per-repository list in `$CVSROOT/CVSROOT/cvsignore' is + appended to the list, if that file exists. + + * The per-user list in `.cvsignore' in your home directory is + appended to the list, if it exists. + + * Any entries in the environment variable `$CVSIGNORE' is appended + to the list. + + * Any `-I' options given to CVS is appended. + + * As CVS traverses through your directories, the contents of any + `.cvsignore' will be appended to the list. The patterns found in + `.cvsignore' are only valid for the directory that contains them, + not for any sub-directories. + + In any of the 5 places listed above, a single exclamation mark (`!') +clears the ignore list. This can be used if you want to store any file +which normally is ignored by CVS. + + Specifying `-I !' to `cvs import' will import everything, which is +generally what you want to do if you are importing files from a +pristine distribution or any other source which is known to not contain +any extraneous files. However, looking at the rules above you will see +there is a fly in the ointment; if the distribution contains any +`.cvsignore' files, then the patterns from those files will be +processed even if `-I !' is specified. The only workaround is to +remove the `.cvsignore' files in order to do the import. Because this +is awkward, in the future `-I !' might be modified to override +`.cvsignore' files in each directory. + + Note that the syntax of the ignore files consists of a series of +lines, each of which contains a space separated list of filenames. +This offers no clean way to specify filenames which contain spaces, but +you can use a workaround like `foo?bar' to match a file named `foo bar' +(it also matches `fooxbar' and the like). Also note that there is +currently no way to specify comments. + + +File: cvs.info, Node: checkoutlist, Next: history file, Prev: cvsignore, Up: Administrative files + +C.6 The checkoutlist file +========================= + +It may be helpful to use CVS to maintain your own files in the +`CVSROOT' directory. For example, suppose that you have a script +`logcommit.pl' which you run by including the following line in the +`commitinfo' administrative file: + + ALL $CVSROOT/CVSROOT/logcommit.pl %r/%p %s + + To maintain `logcommit.pl' with CVS you would add the following line +to the `checkoutlist' administrative file: + + logcommit.pl + + The format of `checkoutlist' is one line for each file that you want +to maintain using CVS, giving the name of the file, followed optionally +by more whitespace and any error message that should print if the file +cannot be checked out into CVSROOT after a commit: + + logcommit.pl Could not update CVSROOT/logcommit.pl. + + After setting up `checkoutlist' in this fashion, the files listed +there will function just like CVS's built-in administrative files. For +example, when checking in one of the files you should get a message +such as: + + cvs commit: Rebuilding administrative file database + +and the checked out copy in the `CVSROOT' directory should be updated. + + Note that listing `passwd' (*note Password authentication server::) +in `checkoutlist' is not recommended for security reasons. + + For information about keeping a checkout out copy in a more general +context than the one provided by `checkoutlist', see *Note Keeping a +checked out copy::. + + +File: cvs.info, Node: history file, Next: Variables, Prev: checkoutlist, Up: Administrative files + +C.7 The history file +==================== + +By default, the file `$CVSROOT/CVSROOT/history' is used to log +information for the `history' command (*note history::). This file +name may be changed with the `HistoryLogPath' and `HistorySearchPath' +config options (*note config::). + + The file format of the `history' file is documented only in comments +in the CVS source code, but generally programs should use the `cvs +history' command to access it anyway, in case the format changes with +future releases of CVS. + + +File: cvs.info, Node: Variables, Next: config, Prev: history file, Up: Administrative files + +C.8 Expansions in administrative files +====================================== + +Sometimes in writing an administrative file, you might want the file to +be able to know various things based on environment CVS is running in. +There are several mechanisms to do that. + + To find the home directory of the user running CVS (from the `HOME' +environment variable), use `~' followed by `/' or the end of the line. +Likewise for the home directory of USER, use `~USER'. These variables +are expanded on the server machine, and don't get any reasonable +expansion if pserver (*note Password authenticated::) is in use; +therefore user variables (see below) may be a better choice to +customize behavior based on the user running CVS. + + One may want to know about various pieces of information internal to +CVS. A CVS internal variable has the syntax `${VARIABLE}', where +VARIABLE starts with a letter and consists of alphanumeric characters +and `_'. If the character following VARIABLE is a non-alphanumeric +character other than `_', the `{' and `}' can be omitted. The CVS +internal variables are: + +`CVSROOT' + This is the absolute path to the current CVS root directory. + *Note Repository::, for a description of the various ways to + specify this, but note that the internal variable contains just + the directory and not any of the access method information. + +`RCSBIN' + In CVS 1.9.18 and older, this specified the directory where CVS + was looking for RCS programs. Because CVS no longer runs RCS + programs, specifying this internal variable is now an error. + +`CVSEDITOR' +`EDITOR' +`VISUAL' + These all expand to the same value, which is the editor that CVS + is using. *Note Global options::, for how to specify this. + +`USER' + Username of the user running CVS (on the CVS server machine). + When using pserver, this is the user specified in the repository + specification which need not be the same as the username the + server is running as (*note Password authentication server::). Do + not confuse this with the environment variable of the same name. + +`SESSIONID' + Unique Session ID of the CVS process. This is a random string of + printable characters of at least 16 characters length. Users + should assume that it may someday grow to at most 256 characters + in length. + +`COMMITID' + Unique Session ID of the CVS process. This is a random string of + printable characters of at least 16 characters length. Users + should assume that it may someday grow to at most 256 characters + in length. + + If you want to pass a value to the administrative files which the +user who is running CVS can specify, use a user variable. To expand a +user variable, the administrative file contains `${=VARIABLE}'. To set +a user variable, specify the global option `-s' to CVS, with argument +`VARIABLE=VALUE'. It may be particularly useful to specify this option +via `.cvsrc' (*note ~/.cvsrc::). + + For example, if you want the administrative file to refer to a test +directory you might create a user variable `TESTDIR'. Then if CVS is +invoked as + + cvs -s TESTDIR=/work/local/tests + +and the administrative file contains `sh ${=TESTDIR}/runtests', then +that string is expanded to `sh /work/local/tests/runtests'. + + All other strings containing `$' are reserved; there is no way to +quote a `$' character so that `$' represents itself. + + Environment variables passed to administrative files are: + +`CVS_USER' + The CVS-specific username provided by the user, if it can be + provided (currently just for the pserver access method), and to + the empty string otherwise. (`CVS_USER' and `USER' may differ + when `$CVSROOT/CVSROOT/passwd' is used to map CVS usernames to + system usernames.) + +`LOGNAME' + The username of the system user. + +`USER' + Same as `LOGNAME'. Do not confuse this with the internal variable + of the same name. + + +File: cvs.info, Node: config, Prev: Variables, Up: Administrative files + +C.9 The CVSROOT/config configuration file +========================================= + +Usually, the `config' file is found at `$CVSROOT/CVSROOT/config', but +this may be overridden on the `pserver' and `server' command lines +(*note server & pserver::). + + The administrative file `config' contains various miscellaneous +settings which affect the behavior of CVS. The syntax is slightly +different from the other administrative files. + + Leading white space on any line is ignored, though the syntax is +very strict and will reject spaces and tabs almost anywhere else. + + Empty lines, lines containing nothing but white space, and lines +which start with `#' (discounting any leading white space) are ignored. + + Other lines consist of the optional leading white space, a keyword, +`=', and a value. Please note again that this syntax is very strict. +Extraneous spaces or tabs, other than the leading white space, are not +permitted on these lines. + + As of CVS 1.12.13, lines of the form `[CVSROOT]' mark the subsequent +section of the config file as applying only to certain repositories. +Multiple `[CVSROOT]' lines without intervening `KEYWORD=VALUE' pairs +cause processing to fall through, processing subsequent keywords for +any root in the list. Finally, keywords and values which appear before +any `[CVSROOT]' lines are defaults, and may to apply to any repository. +For example, consider the following file: + + # Defaults + LogHistory=TMAR + + [/cvsroots/team1] + LockDir=/locks/team1 + + [/cvsroots/team2] + LockDir=/locks/team2 + + [/cvsroots/team3] + LockDir=/locks/team3 + + [/cvsroots/team4] + LockDir=/locks/team4 + + [/cvsroots/team3] + [/cvsroots/team4] + # Override logged commands for teams 3 & 4. + LogHistory=all + + This example file sets up separate lock directories for each +project, as well as a default set of logged commands overridden for the +example's team 3 & team 4. This syntax could be useful, for instance, +if you wished to share a single config file, for instance +`/etc/cvs.conf', among several repositories. + + Currently defined keywords are: + +`HistorySearchPath=PATTERN' + Request that CVS look for its history information in files matching + PATTERN, which is a standard UNIX file glob. If PATTERN matches + multiple files, all will be searched in lexicographically sorted + order. *Note history::, and *Note history file::, for more. + + If no value is supplied for this option, it defaults to + `$CVSROOT/CVSROOT/history'. + +`HistoryLogPath=PATH' + Control where CVS logs its history. If the file does not exist, + CVS will attempt to create it. Format strings, as available to + the GNU C `strftime' function and often the UNIX date command, and + the string $CVSROOT will be substituted in this path. For + example, consider the line: + + HistoryLogPath=$CVSROOT/CVSROOT/history/%Y-%m-%d + + This line would cause CVS to attempt to create its history file in + a subdirectory (`history') of the configuration directory + (`CVSROOT') with a name equal to the current date representation + in the ISO8601 format (for example, on May 11, 2005, CVS would + attempt to log its history under the repository root directory in + a file named `CVSROOT/history/2005-05-11'). *Note history::, and + *Note history file::, for more. + + If no value is supplied for this option, it defaults to + `$CVSROOT/CVSROOT/history'. + +`ImportNewFilesToVendorBranchOnly=VALUE' + Specify whether `cvs import' should always behave as if the `-X' + flag was specified on the command line. VALUE may be either `yes' + or `no'. If set to `yes', all uses of `cvs import' on the + repository will behave as if the `-X' flag was set. The default + value is `no'. + +`KeywordExpand=VALUE' + Specify `i' followed by a list of keywords to be expanded (for + example, `KeywordExpand=iMYCVS,Name,Date'), or `e' followed by a + list of keywords not to be expanded (for example, + `KeywordExpand=eCVSHeader'). For more on keyword expansion, see + *Note Configuring keyword expansion::. + +`LocalKeyword=VALUE' + Specify a local alias for a standard keyword. For example, + `LocalKeyword=MYCVS=CVSHeader'. For more on local keywords, see + *Note Keyword substitution::. + +`LockDir=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 *Note Concurrency::. + + 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. + +`LogHistory=VALUE' + Control what is logged to the `CVSROOT/history' file (*note + history::). 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'.) To disable history logging completely, use + `LogHistory='. + +`MaxCommentLeaderLength=LENGTH' + Set to some length, in bytes, where a trailing `k', `M', `G', or + `T' causes the preceding nubmer to be interpreted as kilobytes, + megabytes, gigabytes, or terrabytes, respectively, will cause + `$Log$' keywords (*note Keyword substitution::), with more than + LENGTH bytes preceding it on a line to be ignored (or to fall back + on the comment leader set in the RCS archive file - see + `UseArchiveCommentLeader' below). Defaults to 20 bytes to allow + checkouts to proceed normally when they include binary files + containing `$Log$' keywords and which users have neglected to mark + as binary. + +`MinCompressionLevel=VALUE' +`MaxCompressionLevel=VALUE' + Restricts the level of compression used by the CVS server to a + VALUE between 0 and 9. VALUEs 1 through 9 are the same ZLIB + compression levels accepted by the `-z' option (*note Global + options::), and 0 means no compression. When one or both of these + keys are set and a client requests a level outside the specified + range, the server will simply use the closest permissable level. + Clients will continue compressing at the level requested by the + user. + + The exception is when level 0 (no compression) is not available + and the client fails to request any compression. The CVS server + will then exit with an error message when it becomes apparent that + the client is not going to request compression. This will not + happen with clients version 1.12.13 and later since these client + versions allow the server to notify them that they must request + some level of compression. + +`PrimaryServer=CVSROOT' + When specified, and the repository specified by CVSROOT is not the + one currently being accessed, then the server will turn itself + into a transparent proxy to CVSROOT for write requests. The + HOSTNAME configured as part of CVSROOT must resolve to the same + string returned by the `uname' command on the primary server for + this to work. Host name resolution is performed via some + combination of `named', a broken out line from `/etc/hosts', and + the Network Information Service (NIS or YP), depending on the + configuration of the particular system. + + Only the `:ext:' method is currently supported for primaries + (actually, `:fork:' is supported as well, but only for testing - + if you find another use for accessing a primary via the `:fork:' + method, please send a note to <bug-cvs@nongnu.org> about it). See + *Note Write proxies:: for more on configuring and using write + proxies. + +`RCSBIN=BINDIR' + 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. + +`RereadLogAfterVerify=VALUE' + 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'. + + *Note_ 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* + + *Note verifymsg::, for more information on how verifymsg may be + used. + +`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 *Note Password + authenticated::. + +`TmpDir=PATH' + Specify PATH as the directory to create temporary files in. *Note + Global options::, for more on setting the path to the temporary + directory. This option first appeared with CVS release 1.12.13. + +`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 (*note Working directory storage::). + +`UseArchiveCommentLeader=VALUE' + Set to `true', if the text preceding a `$Log$' keyword is found to + exceed `MaxCommentLeaderLength' (above) bytes, then the comment + leader set in the RCS archive file (*note admin::), if any, will + be used instead. If there is no comment leader set in the archive + file or VALUE is set to `false', then the keyword will not be + expanded (*note Keyword list::). To force the comment leader in + the RCS archive file to be used exclusively (and `$Log$' expansion + skipped in files where the comment leader has not been set in the + archive file), set VALUE and set `MaxCommentLeaderLength' to `0'. + +`UseNewInfoFmtStrings=VALUE' + Specify whether CVS should support the new or old command line + template model for the commit support files (*note commit files::). + This configuration variable began life in deprecation and is only + here in order to give people time to update legacy repositories to + use the new format string syntax before support for the old syntax + is removed. For information on updating your repository to + support the new model, please see *Note Updating Commit Files::. + + _Note that new repositories (created with the `cvs init' command) + will have this value set to `yes', but the default value is `no'._ + +`UserAdminOptions=VALUE' + Control what options will be allowed with the `cvs admin' command + (*note admin::) for users not in the `cvsadmin' group. The VALUE + string is a list of single character options which should be + allowed. If a user who is not a member of the `cvsadmin' group + tries to execute any `cvs admin' option which is not listed they + will will receive an error message reporting that the option is + restricted. + + If no `cvsadmin' group exists on the server, CVS will ignore the + `UserAdminOptions' keyword (*note admin::). + + When not specified, `UserAdminOptions' defaults to `k'. In other + words, it defaults to allowing users outside of the `cvsadmin' + group to use the `cvs admin' command only to change the default + keyword expansion mode for files. + + As an example, to restrict users not in the `cvsadmin' group to + using `cvs admin' to change the default keyword substitution mode, + lock revisions, unlock revisions, and replace the log message, use + `UserAdminOptions=klum'. + + +File: cvs.info, Node: Environment variables, Next: Compatibility, Prev: Administrative files, Up: Top + +Appendix D All environment variables which affect CVS +***************************************************** + +This is a complete list of all environment variables that affect CVS +(Windows users, please bear with this list; $VAR is equivalent to %VAR% +at the Windows command prompt). + +`$CVSIGNORE' + A whitespace-separated list of file name patterns that CVS should + ignore. *Note cvsignore::. + +`$CVSWRAPPERS' + A whitespace-separated list of file name patterns that CVS should + treat as wrappers. *Note Wrappers::. + +`$CVSREAD' + If this is set, `checkout' and `update' will try hard to make the + files in your working directory read-only. When this is not set, + the default behavior is to permit modification of your working + files. + +`$CVSREADONLYFS' + Turns on read-only repository mode. This allows one to check out + from a read-only repository, such as within an anoncvs server, or + from a CD-ROM repository. + + It has the same effect as if the `-R' command-line option is used. + This can also allow the use of read-only NFS repositories. + +`$CVSUMASK' + Controls permissions of files in the repository. See *Note File + permissions::. + +`$CVSROOT' + Should contain the full pathname to the root of the CVS source + repository (where the RCS files are kept). This information must + be available to CVS for most commands to execute; if `$CVSROOT' is + not set, or if you wish to override it for one invocation, you can + supply it on the command line: `cvs -d cvsroot cvs_command...' + Once you have checked out a working directory, CVS stores the + appropriate root (in the file `CVS/Root'), so normally you only + need to worry about this when initially checking out a working + directory. + +`$CVSEDITOR' +`$EDITOR' +`$VISUAL' + Specifies the program to use for recording log messages during + commit. `$CVSEDITOR' overrides `$EDITOR', which overrides + `$VISUAL'. See *Note Committing your changes:: for more or *Note + Global options:: for alternative ways of specifying a log editor. + +`$PATH' + If `$RCSBIN' is not set, and no path is compiled into CVS, it will + use `$PATH' to try to find all programs it uses. + +`$HOME' + +`$HOMEPATH' + +`$HOMEDRIVE' + Used to locate the directory where the `.cvsrc' file, and other + such files, are searched. On Unix, CVS just checks for `HOME'. + On Windows NT, the system will set `HOMEDRIVE', for example to + `d:' and `HOMEPATH', for example to `\joe'. On Windows 95, you'll + probably need to set `HOMEDRIVE' and `HOMEPATH' yourself. + +`$CVS_RSH' + Specifies the external program which CVS connects with, when + `:ext:' access method is specified. *note Connecting via rsh::. + +`$CVS_SERVER' + Used in client-server mode when accessing a remote repository + using RSH. It specifies the name of the program to start on the + server side (and any necessary arguments) when accessing a remote + repository using the `:ext:', `:fork:', or `:server:' access + methods. The default value for `:ext:' and `:server:' is `cvs'; + the default value for `:fork:' is the name used to run the client. + *note Connecting via rsh:: + +`$CVS_PASSFILE' + Used in client-server mode when accessing the `cvs login server'. + Default value is `$HOME/.cvspass'. *note Password authentication + client:: + +`$CVS_CLIENT_PORT' + Used in client-server mode to set the port to use when accessing + the server via Kerberos, GSSAPI, or CVS's password authentication + protocol if the port is not specified in the CVSROOT. *note + Remote repositories:: + +`$CVS_PROXY_PORT' + Used in client-server mode to set the port to use when accessing a + server via a web proxy, if the port is not specified in the + CVSROOT. Works with GSSAPI, and the password authentication + protocol. *note Remote repositories:: + +`$CVS_RCMD_PORT' + Used in client-server mode. If set, specifies the port number to + be used when accessing the RCMD demon on the server side. + (Currently not used for Unix clients). + +`$CVS_CLIENT_LOG' + Used for debugging only in client-server mode. If set, everything + sent to the server is logged into ``$CVS_CLIENT_LOG'.in' and + everything sent from the server is logged into + ``$CVS_CLIENT_LOG'.out'. + +`$CVS_SERVER_SLEEP' + Used only for debugging the server side in client-server mode. If + set, delays the start of the server child process the specified + amount of seconds so that you can attach to it with a debugger. + +`$CVS_IGNORE_REMOTE_ROOT' + For CVS 1.10 and older, setting this variable prevents CVS from + overwriting the `CVS/Root' file when the `-d' global option is + specified. Later versions of CVS do not rewrite `CVS/Root', so + `CVS_IGNORE_REMOTE_ROOT' has no effect. + +`$CVS_LOCAL_BRANCH_NUM' + Setting this variable allows some control over the branch number + that is assigned. This is specifically to support the local commit + feature of CVSup. If one sets `CVS_LOCAL_BRANCH_NUM' to (say) 1000 + then branches the local repository, the revision numbers will look + like 1.66.1000.xx. There is almost a dead-set certainty that there + will be no conflicts with version numbers. + +`$COMSPEC' + Used under OS/2 only. It specifies the name of the command + interpreter and defaults to CMD.EXE. + +`$TMPDIR' + Directory in which temporary files are located. *Note Global + options::, for more on setting the temporary directory. + +`$CVS_PID' + This is the process identification (aka pid) number of the CVS + process. It is often useful in the programs and/or scripts + specified by the `commitinfo', `verifymsg', `loginfo' files. + + +File: cvs.info, Node: Compatibility, Next: Troubleshooting, Prev: Environment variables, Up: Top + +Appendix E Compatibility between CVS Versions +********************************************* + +The repository format is compatible going back to CVS 1.3. But see +*Note Watches Compatibility::, if you have copies of CVS 1.6 or older +and you want to use the optional developer communication features. + + The working directory format is compatible going back to CVS 1.5. +It did change between CVS 1.3 and CVS 1.5. If you run CVS 1.5 or newer +on a working directory checked out with CVS 1.3, CVS will convert it, +but to go back to CVS 1.3 you need to check out a new working directory +with CVS 1.3. + + The remote protocol is interoperable going back to CVS 1.5, but no +further (1.5 was the first official release with the remote protocol, +but some older versions might still be floating around). In many cases +you need to upgrade both the client and the server to take advantage of +new features and bug fixes, however. + + +File: cvs.info, Node: Troubleshooting, Next: Credits, Prev: Compatibility, Up: Top + +Appendix F Troubleshooting +************************** + +If you are having trouble with CVS, this appendix may help. If there +is a particular error message which you are seeing, then you can look +up the message alphabetically. If not, you can look through the +section on other problems to see if your problem is mentioned there. + +* Menu: + +* Error messages:: Partial list of CVS errors +* Connection:: Trouble making a connection to a CVS server +* Other problems:: Problems not readily listed by error message + + +File: cvs.info, Node: Error messages, Next: Connection, Up: Troubleshooting + +F.1 Partial list of error messages +================================== + +Here is a partial list of error messages that you may see from CVS. It +is not a complete list--CVS is capable of printing many, many error +messages, often with parts of them supplied by the operating system, +but the intention is to list the common and/or potentially confusing +error messages. + + The messages are alphabetical, but introductory text such as `cvs +update: ' is not considered in ordering them. + + In some cases the list includes messages printed by old versions of +CVS (partly because users may not be sure which version of CVS they are +using at any particular moment). + +`FILE:LINE: Assertion 'TEXT' failed' + The exact format of this message may vary depending on your + system. It indicates a bug in CVS, which can be handled as + described in *Note BUGS::. + +`cvs COMMAND: authorization failed: server HOST rejected access' + This is a generic response when trying to connect to a pserver + server which chooses not to provide a specific reason for denying + authorization. Check that the username and password specified are + correct and that the `CVSROOT' specified is allowed by + `--allow-root' in `inetd.conf'. See *Note Password + authenticated::. + +`cvs COMMAND: conflict: removed FILE was modified by second party' + This message indicates that you removed a file, and someone else + modified it. To resolve the conflict, first run `cvs add FILE'. + If desired, look at the other party's modification to decide + whether you still want to remove it. If you don't want to remove + it, stop here. If you do want to remove it, proceed with `cvs + remove FILE' and commit your removal. + +`cannot change permissions on temporary directory' + Operation not permitted + This message has been happening in a non-reproducible, occasional + way when we run the client/server testsuite, both on Red Hat Linux + 3.0.3 and 4.1. We haven't been able to figure out what causes it, + nor is it known whether it is specific to Linux (or even to this + particular machine!). If the problem does occur on other unices, + `Operation not permitted' would be likely to read `Not owner' or + whatever the system in question uses for the unix `EPERM' error. + If you have any information to add, please let us know as + described in *Note BUGS::. If you experience this error while + using CVS, retrying the operation which produced it should work + fine. + +`cvs [server aborted]: Cannot check out files into the repository itself' + The obvious cause for this message (especially for + non-client/server CVS) is that the CVS root is, for example, + `/usr/local/cvsroot' and you try to check out files when you are + in a subdirectory, such as `/usr/local/cvsroot/test'. However, + there is a more subtle cause, which is that the temporary + directory on the server is set to a subdirectory of the root + (which is also not allowed). If this is the problem, set the + temporary directory to somewhere else, for example `/var/tmp'; see + `TMPDIR' in *Note Environment variables::, for how to set the + temporary directory. + +`cannot commit files as 'root'' + See `'root' is not allowed to commit files'. + +`cannot open CVS/Entries for reading: No such file or directory' + This generally indicates a CVS internal error, and can be handled + as with other CVS bugs (*note BUGS::). Usually there is a + workaround--the exact nature of which would depend on the + situation but which hopefully could be figured out. + +`cvs [init aborted]: cannot open CVS/Root: No such file or directory' + This message is harmless. Provided it is not accompanied by other + errors, the operation has completed successfully. This message + should not occur with current versions of CVS, but it is documented + here for the benefit of CVS 1.9 and older. + +`cvs server: cannot open /root/.cvsignore: Permission denied' +`cvs [server aborted]: can't chdir(/root): Permission denied' + See *Note Connection::. + +`cvs [checkout aborted]: cannot rename file FILE to CVS/,,FILE: Invalid argument' + This message has been reported as intermittently happening with + CVS 1.9 on Solaris 2.5. The cause is unknown; if you know more + about what causes it, let us know as described in *Note BUGS::. + +`cvs [COMMAND aborted]: cannot start server via rcmd' + This, unfortunately, is a rather nonspecific error message which + CVS 1.9 will print if you are running the CVS client and it is + having trouble connecting to the server. Current versions of CVS + should print a much more specific error message. If you get this + message when you didn't mean to run the client at all, you + probably forgot to specify `:local:', as described in *Note + Repository::. + +`ci: FILE,v: bad diff output line: Binary files - and /tmp/T2a22651 differ' + CVS 1.9 and older will print this message when trying to check in + a binary file if RCS is not correctly installed. Re-read the + instructions that came with your RCS distribution and the INSTALL + file in the CVS distribution. Alternately, upgrade to a current + version of CVS, which checks in files itself rather than via RCS. + +`cvs checkout: could not check out FILE' + With CVS 1.9, this can mean that the `co' program (part of RCS) + returned a failure. It should be preceded by another error + message, however it has been observed without another error + message and the cause is not well-understood. With the current + version of CVS, which does not run `co', if this message occurs + without another error message, it is definitely a CVS bug (*note + BUGS::). + +`cvs [login aborted]: could not find out home directory' + This means that you need to set the environment variables that CVS + uses to locate your home directory. See the discussion of `HOME', + `HOMEDRIVE', and `HOMEPATH' in *Note Environment variables::. + +`cvs update: could not merge revision REV of FILE: No such file or directory' + CVS 1.9 and older will print this message if there was a problem + finding the `rcsmerge' program. Make sure that it is in your + `PATH', or upgrade to a current version of CVS, which does not + require an external `rcsmerge' program. + +`cvs [update aborted]: could not patch FILE: No such file or directory' + This means that there was a problem finding the `patch' program. + Make sure that it is in your `PATH'. Note that despite + appearances the message is _not_ referring to whether it can find + FILE. If both the client and the server are running a current + version of CVS, then there is no need for an external patch + program and you should not see this message. But if either client + or server is running CVS 1.9, then you need `patch'. + +`cvs update: could not patch FILE; will refetch' + This means that for whatever reason the client was unable to apply + a patch that the server sent. The message is nothing to be + concerned about, because inability to apply the patch only slows + things down and has no effect on what CVS does. + +`dying gasps from SERVER unexpected' + There is a known bug in the server for CVS 1.9.18 and older which + can cause this. For me, this was reproducible if I used the `-t' + global option. It was fixed by Andy Piper's 14 Nov 1997 change to + src/filesubr.c, if anyone is curious. If you see the message, you + probably can just retry the operation which failed, or if you have + discovered information concerning its cause, please let us know as + described in *Note BUGS::. + +`end of file from server (consult above messages if any)' + The most common cause for this message is if you are using an + external `rsh' program and it exited with an error. In this case + the `rsh' program should have printed a message, which will appear + before the above message. For more information on setting up a + CVS client and server, see *Note Remote repositories::. + +`cvs [update aborted]: EOF in key in RCS file FILE,v' +`cvs [checkout aborted]: EOF while looking for end of string in RCS file FILE,v' + This means that there is a syntax error in the given RCS file. + Note that this might be true even if RCS can read the file OK; CVS + does more error checking of errors in the RCS file. That is why + you may see this message when upgrading from CVS 1.9 to CVS 1.10. + The likely cause for the original corruption is hardware, the + operating system, or the like. Of course, if you find a case in + which CVS seems to corrupting the file, by all means report it, + (*note BUGS::). There are quite a few variations of this error + message, depending on exactly where in the RCS file CVS finds the + syntax error. + +`cvs commit: Executing 'mkmodules'' + This means that your repository is set up for a version of CVS + prior to CVS 1.8. When using CVS 1.8 or later, the above message + will be preceded by + + cvs commit: Rebuilding administrative file database + + If you see both messages, the database is being rebuilt twice, + which is unnecessary but harmless. If you wish to avoid the + duplication, and you have no versions of CVS 1.7 or earlier in + use, remove `-i mkmodules' every place it appears in your `modules' + file. For more information on the `modules' file, see *Note + modules::. + +`missing author' + Typically this can happen if you created an RCS file with your + username set to empty. CVS will, bogusly, create an illegal RCS + file with no value for the author field. The solution is to make + sure your username is set to a non-empty value and re-create the + RCS file. + +`cvs [checkout aborted]: no such tag TAG' + This message means that CVS isn't familiar with the tag TAG. + Usually the root cause is that you have mistyped a tag name. + Ocassionally this can also occur because the users creating tags + do not have permissions to write to the `CVSROOT/val-tags' file + (*note File permissions::, for more). + + Prior to CVS version 1.12.10, there were a few relatively obscure + cases where a given tag could be created in an archive file in the + repository but CVS would require the user to try a few other CVS + commands involving that tag until one was found whch caused CVS to + update the `val-tags' file, at which point the originally failing + command would begin to work. This same method can be used to + repair a `val-tags' file that becomes out of date due to the + permissions problem mentioned above. This updating is only + required once per tag - once a tag is listed in `val-tags', it + stays there. + + Note that using `tag -f' to not require tag matches did not and + does not override this check (*note Common options::). + +`*PANIC* administration files missing' + This typically means that there is a directory named CVS but it + does not contain the administrative files which CVS puts in a CVS + directory. If the problem is that you created a CVS directory via + some mechanism other than CVS, then the answer is simple, use a + name other than CVS. If not, it indicates a CVS bug (*note + BUGS::). + +`rcs error: Unknown option: -x,v/' + This message will be followed by a usage message for RCS. It + means that you have an old version of RCS (probably supplied with + your operating system), as well as an old version of CVS. CVS + 1.9.18 and earlier only work with RCS version 5 and later; current + versions of CVS do not run RCS programs. + +`cvs [server aborted]: received broken pipe signal' + This message can be caused by a loginfo program that fails to read + all of the log information from its standard input. If you find + it happening in any other circumstances, please let us know as + described in *Note BUGS::. + +`'root' is not allowed to commit files' + When committing a permanent change, CVS makes a log entry of who + committed the change. If you are committing the change logged in + as "root" (not under "su" or other root-priv giving program), CVS + cannot determine who is actually making the change. As such, by + default, CVS disallows changes to be committed by users logged in + as "root". (You can disable this option by passing the + `--enable-rootcommit' option to `configure' and recompiling CVS. + On some systems this means editing the appropriate `config.h' file + before building CVS.) + +`cvs [server aborted]: Secondary out of sync with primary!' + This usually means that the version of CVS running on a secondary + server is incompatible with the version running on the primary + server (*note Write proxies::). This will not occur if the client + supports redirection. + + It is not the version number that is significant here, but the + list of supported requests that the servers provide to the client. + For example, even if both servers were the same version, if the + secondary was compiled with GSSAPI support and the primary was not, + the list of supported requests provided by the two servers would + be different and the secondary would not work as a transparent + proxy to the primary. Conversely, even if the two servers were + radically different versions but both provided the same list of + valid requests to the client, the transparent proxy would succeed. + +`Terminated with fatal signal 11' + This message usually indicates that CVS (the server, if you're + using client/server mode) has run out of (virtual) memory. + Although CVS tries to catch the error and issue a more meaningful + message, there are many circumstances where that is not possible. + If you appear to have lots of memory available to the system, the + problem is most likely that you're running into a system-wide + limit on the amount of memory a single process can use or a + similar process-specific limit. The mechanisms for displaying and + setting such limits vary from system to system, so you'll have to + consult an expert for your particular system if you don't know how + to do that. + +`Too many arguments!' + This message is typically printed by the `log.pl' script which is + in the `contrib' directory in the CVS source distribution. In + some versions of CVS, `log.pl' has been part of the default CVS + installation. The `log.pl' script gets called from the `loginfo' + administrative file. Check that the arguments passed in `loginfo' + match what your version of `log.pl' expects. In particular, the + `log.pl' from CVS 1.3 and older expects the log file as an + argument whereas the `log.pl' from CVS 1.5 and newer expects the + log file to be specified with a `-f' option. Of course, if you + don't need `log.pl' you can just comment it out of `loginfo'. + +`cvs [update aborted]: unexpected EOF reading FILE,v' + See `EOF in key in RCS file'. + +`cvs [login aborted]: unrecognized auth response from SERVER' + This message typically means that the server is not set up + properly. For example, if `inetd.conf' points to a nonexistent + cvs executable. To debug it further, find the log file which + inetd writes (`/var/log/messages' or whatever inetd uses on your + system). For details, see *Note Connection::, and *Note Password + authentication server::. + +`cvs commit: Up-to-date check failed for `FILE'' + This means that someone else has committed a change to that file + since the last time that you did a `cvs update'. So before + proceeding with your `cvs commit' you need to `cvs update'. CVS + will merge the changes that you made and the changes that the + other person made. If it does not detect any conflicts it will + report `M FILE' and you are ready to `cvs commit'. If it detects + conflicts it will print a message saying so, will report `C FILE', + and you need to manually resolve the conflict. For more details + on this process see *Note Conflicts example::. + +`Usage: diff3 [-exEX3 [-i | -m] [-L label1 -L label3]] file1 file2 file3' + Only one of [exEX3] allowed + This indicates a problem with the installation of `diff3' and + `rcsmerge'. Specifically `rcsmerge' was compiled to look for GNU + diff3, but it is finding unix diff3 instead. The exact text of + the message will vary depending on the system. The simplest + solution is to upgrade to a current version of CVS, which does not + rely on external `rcsmerge' or `diff3' programs. + +`warning: unrecognized response `TEXT' from cvs server' + If TEXT contains a valid response (such as `ok') followed by an + extra carriage return character (on many systems this will cause + the second part of the message to overwrite the first part), then + it probably means that you are using the `:ext:' access method + with a version of rsh, such as most non-unix rsh versions, which + does not by default provide a transparent data stream. In such + cases you probably want to try `:server:' instead of `:ext:'. If + TEXT is something else, this may signify a problem with your CVS + server. Double-check your installation against the instructions + for setting up the CVS server. + +`cvs commit: [TIME] waiting for USER's lock in DIRECTORY' + This is a normal message, not an error. See *Note Concurrency::, + for more details. + +`cvs commit: warning: editor session failed' + This means that the editor which CVS is using exits with a nonzero + exit status. Some versions of vi will do this even when there was + not a problem editing the file. If so, point the `CVSEDITOR' + environment variable to a small script such as: + + #!/bin/sh + vi $* + exit 0 + +`cvs update: warning: FILE was lost' + This means that the working copy of FILE has been deleted but it + has not been removed from CVS. This is nothing to be concerned + about, the update will just recreate the local file from the + repository. (This is a convenient way to discard local changes to + a file: just delete it and then run `cvs update'.) + +`cvs update: warning: FILE is not (any longer) pertinent' + This means that the working copy of FILE has been deleted, it has + not been removed from CVS in the current working directory, but it + has been removed from CVS in some other working directory. This + is nothing to be concerned about, the update would have removed + the local file anyway. + + + +File: cvs.info, Node: Connection, Next: Other problems, Prev: Error messages, Up: Troubleshooting + +F.2 Trouble making a connection to a CVS server +=============================================== + +This section concerns what to do if you are having trouble making a +connection to a CVS server. If you are running the CVS command line +client running on Windows, first upgrade the client to CVS 1.9.12 or +later. The error reporting in earlier versions provided much less +information about what the problem was. If the client is non-Windows, +CVS 1.9 should be fine. + + If the error messages are not sufficient to track down the problem, +the next steps depend largely on which access method you are using. + +`:ext:' + Try running the rsh program from the command line. For example: + "rsh servername cvs -v" should print CVS version information. If + this doesn't work, you need to fix it before you can worry about + CVS problems. + +`:server:' + You don't need a command line rsh program to use this access + method, but if you have an rsh program around, it may be useful as + a debugging tool. Follow the directions given for :ext:. + +`:pserver:' + Errors along the lines of "connection refused" typically indicate + that inetd isn't even listening for connections on port 2401 + whereas errors like "connection reset by peer", "received broken + pipe signal", "recv() from server: EOF", or "end of file from + server" typically indicate that inetd is listening for connections + but is unable to start CVS (this is frequently caused by having an + incorrect path in `inetd.conf' or by firewall software rejecting + the connection). "unrecognized auth response" errors are caused + by a bad command line in `inetd.conf', typically an invalid option + or forgetting to put the `pserver' command at the end of the line. + Another less common problem is invisible control characters that + your editor "helpfully" added without you noticing. + + One good debugging tool is to "telnet servername 2401". After + connecting, send any text (for example "foo" followed by return). + If CVS is working correctly, it will respond with + + cvs [pserver aborted]: bad auth protocol start: foo + + If instead you get: + + Usage: cvs [cvs-options] command [command-options-and-arguments] + ... + + then you're missing the `pserver' command at the end of the line + in `inetd.conf'; check to make sure that the entire command is on + one line and that it's complete. + + Likewise, if you get something like: + + Unknown command: `pserved' + + CVS commands are: + add Add a new file/directory to the repository + ... + + then you've misspelled `pserver' in some way. If it isn't + obvious, check for invisible control characters (particularly + carriage returns) in `inetd.conf'. + + If it fails to work at all, then make sure inetd is working right. + Change the invocation in `inetd.conf' to run the echo program + instead of cvs. For example: + + 2401 stream tcp nowait root /bin/echo echo hello + + After making that change and instructing inetd to re-read its + configuration file, "telnet servername 2401" should show you the + text hello and then the server should close the connection. If + this doesn't work, you need to fix it before you can worry about + CVS problems. + + On AIX systems, the system will often have its own program trying + to use port 2401. This is AIX's problem in the sense that port + 2401 is registered for use with CVS. I hear that there is an AIX + patch available to address this problem. + + Another good debugging tool is the `-d' (debugging) option to + inetd. Consult your system documentation for more information. + + If you seem to be connecting but get errors like: + + cvs server: cannot open /root/.cvsignore: Permission denied + cvs [server aborted]: can't chdir(/root): Permission denied + + then you probably haven't specified `-f' in `inetd.conf'. (In + releases prior to CVS 1.11.1, this problem can be caused by your + system setting the `$HOME' environment variable for programs being + run by inetd. In this case, you can either have inetd run a shell + script that unsets `$HOME' and then runs CVS, or you can use `env' + to run CVS with a pristine environment.) + + If you can connect successfully for a while but then can't, you've + probably hit inetd's rate limit. (If inetd receives too many + requests for the same service in a short period of time, it + assumes that something is wrong and temporarily disables the + service.) Check your inetd documentation to find out how to + adjust the rate limit (some versions of inetd have a single rate + limit, others allow you to set the limit for each service + separately.) + + +File: cvs.info, Node: Other problems, Prev: Connection, Up: Troubleshooting + +F.3 Other common problems +========================= + +Here is a list of problems which do not fit into the above categories. +They are in no particular order. + + * On Windows, if there is a 30 second or so delay when you run a CVS + command, it may mean that you have your home directory set to + `C:/', for example (see `HOMEDRIVE' and `HOMEPATH' in *Note + Environment variables::). CVS expects the home directory to not + end in a slash, for example `C:' or `C:\cvs'. + + * If you are running CVS 1.9.18 or older, and `cvs update' finds a + conflict and tries to merge, as described in *Note Conflicts + example::, but doesn't tell you there were conflicts, then you may + have an old version of RCS. The easiest solution probably is to + upgrade to a current version of CVS, which does not rely on + external RCS programs. + + +File: cvs.info, Node: Credits, Next: BUGS, Prev: Troubleshooting, Up: Top + +Appendix G Credits +****************** + +Roland Pesch, then of Cygnus Support <roland@wrs.com> wrote the manual +pages which were distributed with CVS 1.3. Much of their text was +copied into this manual. He also read an early draft of this manual +and contributed many ideas and corrections. + + The mailing-list `info-cvs' is sometimes informative. I have +included information from postings made by the following persons: David +G. Grubbs <dgg@think.com>. + + Some text has been extracted from the man pages for RCS. + + The CVS FAQ by David G. Grubbs has provided useful material. The +FAQ is no longer maintained, however, and this manual is about the +closest thing there is to a successor (with respect to documenting how +to use CVS, at least). + + In addition, the following persons have helped by telling me about +mistakes I've made: + + Roxanne Brunskill <rbrunski@datap.ca>, + Kathy Dyer <dyer@phoenix.ocf.llnl.gov>, + Karl Pingle <pingle@acuson.com>, + Thomas A Peterson <tap@src.honeywell.com>, + Inge Wallin <ingwa@signum.se>, + Dirk Koschuetzki <koschuet@fmi.uni-passau.de> + and Michael Brown <brown@wi.extrel.com>. + + The list of contributors here is not comprehensive; for a more +complete list of who has contributed to this manual see the file +`doc/ChangeLog' in the CVS source distribution. + + +File: cvs.info, Node: BUGS, Next: Index, Prev: Credits, Up: Top + +Appendix H Dealing with bugs in CVS or this manual +************************************************** + +Neither CVS nor this manual is perfect, and they probably never will +be. If you are having trouble using CVS, or think you have found a +bug, there are a number of things you can do about it. Note that if +the manual is unclear, that can be considered a bug in the manual, so +these problems are often worth doing something about as well as +problems with CVS itself. + + * If you want someone to help you and fix bugs that you report, + there are companies which will do that for a fee. One such + company is: + + Ximbiot + 319 S. River St. + Harrisburg, PA 17104-1657 + USA + Email: info@ximbiot.com + Phone: (717) 579-6168 + Fax: (717) 234-3125 + `http://ximbiot.com/' + + * If you got CVS through a distributor, such as an operating system + vendor or a vendor of freeware CD-ROMs, you may wish to see + whether the distributor provides support. Often, they will provide + no support or minimal support, but this may vary from distributor + to distributor. + + * If you have the skills and time to do so, you may wish to fix the + bug yourself. If you wish to submit your fix for inclusion in + future releases of CVS, see the file HACKING in the CVS source + distribution. It contains much more information on the process of + submitting fixes. + + * There may be resources on the net which can help. A good place to + start is: + + `http://cvs.nongnu.org/' + + If you are so inspired, increasing the information available on + the net is likely to be appreciated. For example, before the + standard CVS distribution worked on Windows 95, there was a web + page with some explanation and patches for running CVS on Windows + 95, and various people helped out by mentioning this page on + mailing lists or newsgroups when the subject came up. + + * It is also possible to report bugs to <bug-cvs@nongnu.org>. Note + that someone may or may not want to do anything with your bug + report--if you need a solution consider one of the options + mentioned above. People probably do want to hear about bugs which + are particularly severe in consequences and/or easy to fix, + however. You can also increase your odds by being as clear as + possible about the exact nature of the bug and any other relevant + information. The way to report bugs is to send email to + <bug-cvs@nongnu.org>. Note that submissions to + <bug-cvs@nongnu.org> may be distributed under the terms of the GNU + Public License, so if you don't like this, don't submit them. + There is usually no justification for sending mail directly to one + of the CVS maintainers rather than to <bug-cvs@nongnu.org>; those + maintainers who want to hear about such bug reports read + <bug-cvs@nongnu.org>. Also note that sending a bug report to + other mailing lists or newsgroups is _not_ a substitute for + sending it to <bug-cvs@nongnu.org>. It is fine to discuss CVS + bugs on whatever forum you prefer, but there are not necessarily + any maintainers reading bug reports sent anywhere except + <bug-cvs@nongnu.org>. + + People often ask if there is a list of known bugs or whether a +particular bug is a known one. The file BUGS in the CVS source +distribution is one list of known bugs, but it doesn't necessarily try +to be comprehensive. Perhaps there will never be a comprehensive, +detailed list of known bugs. + + +File: cvs.info, Node: Index, Prev: BUGS, Up: Top + +Index +***** + + +* Menu: + +* !, in modules file: Excluding directories. + (line 6) +* #cvs.lock, removing: Concurrency. (line 11) +* #cvs.lock, technical details: Locks. (line 6) +* #cvs.pfl, technical details: Locks. (line 6) +* #cvs.rfl, and backups: Backing up. (line 10) +* #cvs.rfl, removing: Concurrency. (line 11) +* #cvs.rfl, technical details: Locks. (line 6) +* #cvs.tfl: Locks. (line 14) +* #cvs.wfl, removing: Concurrency. (line 11) +* #cvs.wfl, technical details: Locks. (line 6) +* &, in modules file: Ampersand modules. (line 6) +* -a, in modules file: Alias modules. (line 6) +* -d, in modules file: Module options. (line 9) +* -e, in modules file <1>: Module program options. + (line 6) +* -e, in modules file: Module options. (line 12) +* -j (merging branches): Merging a branch. (line 6) +* -j (merging branches), and keyword substitution: Merging and keywords. + (line 6) +* -k (keyword substitution): Substitution modes. (line 6) +* -kk, to avoid conflicts during a merge: Merging and keywords. + (line 6) +* -o, in modules file <1>: Module program options. + (line 6) +* -o, in modules file: Module options. (line 16) +* -s, in modules file: Module options. (line 22) +* -t, in modules file <1>: Module program options. + (line 6) +* -t, in modules file: Module options. (line 30) +* .# files: update output. (line 49) +* .bashrc, setting CVSROOT in: Specifying a repository. + (line 12) +* .cshrc, setting CVSROOT in: Specifying a repository. + (line 12) +* .cvsrc file: ~/.cvsrc. (line 6) +* .profile, setting CVSROOT in: Specifying a repository. + (line 12) +* .tcshrc, setting CVSROOT in: Specifying a repository. + (line 12) +* /usr/local/cvsroot, as example repository: Repository. (line 6) +* :ext:, setting up: Connecting via rsh. (line 35) +* :ext:, troubleshooting: Connection. (line 16) +* :fork:, setting up: Connecting via fork. (line 6) +* :gserver:, setting up: GSSAPI authenticated. + (line 6) +* :kserver:, setting up: Kerberos authenticated. + (line 6) +* :local:, setting up: Repository. (line 19) +* :pserver:, setting up: Password authentication client. + (line 6) +* :pserver:, troubleshooting: Connection. (line 27) +* :server:, setting up: Connecting via rsh. (line 35) +* :server:, troubleshooting: Connection. (line 22) +* <<<<<<<: Conflicts example. (line 96) +* =======: Conflicts example. (line 96) +* >>>>>>>: Conflicts example. (line 96) +* __ files (VMS): update output. (line 49) +* Abandoning work: Editing files. (line 42) +* abbreviations for months: Calendar date items. (line 38) +* Access a branch: Accessing branches. (line 6) +* add (subcommand): Adding files. (line 34) +* Adding a tag: Tags. (line 45) +* Adding files: Adding files. (line 6) +* Admin (subcommand): admin. (line 6) +* Admin commands, logging: postadmin. (line 6) +* Administrative files (intro): Intro administrative files. + (line 6) +* Administrative files (reference): Administrative files. + (line 6) +* Administrative files, editing them: Intro administrative files. + (line 33) +* Alias modules: Alias modules. (line 6) +* ALL keyword, in lieu of regular expressions in script hooks: syntax. + (line 12) +* Ampersand modules: Ampersand modules. (line 6) +* annotate (subcommand): annotate. (line 6) +* Atomic transactions, lack of: Concurrency. (line 27) +* Attic: Attic. (line 6) +* Authenticated client, using: Password authentication client. + (line 6) +* Authenticating server, setting up: Password authentication server. + (line 10) +* Authentication, stream: Global options. (line 16) +* Author keyword: Keyword list. (line 8) +* authors of get_date: Authors of get_date. (line 6) +* Automatically ignored files: cvsignore. (line 23) +* Avoiding editor invocation: Common options. (line 86) +* Backing up, repository: Backing up. (line 6) +* Base directory, in CVS directory: Working directory storage. + (line 178) +* BASE, as reserved tag name: Tags. (line 25) +* BASE, special tag: Common options. (line 122) +* Baserev file, in CVS directory: Working directory storage. + (line 184) +* Baserev.tmp file, in CVS directory: Working directory storage. + (line 192) +* beginning of time, for POSIX: Seconds since the Epoch. + (line 13) +* Bellovin, Steven M.: Authors of get_date. (line 6) +* Berets, Jim: Authors of get_date. (line 6) +* Berry, K.: Authors of get_date. (line 14) +* Bill of materials: Builds. (line 25) +* Binary files: Binary files. (line 6) +* Branch merge example: Merging a branch. (line 15) +* Branch number <1>: Branches and revisions. + (line 6) +* Branch number: Revision numbers. (line 6) +* Branch tags, deleting: Modifying tags. (line 19) +* Branch tags, moving: Modifying tags. (line 37) +* Branch, accessing: Accessing branches. (line 6) +* Branch, check out: Accessing branches. (line 6) +* Branch, creating a: Creating a branch. (line 6) +* Branch, identifying: Accessing branches. (line 6) +* Branch, retrieving: Accessing branches. (line 6) +* Branch, vendor-: Tracking sources. (line 10) +* Branches motivation: Branches motivation. (line 6) +* Branches, copying changes between: Branching and merging. + (line 6) +* Branches, sticky: Accessing branches. (line 37) +* Branching: Branching and merging. + (line 6) +* Bringing a file up to date: Updating a file. (line 6) +* Bugs in this manual or CVS: BUGS. (line 6) +* Bugs, reporting: BUGS. (line 13) +* Builds: Builds. (line 6) +* calendar date item: Calendar date items. (line 6) +* case, ignored in dates: General date syntax. (line 64) +* Changes, copying between branches: Branching and merging. + (line 6) +* Changing a log message: admin options. (line 73) +* Check out a branch: Accessing branches. (line 6) +* Checked out copy, keeping: Keeping a checked out copy. + (line 6) +* Checking out source: Getting the source. (line 6) +* checkout (subcommand): checkout. (line 6) +* Checkout program: Module options. (line 16) +* Checkout, as term for getting ready to edit: Editing files. (line 6) +* Checkout, example: Getting the source. (line 6) +* checkoutlist: checkoutlist. (line 6) +* Choosing, reserved or unreserved checkouts: Choosing a model. + (line 6) +* Cleaning up: Cleaning up. (line 6) +* Client/Server Operation: Remote repositories. (line 6) +* Client/Server Operation, port specification <1>: Password authentication server. + (line 10) +* Client/Server Operation, port specification: Remote repositories. + (line 6) +* co (subcommand): checkout. (line 6) +* Command reference: Invoking CVS. (line 6) +* Command structure: Structure. (line 6) +* Comment leader: admin options. (line 27) +* comments, in dates: General date syntax. (line 64) +* commit (subcommand): commit. (line 6) +* commit files, see Info files: commit files. (line 6) +* COMMITID, internal variable: Variables. (line 50) +* commitinfo: commitinfo. (line 6) +* commitinfo (admin file): commitinfo. (line 6) +* commitinfo (admin file), exit status: commitinfo. (line 29) +* commitinfo (admin file), updating legacy repositories: commitinfo. + (line 22) +* commitinfo, command environment: commitinfo. (line 33) +* commitinfo, working directory: commitinfo. (line 33) +* Commits, administrative support files: commit files. (line 6) +* Commits, precommit verification of: commitinfo. (line 6) +* Committing changes to files: Committing your changes. + (line 6) +* Committing, when to: When to commit. (line 6) +* Common options: Common options. (line 6) +* Common syntax of info files, format strings: syntax. (line 35) +* Common syntax of info files, updating legacy repositories: Updating Commit Files. + (line 6) +* compatibility notes, commitinfo admin file: commitinfo. (line 22) +* compatibility notes, config admin file: config. (line 245) +* compatibility notes, loginfo admin file: loginfo. (line 55) +* compatibility notes, taginfo admin file: taginfo. (line 44) +* compatibility notes, verifymsg admin file: verifymsg. (line 34) +* Compatibility, between CVS versions: Compatibility. (line 6) +* Compression <1>: Invoking CVS. (line 75) +* Compression: Global options. (line 140) +* Compression levels, restricting on server: config. (line 149) +* COMSPEC, environment variable: Environment variables. + (line 130) +* config (admin file), import: config. (line 90) +* config (admin file), updating legacy repositories: config. (line 245) +* config, in CVSROOT: config. (line 6) +* configuration file <1>: config. (line 6) +* configuration file: server & pserver. (line 26) +* Configuring keyword expansion: Configuring keyword expansion. + (line 6) +* Conflict markers: Conflicts example. (line 96) +* Conflict resolution: Conflicts example. (line 101) +* Conflicts (merge example): Conflicts example. (line 68) +* connection method options: The connection method. + (line 16) +* Contributors (CVS program): What is CVS?. (line 28) +* Contributors (manual): Credits. (line 6) +* Copying a repository: Moving a repository. (line 6) +* Copying changes: Branching and merging. + (line 6) +* Correcting a log message: admin options. (line 73) +* Creating a branch: Creating a branch. (line 6) +* Creating a project: Starting a new project. + (line 6) +* Creating a repository: Creating a repository. + (line 6) +* Credits (CVS program): What is CVS?. (line 28) +* Credits (manual): Credits. (line 6) +* CVS 1.6, and watches: Watches Compatibility. + (line 6) +* CVS command structure: Structure. (line 6) +* CVS directory, in repository: CVS in repository. (line 6) +* CVS directory, in working directory: Working directory storage. + (line 6) +* CVS passwd file: Password authentication server. + (line 67) +* CVS, history of: What is CVS?. (line 28) +* CVS, introduction to: What is CVS?. (line 6) +* CVS, versions of: Compatibility. (line 6) +* CVS/Base directory: Working directory storage. + (line 178) +* CVS/Baserev file: Working directory storage. + (line 184) +* CVS/Baserev.tmp file: Working directory storage. + (line 192) +* CVS/Entries file: Working directory storage. + (line 60) +* CVS/Entries.Backup file: Working directory storage. + (line 143) +* CVS/Entries.Log file: Working directory storage. + (line 120) +* CVS/Entries.Static file: Working directory storage. + (line 148) +* CVS/Notify file: Working directory storage. + (line 167) +* CVS/Notify.tmp file: Working directory storage. + (line 172) +* CVS/Repository file: Working directory storage. + (line 32) +* CVS/Root file: Specifying a repository. + (line 25) +* CVS/Tag file: Working directory storage. + (line 156) +* CVS/Template file: Working directory storage. + (line 198) +* CVS_CLIENT_LOG, environment variable: Environment variables. + (line 105) +* CVS_CLIENT_PORT: Environment variables. + (line 88) +* CVS_IGNORE_REMOTE_ROOT, environment variable: Environment variables. + (line 116) +* CVS_LOCAL_BRANCH_NUM, environment variable: Environment variables. + (line 122) +* CVS_PASSFILE, environment variable: Password authentication client. + (line 46) +* CVS_PID, environment variable: Environment variables. + (line 138) +* CVS_PROXY_PORT <1>: Environment variables. + (line 94) +* CVS_PROXY_PORT: The connection method. + (line 26) +* CVS_RCMD_PORT, environment variable: Environment variables. + (line 100) +* CVS_RSH method option: The connection method. + (line 51) +* CVS_RSH, environment variable: Environment variables. + (line 70) +* CVS_SERVER method option: The connection method. + (line 65) +* CVS_SERVER, and :fork:: Connecting via fork. (line 24) +* CVS_SERVER, environment variable: Connecting via rsh. (line 22) +* CVS_SERVER_SLEEP, environment variable: Environment variables. + (line 111) +* CVS_USER, environment variable: Variables. (line 83) +* cvsadmin: admin. (line 18) +* CVSEDITOR, environment variable <1>: Environment variables. + (line 48) +* CVSEDITOR, environment variable: Committing your changes. + (line 17) +* CVSEDITOR, internal variable: Variables. (line 37) +* CVSHeader keyword: Keyword list. (line 11) +* cvsignore (admin file), global: cvsignore. (line 6) +* CVSIGNORE, environment variable: Environment variables. + (line 10) +* CVSREAD, environment variable: Environment variables. + (line 18) +* CVSREAD, overriding: Global options. (line 124) +* CVSREADONLYFS, environment variable: Environment variables. + (line 24) +* cvsroot: Repository. (line 6) +* CVSROOT (file): Administrative files. + (line 6) +* CVSROOT, environment variable: Specifying a repository. + (line 12) +* CVSROOT, internal variable: Variables. (line 26) +* CVSROOT, module name: Intro administrative files. + (line 6) +* CVSROOT, multiple repositories: Multiple repositories. + (line 6) +* CVSROOT, overriding: Global options. (line 53) +* CVSROOT, storage of files: CVSROOT storage. (line 6) +* CVSROOT/config: config. (line 6) +* CVSROOT/Emptydir directory: Working directory storage. + (line 58) +* CVSROOT/val-tags file, and read-only access to projects: File permissions. + (line 26) +* CVSROOT/val-tags file, forcing tags into: Error messages. (line 202) +* CVSUMASK, environment variable: File permissions. (line 35) +* cvswrappers (admin file): Wrappers. (line 6) +* CVSWRAPPERS, environment variable <1>: Environment variables. + (line 14) +* CVSWRAPPERS, environment variable: Wrappers. (line 6) +* date format, ISO 8601: Calendar date items. (line 30) +* date input formats: Date input formats. (line 6) +* Date keyword: Keyword list. (line 25) +* Dates: Common options. (line 18) +* day of week item: Day of week items. (line 6) +* Dead state: Attic. (line 17) +* Decimal revision number: Revision numbers. (line 6) +* DEFAULT keyword, in lieu of regular expressions in script hooks: syntax. + (line 12) +* Defining a module: Defining the module. (line 6) +* Defining modules (intro): Intro administrative files. + (line 6) +* Defining modules (reference manual): modules. (line 6) +* Deleting branch tags: Modifying tags. (line 19) +* Deleting files: Removing files. (line 6) +* Deleting revisions: admin options. (line 95) +* Deleting sticky tags: Sticky tags. (line 30) +* Deleting tags: Modifying tags. (line 19) +* Descending directories: Recursive behavior. (line 6) +* Device nodes: Special Files. (line 6) +* Diff: Viewing differences. (line 6) +* diff (subcommand): diff. (line 6) +* Differences, merging: Merging two revisions. + (line 6) +* Directories, moving: Moving directories. (line 6) +* Directories, removing: Removing directories. + (line 6) +* Directory, descending: Recursive behavior. (line 6) +* Disjoint repositories: Multiple repositories. + (line 6) +* displacement of dates: Relative items in date strings. + (line 6) +* Distributing log messages: loginfo. (line 6) +* driver.c (merge example): Conflicts example. (line 6) +* edit (subcommand): Editing files. (line 13) +* Editing administrative files: Intro administrative files. + (line 33) +* Editing the modules file: Defining the module. (line 6) +* Editor, avoiding invocation of: Common options. (line 86) +* EDITOR, environment variable <1>: Environment variables. + (line 49) +* EDITOR, environment variable: Committing your changes. + (line 17) +* EDITOR, internal variable: Variables. (line 38) +* EDITOR, overriding: Global options. (line 58) +* editors (subcommand): Watch information. (line 15) +* Eggert, Paul: Authors of get_date. (line 6) +* emerge: Conflicts example. (line 140) +* Emptydir, in CVSROOT directory: Working directory storage. + (line 58) +* Encryption: Global options. (line 130) +* Entries file, in CVS directory: Working directory storage. + (line 60) +* Entries.Backup file, in CVS directory: Working directory storage. + (line 143) +* Entries.Log file, in CVS directory: Working directory storage. + (line 120) +* Entries.Static file, in CVS directory: Working directory storage. + (line 148) +* Environment variables: Environment variables. + (line 6) +* environment variables, passed to administrative files: Variables. + (line 82) +* epoch, for POSIX: Seconds since the Epoch. + (line 13) +* Errors, reporting: BUGS. (line 13) +* Example of a work-session: A sample session. (line 6) +* Example of merge: Conflicts example. (line 6) +* Example, branch merge: Merging a branch. (line 15) +* Excluding directories, in modules file: Excluding directories. + (line 6) +* Exit status, of commitinfo: commitinfo. (line 29) +* Exit status, of CVS: Exit status. (line 6) +* Exit status, of editor: Error messages. (line 333) +* Exit status, of taginfo admin file: taginfo. (line 51) +* Exit status, of verifymsg: verifymsg. (line 46) +* export (subcommand): export. (line 6) +* Export program: Module options. (line 12) +* Fetching source: Getting the source. (line 6) +* File had conflicts on merge: File status. (line 46) +* File locking: Multiple developers. (line 6) +* File permissions, general: File permissions. (line 6) +* File permissions, Windows-specific: Windows permissions. (line 6) +* File status: File status. (line 6) +* Files, moving: Moving files. (line 6) +* Files, reference manual: Administrative files. + (line 6) +* Fixing a log message: admin options. (line 73) +* Forcing a tag match: Common options. (line 43) +* fork, access method: Connecting via fork. (line 6) +* Form for log message: rcsinfo. (line 6) +* Format of CVS commands: Structure. (line 6) +* format strings: syntax. (line 35) +* format strings, commitinfo admin file: commitinfo. (line 16) +* format strings, common syntax: syntax. (line 35) +* format strings, config admin file: config. (line 245) +* format strings, loginfo admin file: loginfo. (line 34) +* format strings, postadmin admin file: postadmin. (line 12) +* format strings, postproxy admin file: postproxy. (line 23) +* format strings, posttag admin file: posttag. (line 12) +* format strings, postwatch admin file: postwatch. (line 13) +* format strings, preproxy admin file: preproxy. (line 20) +* format strings, taginfo admin file: taginfo. (line 12) +* format strings, verifymsg admin file: verifymsg. (line 20) +* general date syntax: General date syntax. (line 6) +* Getting started: A sample session. (line 6) +* Getting the source: Getting the source. (line 6) +* Global cvsignore: cvsignore. (line 6) +* Global options: Global options. (line 6) +* Group, UNIX file permissions, in repository: File permissions. + (line 6) +* gserver (client/server connection method), port specification <1>: Password authentication server. + (line 10) +* gserver (client/server connection method), port specification: Remote repositories. + (line 6) +* GSSAPI: GSSAPI authenticated. + (line 6) +* Gzip <1>: Invoking CVS. (line 75) +* Gzip: Global options. (line 140) +* Hard links: Special Files. (line 6) +* HEAD, as reserved tag name: Tags. (line 25) +* HEAD, special tag: Common options. (line 122) +* Header keyword: Keyword list. (line 28) +* history (subcommand): history. (line 6) +* History browsing: History browsing. (line 6) +* History file: history file. (line 6) +* History files: Repository files. (line 68) +* History of CVS: What is CVS?. (line 28) +* HistoryLogPath, in CVSROOT/config: config. (line 61) +* HistorySearchPath, in CVSROOT/config: config. (line 70) +* HOME, environment variable: Environment variables. + (line 59) +* HOMEDRIVE, environment variable: Environment variables. + (line 62) +* HOMEPATH, environment variable: Environment variables. + (line 60) +* HTTP proxies, connecting via: The connection method. + (line 26) +* Id keyword: Keyword list. (line 34) +* Ident (shell command): Using keywords. (line 19) +* Identifying a branch: Accessing branches. (line 6) +* Identifying files: Keyword substitution. + (line 6) +* Ignored files: cvsignore. (line 23) +* Ignoring files: cvsignore. (line 6) +* import (subcommand): import. (line 6) +* import, config admin file: config. (line 90) +* Importing files: From files. (line 6) +* Importing files, from other version control systems: From other version control systems. + (line 6) +* Importing modules: First import. (line 6) +* ImportNewFilesToVendorBranchOnly, in CVSROOT/config: config. + (line 90) +* Index: Index. (line 6) +* inetd, configuring for pserver: Password authentication server. + (line 10) +* info files: Trigger Scripts. (line 6) +* info files, commitinfo: commitinfo. (line 6) +* info files, common syntax: syntax. (line 6) +* info files, common syntax, format strings: syntax. (line 35) +* info files, common syntax, updating legacy repositories: Updating Commit Files. + (line 6) +* info files, precommit verification of commits: commitinfo. (line 6) +* info files, security: Trigger Script Security. + (line 6) +* Informing others: Informing others. (line 6) +* init (subcommand): Creating a repository. + (line 35) +* Installed images (VMS): File permissions. (line 59) +* Internal variables: Variables. (line 6) +* Introduction to CVS: What is CVS?. (line 6) +* Invoking CVS: Invoking CVS. (line 6) +* ISO 8601 date format: Calendar date items. (line 30) +* Isolation: History browsing. (line 6) +* items in date strings: General date syntax. (line 6) +* Join: Merging a branch. (line 13) +* Keeping a checked out copy: Keeping a checked out copy. + (line 6) +* Kerberos, using :gserver:: GSSAPI authenticated. + (line 6) +* Kerberos, using :kserver:: Kerberos authenticated. + (line 6) +* Kerberos, using kerberized rsh: Connecting via rsh. (line 35) +* Keyword expansion: Keyword substitution. + (line 6) +* Keyword List: Keyword list. (line 6) +* Keyword substitution: Keyword substitution. + (line 6) +* Keyword substitution, and merging: Merging and keywords. + (line 6) +* Keyword substitution, changing modes: Substitution modes. (line 6) +* KeywordExpand, in CVSROOT/config: config. (line 97) +* Kflag: Substitution modes. (line 6) +* kinit: Kerberos authenticated. + (line 27) +* Known bugs in this manual or CVS: BUGS. (line 71) +* kserver (client/server connection method), port specification <1>: Password authentication server. + (line 10) +* kserver (client/server connection method), port specification: Remote repositories. + (line 6) +* language, in dates: General date syntax. (line 40) +* Layout of repository: Repository. (line 6) +* Left-hand options: Global options. (line 6) +* Linear development: Revision numbers. (line 6) +* Link, symbolic, importing: import output. (line 23) +* List, mailing list: What is CVS?. (line 44) +* Local keyword: Keyword list. (line 97) +* LocalKeyword, in CVSROOT/config: config. (line 104) +* Locally Added: File status. (line 19) +* Locally Modified: File status. (line 16) +* Locally Removed: File status. (line 23) +* LockDir, in CVSROOT/config: config. (line 109) +* Locker keyword: Keyword list. (line 43) +* Locking files: Multiple developers. (line 6) +* Locks, cvs, and backups: Backing up. (line 10) +* Locks, cvs, introduction: Concurrency. (line 6) +* Locks, cvs, technical details: Locks. (line 6) +* log (subcommand): log. (line 6) +* Log information, saving: history file. (line 6) +* Log keyword: Keyword list. (line 47) +* Log keyword, configuring substitution behavior <1>: config. (line 137) +* Log keyword, configuring substitution behavior: Keyword list. + (line 47) +* Log message entry: Committing your changes. + (line 6) +* Log message template: rcsinfo. (line 6) +* Log message, correcting: admin options. (line 73) +* Log message, verifying: verifymsg. (line 6) +* Log messages: loginfo. (line 6) +* logging, commits <1>: rcsinfo. (line 6) +* logging, commits <2>: loginfo. (line 6) +* logging, commits: verifymsg. (line 6) +* LogHistory, in CVSROOT/config: config. (line 129) +* Login (subcommand): Password authentication client. + (line 6) +* loginfo (admin file): loginfo. (line 6) +* loginfo (admin file), updating legacy repositories: loginfo. + (line 55) +* LOGNAME, environment variable: Variables. (line 90) +* Logout (subcommand): Password authentication client. + (line 70) +* ls (subcommand): ls & rls. (line 6) +* MacKenzie, David: Authors of get_date. (line 6) +* Mail, automatic mail on commit: Informing others. (line 6) +* Mailing list: What is CVS?. (line 44) +* Mailing log messages: loginfo. (line 6) +* Main trunk and branches: Branching and merging. + (line 6) +* make: Builds. (line 6) +* Many repositories: Multiple repositories. + (line 6) +* Markers, conflict: Conflicts example. (line 96) +* MaxCommentLeaderLength: Keyword list. (line 47) +* MaxCommentLeaderLength, in CVSROOT/config: config. (line 137) +* MaxCompressionLevel, in CVSROOT/config: config. (line 149) +* Merge, an example: Conflicts example. (line 6) +* Merge, branch example: Merging a branch. (line 15) +* Merging: Branching and merging. + (line 6) +* Merging a branch: Merging a branch. (line 6) +* Merging a file: Updating a file. (line 6) +* Merging two revisions: Merging two revisions. + (line 6) +* Merging, and keyword substitution: Merging and keywords. + (line 6) +* Meyering, Jim: Authors of get_date. (line 6) +* MinCompressionLevel, in CVSROOT/config: config. (line 149) +* minutes, time zone correction by: Time of day items. (line 29) +* mkmodules: Error messages. (line 170) +* Modifications, copying between branches: Branching and merging. + (line 6) +* Module status: Module options. (line 22) +* Module, defining: Defining the module. (line 6) +* Modules (admin file): modules. (line 6) +* Modules file: Intro administrative files. + (line 6) +* Modules file program options: Module program options. + (line 6) +* Modules file, changing: Defining the module. (line 6) +* modules.db: CVSROOT storage. (line 25) +* modules.dir: CVSROOT storage. (line 25) +* modules.pag: CVSROOT storage. (line 25) +* month names in date strings: Calendar date items. (line 38) +* months, written-out: General date syntax. (line 36) +* Motivation for branches: Branches motivation. (line 6) +* Moving a repository: Moving a repository. (line 6) +* Moving branch tags: Modifying tags. (line 37) +* Moving directories: Moving directories. (line 6) +* Moving files: Moving files. (line 6) +* Moving tags: Modifying tags. (line 37) +* Multiple developers: Multiple developers. (line 6) +* Multiple repositories: Multiple repositories. + (line 6) +* Name keyword: Keyword list. (line 37) +* Name, symbolic (tag): Tags. (line 25) +* Needs Checkout: File status. (line 27) +* Needs Merge: File status. (line 37) +* Needs Patch: File status. (line 32) +* Newsgroups: What is CVS?. (line 44) +* notify (admin file): Getting Notified. (line 60) +* Notify file, in CVS directory: Working directory storage. + (line 167) +* Notify.tmp file, in CVS directory: Working directory storage. + (line 172) +* Number, branch <1>: Branches and revisions. + (line 6) +* Number, branch: Revision numbers. (line 6) +* Number, revision-: Revision numbers. (line 6) +* numbers, written-out: General date syntax. (line 26) +* Option defaults: ~/.cvsrc. (line 6) +* options, connection method: The connection method. + (line 16) +* Options, global: Global options. (line 6) +* Options, in modules file: Module options. (line 6) +* ordinal numbers: General date syntax. (line 26) +* Outdating revisions: admin options. (line 95) +* Overlap: Updating a file. (line 24) +* Overriding CVSREAD: Global options. (line 124) +* Overriding CVSROOT: Global options. (line 53) +* Overriding EDITOR: Global options. (line 58) +* Overriding RCSBIN: Global options. (line 24) +* Overview: Overview. (line 6) +* Ownership, saving in CVS: Special Files. (line 6) +* Parallel repositories: Multiple repositories. + (line 6) +* passwd (admin file): Password authentication server. + (line 67) +* Password client, using: Password authentication client. + (line 6) +* Password server, setting up: Password authentication server. + (line 10) +* PATH, environment variable: Environment variables. + (line 55) +* Per-directory sticky tags/dates: Working directory storage. + (line 156) +* Permissions, general: File permissions. (line 6) +* Permissions, saving in CVS: Special Files. (line 6) +* Permissions, Windows-specific: Windows permissions. (line 6) +* Pinard, F.: Authors of get_date. (line 14) +* Policy: When to commit. (line 6) +* port, specifying for remote repositories <1>: Password authentication server. + (line 10) +* port, specifying for remote repositories: Remote repositories. + (line 6) +* postadmin (admin file): postadmin. (line 6) +* postproxy (admin file): postproxy. (line 6) +* posttag (admin file): posttag. (line 6) +* postwatch (admin file): postwatch. (line 6) +* preproxy (admin file): preproxy. (line 6) +* Primary server <1>: config. (line 168) +* Primary server: Write proxies. (line 6) +* PrimaryServer, in CVSROOT/config <1>: config. (line 168) +* PrimaryServer, in CVSROOT/config: Write proxies. (line 6) +* proxies, HTTP, connecting via: The connection method. + (line 26) +* proxies, web, connecting via: The connection method. + (line 26) +* proxy, method option: The connection method. + (line 26) +* proxy, write <1>: config. (line 168) +* proxy, write: Write proxies. (line 6) +* proxyport, method option: The connection method. + (line 26) +* pserver (client/server connection method), port specification <1>: Password authentication server. + (line 10) +* pserver (client/server connection method), port specification: Remote repositories. + (line 6) +* pserver (subcommand) <1>: server & pserver. (line 6) +* pserver (subcommand): Password authentication server. + (line 10) +* pure numbers in date strings: Pure numbers in date strings. + (line 6) +* PVCS, importing files from: From other version control systems. + (line 45) +* RCS history files: Repository files. (line 68) +* RCS revision numbers: Tags. (line 10) +* RCS, importing files from: From other version control systems. + (line 10) +* RCS-style locking: Multiple developers. (line 6) +* RCSBIN, in CVSROOT/config: config. (line 186) +* RCSBIN, internal variable: Variables. (line 32) +* RCSBIN, overriding: Global options. (line 24) +* RCSfile keyword: Keyword list. (line 84) +* rcsinfo (admin file): rcsinfo. (line 6) +* rdiff (subcommand): rdiff. (line 6) +* Read-only files, and -r: Global options. (line 105) +* Read-only files, and CVSREAD: Environment variables. + (line 18) +* Read-only files, and watches: Setting a watch. (line 10) +* Read-only files, in repository: File permissions. (line 6) +* Read-only mode: Global options. (line 86) +* Read-only repository access: Read-only access. (line 6) +* Read-only repository mode: Global options. (line 78) +* readers (admin file): Read-only access. (line 6) +* Recursive (directory descending): Recursive behavior. (line 6) +* Redirect, method option: The connection method. + (line 86) +* Reference manual (files): Administrative files. + (line 6) +* Reference manual for variables: Environment variables. + (line 6) +* Reference, commands: Invoking CVS. (line 6) +* Regular expression syntax: syntax. (line 10) +* Regular modules: Regular modules. (line 6) +* relative items in date strings: Relative items in date strings. + (line 6) +* release (subcommand): release. (line 6) +* Releases, revisions and versions: Versions revisions releases. + (line 6) +* Releasing your working copy: Cleaning up. (line 6) +* Remote repositories: Remote repositories. (line 6) +* Remote repositories, port specification <1>: Password authentication server. + (line 10) +* Remote repositories, port specification: Remote repositories. + (line 6) +* Remove (subcommand): Removing files. (line 34) +* Removing a change: Merging two revisions. + (line 9) +* Removing branch tags: Modifying tags. (line 19) +* Removing directories: Removing directories. + (line 6) +* Removing files: Removing files. (line 6) +* Removing tags: Modifying tags. (line 19) +* Removing your working copy: Cleaning up. (line 6) +* Renaming directories: Moving directories. (line 6) +* Renaming files: Moving files. (line 6) +* Renaming tags: Modifying tags. (line 57) +* Replacing a log message: admin options. (line 73) +* Reporting bugs: BUGS. (line 13) +* Repositories, multiple: Multiple repositories. + (line 6) +* Repositories, remote: Remote repositories. (line 6) +* Repositories, remote, port specification <1>: Password authentication server. + (line 10) +* Repositories, remote, port specification: Remote repositories. + (line 6) +* Repository (intro): Repository. (line 6) +* Repository file, in CVS directory: Working directory storage. + (line 32) +* Repository, backing up: Backing up. (line 6) +* Repository, example: Repository. (line 6) +* Repository, how data is stored: Repository storage. (line 6) +* Repository, moving: Moving a repository. (line 6) +* Repository, setting up: Creating a repository. + (line 6) +* RereadLogAfterVerify, in CVSROOT/config: config. (line 192) +* Reserved checkouts: Multiple developers. (line 6) +* Resetting sticky tags: Sticky tags. (line 30) +* Resolving a conflict: Conflicts example. (line 101) +* Restoring old version of removed file: Merging two revisions. + (line 19) +* Resurrecting old version of dead file: Merging two revisions. + (line 19) +* Retrieve a branch: Accessing branches. (line 6) +* Retrieving an old revision using tags: Tags. (line 84) +* Reverting to repository version: Editing files. (line 42) +* Revision keyword: Keyword list. (line 87) +* Revision management: Revision management. (line 6) +* Revision numbers: Revision numbers. (line 6) +* Revision numbers (branches): Branches and revisions. + (line 6) +* Revision tree: Revision numbers. (line 6) +* Revision tree, making branches: Branching and merging. + (line 6) +* Revisions, merging differences between: Merging two revisions. + (line 6) +* Revisions, versions and releases: Versions revisions releases. + (line 6) +* Right-hand options: Common options. (line 6) +* rls (subcommand): ls & rls. (line 6) +* Root file, in CVS directory: Specifying a repository. + (line 25) +* rsh: Connecting via rsh. (line 6) +* rsh replacements (Kerberized, SSH, &c): Connecting via rsh. (line 35) +* rtag (subcommand): Tagging by date/tag. (line 6) +* rtag (subcommand), creating a branch using: Creating a branch. + (line 6) +* Salz, Rich: Authors of get_date. (line 6) +* Saving space: admin options. (line 95) +* SCCS, importing files from: From other version control systems. + (line 38) +* script hook, postadmin: postadmin. (line 6) +* script hook, postproxy: postproxy. (line 6) +* script hook, posttag: posttag. (line 6) +* script hook, postwatch: postwatch. (line 6) +* script hook, preproxy: preproxy. (line 6) +* script hook, taginfo: taginfo. (line 6) +* script hooks: Trigger Scripts. (line 6) +* script hooks, commitinfo: commitinfo. (line 6) +* script hooks, common syntax: syntax. (line 6) +* script hooks, precommit verification of commits: commitinfo. + (line 6) +* script hooks, security: Trigger Script Security. + (line 6) +* Secondary server <1>: config. (line 168) +* Secondary server: Write proxies. (line 6) +* secondary server, pull updates: postproxy. (line 6) +* Security, file permissions in repository: File permissions. (line 6) +* Security, GSSAPI: GSSAPI authenticated. + (line 6) +* Security, Kerberos: Kerberos authenticated. + (line 6) +* Security, of pserver: Password authentication security. + (line 6) +* Security, setuid: File permissions. (line 59) +* server (subcommand): server & pserver. (line 6) +* Server, CVS: Remote repositories. (line 6) +* Server, temporary directories: Server temporary directory. + (line 6) +* Setgid: File permissions. (line 59) +* Setting up a repository: Creating a repository. + (line 6) +* Setuid: File permissions. (line 59) +* Source keyword: Keyword list. (line 90) +* Source, getting CVS source: What is CVS?. (line 38) +* Source, getting from CVS: Getting the source. (line 6) +* Special files: Special Files. (line 6) +* Specifying dates: Common options. (line 18) +* Spreading information: Informing others. (line 6) +* SSH (rsh replacement): Connecting via rsh. (line 35) +* Starting a project with CVS: Starting a new project. + (line 6) +* State keyword: Keyword list. (line 93) +* Status of a file: File status. (line 6) +* Status of a module: Module options. (line 22) +* Sticky date: Sticky tags. (line 36) +* Sticky tags: Sticky tags. (line 6) +* Sticky tags, resetting: Sticky tags. (line 30) +* Sticky tags/dates, per-directory: Working directory storage. + (line 156) +* Storing log messages: loginfo. (line 6) +* Stream authentication: Global options. (line 16) +* Structure: Structure. (line 6) +* Subdirectories: Recursive behavior. (line 6) +* Support, getting CVS support: BUGS. (line 17) +* Symbolic link, importing: import output. (line 23) +* Symbolic links: Special Files. (line 6) +* Symbolic name (tag): Tags. (line 25) +* Syntax of info files, updating legacy repositories: Updating Commit Files. + (line 6) +* syntax of trigger script hooks: syntax. (line 6) +* SystemAuth, in CVSROOT/config: config. (line 209) +* tag (subcommand): Tagging the working directory. + (line 6) +* tag (subcommand), creating a branch using: Creating a branch. + (line 6) +* tag (subcommand), introduction: Tags. (line 25) +* Tag file, in CVS directory: Working directory storage. + (line 156) +* Tag program: Module options. (line 30) +* taginfo (admin file): taginfo. (line 6) +* taginfo (admin file), exit status: taginfo. (line 51) +* taginfo (admin file), updating legacy repositories: taginfo. + (line 44) +* Tags: Tags. (line 6) +* Tags, deleting: Modifying tags. (line 19) +* Tags, example: Tags. (line 45) +* Tags, logging <1>: posttag. (line 6) +* Tags, logging: taginfo. (line 6) +* Tags, moving: Modifying tags. (line 37) +* Tags, renaming: Modifying tags. (line 57) +* Tags, retrieving old revisions: Tags. (line 84) +* Tags, sticky: Sticky tags. (line 6) +* Tags, symbolic name: Tags. (line 25) +* Tags, verifying: taginfo. (line 6) +* tc, Trivial Compiler (example): A sample session. (line 6) +* Team of developers: Multiple developers. (line 6) +* Template file, in CVS directory: Working directory storage. + (line 198) +* Template for log message: rcsinfo. (line 6) +* Temporary directories, and server: Server temporary directory. + (line 6) +* temporary directory, set in config: config. (line 216) +* temporary file directory, set via command line: Global options. + (line 30) +* temporary file directory, set via config: Global options. (line 30) +* temporary file directory, set via environment variable <1>: Environment variables. + (line 134) +* temporary file directory, set via environment variable: Global options. + (line 30) +* temporary files, location of <1>: Environment variables. + (line 134) +* temporary files, location of <2>: config. (line 216) +* temporary files, location of: Global options. (line 30) +* Third-party sources: Tracking sources. (line 6) +* Time: Common options. (line 18) +* time of day item: Time of day items. (line 6) +* time zone correction: Time of day items. (line 29) +* time zone item <1>: Time zone items. (line 6) +* time zone item: General date syntax. (line 44) +* Timezone, in output <1>: log examples. (line 6) +* Timezone, in output: log. (line 17) +* TMPDIR, environment variable <1>: Environment variables. + (line 134) +* TMPDIR, environment variable: Global options. (line 30) +* TmpDir, in config: config. (line 216) +* TopLevelAdmin, in CVSROOT/config: config. (line 221) +* Trace: Global options. (line 114) +* Traceability: History browsing. (line 6) +* Tracking sources: Tracking sources. (line 6) +* Transactions, atomic, lack of: Concurrency. (line 27) +* trigger script hooks, common syntax: syntax. (line 6) +* trigger scripts: Trigger Scripts. (line 6) +* trigger scripts, commitinfo: commitinfo. (line 6) +* trigger scripts, precommit verification of commits: commitinfo. + (line 6) +* trigger scripts, security: Trigger Script Security. + (line 6) +* Trivial Compiler (example): A sample session. (line 6) +* Typical repository: Repository. (line 6) +* Umask, for repository files: File permissions. (line 35) +* Undoing a change: Merging two revisions. + (line 9) +* unedit (subcommand): Editing files. (line 42) +* Unknown: File status. (line 52) +* Unreserved checkouts: Multiple developers. (line 6) +* Unresolved Conflict: File status. (line 41) +* Up-to-date: File status. (line 11) +* update (subcommand): update. (line 6) +* Update, introduction: Updating a file. (line 6) +* update, to display file status: File status. (line 75) +* Updating a file: Updating a file. (line 6) +* UseArchiveCommentLeader: Keyword list. (line 47) +* UseArchiveCommentLeader, in CVSROOT/config: config. (line 234) +* UseNewInfoFmtStrings, in CVSROOT/config: config. (line 245) +* User aliases: Password authentication server. + (line 96) +* User variables: Variables. (line 62) +* USER, environment variable: Variables. (line 93) +* USER, internal variable: Variables. (line 43) +* UserAdminOptions, in CVSROOT/config <1>: config. (line 257) +* UserAdminOptions, in CVSROOT/config: admin. (line 18) +* users (admin file): Getting Notified. (line 75) +* val-tags file, and read-only access to projects: File permissions. + (line 26) +* val-tags file, forcing tags into: Error messages. (line 202) +* Variables: Variables. (line 6) +* Vendor: Tracking sources. (line 10) +* Vendor branch: Tracking sources. (line 10) +* verifymsg (admin file): verifymsg. (line 6) +* verifymsg (admin/commit file), updating legacy repositories: verifymsg. + (line 34) +* verifymsg, changing the log message <1>: config. (line 192) +* verifymsg, changing the log message: verifymsg. (line 49) +* verifymsg, example: verifymsg example. (line 6) +* version (subcommand): Invoking CVS. (line 821) +* Versions, of CVS: Compatibility. (line 6) +* Versions, revisions and releases: Versions revisions releases. + (line 6) +* Viewing differences: Viewing differences. (line 6) +* VISUAL, environment variable <1>: Environment variables. + (line 50) +* VISUAL, environment variable: Committing your changes. + (line 23) +* VISUAL, internal variable: Variables. (line 39) +* watch add (subcommand): Getting Notified. (line 11) +* Watch family of commands, logging: postwatch. (line 6) +* watch off (subcommand): Setting a watch. (line 26) +* watch on (subcommand): Setting a watch. (line 9) +* watch remove (subcommand): Getting Notified. (line 54) +* watchers (subcommand): Watch information. (line 6) +* Watches: Watches. (line 6) +* wdiff (import example): First import. (line 19) +* Web pages, maintaining with CVS: Keeping a checked out copy. + (line 6) +* web proxies, connecting via: The connection method. + (line 26) +* What (shell command): Using keywords. (line 32) +* What branches are good for: Branches motivation. (line 6) +* What is CVS not?: What is CVS not?. (line 6) +* What is CVS?: What is CVS?. (line 6) +* When to commit: When to commit. (line 6) +* Windows, and permissions: Windows permissions. (line 6) +* Work-session, example of: A sample session. (line 6) +* Working copy: Multiple developers. (line 6) +* Working copy, removing: Cleaning up. (line 6) +* Wrappers: Wrappers. (line 6) +* write proxy <1>: config. (line 168) +* write proxy: Write proxies. (line 6) +* Write proxy, logging <1>: postproxy. (line 6) +* Write proxy, logging: preproxy. (line 6) +* Write proxy, pull updates: postproxy. (line 6) +* Write proxy, verifying: preproxy. (line 6) +* writers (admin file): Read-only access. (line 6) +* Ximbiot: BUGS. (line 17) +* xinetd, configuring for pserver: Password authentication server. + (line 10) +* Zone, time, in output <1>: log examples. (line 6) +* Zone, time, in output: log. (line 17) + + |