[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Texi2html-cvs] texi2html ChangeLog TODO texi2html.init texi2ht...
|
From: |
Patrice Dumas |
|
Subject: |
[Texi2html-cvs] texi2html ChangeLog TODO texi2html.init texi2ht... |
|
Date: |
Wed, 12 Mar 2008 10:24:18 +0000 |
CVSROOT: /cvsroot/texi2html
Module name: texi2html
Changes by: Patrice Dumas <pertusus> 08/03/12 10:24:16
Modified files:
. : ChangeLog TODO texi2html.init texi2html.pl
Tests : test.sh
examples : mediawiki.init
Added files:
Tests/ccvs_mediawiki_nosplit_res: cvs cvs.2 cvs.passfirst
cvs.passtexi
Tests/ccvs_mediawiki_res: cvs cvs.2 cvs.passfirst cvs.passtexi
`cvs: About this Manual'
`cvs: Adding, removing, and renaming files
and directories'
`cvs: All environment variables which affect
CVS'
`cvs: Branching and merging'
`cvs: Compatibility between CVS Versions'
`cvs: Credits'
`cvs: Dealing with bugs in CVS or this
manual'
`cvs: Guide to CVS commands'
`cvs: Handling binary files'
`cvs: History browsing'
`cvs: How your build system interacts with
CVS'
`cvs: Index'
`cvs: Keyword substitution'
`cvs: Multiple developers'
`cvs: Overview'
`cvs: Quick reference to CVS commands'
`cvs: Recursive behavior'
`cvs: Reference manual for Administrative
files'
`cvs: Revision management'
`cvs: Revisions'
`cvs: Short Table of Contents'
`cvs: Special Files'
`cvs: Starting a project with CVS'
`cvs: Table of Contents'
`cvs: The Repository'
`cvs: Tracking third-party sources'
`cvs: Troubleshooting'
Log message:
* texi2html.pl, texi2html.init, examples/mediawiki.init: add
the program_string reference.
* examples/mediawiki.init: cleanup perl warnings.
* texi2html.pl: element_file_name called with doc sets docu_doc
and not docu_top (Reinhold Kainhofer).
* Tests/test.sh: more robust for files with spaces.
* Tests/*: add tests for mediawiki output.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/texi2html/ChangeLog?cvsroot=texi2html&r1=1.284&r2=1.285
http://cvs.savannah.gnu.org/viewcvs/texi2html/TODO?cvsroot=texi2html&r1=1.41&r2=1.42
http://cvs.savannah.gnu.org/viewcvs/texi2html/texi2html.init?cvsroot=texi2html&r1=1.131&r2=1.132
http://cvs.savannah.gnu.org/viewcvs/texi2html/texi2html.pl?cvsroot=texi2html&r1=1.197&r2=1.198
http://cvs.savannah.gnu.org/viewcvs/texi2html/Tests/test.sh?cvsroot=texi2html&r1=1.76&r2=1.77
http://cvs.savannah.gnu.org/viewcvs/texi2html/Tests/ccvs_mediawiki_nosplit_res/cvs?cvsroot=texi2html&rev=1.1
http://cvs.savannah.gnu.org/viewcvs/texi2html/Tests/ccvs_mediawiki_nosplit_res/cvs.2?cvsroot=texi2html&rev=1.1
http://cvs.savannah.gnu.org/viewcvs/texi2html/Tests/ccvs_mediawiki_nosplit_res/cvs.passfirst?cvsroot=texi2html&rev=1.1
http://cvs.savannah.gnu.org/viewcvs/texi2html/Tests/ccvs_mediawiki_nosplit_res/cvs.passtexi?cvsroot=texi2html&rev=1.1
http://cvs.savannah.gnu.org/viewcvs/texi2html/Tests/ccvs_mediawiki_res/cvs?cvsroot=texi2html&rev=1.1
http://cvs.savannah.gnu.org/viewcvs/texi2html/Tests/ccvs_mediawiki_res/cvs.2?cvsroot=texi2html&rev=1.1
http://cvs.savannah.gnu.org/viewcvs/texi2html/Tests/ccvs_mediawiki_res/cvs.passfirst?cvsroot=texi2html&rev=1.1
http://cvs.savannah.gnu.org/viewcvs/texi2html/Tests/ccvs_mediawiki_res/cvs.passtexi?cvsroot=texi2html&rev=1.1
http://cvs.savannah.gnu.org/viewcvs/texi2html/Tests/ccvs_mediawiki_res/cvs:%32About%32this%32Manual?cvsroot=texi2html&rev=1.1
http://cvs.savannah.gnu.org/viewcvs/texi2html/Tests/ccvs_mediawiki_res/cvs:%32Adding%44%32removing%44%32and%32renaming%32files%32and%32directories?cvsroot=texi2html&rev=1.1
http://cvs.savannah.gnu.org/viewcvs/texi2html/Tests/ccvs_mediawiki_res/cvs:%32All%32environment%32variables%32which%32affect%32CVS?cvsroot=texi2html&rev=1.1
http://cvs.savannah.gnu.org/viewcvs/texi2html/Tests/ccvs_mediawiki_res/cvs:%32Branching%32and%32merging?cvsroot=texi2html&rev=1.1
http://cvs.savannah.gnu.org/viewcvs/texi2html/Tests/ccvs_mediawiki_res/cvs:%32Compatibility%32between%32CVS%32Versions?cvsroot=texi2html&rev=1.1
http://cvs.savannah.gnu.org/viewcvs/texi2html/Tests/ccvs_mediawiki_res/cvs:%32Credits?cvsroot=texi2html&rev=1.1
http://cvs.savannah.gnu.org/viewcvs/texi2html/Tests/ccvs_mediawiki_res/cvs:%32Dealing%32with%32bugs%32in%32CVS%32or%32this%32manual?cvsroot=texi2html&rev=1.1
http://cvs.savannah.gnu.org/viewcvs/texi2html/Tests/ccvs_mediawiki_res/cvs:%32Guide%32to%32CVS%32commands?cvsroot=texi2html&rev=1.1
http://cvs.savannah.gnu.org/viewcvs/texi2html/Tests/ccvs_mediawiki_res/cvs:%32Handling%32binary%32files?cvsroot=texi2html&rev=1.1
http://cvs.savannah.gnu.org/viewcvs/texi2html/Tests/ccvs_mediawiki_res/cvs:%32History%32browsing?cvsroot=texi2html&rev=1.1
http://cvs.savannah.gnu.org/viewcvs/texi2html/Tests/ccvs_mediawiki_res/cvs:%32How%32your%32build%32system%32interacts%32with%32CVS?cvsroot=texi2html&rev=1.1
http://cvs.savannah.gnu.org/viewcvs/texi2html/Tests/ccvs_mediawiki_res/cvs:%32Index?cvsroot=texi2html&rev=1.1
http://cvs.savannah.gnu.org/viewcvs/texi2html/Tests/ccvs_mediawiki_res/cvs:%32Keyword%32substitution?cvsroot=texi2html&rev=1.1
http://cvs.savannah.gnu.org/viewcvs/texi2html/Tests/ccvs_mediawiki_res/cvs:%32Multiple%32developers?cvsroot=texi2html&rev=1.1
http://cvs.savannah.gnu.org/viewcvs/texi2html/Tests/ccvs_mediawiki_res/cvs:%32Overview?cvsroot=texi2html&rev=1.1
http://cvs.savannah.gnu.org/viewcvs/texi2html/Tests/ccvs_mediawiki_res/cvs:%32Quick%32reference%32to%32CVS%32commands?cvsroot=texi2html&rev=1.1
http://cvs.savannah.gnu.org/viewcvs/texi2html/Tests/ccvs_mediawiki_res/cvs:%32Recursive%32behavior?cvsroot=texi2html&rev=1.1
http://cvs.savannah.gnu.org/viewcvs/texi2html/Tests/ccvs_mediawiki_res/cvs:%32Reference%32manual%32for%32Administrative%32files?cvsroot=texi2html&rev=1.1
http://cvs.savannah.gnu.org/viewcvs/texi2html/Tests/ccvs_mediawiki_res/cvs:%32Revision%32management?cvsroot=texi2html&rev=1.1
http://cvs.savannah.gnu.org/viewcvs/texi2html/Tests/ccvs_mediawiki_res/cvs:%32Revisions?cvsroot=texi2html&rev=1.1
http://cvs.savannah.gnu.org/viewcvs/texi2html/Tests/ccvs_mediawiki_res/cvs:%32Short%32Table%32of%32Contents?cvsroot=texi2html&rev=1.1
http://cvs.savannah.gnu.org/viewcvs/texi2html/Tests/ccvs_mediawiki_res/cvs:%32Special%32Files?cvsroot=texi2html&rev=1.1
http://cvs.savannah.gnu.org/viewcvs/texi2html/Tests/ccvs_mediawiki_res/cvs:%32Starting%32a%32project%32with%32CVS?cvsroot=texi2html&rev=1.1
http://cvs.savannah.gnu.org/viewcvs/texi2html/Tests/ccvs_mediawiki_res/cvs:%32Table%32of%32Contents?cvsroot=texi2html&rev=1.1
http://cvs.savannah.gnu.org/viewcvs/texi2html/Tests/ccvs_mediawiki_res/cvs:%32The%32Repository?cvsroot=texi2html&rev=1.1
http://cvs.savannah.gnu.org/viewcvs/texi2html/Tests/ccvs_mediawiki_res/cvs:%32Tracking%32third-party%32sources?cvsroot=texi2html&rev=1.1
http://cvs.savannah.gnu.org/viewcvs/texi2html/Tests/ccvs_mediawiki_res/cvs:%32Troubleshooting?cvsroot=texi2html&rev=1.1
http://cvs.savannah.gnu.org/viewcvs/texi2html/examples/mediawiki.init?cvsroot=texi2html&r1=1.5&r2=1.6
Patches:
Index: ChangeLog
===================================================================
RCS file: /cvsroot/texi2html/texi2html/ChangeLog,v
retrieving revision 1.284
retrieving revision 1.285
diff -u -b -r1.284 -r1.285
--- ChangeLog 7 Oct 2007 13:22:44 -0000 1.284
+++ ChangeLog 12 Mar 2008 10:24:11 -0000 1.285
@@ -1,3 +1,13 @@
+2008-03-12 Patrice Dumas <address@hidden>
+
+ * texi2html.pl, texi2html.init, examples/mediawiki.init: add
+ the program_string reference.
+ * examples/mediawiki.init: cleanup perl warnings.
+ * texi2html.pl: element_file_name called with doc sets docu_doc
+ and not docu_top (Reinhold Kainhofer).
+ * Tests/test.sh: more robust for files with spaces.
+ * Tests/*: add tests for mediawiki output.
+
2007-10-07 Patrice Dumas <address@hidden>
* texi2html.pl: better handling of special regions.
Index: TODO
===================================================================
RCS file: /cvsroot/texi2html/texi2html/TODO,v
retrieving revision 1.41
retrieving revision 1.42
diff -u -b -r1.41 -r1.42
--- TODO 7 Oct 2007 13:22:45 -0000 1.41
+++ TODO 12 Mar 2008 10:24:12 -0000 1.42
@@ -125,3 +125,5 @@
* maybe be quiet during special region expansion outside of document. It
is not very clear that it is wrong, though.
+
+* document program_string
Index: texi2html.init
===================================================================
RCS file: /cvsroot/texi2html/texi2html/texi2html.init,v
retrieving revision 1.131
retrieving revision 1.132
diff -u -b -r1.131 -r1.132
--- texi2html.init 7 Oct 2007 13:22:45 -0000 1.131
+++ texi2html.init 12 Mar 2008 10:24:12 -0000 1.132
@@ -12,7 +12,7 @@
# Afterwards, load the file with command-line
# option -init-file <your_init_file>
#
-# $Id: texi2html.init,v 1.131 2007/10/07 13:22:45 pertusus Exp $
+# $Id: texi2html.init,v 1.132 2008/03/12 10:24:12 pertusus Exp $
######################################################################
# The following variables can also be set by command-line options
@@ -812,6 +812,7 @@
$print_redirection_page = \&T2H_DEFAULT_print_redirection_page;
$node_file_name = \&T2H_DEFAULT_node_file_name;
$inline_contents = \&T2H_DEFAULT_inline_contents;
+$program_string = \&T2H_DEFAULT_program_string;
########################################################################
# Layout for html for every sections
@@ -1082,7 +1083,7 @@
EOT
}
-sub program_string()
+sub T2H_DEFAULT_program_string()
{
my $user = $Texi2HTML::THISDOC{'user'};
my $date = $Texi2HTML::THISDOC{'today'};
@@ -1119,7 +1120,7 @@
sub T2H_DEFAULT_print_page_foot($)
{
my $fh = shift;
- my $program_string = program_string();
+ my $program_string = &$program_string();
print $fh <<EOT;
<p>
<font size="-1">
@@ -1439,7 +1440,7 @@
# and all global variables like $ADDRESS are not available.
$PRE_ABOUT = sub
{
- return ' ' . program_string() . "\n";
+ return ' ' . &$program_string() . "\n";
};
# If customizing $AFTER_ABOUT, be sure to put the content inside <p></p>.
Index: texi2html.pl
===================================================================
RCS file: /cvsroot/texi2html/texi2html/texi2html.pl,v
retrieving revision 1.197
retrieving revision 1.198
diff -u -b -r1.197 -r1.198
--- texi2html.pl 7 Oct 2007 12:07:09 -0000 1.197
+++ texi2html.pl 12 Mar 2008 10:24:12 -0000 1.198
@@ -60,7 +60,7 @@
#--##########################################################################
# CVS version:
-# $Id: texi2html.pl,v 1.197 2007/10/07 12:07:09 pertusus Exp $
+# $Id: texi2html.pl,v 1.198 2008/03/12 10:24:12 pertusus Exp $
# Homepage:
my $T2H_HOMEPAGE = "http://www.nongnu.org/texi2html/";;
@@ -361,6 +361,7 @@
$node_file_name
$element_file_name
$inline_contents
+$program_string
$protect_text
$anchor
@@ -2948,9 +2949,9 @@
}
if (defined $Texi2HTML::Config::element_file_name)
{
- my $docu_name = &$Texi2HTML::Config::element_file_name
+ my $docu_doc_set = &$Texi2HTML::Config::element_file_name
(undef, "doc", $docu_name);
- $docu_top = $docu_name if (defined($docu_name));
+ $docu_doc = $docu_doc_set if (defined($docu_doc_set));
}
$docu_toc = $docu_foot = $docu_stoc = $docu_about = $docu_top = $docu_doc;
}
Index: Tests/test.sh
===================================================================
RCS file: /cvsroot/texi2html/texi2html/Tests/test.sh,v
retrieving revision 1.76
retrieving revision 1.77
diff -u -b -r1.76 -r1.77
--- Tests/test.sh 7 Oct 2007 12:07:09 -0000 1.76
+++ Tests/test.sh 12 Mar 2008 10:24:12 -0000 1.77
@@ -80,32 +80,33 @@
[ -d $dir_res ] || return
echo " diffs:"
previous_good='no'
-for file in `ls $dir_res` ; do
+for full_file in "$dir_res"/* ; do
+ file=`basename "$full_file"`
found='no'
- if [ -d $dir_res/$file -a $dir_res/$file = $dir_res/'CVS' ]; then
continue
- elif [ -d $dir_res/$file ]; then
+ if [ -d "${dir_res}/${file}" -a "$dir_res/$file" = "${dir_res}/CVS" ];
then continue
+ elif [ -d "${dir_res}/$file" ]; then
file_or_dir=dir
- if [ ! -d $dir/$file ]; then
+ if [ ! -d "${dir}/$file" ]; then
result=1
else
found='yes'
- diff --recursive $dir_res/$file $dir/$file 2>&1 >
/dev/null
+ diff --recursive "${dir_res}/$file" "${dir}/$file" 2>&1
> /dev/null
result=$?
fi
- elif [ -f $dir_res/$file ]; then
+ elif [ -f "${dir_res}/$file" ]; then
file_or_dir=file
- if [ ! -f $dir/$file ]; then
+ if [ ! -f "${dir}/$file" ]; then
result=1
else
found='yes'
if [ $ignore_tags = 'yes' ]; then
- temp_file=$dir/${file}_tempnotag
- sed 's/\$\([[:alpha:]]\+\):.*\$/\$\1\$/g'
$dir/${file} > $temp_file
- sed 's/\$\([[:alpha:]]\+\):.*\$/\$\1\$/g'
$dir_res/$file | diff - $temp_file 2>&1 > /dev/null
+ temp_file="${dir}/${file}_tempnotag"
+ sed 's/\$\([[:alpha:]]\+\):.*\$/\$\1\$/g'
"${dir}/${file}" > $temp_file
+ sed 's/\$\([[:alpha:]]\+\):.*\$/\$\1\$/g'
"${dir_res}/$file" | diff - $temp_file 2>&1 > /dev/null
result=$?
rm $temp_file
else
- diff $dir_res/$file $dir/$file 2>&1 > /dev/null
+ diff "${dir_res}/$file" "${dir}/$file" 2>&1 >
/dev/null
result=$?
fi
fi
@@ -372,5 +373,7 @@
test_texi nodes_texinfo ../texinfo/texinfo.txi "-split node -node-files
-ifinfo -output . -I ../texinfo" 0 txi texinfo #ignore_tags
test_texi ccvs cvs.texinfo "-split chapter -output ." 0 texinfo
test_texi tar ../tar_texi/tar.texi
+test_texi ccvs_mediawiki ../ccvs/cvs.texinfo "-init
../../examples/mediawiki.init -split chapter -output ." 0 texinfo
+test_texi ccvs_mediawiki_nosplit ../ccvs/cvs.texinfo "-init
../../examples/mediawiki.init" 0 texinfo
test_texi singular ../singular_texi/singular.tex "-init-file
../singular_texi/t2h_singular.init -l2h -short-ext -prefix sing -top-file
index.htm -noVerbose -output ." 0 tex sing #ignore_tags
#test_texi singular_httex ../singular_texi/singular.tex "-init-file
../singular_texi/t2h_singular.init -init ../../examples/tex4ht.init -short-ext
-prefix sing -top-file index.htm -noVerbose -output ." 0 tex sing #ignore_tags
Index: examples/mediawiki.init
===================================================================
RCS file: /cvsroot/texi2html/texi2html/examples/mediawiki.init,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -b -r1.5 -r1.6
--- examples/mediawiki.init 7 Oct 2007 13:22:46 -0000 1.5
+++ examples/mediawiki.init 12 Mar 2008 10:24:16 -0000 1.6
@@ -8,7 +8,7 @@
# Load the file with command-line
# option -init-file mediawiki.init
#
-# $Id: mediawiki.init,v 1.5 2007/10/07 13:22:46 pertusus Exp $
+# $Id: mediawiki.init,v 1.6 2008/03/12 10:24:16 pertusus Exp $
######################################################################
# The following variables can also be set by command-line options
@@ -57,6 +57,7 @@
$print_page_head = \&mediawiki_print_page_head;
$print_page_foot = \&mediawiki_print_page_foot;
+$program_string = \&mediawiki_program_string;
sub mediawiki_print_page_head($)
{
@@ -64,7 +65,7 @@
print $fh "$AFTER_BODY_OPEN\n" if $AFTER_BODY_OPEN;
}
-sub program_string()
+sub mediawiki_program_string()
{
my $user = $Texi2HTML::THISDOC{'user'};
my $date = $Texi2HTML::THISDOC{'today'};
@@ -93,7 +94,7 @@
sub mediawiki_print_page_foot($)
{
my $fh = shift;
- my $program_string = program_string();
+ my $program_string = &$program_string();
print $fh $program_string, "\n";
print $fh $PRE_BODY_CLOSE, "\n" if $PRE_BODY_CLOSE;
}
@@ -151,13 +152,13 @@
# there is a " the resulting text is also enclosed within `'
# default is {'args' => ['normal'], 'attribute' => ''},
-$style_map{'titlefont'} => {'function' => \&mediawiki_titlefont};
-$style_map{'option'} => {'args' => ['code'],
- 'attribute' => 'code',
- 'quote' => '"'};
-$style_map{'samp'} => {'args' => ['code'],
- 'attribute' => 'code',
- 'quote' => '"'};
+$style_map{'titlefont'} = {'function' => \&mediawiki_titlefont};
+#$style_map{'option'} = {'args' => ['code'],
+# 'attribute' => 'code',
+# 'quote' => '"'};
+#$style_map{'samp'} = {'args' => ['code'],
+# 'attribute' => 'code',
+# 'quote' => '"'};
Index: Tests/ccvs_mediawiki_nosplit_res/cvs
===================================================================
RCS file: Tests/ccvs_mediawiki_nosplit_res/cvs
diff -N Tests/ccvs_mediawiki_nosplit_res/cvs
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ Tests/ccvs_mediawiki_nosplit_res/cvs 12 Mar 2008 10:24:12 -0000
1.1
@@ -0,0 +1,17225 @@
+<div id="Top"></div>
+<div id="SEC_Top"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+== CVS—Concurrent Versions System v1.12.1.1 ==
+
+<p>This info manual describes how to use and administer
+<small>CVS</small> version 1.12.1.1.
+</p>
+
+<pre class="menu-preformatted"><nowiki></nowiki>•[[#SEC1|
Overview]]::<nowiki> An introduction to CVS
+</nowiki>•[[#SEC9| Repository]]::<nowiki> Where all your
sources are stored
+</nowiki>•[[#SEC38| Starting a new project]]::<nowiki> Starting a
project with CVS
+</nowiki>•[[#SEC44| Revisions]]::<nowiki> Numeric and
symbolic names for revisions
+</nowiki>•[[#SEC54| Branching and merging]]::<nowiki>
Diverging/rejoining branches of development
+</nowiki>•[[#SEC65| Recursive behavior]]::<nowiki> CVS descends
directories
+</nowiki>•[[#SEC66| Adding and removing]]::<nowiki>
Adding/removing/renaming files/directories
+</nowiki>•[[#SEC75| History browsing]]::<nowiki> Viewing the
history of files in various ways
+
+CVS and the Real World.
+-----------------------
+</nowiki>•[[#SEC80| Binary files]]::<nowiki> CVS can
handle binary files
+</nowiki>•[[#SEC83| Multiple developers]]::<nowiki> How CVS helps
a group of developers
+</nowiki>•[[#SEC96| Revision management]]::<nowiki> Policy
questions for revision management
+</nowiki>•[[#SEC98| Keyword substitution]]::<nowiki> CVS can
include the revision inside the file
+</nowiki>•[[#SEC105| Tracking sources]]::<nowiki> Tracking
third-party sources
+</nowiki>•[[#SEC112| Builds]]::<nowiki> Issues
related to CVS and builds
+</nowiki>•[[#SEC113| Special Files]]::<nowiki> Devices, links
and other non-regular files
+
+References.
+-----------
+</nowiki>•[[#SEC114| CVS commands]]::<nowiki> CVS commands
share some things
+</nowiki>•[[#SEC156| Invoking CVS]]::<nowiki> Quick
reference to CVS commands
+</nowiki>•[[#SEC157| Administrative files]]::<nowiki> Reference
manual for the Administrative files
+</nowiki>•[[#SEC181| Environment variables]]::<nowiki> All
environment variables which affect CVS
+</nowiki>•[[#SEC182| Compatibility]]::<nowiki> Upgrading
CVS versions
+</nowiki>•[[#SEC183| Troubleshooting]]::<nowiki> Some tips
when nothing works
+</nowiki>•[[#SEC187| Credits]]::<nowiki> Some of the
contributors to this manual
+</nowiki>•[[#SEC188| BUGS]]::<nowiki> Dealing with
bugs in CVS or this manual
+</nowiki>•[[#SEC189| Index]]::<nowiki> Index
+</nowiki></pre>
+<hr size="1">
+<div id="Overview"></div>
+<div id="SEC1"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC_Top| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC2| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">[ << ]</td>
+<td valign="middle" align="left">|[[#SEC_Top| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC9| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+== Overview ==
+
+<p>This chapter is for people who have never used
+<small>CVS</small>, and perhaps have never used version control
+software before.
+</p>
+<p>If you are already familiar with <small>CVS</small> and are just
+trying to learn a particular feature or remember a
+certain command, you can probably skip everything here.
+</p>
+<pre class="menu-preformatted"><nowiki></nowiki>•[[#SEC2| What is
CVS?]]::<nowiki> What you can do with CVS
+</nowiki>•[[#SEC3| What is CVS not?]]::<nowiki> Problems CVS
doesn't try to solve
+</nowiki>•[[#SEC4| A sample session]]::<nowiki> A tour of
basic CVS usage
+</nowiki></pre>
+<hr size="6">
+<div id="What-is-CVS_003f"></div>
+<div id="SEC2"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC1| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC3| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC1| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC1| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC9| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== What is CVS? ===
+
+<p><small>CVS</small> is a version control system. Using it, you can
+record the history of your source files.
+</p>
+
+<p>For example, bugs sometimes creep in when
+software is modified, and you might not detect the bug
+until a long time after you make the modification.
+With <small>CVS</small>, you can easily retrieve old versions to see
+exactly which change caused the bug. This can
+sometimes be a big help.
+</p>
+<p>You could of course save every version of every file
+you have ever created. This would
+however waste an enormous amount of disk space. <small>CVS</small>
+stores all the versions of a file in a single file in a
+clever way that only stores the differences between
+versions.
+</p>
+<p><small>CVS</small> also helps you if you are part of a group of people
working
+on the same project. It is all too easy to overwrite
+each others’ changes unless you are extremely careful.
+Some editors, like <small>GNU</small> Emacs, try to make sure that
+the same file is never modified by two people at the
+same time. Unfortunately, if someone is using another
+editor, that safeguard will not work. <small>CVS</small> solves this problem
+by insulating the different developers from each other. Every
+developer works in his own directory, and <small>CVS</small> merges
+the work when each developer is done.
+</p>
+<div id="IDX1"></div>
+<div id="IDX2"></div>
+<div id="IDX3"></div>
+<div id="IDX4"></div>
+<p><small>CVS</small> started out as a bunch of shell scripts written by
+Dick Grune, posted to the newsgroup
+<code>comp.sources.unix</code> in the volume 6
+release of July, 1986. While no actual code from
+these shell scripts is present in the current version
+of <small>CVS</small> much of the <small>CVS</small> conflict resolution
algorithms
+come from them.
+</p>
+<p>In April, 1989, Brian Berliner designed and coded <small>CVS</small>.
+Jeff Polk later helped Brian with the design of the <small>CVS</small>
+module and vendor branch support.
+</p>
+<div id="IDX5"></div>
+<p>You can get <small>CVS</small> in a variety of ways, including
+free download from the internet. For more information
+on downloading <small>CVS</small> and other <small>CVS</small> topics, see:
+</p>
+<table><tr><td> </td><td><pre
class="example"><nowiki>http://www.cvshome.org/
+http://www.loria.fr/~molli/cvs-index.html
+</nowiki></pre></td></tr></table>
+
+<div id="IDX6"></div>
+<div id="IDX7"></div>
+<div id="IDX8"></div>
+<p>There is a mailing list, known as <code>info-cvs</code>,
+devoted to <small>CVS</small>. To subscribe or
+unsubscribe
+write to
+<code>address@hidden</code>.
+If you prefer a usenet group, the right
+group is <code>comp.software.config-mgmt</code> which is for
+<small>CVS</small> discussions (along with other configuration
+management systems). In the future, it might be
+possible to create a
+<code>comp.software.config-mgmt.cvs</code>, but probably only
+if there is sufficient <small>CVS</small> traffic on
+<code>comp.software.config-mgmt</code>.
+</p>
+<p>You can also subscribe to the <code>bug-cvs</code> mailing list,
+described in more detail in [[#SEC188|Dealing with bugs in CVS or this
manual]]. To subscribe
+send mail to <code>address@hidden</code>.
+</p>
+<hr size="6">
+<div id="What-is-CVS-not_003f"></div>
+<div id="SEC3"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC2| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC4| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC1| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC1| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC9| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== What is CVS not? ===
+
+<p><small>CVS</small> can do a lot of things for you, but it does
+not try to be everything for everyone.
+</p>
+<dl compact="compact">
+<dt> <small>CVS</small> is not a build system.</dt>
+<dd>
+<p>Though the structure of your repository and modules
+file interact with your build system
+(e.g. ‘<tt>Makefile</tt>’s), they are essentially
+independent.
+</p>
+<p><small>CVS</small> does not dictate how you build anything. It
+merely stores files for retrieval in a tree structure
+you devise.
+</p>
+<p><small>CVS</small> does not dictate how to use disk space in the
+checked out working directories. If you write your
+‘<tt>Makefile</tt>’s or scripts in every directory so they
+have to know the relative positions of everything else,
+you wind up requiring the entire repository to be
+checked out.
+</p>
+<p>If you modularize your work, and construct a build
+system that will share files (via links, mounts,
+<code>VPATH</code> in ‘<tt>Makefile</tt>’s, etc.), you can
+arrange your disk usage however you like.
+</p>
+<p>But you have to remember that <em>any</em> such system is
+a lot of work to construct and maintain. <small>CVS</small> does
+not address the issues involved.
+</p>
+<p>Of course, you should place the tools created to
+support such a build system (scripts, ‘<tt>Makefile</tt>’s,
+etc) under <small>CVS</small>.
+</p>
+<p>Figuring out what files need to be rebuilt when
+something changes is, again, something to be handled
+outside the scope of <small>CVS</small>. One traditional
+approach is to use <code>make</code> for building, and use
+some automated tool for generating the dependencies which
+<code>make</code> uses.
+</p>
+<p>See [[#SEC112|How your build system interacts with CVS]], for more
information on doing builds
+in conjunction with <small>CVS</small>.
+</p>
+</dd>
+<dt> <small>CVS</small> is not a substitute for management.</dt>
+<dd>
+<p>Your managers and project leaders are expected to talk
+to you frequently enough to make certain you are aware
+of schedules, merge points, branch names and release
+dates. If they don’t, <small>CVS</small> can’t help.
+</p>
+<p><small>CVS</small> is an instrument for making sources dance to
+your tune. But you are the piper and the composer. No
+instrument plays itself or writes its own music.
+</p>
+</dd>
+<dt> <small>CVS</small> is not a substitute for developer communication.</dt>
+<dd>
+<p>When faced with conflicts within a single file, most
+developers manage to resolve them without too much
+effort. But a more general definition of “conflict”
+includes problems too difficult to solve without
+communication between developers.
+</p>
+<p><small>CVS</small> cannot determine when simultaneous changes
+within a single file, or across a whole collection of
+files, will logically conflict with one another. Its
+concept of a <em>conflict</em> is purely textual, arising
+when two changes to the same base file are near enough
+to spook the merge (i.e. <code>diff3</code>) command.
+</p>
+<p><small>CVS</small> does not claim to help at all in figuring out
+non-textual or distributed conflicts in program logic.
+</p>
+<p>For example: Say you change the arguments to function
+<code>X</code> defined in file ‘<tt>A</tt>’. At the same time,
+someone edits file ‘<tt>B</tt>’, adding new calls to
+function <code>X</code> using the old arguments. You are
+outside the realm of <small>CVS</small>’s competence.
+</p>
+<p>Acquire the habit of reading specs and talking to your
+peers.
+</p>
+
+</dd>
+<dt> <small>CVS</small> does not have change control</dt>
+<dd>
+<p>Change control refers to a number of things. First of
+all it can mean <em>bug-tracking</em>, that is being able
+to keep a database of reported bugs and the status of
+each one (is it fixed? in what release? has the bug
+submitter agreed that it is fixed?). For interfacing
+<small>CVS</small> to an external bug-tracking system, see the
+‘<tt>rcsinfo</tt>’ and ‘<tt>verifymsg</tt>’ files
+(see section [[#SEC157|Reference manual for Administrative files]]).
+</p>
+<p>Another aspect of change control is keeping track of
+the fact that changes to several files were in fact
+changed together as one logical change. If you check
+in several files in a single <code>cvs commit</code>
+operation, <small>CVS</small> then forgets that those files were
+checked in together, and the fact that they have the
+same log message is the only thing tying them
+together. Keeping a <small>GNU</small> style ‘<tt>ChangeLog</tt>’
+can help somewhat.
+</p>
+<p>Another aspect of change control, in some systems, is
+the ability to keep track of the status of each
+change. Some changes have been written by a developer,
+others have been reviewed by a second developer, and so
+on. Generally, the way to do this with <small>CVS</small> is to
+generate a diff (using <code>cvs diff</code> or <code>diff</code>)
+and email it to someone who can then apply it using the
+<code>patch</code> utility. This is very flexible, but
+depends on mechanisms outside <small>CVS</small> to make sure
+nothing falls through the cracks.
+</p>
+</dd>
+<dt> <small>CVS</small> is not an automated testing program</dt>
+<dd>
+<p>It should be possible to enforce mandatory use of a
+testsuite using the <code>commitinfo</code> file. I haven’t
+heard a lot about projects trying to do that or whether
+there are subtle gotchas, however.
+</p>
+</dd>
+<dt> <small>CVS</small> does not have a builtin process model</dt>
+<dd>
+<p>Some systems provide ways to ensure that changes or
+releases go through various steps, with various
+approvals as needed. Generally, one can accomplish
+this with <small>CVS</small> but it might be a little more work.
+In some cases you’ll want to use the ‘<tt>commitinfo</tt>’,
+‘<tt>loginfo</tt>’, ‘<tt>rcsinfo</tt>’, or
‘<tt>verifymsg</tt>’
+files, to require that certain steps be performed
+before cvs will allow a checkin. Also consider whether
+features such as branches and tags can be used to
+perform tasks such as doing work in a development tree
+and then merging certain changes over to a stable tree
+only once they have been proven.
+</p></dd>
+</dl>
+
+<hr size="6">
+<div id="A-sample-session"></div>
+<div id="SEC4"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC3| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC5| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC1| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC1| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC9| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== A sample session ===
+
+
+<p>As a way of introducing <small>CVS</small>, we’ll go through a
+typical work-session using <small>CVS</small>. The first thing
+to understand is that <small>CVS</small> stores all files in a
+centralized <em>repository</em> (see section [[#SEC9|The Repository]]); this
+section assumes that a repository is set up.
+</p>
+<p>Suppose you are working on a simple compiler. The source
+consists of a handful of C files and a ‘<tt>Makefile</tt>’.
+The compiler is called ‘<samp>tc</samp>’ (Trivial Compiler),
+and the repository is set up so that there is a module
+called ‘<samp>tc</samp>’.
+</p>
+<pre class="menu-preformatted"><nowiki></nowiki>•[[#SEC5| Getting the
source]]::<nowiki> Creating a workspace
+</nowiki>•[[#SEC6| Committing your changes]]::<nowiki> Making your
work available to others
+</nowiki>•[[#SEC7| Cleaning up]]::<nowiki> Cleaning up
+</nowiki>•[[#SEC8| Viewing differences]]::<nowiki> Viewing
differences
+</nowiki></pre>
+<hr size="6">
+<div id="Getting-the-source"></div>
+<div id="SEC5"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC4| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC6| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC1| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC4| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC9| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+==== Getting the source ====
+
+<p>The first thing you must do is to get your own working copy of the
+source for ‘<samp>tc</samp>’. For this, you use the
<code>checkout</code> command:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>$ cvs checkout tc
+</nowiki></pre></td></tr></table>
+
+<p>This will create a new directory called ‘<tt>tc</tt>’ and
populate it with
+the source files.
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>$ cd tc
+$ ls
+CVS Makefile backend.c driver.c frontend.c parser.c
+</nowiki></pre></td></tr></table>
+
+<p>The ‘<tt>CVS</tt>’ directory is used internally by
+<small>CVS</small>. Normally, you should not modify or remove
+any of the files in it.
+</p>
+<p>You start your favorite editor, hack away at
‘<tt>backend.c</tt>’, and a couple
+of hours later you have added an optimization pass to the compiler.
+A note to <small>RCS</small> and <small>SCCS</small> users: There is no need
to lock the files that
+you want to edit. See section [[#SEC83|Multiple developers]], for an
explanation.
+</p>
+<hr size="6">
+<div id="Committing-your-changes"></div>
+<div id="SEC6"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC5| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC7| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC1| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC4| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC9| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+==== Committing your changes ====
+
+<p>When you have checked that the compiler is still compilable you decide
+to make a new version of ‘<tt>backend.c</tt>’. This will
+store your new ‘<tt>backend.c</tt>’ in the repository and
+make it available to anyone else who is using that same
+repository.
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>$ cvs commit
backend.c
+</nowiki></pre></td></tr></table>
+
+<p><small>CVS</small> starts an editor, to allow you to enter a log
+message. You type in “Added an optimization pass.”,
+save the temporary file, and exit the editor.
+</p>
+<div id="IDX9"></div>
+<div id="IDX10"></div>
+<p>The environment variable <code>$CVSEDITOR</code> determines
+which editor is started. If <code>$CVSEDITOR</code> is not
+set, then if the environment variable <code>$EDITOR</code> is
+set, it will be used. If both <code>$CVSEDITOR</code> and
+<code>$EDITOR</code> are not set then there is a default
+which will vary with your operating system, for example
+<code>vi</code> for unix or <code>notepad</code> for Windows
+NT/95.
+</p>
+<div id="IDX11"></div>
+<p>In addition, <small>CVS</small> checks the <code>$VISUAL</code> environment
+variable. Opinions vary on whether this behavior is desirable and
+whether future releases of <small>CVS</small> should check
<code>$VISUAL</code> or
+ignore it. You will be OK either way if you make sure that
+<code>$VISUAL</code> is either unset or set to the same thing as
+<code>$EDITOR</code>.
+</p>
+<p>When <small>CVS</small> starts the editor, it includes a list of
+files which are modified. For the <small>CVS</small> client,
+this list is based on comparing the modification time
+of the file against the modification time that the file
+had when it was last gotten or updated. Therefore, if
+a file’s modification time has changed but its contents
+have not, it will show up as modified. The simplest
+way to handle this is simply not to worry about it—if
+you proceed with the commit <small>CVS</small> will detect that
+the contents are not modified and treat it as an
+unmodified file. The next <code>update</code> will clue
+<small>CVS</small> in to the fact that the file is unmodified,
+and it will reset its stored timestamp so that the file
+will not show up in future editor sessions.
+</p>
+<p>If you want to avoid
+starting an editor you can specify the log message on
+the command line using the ‘<samp>-m</samp>’ flag instead, like
+this:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>$ cvs commit -m
"Added an optimization pass" backend.c
+</nowiki></pre></td></tr></table>
+
+<hr size="6">
+<div id="Cleaning-up"></div>
+<div id="SEC7"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC6| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC8| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC1| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC4| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC9| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+==== Cleaning up ====
+
+<p>Before you turn to other tasks you decide to remove your working copy of
+tc. One acceptable way to do that is of course
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>$ cd ..
+$ rm -r tc
+</nowiki></pre></td></tr></table>
+
+<p>but a better way is to use the <code>release</code> command (see section
[[#SEC149|release—Indicate that a Module is no longer in use]]):
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>$ cd ..
+$ cvs release -d tc
+M driver.c
+? tc
+You have [1] altered files in this repository.
+Are you sure you want to release (and delete) directory `tc': n
+** `release' aborted by user choice.
+</nowiki></pre></td></tr></table>
+
+<p>The <code>release</code> command checks that all your modifications have
been
+committed. If history logging is enabled it also makes a note in the
+history file. See section [[#SEC178|The history file]].
+</p>
+<p>When you use the ‘<samp>-d</samp>’ flag with
<code>release</code>, it
+also removes your working copy.
+</p>
+<p>In the example above, the <code>release</code> command wrote a couple of
lines
+of output. ‘<samp>? tc</samp>’ means that the file
‘<tt>tc</tt>’ is unknown to <small>CVS</small>.
+That is nothing to worry about: ‘<tt>tc</tt>’ is the executable
compiler,
+and it should not be stored in the repository. See section [[#SEC176|Ignoring
files via cvsignore]],
+for information about how to make that warning go away.
+See section [[#SEC151|release output]], for a complete explanation of
+all possible output from <code>release</code>.
+</p>
+<p>‘<samp>M driver.c</samp>’ is more serious. It means that the
+file ‘<tt>driver.c</tt>’ has been modified since it was
+checked out.
+</p>
+<p>The <code>release</code> command always finishes by telling
+you how many modified files you have in your working
+copy of the sources, and then asks you for confirmation
+before deleting any files or making any note in the
+history file.
+</p>
+<p>You decide to play it safe and answer <kbd>n <RET></kbd>
+when <code>release</code> asks for confirmation.
+</p>
+<hr size="6">
+<div id="Viewing-differences"></div>
+<div id="SEC8"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC7| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC9| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC1| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC4| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC9| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+==== Viewing differences ====
+
+<p>You do not remember modifying ‘<tt>driver.c</tt>’, so you want
to see what
+has happened to that file.
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>$ cd tc
+$ cvs diff driver.c
+</nowiki></pre></td></tr></table>
+
+<p>This command runs <code>diff</code> to compare the version of
‘<tt>driver.c</tt>’
+that you checked out with your working copy. When you see the output
+you remember that you added a command line option that enabled the
+optimization pass. You check it in, and release the module.
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>$ cvs commit -m
"Added an optimization pass" driver.c
+Checking in driver.c;
+/usr/local/cvsroot/tc/driver.c,v <-- driver.c
+new revision: 1.2; previous revision: 1.1
+done
+$ cd ..
+$ cvs release -d tc
+? tc
+You have [0] altered files in this repository.
+Are you sure you want to release (and delete) directory `tc': y
+</nowiki></pre></td></tr></table>
+
+<hr size="6">
+<div id="Repository"></div>
+<div id="SEC9"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC8| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC10| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC1| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC_Top| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC38| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+== The Repository ==
+
+<p>The <small>CVS</small> <em>repository</em> stores a complete copy of
+all the files and directories which are under version
+control.
+</p>
+<p>Normally, you never access any of the files in the
+repository directly. Instead, you use <small>CVS</small>
+commands to get your own copy of the files into a
+<em>working directory</em>, and then
+work on that copy. When you’ve finished a set of
+changes, you check (or <em>commit</em>) them back into the
+repository. The repository then contains the changes
+which you have made, as well as recording exactly what
+you changed, when you changed it, and other such
+information. Note that the repository is not a
+subdirectory of the working directory, or vice versa;
+they should be in separate locations.
+</p>
+<div id="IDX12"></div>
+<p><small>CVS</small> can access a repository by a variety of
+means. It might be on the local computer, or it might
+be on a computer across the room or across the world.
+To distinguish various ways to access a repository, the
+repository name can start with an <em>access method</em>.
+For example, the access method <code>:local:</code> means to
+access a repository directory, so the repository
+<code>:local:/usr/local/cvsroot</code> means that the
+repository is in ‘<tt>/usr/local/cvsroot</tt>’ on the
+computer running <small>CVS</small>. For information on other
+access methods, see [[#SEC26|Remote repositories]].
+</p>
+<p>If the access method is omitted, then if the repository
+starts with ‘<samp>/</samp>’, then <code>:local:</code> is
+assumed. If it does not start with ‘<samp>/</samp>’ then either
+<code>:ext:</code> or <code>:server:</code> is assumed. For
+example, if you have a local repository in
+‘<tt>/usr/local/cvsroot</tt>’, you can use
+<code>/usr/local/cvsroot</code> instead of
+<code>:local:/usr/local/cvsroot</code>. But if (under
+Windows NT, for example) your local repository is
+‘<tt>c:\src\cvsroot</tt>’, then you must specify the access
+method, as in <code>:local:c:/src/cvsroot</code>.
+</p>
+<p>The repository is split in two parts.
‘<tt>$CVSROOT/CVSROOT</tt>’ contains
+administrative files for <small>CVS</small>. The other directories contain
the actual
+user-defined modules.
+</p>
+<pre class="menu-preformatted"><nowiki></nowiki>•[[#SEC10| Specifying a
repository]]::<nowiki> Telling CVS where your repository is
+</nowiki>•[[#SEC11| Repository storage]]::<nowiki> The structure
of the repository
+</nowiki>•[[#SEC19| Working directory storage]]::<nowiki> The structure
of working directories
+</nowiki>•[[#SEC20| Intro administrative files]]::<nowiki> Defining
modules
+</nowiki>•[[#SEC22| Multiple repositories]]::<nowiki> Multiple
repositories
+</nowiki>•[[#SEC23| Creating a repository]]::<nowiki> Creating a
repository
+</nowiki>•[[#SEC24| Backing up]]::<nowiki> Backing up a
repository
+</nowiki>•[[#SEC25| Moving a repository]]::<nowiki> Moving a
repository
+</nowiki>•[[#SEC26| Remote repositories]]::<nowiki> Accessing
repositories on remote machines
+</nowiki>•[[#SEC36| Read-only access]]::<nowiki> Granting
read-only access to the repository
+</nowiki>•[[#SEC37| Server temporary directory]]::<nowiki> The server
creates temporary directories
+</nowiki></pre>
+<hr size="6">
+<div id="Specifying-a-repository"></div>
+<div id="SEC10"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC9| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC11| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC9| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC9| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC38| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== Telling CVS where your repository is ===
+
+<p>There are several ways to tell <small>CVS</small>
+where to find the repository. You can name the
+repository on the command line explicitly, with the
+<code>-d</code> (for "directory") option:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>cvs -d
/usr/local/cvsroot checkout yoyodyne/tc
+</nowiki></pre></td></tr></table>
+
+<div id="IDX13"></div>
+<div id="IDX14"></div>
+<div id="IDX15"></div>
+<div id="IDX16"></div>
+<div id="IDX17"></div>
+<p> Or you can set the <code>$CVSROOT</code> environment
+variable to an absolute path to the root of the
+repository, ‘<tt>/usr/local/cvsroot</tt>’ in this example.
+To set <code>$CVSROOT</code>, <code>csh</code> and <code>tcsh</code>
+users should have this line in their ‘<tt>.cshrc</tt>’ or
+‘<tt>.tcshrc</tt>’ files:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>setenv CVSROOT
/usr/local/cvsroot
+</nowiki></pre></td></tr></table>
+
+<p><code>sh</code> and <code>bash</code> users should instead have these lines
in their
+‘<tt>.profile</tt>’ or ‘<tt>.bashrc</tt>’:
+</p>
+<table><tr><td> </td><td><pre
class="example"><nowiki>CVSROOT=/usr/local/cvsroot
+export CVSROOT
+</nowiki></pre></td></tr></table>
+
+<div id="IDX18"></div>
+<div id="IDX19"></div>
+<p> A repository specified with <code>-d</code> will
+override the <code>$CVSROOT</code> environment variable.
+Once you’ve checked a working copy out from the
+repository, it will remember where its repository is
+(the information is recorded in the
+‘<tt>CVS/Root</tt>’ file in the working copy).
+</p>
+<p>The <code>-d</code> option and the ‘<tt>CVS/Root</tt>’ file both
+override the <code>$CVSROOT</code> environment variable. If
+<code>-d</code> option differs from ‘<tt>CVS/Root</tt>’, the
+former is used. Of course, for proper operation they
+should be two ways of referring to the same repository.
+</p>
+<hr size="6">
+<div id="Repository-storage"></div>
+<div id="SEC11"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC10| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC12| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC9| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC9| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC38| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== How data is stored in the repository ===
+
+<p>For most purposes it isn’t important <em>how</em>
+<small>CVS</small> stores information in the repository. In
+fact, the format has changed in the past, and is likely
+to change in the future. Since in almost all cases one
+accesses the repository via <small>CVS</small> commands, such
+changes need not be disruptive.
+</p>
+<p>However, in some cases it may be necessary to
+understand how <small>CVS</small> stores data in the repository,
+for example you might need to track down <small>CVS</small> locks
+(see section [[#SEC88|Several developers simultaneously attempting to run
CVS]]) or you might need to deal with
+the file permissions appropriate for the repository.
+</p>
+<pre class="menu-preformatted"><nowiki></nowiki>•[[#SEC12| Repository
files]]::<nowiki> What files are stored in the repository
+</nowiki>•[[#SEC13| File permissions]]::<nowiki> File
permissions
+</nowiki>•[[#SEC14| Windows permissions]]::<nowiki> Issues
specific to Windows
+</nowiki>•[[#SEC15| Attic]]::<nowiki> Some files
are stored in the Attic
+</nowiki>•[[#SEC16| CVS in repository]]::<nowiki> Additional
information in CVS directory
+</nowiki>•[[#SEC17| Locks]]::<nowiki> CVS locks
control concurrent accesses
+</nowiki>•[[#SEC18| CVSROOT storage]]::<nowiki> A few things
about CVSROOT are different
+</nowiki></pre>
+<hr size="6">
+<div id="Repository-files"></div>
+<div id="SEC12"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC11| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC13| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC9| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC11| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC38| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+==== Where files are stored within the repository ====
+
+
+<p>The overall structure of the repository is a directory
+tree corresponding to the directories in the working
+directory. For example, supposing the repository is in
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>/usr/local/cvsroot
+</nowiki></pre></td></tr></table>
+
+<p>here is a possible directory tree (showing only the
+directories):
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki><tt>/usr</tt>
+ |
+ +--<tt>local</tt>
+ | |
+ | +--<tt>cvsroot</tt>
+ | | |
+ | | +--<tt>CVSROOT</tt>
+ | (administrative files)
+ |
+ +--<tt>gnu</tt>
+ | |
+ | +--<tt>diff</tt>
+ | | (source code to GNU diff)
+ | |
+ | +--<tt>rcs</tt>
+ | | (source code to RCS)
+ | |
+ | +--<tt>cvs</tt>
+ | (source code to CVS)
+ |
+ +--<tt>yoyodyne</tt>
+ |
+ +--<tt>tc</tt>
+ | |
+ | +--<tt>man</tt>
+ | |
+ | +--<tt>testing</tt>
+ |
+ +--(other Yoyodyne software)
+</nowiki></pre></td></tr></table>
+
+<p>With the directories are <em>history files</em> for each file
+under version control. The name of the history file is
+the name of the corresponding file with ‘<samp>,v</samp>’
+appended to the end. Here is what the repository for
+the ‘<tt>yoyodyne/tc</tt>’ directory might look like:
+</p><table><tr><td> </td><td><pre class="example"><nowiki>
<code>$CVSROOT</code>
+ |
+ +--<tt>yoyodyne</tt>
+ | |
+ | +--<tt>tc</tt>
+ | | |
+ +--<tt>Makefile,v</tt>
+ +--<tt>backend.c,v</tt>
+ +--<tt>driver.c,v</tt>
+ +--<tt>frontend.c,v</tt>
+ +--<tt>parser.c,v</tt>
+ +--<tt>man</tt>
+ | |
+ | +--<tt>tc.1,v</tt>
+ |
+ +--<tt>testing</tt>
+ |
+ +--<tt>testpgm.t,v</tt>
+ +--<tt>test2.t,v</tt>
+</nowiki></pre></td></tr></table>
+
+<div id="IDX20"></div>
+<div id="IDX21"></div>
+<p>The history files contain, among other things, enough
+information to recreate any revision of the file, a log
+of all commit messages and the user-name of the person
+who committed the revision. The history files are
+known as <em>RCS files</em>, because the first program to
+store files in that format was a version control system
+known as <small>RCS</small>. For a full
+description of the file format, see the <code>man</code> page
+<cite>rcsfile(5)</cite>, distributed with <small>RCS</small>, or the
+file ‘<tt>doc/RCSFILES</tt>’ in the <small>CVS</small> source
+distribution. This
+file format has become very common—many systems other
+than <small>CVS</small> or <small>RCS</small> can at least import history
+files in this format.
+</p>
+<p>The <small>RCS</small> files used in <small>CVS</small> differ in a few
+ways from the standard format. The biggest difference
+is magic branches; for more information see [[#SEC59|Magic branch numbers]].
Also in <small>CVS</small> the valid tag names
+are a subset of what <small>RCS</small> accepts; for <small>CVS</small>’s
+rules see [[#SEC48|Tags–Symbolic revisions]].
+</p>
+<hr size="6">
+<div id="File-permissions"></div>
+<div id="SEC13"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC12| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC14| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC9| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC11| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC38| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+==== File permissions ====
+<p>All ‘<samp>,v</samp>’ files are created read-only, and you
+should not change the permission of those files. The
+directories inside the repository should be writable by
+the persons that have permission to modify the files in
+each directory. This normally means that you must
+create a UNIX group (see group(5)) consisting of the
+persons that are to edit the files in a project, and
+set up the repository so that it is that group that
+owns the directory.
+(On some systems, you also need to set the set-group-ID-on-execution bit
+on the repository directories (see chmod(1)) so that newly-created files
+and directories get the group-ID of the parent directory rather than
+that of the current process.)
+</p>
+
+<p>This means that you can only control access to files on
+a per-directory basis.
+</p>
+<p>Note that users must also have write access to check
+out files, because <small>CVS</small> needs to create lock files
+(see section [[#SEC88|Several developers simultaneously attempting to run
CVS]]). You can use LockDir in CVSROOT/config
+to put the lock files somewhere other than in the repository
+if you want to allow read-only access to some directories
+(see section [[#SEC180|The CVSROOT/config configuration file]]).
+</p>
+<p>Also note that users must have write access to the
+‘<tt>CVSROOT/val-tags</tt>’ file. <small>CVS</small> uses it to
keep
+track of what tags are valid tag names (it is sometimes
+updated when tags are used, as well as when they are
+created).
+</p>
+<p>Each <small>RCS</small> file will be owned by the user who last
+checked it in. This has little significance; what
+really matters is who owns the directories.
+</p>
+<div id="IDX22"></div>
+<div id="IDX23"></div>
+<p><small>CVS</small> tries to set up reasonable file permissions
+for new directories that are added inside the tree, but
+you must fix the permissions manually when a new
+directory should have different permissions than its
+parent directory. If you set the <code>CVSUMASK</code>
+environment variable that will control the file
+permissions which <small>CVS</small> uses in creating directories
+and/or files in the repository. <code>CVSUMASK</code> does
+not affect the file permissions in the working
+directory; such files have the permissions which are
+typical for newly created files, except that sometimes
+<small>CVS</small> creates them read-only (see the sections on
+watches, [[#SEC90|Telling CVS to watch certain files]]; -r, [[#SEC118|Global
options]]; or <code>CVSREAD</code>, [[#SEC181|All environment variables which
affect CVS]]).
+</p>
+<p>Note that using the client/server <small>CVS</small>
+(see section [[#SEC26|Remote repositories]]), there is no good way to
+set <code>CVSUMASK</code>; the setting on the client machine
+has no effect. If you are connecting with <code>rsh</code>, you
+can set <code>CVSUMASK</code> in ‘<tt>.bashrc</tt>’ or
‘<tt>.cshrc</tt>’, as
+described in the documentation for your operating
+system. This behavior might change in future versions
+of <small>CVS</small>; do not rely on the setting of
+<code>CVSUMASK</code> on the client having no effect.
+</p>
+<p>Using pserver, you will generally need stricter
+permissions on the <small>CVSROOT</small> directory and
+directories above it in the tree; see [[#SEC32|Security considerations with
password authentication]].
+</p>
+<div id="IDX24"></div>
+<div id="IDX25"></div>
+<div id="IDX26"></div>
+<div id="IDX27"></div>
+<p>Some operating systems have features which allow a
+particular program to run with the ability to perform
+operations which the caller of the program could not.
+For example, the set user ID (setuid) or set group ID
+(setgid) features of unix or the installed image
+feature of VMS. <small>CVS</small> was not written to use such
+features and therefore attempting to install <small>CVS</small> in
+this fashion will provide protection against only
+accidental lapses; anyone who is trying to circumvent
+the measure will be able to do so, and depending on how
+you have set it up may gain access to more than just
+<small>CVS</small>. You may wish to instead consider pserver. It
+shares some of the same attributes, in terms of
+possibly providing a false sense of security or opening
+security holes wider than the ones you are trying to
+fix, so read the documentation on pserver security
+carefully if you are considering this option
+([[#SEC32|Security considerations with password authentication]]).
+</p>
+<hr size="6">
+<div id="Windows-permissions"></div>
+<div id="SEC14"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC13| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC15| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC9| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC11| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC38| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+==== File Permission issues specific to Windows ====
+
+<p>Some file permission issues are specific to Windows
+operating systems (Windows 95, Windows NT, and
+presumably future operating systems in this family.
+Some of the following might apply to OS/2 but I’m not
+sure).
+</p>
+<p>If you are using local <small>CVS</small> and the repository is on a
+networked file system which is served by the Samba SMB
+server, some people have reported problems with
+permissions. Enabling WRITE=YES in the samba
+configuration is said to fix/workaround it.
+Disclaimer: I haven’t investigated enough to know the
+implications of enabling that option, nor do I know
+whether there is something which <small>CVS</small> could be doing
+differently in order to avoid the problem. If you find
+something out, please let us know as described in
+[[#SEC188|Dealing with bugs in CVS or this manual]].
+</p>
+<hr size="6">
+<div id="Attic"></div>
+<div id="SEC15"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC14| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC16| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC9| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC11| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC38| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+==== The attic ====
+
+<p>You will notice that sometimes <small>CVS</small> stores an
+<small>RCS</small> file in the <code>Attic</code>. For example, if the
+<small>CVSROOT</small> is ‘<tt>/usr/local/cvsroot</tt>’ and we are
+talking about the file ‘<tt>backend.c</tt>’ in the
+directory ‘<tt>yoyodyne/tc</tt>’, then the file normally
+would be in
+</p>
+<table><tr><td> </td><td><pre
class="example"><nowiki>/usr/local/cvsroot/yoyodyne/tc/backend.c,v
+</nowiki></pre></td></tr></table>
+
+<p>but if it goes in the attic, it would be in
+</p>
+<table><tr><td> </td><td><pre
class="example"><nowiki>/usr/local/cvsroot/yoyodyne/tc/Attic/backend.c,v
+</nowiki></pre></td></tr></table>
+
+<div id="IDX28"></div>
+<p>instead. It should not matter from a user point of
+view whether a file is in the attic; <small>CVS</small> keeps
+track of this and looks in the attic when it needs to.
+But in case you want to know, the rule is that the RCS
+file is stored in the attic if and only if the head
+revision on the trunk has state <code>dead</code>. A
+<code>dead</code> state means that file has been removed, or
+never added, for that revision. For example, if you
+add a file on a branch, it will have a trunk revision
+in <code>dead</code> state, and a branch revision in a
+non-<code>dead</code> state.
+</p>
+<hr size="6">
+<div id="CVS-in-repository"></div>
+<div id="SEC16"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC15| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC17| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC9| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC11| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC38| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+==== The CVS directory in the repository ====
+
+<p>The ‘<tt>CVS</tt>’ directory in each repository directory
+contains information such as file attributes (in a file
+called ‘<tt>CVS/fileattr</tt>’. In the
+future additional files may be added to this directory,
+so implementations should silently ignore additional
+files.
+</p>
+<p>This behavior is implemented only by <small>CVS</small> 1.7 and
+later; for details see [[#SEC94|Using watches with old versions of CVS]].
+</p>
+<p>The format of the fileattr file is a series of entries
+of the following form (where ‘<samp>{</samp>’ and
‘<samp>}</samp>’
+means the text between the braces can be repeated zero
+or more times):
+</p>
+<p><var>ent-type</var> <var>filename</var> <tab> <var>attrname</var> =
<var>attrval</var>
+ {; <var>attrname</var> = <var>attrval</var>} <linefeed>
+</p>
+<p><var>ent-type</var> is ‘<samp>F</samp>’ for a file, in which
case the entry specifies the
+attributes for that file.
+</p>
+<p><var>ent-type</var> is ‘<samp>D</samp>’,
+and <var>filename</var> empty, to specify default attributes
+to be used for newly added files.
+</p>
+<p>Other <var>ent-type</var> are reserved for future expansion.
<small>CVS</small> 1.9 and older
+will delete them any time it writes file attributes.
+<small>CVS</small> 1.10 and later will preserve them.
+</p>
+<p>Note that the order of the lines is not significant;
+a program writing the fileattr file may
+rearrange them at its convenience.
+</p>
+<p>There is currently no way of quoting tabs or linefeeds in the
+filename, ‘<samp>=</samp>’ in <var>attrname</var>,
+‘<samp>;</samp>’ in <var>attrval</var>, etc. Note: some
implementations also
+don’t handle a NUL character in any of the fields, but
+implementations are encouraged to allow it.
+</p>
+<p>By convention, <var>attrname</var> starting with
‘<samp>_</samp>’ is for an attribute given
+special meaning by <small>CVS</small>; other <var>attrname</var>s are for
user-defined attributes
+(or will be, once implementations start supporting user-defined attributes).
+</p>
+<p>Builtin attributes:
+</p>
+<dl compact="compact">
+<dt> <code>_watched</code></dt>
+<dd><p>Present means the file is watched and should be checked out
+read-only.
+</p>
+</dd>
+<dt> <code>_watchers</code></dt>
+<dd><p>Users with watches for this file. Value is
+<var>watcher</var> > <var>type</var> { , <var>watcher</var> >
<var>type</var> }
+where <var>watcher</var> is a username, and <var>type</var>
+is zero or more of edit,unedit,commit separated by
+‘<samp>+</samp>’ (that is, nothing if none; there is no
"none" or "all" keyword).
+</p>
+</dd>
+<dt> <code>_editors</code></dt>
+<dd><p>Users editing this file. Value is
+<var>editor</var> > <var>val</var> { , <var>editor</var> >
<var>val</var> }
+where <var>editor</var> is a username, and <var>val</var> is
+<var>time</var>+<var>hostname</var>+<var>pathname</var>, where
+<var>time</var> is when the <code>cvs edit</code> command (or
+equivalent) happened,
+and <var>hostname</var> and <var>pathname</var> are for the working directory.
+</p></dd>
+</dl>
+
+<p>Example:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>Ffile1
_watched=;_watchers=joe>edit,mary>commit
+Ffile2 _watched=;_editors=sue>8 Jan 1975+workstn1+/home/sue/cvs
+D _watched=
+</nowiki></pre></td></tr></table>
+
+<p>means that the file ‘<tt>file1</tt>’ should be checked out
+read-only. Furthermore, joe is watching for edits and
+mary is watching for commits. The file ‘<tt>file2</tt>’
+should be checked out read-only; sue started editing it
+on 8 Jan 1975 in the directory ‘<tt>/home/sue/cvs</tt>’ on
+the machine <code>workstn1</code>. Future files which are
+added should be checked out read-only. To represent
+this example here, we have shown a space after
+‘<samp>D</samp>’, ‘<samp>Ffile1</samp>’, and
‘<samp>Ffile2</samp>’, but in fact
+there must be a single tab character there and no spaces.
+</p>
+<hr size="6">
+<div id="Locks"></div>
+<div id="SEC17"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC16| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC18| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC9| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC11| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC38| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+==== CVS locks in the repository ====
+
+<p>For an introduction to <small>CVS</small> locks focusing on
+user-visible behavior, see [[#SEC88|Several developers simultaneously
attempting to run CVS]]. The
+following section is aimed at people who are writing
+tools which want to access a <small>CVS</small> repository without
+interfering with other tools accessing the same
+repository. If you find yourself confused by concepts
+described here, like <em>read lock</em>, <em>write lock</em>,
+and <em>deadlock</em>, you might consult the literature on
+operating systems or databases.
+</p>
+<div id="IDX29"></div>
+<p>Any file in the repository with a name starting
+with ‘<tt>#cvs.rfl.</tt>’ is a read lock. Any file in
+the repository with a name starting with
+‘<tt>#cvs.wfl</tt>’ is a write lock. Old versions of
<small>CVS</small>
+(before <small>CVS</small> 1.5) also created files with names starting
+with ‘<tt>#cvs.tfl</tt>’, but they are not discussed here.
+The directory ‘<tt>#cvs.lock</tt>’ serves as a master
+lock. That is, one must obtain this lock first before
+creating any of the other locks.
+</p>
+<p>To obtain a readlock, first create the ‘<tt>#cvs.lock</tt>’
+directory. This operation must be atomic (which should
+be true for creating a directory under most operating
+systems). If it fails because the directory already
+existed, wait for a while and try again. After
+obtaining the ‘<tt>#cvs.lock</tt>’ lock, create a file
+whose name is ‘<tt>#cvs.rfl.</tt>’ followed by information
+of your choice (for example, hostname and process
+identification number). Then remove the
+‘<tt>#cvs.lock</tt>’ directory to release the master lock.
+Then proceed with reading the repository. When you are
+done, remove the ‘<tt>#cvs.rfl</tt>’ file to release the
+read lock.
+</p>
+<p>To obtain a writelock, first create the
+‘<tt>#cvs.lock</tt>’ directory, as with a readlock. Then
+check that there are no files whose names start with
+‘<tt>#cvs.rfl.</tt>’. If there are, remove
+‘<tt>#cvs.lock</tt>’, wait for a while, and try again. If
+there are no readers, then create a file whose name is
+‘<tt>#cvs.wfl</tt>’ followed by information of your choice
+(for example, hostname and process identification
+number). Hang on to the ‘<tt>#cvs.lock</tt>’ lock. Proceed
+with writing the repository. When you are done, first
+remove the ‘<tt>#cvs.wfl</tt>’ file and then the
+‘<tt>#cvs.lock</tt>’ directory. Note that unlike the
+‘<tt>#cvs.rfl</tt>’ file, the ‘<tt>#cvs.wfl</tt>’ file
is just
+informational; it has no effect on the locking operation
+beyond what is provided by holding on to the
+‘<tt>#cvs.lock</tt>’ lock itself.
+</p>
+<p>Note that each lock (writelock or readlock) only locks
+a single directory in the repository, including
+‘<tt>Attic</tt>’ and ‘<tt>CVS</tt>’ but not including
+subdirectories which represent other directories under
+version control. To lock an entire tree, you need to
+lock each directory (note that if you fail to obtain
+any lock you need, you must release the whole tree
+before waiting and trying again, to avoid deadlocks).
+</p>
+<p>Note also that <small>CVS</small> expects writelocks to control
+access to individual ‘<tt>foo,v</tt>’ files. <small>RCS</small>
has
+a scheme where the ‘<tt>,foo,</tt>’ file serves as a lock,
+but <small>CVS</small> does not implement it and so taking out a
+<small>CVS</small> writelock is recommended. See the comments at
+rcs_internal_lockfile in the <small>CVS</small> source code for
+further discussion/rationale.
+</p>
+<hr size="6">
+<div id="CVSROOT-storage"></div>
+<div id="SEC18"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC17| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC19| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC9| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC11| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC38| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+==== How files are stored in the CVSROOT directory ====
+
+<p>The ‘<tt>$CVSROOT/CVSROOT</tt>’ directory contains the
+various administrative files. In some ways this
+directory is just like any other directory in the
+repository; it contains <small>RCS</small> files whose names end
+in ‘<samp>,v</samp>’, and many of the <small>CVS</small> commands
operate
+on it the same way. However, there are a few
+differences.
+</p>
+<p>For each administrative file, in addition to the
+<small>RCS</small> file, there is also a checked out copy of the
+file. For example, there is an <small>RCS</small> file
+‘<tt>loginfo,v</tt>’ and a file ‘<tt>loginfo</tt>’
which
+contains the latest revision contained in
+‘<tt>loginfo,v</tt>’. When you check in an administrative
+file, <small>CVS</small> should print
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>cvs commit:
Rebuilding administrative file database
+</nowiki></pre></td></tr></table>
+
+<p>and update the checked out copy in
+‘<tt>$CVSROOT/CVSROOT</tt>’. If it does not, there is
+something wrong (see section [[#SEC188|Dealing with bugs in CVS or this
manual]]). To add your own files
+to the files to be updated in this fashion, you can add
+them to the ‘<tt>checkoutlist</tt>’ administrative file
+(see section [[#SEC177|The checkoutlist file]]).
+</p>
+<div id="IDX30"></div>
+<div id="IDX31"></div>
+<div id="IDX32"></div>
+<p>By default, the ‘<tt>modules</tt>’ file behaves as
+described above. If the modules file is very large,
+storing it as a flat text file may make looking up
+modules slow (I’m not sure whether this is as much of a
+concern now as when <small>CVS</small> first evolved this
+feature; I haven’t seen benchmarks). Therefore, by
+making appropriate edits to the <small>CVS</small> source code
+one can store the modules file in a database which
+implements the <code>ndbm</code> interface, such as Berkeley
+db or GDBM. If this option is in use, then the modules
+database will be stored in the files ‘<tt>modules.db</tt>’,
+‘<tt>modules.pag</tt>’, and/or ‘<tt>modules.dir</tt>’.
+</p>
+<p>For information on the meaning of the various
+administrative files, see [[#SEC157|Reference manual for Administrative
files]].
+</p>
+<hr size="6">
+<div id="Working-directory-storage"></div>
+<div id="SEC19"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC18| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC20| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC9| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC9| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC38| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== How data is stored in the working directory ===
+
+
+<p>While we are discussing <small>CVS</small> internals which may
+become visible from time to time, we might as well talk
+about what <small>CVS</small> puts in the ‘<tt>CVS</tt>’
directories
+in the working directories. As with the repository,
+<small>CVS</small> handles this information and one can usually
+access it via <small>CVS</small> commands. But in some cases it
+may be useful to look at it, and other programs, such
+as the <code>jCVS</code> graphical user interface or the
+<code>VC</code> package for emacs, may need to look at it.
+Such programs should follow the recommendations in this
+section if they hope to be able to work with other
+programs which use those files, including future
+versions of the programs just mentioned and the
+command-line <small>CVS</small> client.
+</p>
+<p>The ‘<tt>CVS</tt>’ directory contains several files.
+Programs which are reading this directory should
+silently ignore files which are in the directory but
+which are not documented here, to allow for future
+expansion.
+</p>
+<p>The files are stored according to the text file
+convention for the system in question. This means that
+working directories are not portable between systems
+with differing conventions for storing text files.
+This is intentional, on the theory that the files being
+managed by <small>CVS</small> probably will not be portable between
+such systems either.
+</p>
+<dl compact="compact">
+<dt> ‘<tt>Root</tt>’</dt>
+<dd><p>This file contains the current <small>CVS</small> root, as
+described in [[#SEC10|Telling CVS where your repository is]].
+</p>
+<div id="IDX33"></div>
+<div id="IDX34"></div>
+</dd>
+<dt> ‘<tt>Repository</tt>’</dt>
+<dd><p>This file contains the directory within the repository
+which the current directory corresponds with. It can
+be either an absolute pathname or a relative pathname;
+<small>CVS</small> has had the ability to read either format
+since at least version 1.3 or so. The relative
+pathname is relative to the root, and is the more
+sensible approach, but the absolute pathname is quite
+common and implementations should accept either. For
+example, after the command
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>cvs -d
:local:/usr/local/cvsroot checkout yoyodyne/tc
+</nowiki></pre></td></tr></table>
+
+<p>‘<tt>Root</tt>’ will contain
+</p>
+<table><tr><td> </td><td><pre
class="example"><nowiki>:local:/usr/local/cvsroot
+</nowiki></pre></td></tr></table>
+
+<p>and ‘<tt>Repository</tt>’ will contain either
+</p>
+<table><tr><td> </td><td><pre
class="example"><nowiki>/usr/local/cvsroot/yoyodyne/tc
+</nowiki></pre></td></tr></table>
+
+<p>or
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>yoyodyne/tc
+</nowiki></pre></td></tr></table>
+
+<p>If the particular working directory does not correspond
+to a directory in the repository, then ‘<tt>Repository</tt>’
+should contain ‘<tt>CVSROOT/Emptydir</tt>’.
+<div id="IDX35"></div>
+<div id="IDX36"></div>
+</p>
+<div id="IDX37"></div>
+<div id="IDX38"></div>
+</dd>
+<dt> ‘<tt>Entries</tt>’</dt>
+<dd><p>This file lists the files and directories in the
+working directory.
+The first character of each line indicates what sort of
+line it is. If the character is unrecognized, programs
+reading the file should silently skip that line, to
+allow for future expansion.
+</p>
+<p>If the first character is ‘<samp>/</samp>’, then the format is:
+</p>
+<table><tr><td> </td><td><pre
class="example"><nowiki>/<var>name</var>/<var>revision</var>/<var>timestamp</var>[+<var>conflict</var>]/<var>options</var>/<var>tagdate</var>
+</nowiki></pre></td></tr></table>
+
+<p>where ‘<samp>[</samp>’ and ‘<samp>]</samp>’ are not
part of the entry,
+but instead indicate that the ‘<samp>+</samp>’ and conflict
+marker are optional. <var>name</var> is the name of the
+file within the directory. <var>revision</var> is the
+revision that the file in the working derives from, or
+‘<samp>0</samp>’ for an added file, or
‘<samp>-</samp>’ followed by a
+revision for a removed file. <var>timestamp</var> is the
+timestamp of the file at the time that <small>CVS</small> created
+it; if the timestamp differs with the actual
+modification time of the file it means the file has
+been modified. It is stored in
+the format used by the ISO C asctime() function (for
+example, ‘<samp>Sun Apr 7 01:29:26 1996</samp>’). One may
+write a string which is not in that format, for
+example, ‘<samp>Result of merge</samp>’, to indicate that the
+file should always be considered to be modified. This
+is not a special case; to see whether a file is
+modified a program should take the timestamp of the file
+and simply do a string compare with <var>timestamp</var>.
+If there was a conflict, <var>conflict</var> can be set to
+the modification time of the file after the file has been
+written with conflict markers (see section [[#SEC86|Conflicts example]]).
+Thus if <var>conflict</var> is subsequently the same as the actual
+modification time of the file it means that the user
+has obviously not resolved the conflict. <var>options</var>
+contains sticky options (for example ‘<samp>-kb</samp>’ for a
+binary file). <var>tagdate</var> contains ‘<samp>T</samp>’
followed
+by a tag name, or ‘<samp>D</samp>’ for a date, followed by a
+sticky tag or date. Note that if <var>timestamp</var>
+contains a pair of timestamps separated by a space,
+rather than a single timestamp, you are dealing with a
+version of <small>CVS</small> earlier than <small>CVS</small> 1.5 (not
+documented here).
+</p>
+<p>The timezone on the timestamp in CVS/Entries (local or
+universal) should be the same as the operating system
+stores for the timestamp of the file itself. For
+example, on Unix the file’s timestamp is in universal
+time (UT), so the timestamp in CVS/Entries should be
+too. On <small>VMS</small>, the file’s timestamp is in local
+time, so <small>CVS</small> on <small>VMS</small> should use local time.
+This rule is so that files do not appear to be modified
+merely because the timezone changed (for example, to or
+from summer time).
+</p>
+<p>If the first character of a line in ‘<tt>Entries</tt>’ is
+‘<samp>D</samp>’, then it indicates a subdirectory.
‘<samp>D</samp>’
+on a line all by itself indicates that the program
+which wrote the ‘<tt>Entries</tt>’ file does record
+subdirectories (therefore, if there is such a line and
+no other lines beginning with ‘<samp>D</samp>’, one knows there
+are no subdirectories). Otherwise, the line looks
+like:
+</p>
+<table><tr><td> </td><td><pre
class="example"><nowiki>D/<var>name</var>/<var>filler1</var>/<var>filler2</var>/<var>filler3</var>/<var>filler4</var>
+</nowiki></pre></td></tr></table>
+
+<p>where <var>name</var> is the name of the subdirectory, and
+all the <var>filler</var> fields should be silently ignored,
+for future expansion. Programs which modify
+<code>Entries</code> files should preserve these fields.
+</p>
+<p>The lines in the ‘<tt>Entries</tt>’ file can be in any order.
+</p>
+<div id="IDX39"></div>
+<div id="IDX40"></div>
+</dd>
+<dt> ‘<tt>Entries.Log</tt>’</dt>
+<dd><p>This file does not record any information beyond that
+in ‘<tt>Entries</tt>’, but it does provide a way to update
+the information without having to rewrite the entire
+‘<tt>Entries</tt>’ file, including the ability to preserve
+the information even if the program writing
+‘<tt>Entries</tt>’ and ‘<tt>Entries.Log</tt>’ abruptly
aborts.
+Programs which are reading the ‘<tt>Entries</tt>’ file
+should also check for ‘<tt>Entries.Log</tt>’. If the latter
+exists, they should read ‘<tt>Entries</tt>’ and then apply
+the changes mentioned in ‘<tt>Entries.Log</tt>’. After
+applying the changes, the recommended practice is to
+rewrite ‘<tt>Entries</tt>’ and then delete
‘<tt>Entries.Log</tt>’.
+The format of a line in ‘<tt>Entries.Log</tt>’ is a single
+character command followed by a space followed by a
+line in the format specified for a line in
+‘<tt>Entries</tt>’. The single character command is
+‘<samp>A</samp>’ to indicate that the entry is being added,
+‘<samp>R</samp>’ to indicate that the entry is being removed,
+or any other character to indicate that the entire line
+in ‘<tt>Entries.Log</tt>’ should be silently ignored (for
+future expansion). If the second character of the line
+in ‘<tt>Entries.Log</tt>’ is not a space, then it was
+written by an older version of <small>CVS</small> (not documented
+here).
+</p>
+<p>Programs which are writing rather than reading can
+safely ignore ‘<tt>Entries.Log</tt>’ if they so choose.
+</p>
+<div id="IDX41"></div>
+<div id="IDX42"></div>
+</dd>
+<dt> ‘<tt>Entries.Backup</tt>’</dt>
+<dd><p>This is a temporary file. Recommended usage is to
+write a new entries file to ‘<tt>Entries.Backup</tt>’, and
+then to rename it (atomically, where possible) to
‘<tt>Entries</tt>’.
+</p>
+<div id="IDX43"></div>
+<div id="IDX44"></div>
+</dd>
+<dt> ‘<tt>Entries.Static</tt>’</dt>
+<dd><p>The only relevant thing about this file is whether it
+exists or not. If it exists, then it means that only
+part of a directory was gotten and <small>CVS</small> will
+not create additional files in that directory. To
+clear it, use the <code>update</code> command with the
+‘<samp>-d</samp>’ option, which will get the additional files
+and remove ‘<tt>Entries.Static</tt>’.
+</p>
+<div id="IDX45"></div>
+<div id="IDX46"></div>
+<div id="IDX47"></div>
+<div id="IDX48"></div>
+</dd>
+<dt> ‘<tt>Tag</tt>’</dt>
+<dd><p>This file contains per-directory sticky tags or dates.
+The first character is ‘<samp>T</samp>’ for a branch tag,
+‘<samp>N</samp>’ for a non-branch tag, or
‘<samp>D</samp>’ for a date,
+or another character to mean the file should be
+silently ignored, for future expansion. This character
+is followed by the tag or date. Note that
+per-directory sticky tags or dates are used for things
+like applying to files which are newly added; they
+might not be the same as the sticky tags or dates on
+individual files. For general information on sticky
+tags and dates, see [[#SEC53|Sticky tags]].
+</p>
+<div id="IDX49"></div>
+<div id="IDX50"></div>
+</dd>
+<dt> ‘<tt>Notify</tt>’</dt>
+<dd><p>This file stores notifications (for example, for
+<code>edit</code> or <code>unedit</code>) which have not yet been
+sent to the server. Its format is not yet documented
+here.
+</p>
+<div id="IDX51"></div>
+<div id="IDX52"></div>
+</dd>
+<dt> ‘<tt>Notify.tmp</tt>’</dt>
+<dd><p>This file is to ‘<tt>Notify</tt>’ as
‘<tt>Entries.Backup</tt>’
+is to ‘<tt>Entries</tt>’. That is, to write
‘<tt>Notify</tt>’,
+first write the new contents to ‘<tt>Notify.tmp</tt>’ and
+then (atomically where possible), rename it to
+‘<tt>Notify</tt>’.
+</p>
+<div id="IDX53"></div>
+<div id="IDX54"></div>
+</dd>
+<dt> ‘<tt>Base</tt>’</dt>
+<dd><p>If watches are in use, then an <code>edit</code> command
+stores the original copy of the file in the ‘<tt>Base</tt>’
+directory. This allows the <code>unedit</code> command to
+operate even if it is unable to communicate with the
+server.
+</p>
+<div id="IDX55"></div>
+<div id="IDX56"></div>
+</dd>
+<dt> ‘<tt>Baserev</tt>’</dt>
+<dd><p>The file lists the revision for each of the files in
+the ‘<tt>Base</tt>’ directory. The format is:
+</p>
+<table><tr><td> </td><td><pre
class="example"><nowiki>B<var>name</var>/<var>rev</var>/<var>expansion</var>
+</nowiki></pre></td></tr></table>
+
+<p>where <var>expansion</var> should be ignored, to allow for
+future expansion.
+</p>
+<div id="IDX57"></div>
+<div id="IDX58"></div>
+</dd>
+<dt> ‘<tt>Baserev.tmp</tt>’</dt>
+<dd><p>This file is to ‘<tt>Baserev</tt>’ as
‘<tt>Entries.Backup</tt>’
+is to ‘<tt>Entries</tt>’. That is, to write
‘<tt>Baserev</tt>’,
+first write the new contents to ‘<tt>Baserev.tmp</tt>’ and
+then (atomically where possible), rename it to
+‘<tt>Baserev</tt>’.
+</p>
+<div id="IDX59"></div>
+<div id="IDX60"></div>
+</dd>
+<dt> ‘<tt>Template</tt>’</dt>
+<dd><p>This file contains the template specified by the
+‘<tt>rcsinfo</tt>’ file (see section [[#SEC175|Rcsinfo]]). It is
only used
+by the client; the non-client/server <small>CVS</small> consults
+‘<tt>rcsinfo</tt>’ directly.
+</p></dd>
+</dl>
+
+<hr size="6">
+<div id="Intro-administrative-files"></div>
+<div id="SEC20"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC19| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC21| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC9| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC9| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC38| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== The administrative files ===
+
+
+<p>The directory ‘<tt>$CVSROOT/CVSROOT</tt>’ contains some
<em>administrative
+files</em>. See section [[#SEC157|Reference manual for Administrative
files]], for a complete description.
+You can use <small>CVS</small> without any of these files, but
+some commands work better when at least the
+‘<tt>modules</tt>’ file is properly set up.
+</p>
+<p>The most important of these files is the ‘<tt>modules</tt>’
+file. It defines all modules in the repository. This
+is a sample ‘<tt>modules</tt>’ file.
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>CVSROOT
CVSROOT
+modules CVSROOT modules
+cvs gnu/cvs
+rcs gnu/rcs
+diff gnu/diff
+tc yoyodyne/tc
+</nowiki></pre></td></tr></table>
+
+<p>The ‘<tt>modules</tt>’ file is line oriented. In its
+simplest form each line contains the name of the
+module, whitespace, and the directory where the module
+resides. The directory is a path relative to
+<code>$CVSROOT</code>. The last four lines in the example
+above are examples of such lines.
+</p>
+
+<p>The line that defines the module called ‘<samp>modules</samp>’
+uses features that are not explained here.
+See section [[#SEC158|The modules file]], for a full explanation of all the
+available features.
+</p>
+<hr size="6">
+<div id="SEC21"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC20| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC22| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC9| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC20| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC38| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+==== Editing administrative files ====
+
+<p>You edit the administrative files in the same way that you would edit
+any other module. Use ‘<samp>cvs checkout CVSROOT</samp>’ to get
a working
+copy, edit it, and commit your changes in the normal way.
+</p>
+<p>It is possible to commit an erroneous administrative
+file. You can often fix the error and check in a new
+revision, but sometimes a particularly bad error in the
+administrative file makes it impossible to commit new
+revisions.
+</p>
+<hr size="6">
+<div id="Multiple-repositories"></div>
+<div id="SEC22"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC21| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC23| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC9| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC9| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC38| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== Multiple repositories ===
+
+<p>In some situations it is a good idea to have more than
+one repository, for instance if you have two
+development groups that work on separate projects
+without sharing any code. All you have to do to have
+several repositories is to specify the appropriate
+repository, using the <code>CVSROOT</code> environment
+variable, the ‘<samp>-d</samp>’ option to <small>CVS</small>, or
(once
+you have checked out a working directory) by simply
+allowing <small>CVS</small> to use the repository that was used
+to check out the working directory
+(see section [[#SEC10|Telling CVS where your repository is]]).
+</p>
+<p>The big advantage of having multiple repositories is
+that they can reside on different servers. With <small>CVS</small>
+version 1.10, a single command cannot recurse into
+directories from different repositories. With development
+versions of <small>CVS</small>, you can check out code from multiple
+servers into your working directory. <small>CVS</small> will
+recurse and handle all the details of making
+connections to as many server machines as necessary to
+perform the requested command. Here is an example of
+how to set up a working directory:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>cvs -d server1:/cvs
co dir1
+cd dir1
+cvs -d server2:/root co sdir
+cvs update
+</nowiki></pre></td></tr></table>
+
+<p>The <code>cvs co</code> commands set up the working
+directory, and then the <code>cvs update</code> command will
+contact server2, to update the dir1/sdir subdirectory,
+and server1, to update everything else.
+</p>
+
+<hr size="6">
+<div id="Creating-a-repository"></div>
+<div id="SEC23"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC22| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC24| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC9| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC9| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC38| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== Creating a repository ===
+
+
+<p>To set up a <small>CVS</small> repository, first choose the
+machine and disk on which you want to store the
+revision history of the source files. CPU and memory
+requirements are modest, so most machines should be
+adequate. For details see [[#SEC27|Server requirements]].
+</p>
+<p>To estimate disk space
+requirements, if you are importing RCS files from
+another system, the size of those files is the
+approximate initial size of your repository, or if you
+are starting without any version history, a rule of
+thumb is to allow for the server approximately three
+times the size of the code to be under <small>CVS</small> for the
+repository (you will eventually outgrow this, but not
+for a while). On the machines on which the developers
+will be working, you’ll want disk space for
+approximately one working directory for each developer
+(either the entire tree or a portion of it, depending
+on what each developer uses).
+</p>
+<p>The repository should be accessible
+(directly or via a networked file system) from all
+machines which want to use <small>CVS</small> in server or local
+mode; the client machines need not have any access to
+it other than via the <small>CVS</small> protocol. It is not
+possible to use <small>CVS</small> to read from a repository
+which one only has read access to; <small>CVS</small> needs to be
+able to create lock files (see section [[#SEC88|Several developers
simultaneously attempting to run CVS]]).
+</p>
+<div id="IDX61"></div>
+<p>To create a repository, run the <code>cvs init</code>
+command. It will set up an empty repository in the
+<small>CVS</small> root specified in the usual way
+(see section [[#SEC9|The Repository]]). For example,
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>cvs -d
/usr/local/cvsroot init
+</nowiki></pre></td></tr></table>
+
+<p><code>cvs init</code> is careful to never overwrite any
+existing files in the repository, so no harm is done if
+you run <code>cvs init</code> on an already set-up
+repository.
+</p>
+<p><code>cvs init</code> will enable history logging; if you
+don’t want that, remove the history file after running
+<code>cvs init</code>. See section [[#SEC178|The history file]].
+</p>
+<hr size="6">
+<div id="Backing-up"></div>
+<div id="SEC24"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC23| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC25| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC9| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC9| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC38| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== Backing up a repository ===
+
+<p>There is nothing particularly magical about the files
+in the repository; for the most part it is possible to
+back them up just like any other files. However, there
+are a few issues to consider.
+</p>
+<div id="IDX62"></div>
+<div id="IDX63"></div>
+<p>The first is that to be paranoid, one should either not
+use <small>CVS</small> during the backup, or have the backup
+program lock <small>CVS</small> while doing the backup. To not
+use <small>CVS</small>, you might forbid logins to machines which
+can access the repository, turn off your <small>CVS</small>
+server, or similar mechanisms. The details would
+depend on your operating system and how you have
+<small>CVS</small> set up. To lock <small>CVS</small>, you would create
+‘<tt>#cvs.rfl</tt>’ locks in each repository directory.
+See [[#SEC88|Several developers simultaneously attempting to run CVS]], for
more on <small>CVS</small> locks.
+Having said all this, if you just back up without any
+of these precautions, the results are unlikely to be
+particularly dire. Restoring from backup, the
+repository might be in an inconsistent state, but this
+would not be particularly hard to fix manually.
+</p>
+<p>When you restore a repository from backup, assuming
+that changes in the repository were made after the time
+of the backup, working directories which were not
+affected by the failure may refer to revisions which no
+longer exist in the repository. Trying to run <small>CVS</small>
+in such directories will typically produce an error
+message. One way to get those changes back into the
+repository is as follows:
+</p>
+<ul>
+<li>
+Get a new working directory.
+
+</li><li>
+Copy the files from the working directory from before
+the failure over to the new working directory (do not
+copy the contents of the ‘<tt>CVS</tt>’ directories, of
+course).
+
+</li><li>
+Working in the new working directory, use commands such
+as <code>cvs update</code> and <code>cvs diff</code> to figure out
+what has changed, and then when you are ready, commit
+the changes into the repository.
+</li></ul>
+
+<hr size="6">
+<div id="Moving-a-repository"></div>
+<div id="SEC25"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC24| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC26| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC9| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC9| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC38| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== Moving a repository ===
+
+<p>Just as backing up the files in the repository is
+pretty much like backing up any other files, if you
+need to move a repository from one place to another it
+is also pretty much like just moving any other
+collection of files.
+</p>
+<p>The main thing to consider is that working directories
+point to the repository. The simplest way to deal with
+a moved repository is to just get a fresh working
+directory after the move. Of course, you’ll want to
+make sure that the old working directory had been
+checked in before the move, or you figured out some
+other way to make sure that you don’t lose any
+changes. If you really do want to reuse the existing
+working directory, it should be possible with manual
+surgery on the ‘<tt>CVS/Repository</tt>’ files. You can
+see [[#SEC19|How data is stored in the working directory]], for information on
+the ‘<tt>CVS/Repository</tt>’ and ‘<tt>CVS/Root</tt>’
files, but
+unless you are sure you want to bother, it probably
+isn’t worth it.
+</p>
+<hr size="6">
+<div id="Remote-repositories"></div>
+<div id="SEC26"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC25| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC27| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC9| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC9| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC38| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== Remote repositories ===
+
+<p> Your working copy of the sources can be on a
+different machine than the repository. Using <small>CVS</small>
+in this manner is known as <em>client/server</em>
+operation. You run <small>CVS</small> on a machine which can
+mount your working directory, known as the
+<em>client</em>, and tell it to communicate to a machine
+which can mount the repository, known as the
+<em>server</em>. Generally, using a remote
+repository is just like using a local one, except that
+the format of the repository name is:
+</p>
+<table><tr><td> </td><td><pre
class="example"><nowiki>[:<var>method</var>:][[<var>user</var>][:<var>password</var>address@hidden<var>hostname</var>[:[<var>port</var>]]/path/to/repository
+</nowiki></pre></td></tr></table>
+
+<p>Specifying a password in the repository name is not recommended during
+checkout, since this will cause <small>CVS</small> to store a cleartext copy
of the
+password in each created directory. <code>cvs login</code> first instead
+(see section [[#SEC31|Using the client with password authentication]]).
+</p>
+<p>The details of exactly what needs to be set up depend
+on how you are connecting to the server.
+</p>
+<p>If <var>method</var> is not specified, and the repository
+name contains ‘<samp>:</samp>’, then the default is
<code>ext</code>
+or <code>server</code>, depending on your platform; both are
+described in [[#SEC28|Connecting with rsh]].
+</p>
+<pre class="menu-preformatted"><nowiki></nowiki>•[[#SEC27| Server
requirements]]::<nowiki> Memory and other resources for servers
+</nowiki>•[[#SEC28| Connecting via rsh]]::<nowiki> Using the
<code>rsh</code> program to connect
+</nowiki>•[[#SEC29| Password authenticated]]::<nowiki> Direct
connections using passwords
+</nowiki>•[[#SEC33| GSSAPI authenticated]]::<nowiki> Direct
connections using GSSAPI
+</nowiki>•[[#SEC34| Kerberos authenticated]]::<nowiki> Direct
connections with kerberos
+</nowiki>•[[#SEC35| Connecting via fork]]::<nowiki> Using a
forked <code>cvs server</code> to connect
+</nowiki></pre>
+<hr size="6">
+<div id="Server-requirements"></div>
+<div id="SEC27"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC26| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC28| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC9| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC26| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC38| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+==== Server requirements ====
+
+<p>The quick answer to what sort of machine is suitable as
+a server is that requirements are modest—a server
+with 32M of memory or even less can handle a fairly
+large source tree with a fair amount of activity.
+</p>
+<p>The real answer, of course, is more complicated.
+Estimating the known areas of large memory consumption
+should be sufficient to estimate memory requirements.
+There are two such areas documented here; other memory
+consumption should be small by comparison (if you find
+that is not the case, let us know, as described in
+[[#SEC188|Dealing with bugs in CVS or this manual]], so we can update this
documentation).
+</p>
+<p>The first area of big memory consumption is large
+checkouts, when using the <small>CVS</small> server. The server
+consists of two processes for each client that it is
+serving. Memory consumption on the child process
+should remain fairly small. Memory consumption on the
+parent process, particularly if the network connection
+to the client is slow, can be expected to grow to
+slightly more than the size of the sources in a single
+directory, or two megabytes, whichever is larger.
+</p>
+<p>Multiplying the size of each <small>CVS</small> server by the
+number of servers which you expect to have active at
+one time should give an idea of memory requirements for
+the server. For the most part, the memory consumed by
+the parent process probably can be swap space rather
+than physical memory.
+</p>
+
+<p>The second area of large memory consumption is
+<code>diff</code>, when checking in large files. This is
+required even for binary files. The rule of thumb is
+to allow about ten times the size of the largest file
+you will want to check in, although five times may be
+adequate. For example, if you want to check in a file
+which is 10 megabytes, you should have 100 megabytes of
+memory on the machine doing the checkin (the server
+machine for client/server, or the machine running
+<small>CVS</small> for non-client/server). This can be swap
+space rather than physical memory. Because the memory
+is only required briefly, there is no particular need
+to allow memory for more than one such checkin at a
+time.
+</p>
+<p>Resource consumption for the client is even more
+modest—any machine with enough capacity to run the
+operating system in question should have little
+trouble.
+</p>
+<p>For information on disk space requirements, see
+[[#SEC23|Creating a repository]].
+</p>
+<hr size="6">
+<div id="Connecting-via-rsh"></div>
+<div id="SEC28"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC27| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC29| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC9| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC26| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC38| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+==== Connecting with rsh ====
+
+<p><small>CVS</small> uses the ‘<samp>rsh</samp>’ protocol to
perform these
+operations, so the remote user host needs to have a
+‘<tt>.rhosts</tt>’ file which grants access to the local
+user. Note that the program that <small>CVS</small> uses for this
+purpose may be specified using the ‘<tt>--with-rsh</tt>’
+flag to configure.
+</p>
+<p>For example, suppose you are the user ‘<samp>mozart</samp>’ on
+the local machine ‘<samp>toe.example.com</samp>’, and the
+server machine is ‘<samp>faun.example.org</samp>’. On
+faun, put the following line into the file
+‘<tt>.rhosts</tt>’ in ‘<samp>bach</samp>’’s home
directory:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>toe.example.com
mozart
+</nowiki></pre></td></tr></table>
+
+<p>Then test that ‘<samp>rsh</samp>’ is working with
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>rsh -l bach
faun.example.org 'echo $PATH'
+</nowiki></pre></td></tr></table>
+
+<div id="IDX64"></div>
+<p>Next you have to make sure that <code>rsh</code> will be able
+to find the server. Make sure that the path which
+<code>rsh</code> printed in the above example includes the
+directory containing a program named <code>cvs</code> which
+is the server. You need to set the path in
+‘<tt>.bashrc</tt>’, ‘<tt>.cshrc</tt>’, etc., not
‘<tt>.login</tt>’
+or ‘<tt>.profile</tt>’. Alternately, you can set the
+environment variable <code>CVS_SERVER</code> on the client
+machine to the filename of the server you want to use,
+for example ‘<tt>/usr/local/bin/cvs-1.6</tt>’.
+</p>
+<p>There is no need to edit ‘<tt>inetd.conf</tt>’ or start a
+<small>CVS</small> server daemon.
+</p>
+<div id="IDX65"></div>
+<div id="IDX66"></div>
+<div id="IDX67"></div>
+<div id="IDX68"></div>
+<div id="IDX69"></div>
+<p>There are two access methods that you use in <code>CVSROOT</code>
+for rsh. <code>:server:</code> specifies an internal rsh
+client, which is supported only by some <small>CVS</small> ports.
+<code>:ext:</code> specifies an external rsh program. By
+default this is <code>rsh</code> (unless otherwise specified
+by the ‘<tt>--with-rsh</tt>’ flag to configure) but you may set the
+<code>CVS_RSH</code> environment variable to invoke another
+program which can access the remote server (for
+example, <code>remsh</code> on HP-UX 9 because <code>rsh</code> is
+something different). It must be a program which can
+transmit data to and from the server without modifying
+it; for example the Windows NT <code>rsh</code> is not
+suitable since it by default translates between CRLF
+and LF. The OS/2 <small>CVS</small> port has a hack to pass
‘<samp>-b</samp>’
+to <code>rsh</code> to get around this, but since this could
+potentially cause problems for programs other than the
+standard <code>rsh</code>, it may change in the future. If
+you set <code>CVS_RSH</code> to <code>SSH</code> or some other rsh
+replacement, the instructions in the rest of this
+section concerning ‘<tt>.rhosts</tt>’ and so on are likely
+to be inapplicable; consult the documentation for your rsh
+replacement.
+</p>
+<p>Continuing our example, supposing you want to access
+the module ‘<tt>foo</tt>’ in the repository
+‘<tt>/usr/local/cvsroot/</tt>’, on machine
+‘<tt>faun.example.org</tt>’, you are ready to go:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>cvs -d
:ext:address@hidden:/usr/local/cvsroot checkout foo
+</nowiki></pre></td></tr></table>
+
+<p>(The ‘<tt>bach@</tt>’ can be omitted if the username is
+the same on both the local and remote hosts.)
+</p>
+
+<hr size="6">
+<div id="Password-authenticated"></div>
+<div id="SEC29"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC28| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC30| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC9| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC26| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC38| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+==== Direct connection with password authentication ====
+
+<p>The <small>CVS</small> client can also connect to the server
+using a password protocol. This is particularly useful
+if using <code>rsh</code> is not feasible (for example,
+the server is behind a firewall), and Kerberos also is
+not available.
+</p>
+<p> To use this method, it is necessary to make
+some adjustments on both the server and client sides.
+</p>
+<pre class="menu-preformatted"><nowiki></nowiki>•[[#SEC30| Password
authentication server]]::<nowiki> Setting up the server
+</nowiki>•[[#SEC31| Password authentication client]]::<nowiki> Using
the client
+</nowiki>•[[#SEC32| Password authentication security]]::<nowiki> What
this method does and does not do
+</nowiki></pre>
+<hr size="6">
+<div id="Password-authentication-server"></div>
+<div id="SEC30"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC29| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC31| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC9| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC29| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC38| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+===== Setting up the server for password authentication =====
+
+<p>First of all, you probably want to tighten the
+permissions on the ‘<tt>$CVSROOT</tt>’ and
+‘<tt>$CVSROOT/CVSROOT</tt>’ directories. See [[#SEC32|Security
considerations with password authentication]], for more details.
+</p>
+<div id="IDX70"></div>
+<div id="IDX71"></div>
+<div id="IDX72"></div>
+<div id="IDX73"></div>
+<div id="IDX74"></div>
+<div id="IDX75"></div>
+<div id="IDX76"></div>
+<div id="IDX77"></div>
+<div id="IDX78"></div>
+<div id="IDX79"></div>
+<div id="IDX80"></div>
+<div id="IDX81"></div>
+<p>On the server side, the file ‘<tt>/etc/inetd.conf</tt>’
+needs to be edited so <code>inetd</code> knows to run the
+command <code>cvs pserver</code> when it receives a
+connection on the right port. By default, the port
+number is 2401; it would be different if your client
+were compiled with <code>CVS_AUTH_PORT</code> defined to
+something else, though. This can also be specified in the CVSROOT variable
+(see section [[#SEC26|Remote repositories]]) or overridden with the
CVS_CLIENT_PORT
+environment variable (see section [[#SEC181|All environment variables which
affect CVS]]).
+</p>
+<p> If your <code>inetd</code> allows raw port numbers in
+‘<tt>/etc/inetd.conf</tt>’, then the following (all on a
+single line in ‘<tt>inetd.conf</tt>’) should be sufficient:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>2401 stream tcp
nowait root /usr/local/bin/cvs
+cvs -f --allow-root=/usr/cvsroot pserver
+</nowiki></pre></td></tr></table>
+
+<p>(You could also use the
+‘<samp>-T</samp>’ option to specify a temporary directory.)
+</p>
+<p>The ‘<samp>--allow-root</samp>’ option specifies the allowable
+<small>CVSROOT</small> directory. Clients which attempt to use a
+different <small>CVSROOT</small> directory will not be allowed to
+connect. If there is more than one <small>CVSROOT</small>
+directory which you want to allow, repeat the option.
+(Unfortunately, many versions of <code>inetd</code> have very small
+limits on the number of arguments and/or the total length
+of the command. The usual solution to this problem is
+to have <code>inetd</code> run a shell script which then invokes
+<small>CVS</small> with the necessary arguments.)
+</p>
+<p> If your <code>inetd</code> wants a symbolic service
+name instead of a raw port number, then put this in
+‘<tt>/etc/services</tt>’:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>cvspserver
2401/tcp
+</nowiki></pre></td></tr></table>
+
+<p>and put <code>cvspserver</code> instead of <code>2401</code> in
‘<tt>inetd.conf</tt>’.
+</p>
+<p>If your system uses <code>xinetd</code> instead of <code>inetd</code>,
+the procedure is slightly different.
+Create a file called ‘<tt>/etc/xinetd.d/cvspserver</tt>’
containing the following:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>service cvspserver
+{
+ port = 2401
+ socket_type = stream
+ protocol = tcp
+ wait = no
+ user = root
+ passenv = PATH
+ server = /usr/local/bin/cvs
+ server_args = -f --allow-root=/usr/cvsroot pserver
+}
+</nowiki></pre></td></tr></table>
+
+<p>(If <code>cvspserver</code> is defined in
‘<tt>/etc/services</tt>’, you can omit
+the <code>port</code> line.)
+</p>
+<p> Once the above is taken care of, restart your
+<code>inetd</code>, or do whatever is necessary to force it
+to reread its initialization files.
+</p>
+<p>If you are having trouble setting this up, see
+[[#SEC185|Trouble making a connection to a CVS server]].
+</p>
+<div id="IDX82"></div>
+<div id="IDX83"></div>
+<p>Because the client stores and transmits passwords in
+cleartext (almost—see [[#SEC32|Security considerations with password
authentication]], for details), a separate <small>CVS</small> password
+file is generally used, so people don’t compromise
+their regular passwords when they access the
+repository. This file is
+‘<tt>$CVSROOT/CVSROOT/passwd</tt>’ (see section [[#SEC20|The
administrative files]]). It uses a colon-separated
+format, similar to ‘<tt>/etc/passwd</tt>’ on Unix systems,
+except that it has fewer fields: <small>CVS</small> username,
+optional password, and an optional system username for
+<small>CVS</small> to run as if authentication succeeds. Here is
+an example ‘<tt>passwd</tt>’ file with five entries:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>anonymous:
+bach:ULtgRLXo7NRxs
+spwang:1sOp854gDF3DY
+melissa:tGX1fS8sun6rY:pubcvs
+qproj:XR4EZcEs0szik:pubcvs
+</nowiki></pre></td></tr></table>
+
+<p>(The passwords are encrypted according to the standard
+Unix <code>crypt()</code> function, so it is possible to
+paste in passwords directly from regular Unix
+‘<tt>/etc/passwd</tt>’ files.)
+</p>
+<p>The first line in the example will grant access to any
+<small>CVS</small> client attempting to authenticate as user
+<code>anonymous</code>, no matter what password they use,
+including an empty password. (This is typical for
+sites granting anonymous read-only access; for
+information on how to do the "read-only" part, see
+[[#SEC36|Read-only repository access]].)
+</p>
+<p>The second and third lines will grant access to
+<code>bach</code> and <code>spwang</code> if they supply their
+respective plaintext passwords.
+</p>
+<div id="IDX84"></div>
+<p>The fourth line will grant access to <code>melissa</code>, if
+she supplies the correct password, but her <small>CVS</small>
+operations will actually run on the server side under
+the system user <code>pubcvs</code>. Thus, there need not be
+any system user named <code>melissa</code>, but there
+<em>must</em> be one named <code>pubcvs</code>.
+</p>
+<p>The fifth line shows that system user identities can be
+shared: any client who successfully authenticates as
+<code>qproj</code> will actually run as <code>pubcvs</code>, just
+as <code>melissa</code> does. That way you could create a
+single, shared system user for each project in your
+repository, and give each developer their own line in
+the ‘<tt>$CVSROOT/CVSROOT/passwd</tt>’ file. The
<small>CVS</small>
+username on each line would be different, but the
+system username would be the same. The reason to have
+different <small>CVS</small> usernames is that <small>CVS</small> will log
their
+actions under those names: when <code>melissa</code> commits
+a change to a project, the checkin is recorded in the
+project’s history under the name <code>melissa</code>, not
+<code>pubcvs</code>. And the reason to have them share a
+system username is so that you can arrange permissions
+in the relevant area of the repository such that only
+that account has write-permission there.
+</p>
+<p>If the system-user field is present, all
+password-authenticated <small>CVS</small> commands run as that
+user; if no system user is specified, <small>CVS</small> simply
+takes the <small>CVS</small> username as the system username and
+runs commands as that user. In either case, if there
+is no such user on the system, then the <small>CVS</small>
+operation will fail (regardless of whether the client
+supplied a valid password).
+</p>
+<p>The password and system-user fields can both be omitted
+(and if the system-user field is omitted, then also
+omit the colon that would have separated it from the
+encrypted password). For example, this would be a
+valid ‘<tt>$CVSROOT/CVSROOT/passwd</tt>’ file:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>anonymous::pubcvs
+fish:rKa5jzULzmhOo:kfogel
+sussman:1sOp854gDF3DY
+</nowiki></pre></td></tr></table>
+
+<p>When the password field is omitted or empty, then the
+client’s authentication attempt will succeed with any
+password, including the empty string. However, the
+colon after the <small>CVS</small> username is always necessary,
+even if the password is empty.
+</p>
+<p><small>CVS</small> can also fall back to use system authentication.
+When authenticating a password, the server first checks
+for the user in the ‘<tt>$CVSROOT/CVSROOT/passwd</tt>’
+file. If it finds the user, it will use that entry for
+authentication as described above. But if it does not
+find the user, or if the <small>CVS</small> ‘<tt>passwd</tt>’ file
+does not exist, then the server can try to authenticate
+the username and password using the operating system’s
+user-lookup routines (this "fallback" behavior can be
+disabled by setting <code>SystemAuth=no</code> in the
+<small>CVS</small> ‘<tt>config</tt>’ file, see section
[[#SEC180|The CVSROOT/config configuration file]]).
+</p>
+<p>The default fallback behaviour is to look in
+‘<tt>/etc/passwd</tt>’ for this system password unless your
+system has PAM (Pluggable Authentication Modules)
+and your <small>CVS</small> server executable was configured to
+use it at compile time (using <code>./configure --enable-pam</code> - see the
+INSTALL file for more). In this case, PAM will be consulted instead.
+This means that <small>CVS</small> can be configured to use any password
+authentication source PAM can be configured to use (possibilities
+include a simple UNIX password, NIS, LDAP, and others) in its
+global configuration file (usually ‘<tt>/etc/pam.conf</tt>’
+or possibly ‘<tt>/etc/pam.d/cvs</tt>’). See your PAM documentation
+for more details on PAM configuration.
+</p>
+<p>Note that PAM is an experimental feature in <small>CVS</small> and feedback
is
+encouraged. Please send a mail to one of the <small>CVS</small> mailing lists
+(<code>address@hidden</code> or <code>address@hidden</code>) if you use the
+<small>CVS</small> PAM support.
+</p>
+<p><strong>WARNING: Using PAM gives the system administrator much more
+flexibility about how <small>CVS</small> users are authenticated but
+no more security than other methods. See below for more.</strong>
+</p>
+<p>CVS needs an "auth" and "account" module in the
+PAM configuration file. A typical PAM configuration
+would therefore have the following lines
+in ‘<tt>/etc/pam.conf</tt>’ to emulate the standard
<small>CVS</small>
+system ‘<tt>/etc/passwd</tt>’ authentication:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>cvs auth
required pam_unix.so
+cvs account required pam_unix.so
+</nowiki></pre></td></tr></table>
+
+<p>The the equivalent ‘<tt>/etc/pam.d/cvs</tt>’ would contain
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>auth
required pam_unix.so
+account required pam_unix.so
+</nowiki></pre></td></tr></table>
+
+<p>Some systems require a full path to the module so that
+‘<tt>pam_unix.so</tt>’ (Linux) would become something like
+‘<tt>/usr/lib/security/$ISA/pam_unix.so.1</tt>’ (Sun Solaris).
+See the ‘<tt>contrib/pam</tt>’ subdirectory of the
<small>CVS</small>
+source distribution for further example configurations.
+</p>
+<p>The PAM service name given above as "cvs" is just
+the service name in the default configuration amd can be
+set using
+<code>./configure
--with-hardcoded-pam-service-name=<pam-service-name></code>
+before compiling. <small>CVS</small> can also be configured to use whatever
+name it is invoked as as its PAM service name using
+<code>./configure --without-hardcoded-pam-service-name</code>, but this
+feature should not be used if you may not have control of the name
+<small>CVS</small> will be invoked as.
+</p>
+<p>Be aware, also, that falling back to system
+authentication might be a security risk: <small>CVS</small>
+operations would then be authenticated with that user’s
+regular login password, and the password flies across
+the network in plaintext. See [[#SEC32|Security considerations with password
authentication]] for more on this.
+This may be more of a problem with PAM authentication
+because it is likely that the source of the system
+password is some central authentication service like
+LDAP which is also used to authenticate other services.
+</p>
+<p>On the other hand, PAM makes it very easy to change your password
+regularly. If they are given the option of a one-password system for
+all of their activities, users are often more willing to change their
+password on a regular basis.
+</p>
+<p>In the non-PAM configuration where the password is stored in the
+‘<tt>CVSROOT/passwd</tt>’ file, it is difficult to change
passwords on a
+regular basis since only administrative users (or in some cases
+processes that act as an administrative user) are typicaly given
+access to modify this file. Either there needs to be some
+hand-crafted web page or set-uid program to update the file, or the
+update needs to be done by submitting a request to an administrator to
+perform the duty by hand. In the first case, having to remember to
+update a separate password on a periodic basis can be difficult. In
+the second case, the manual nature of the change will typically mean
+that the password will not be changed unless it is absolutely
+necessary.
+</p>
+<p>Note that PAM administrators should probably avoid configuring
+one-time-passwords (OTP) for <small>CVS</small> authentication/authorization.
If
+OTPs are desired, the administrator may wish to encourage the use of
+one of the other Client/Server access methods. See the section on
+see section [[#SEC26|Remote repositories]] for a list of other methods.
+</p>
+<p>Right now, the only way to put a password in the
+<small>CVS</small> ‘<tt>passwd</tt>’ file is to paste it there from
+somewhere else. Someday, there may be a <code>cvs
+passwd</code> command.
+</p>
+<p>Unlike many of the files in ‘<tt>$CVSROOT/CVSROOT</tt>’, it
+is normal to edit the ‘<tt>passwd</tt>’ file in-place,
+rather than via <small>CVS</small>. This is because of the
+possible security risks of having the ‘<tt>passwd</tt>’
+file checked out to people’s working copies. If you do
+want to include the ‘<tt>passwd</tt>’ file in checkouts of
+‘<tt>$CVSROOT/CVSROOT</tt>’, see [[#SEC177|The checkoutlist file]].
+</p>
+
+<hr size="6">
+<div id="Password-authentication-client"></div>
+<div id="SEC31"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC30| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC32| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC9| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC29| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC38| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+===== Using the client with password authentication =====
+<p>To run a <small>CVS</small> command on a remote repository via
+the password-authenticating server, one specifies the
+<code>pserver</code> protocol, optional username, repository host, an
+optional port number, and path to the repository. For example:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>cvs -d
:pserver:faun.example.org:/usr/local/cvsroot checkout someproj
+</nowiki></pre></td></tr></table>
+
+<p>or
+</p>
+<table><tr><td> </td><td><pre
class="example"><nowiki>CVSROOT=:pserver:address@hidden:2401/usr/local/cvsroot
+cvs checkout someproj
+</nowiki></pre></td></tr></table>
+
+<p>However, unless you’re connecting to a public-access
+repository (i.e., one where that username doesn’t
+require a password), you’ll need to supply a password or <em>log in</em>
first.
+Logging in verifies your password with the repository and stores it in a file.
+It’s done with the <code>login</code> command, which will
+prompt you interactively for the password if you didn’t supply one as
part of
+<var>$CVSROOT</var>:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>cvs -d
:pserver:address@hidden:/usr/local/cvsroot login
+CVS password:
+</nowiki></pre></td></tr></table>
+
+<p>or
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>cvs -d
:pserver:bach:address@hidden:/usr/local/cvsroot login
+</nowiki></pre></td></tr></table>
+
+<p>After you enter the password, <small>CVS</small> verifies it with
+the server. If the verification succeeds, then that
+combination of username, host, repository, and password
+is permanently recorded, so future transactions with
+that repository won’t require you to run <code>cvs
+login</code>. (If verification fails, <small>CVS</small> will exit
+complaining that the password was incorrect, and
+nothing will be recorded.)
+</p>
+<p>The records are stored, by default, in the file
+‘<tt>$HOME/.cvspass</tt>’. That file’s format is
+human-readable, and to a degree human-editable, but
+note that the passwords are not stored in
+cleartext—they are trivially encoded to protect them
+from "innocent" compromise (i.e., inadvertent viewing
+by a system administrator or other non-malicious
+person).
+</p>
+<div id="IDX85"></div>
+<p>You can change the default location of this file by
+setting the <code>CVS_PASSFILE</code> environment variable.
+If you use this variable, make sure you set it
+<em>before</em> <code>cvs login</code> is run. If you were to
+set it after running <code>cvs login</code>, then later
+<small>CVS</small> commands would be unable to look up the
+password for transmission to the server.
+</p>
+<p>Once you have logged in, all <small>CVS</small> commands using
+that remote repository and username will authenticate
+with the stored password. So, for example
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>cvs -d
:pserver:address@hidden:/usr/local/cvsroot checkout foo
+</nowiki></pre></td></tr></table>
+
+<p>should just work (unless the password changes on the
+server side, in which case you’ll have to re-run
+<code>cvs login</code>).
+</p>
+<p>Note that if the ‘<samp>:pserver:</samp>’ were not present in
+the repository specification, <small>CVS</small> would assume it
+should use <code>rsh</code> to connect with the server
+instead (see section [[#SEC28|Connecting with rsh]]).
+</p>
+<p>Of course, once you have a working copy checked out and
+are running <small>CVS</small> commands from within it, there is
+no longer any need to specify the repository
+explicitly, because <small>CVS</small> can deduce the repository
+from the working copy’s ‘<tt>CVS</tt>’ subdirectory.
+</p>
+<div id="IDX86"></div>
+<p>The password for a given remote repository can be
+removed from the <code>CVS_PASSFILE</code> by using the
+<code>cvs logout</code> command.
+</p>
+<hr size="6">
+<div id="Password-authentication-security"></div>
+<div id="SEC32"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC31| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC33| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC9| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC29| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC38| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+===== Security considerations with password authentication =====
+
+<p>The passwords are stored on the client side in a
+trivial encoding of the cleartext, and transmitted in
+the same encoding. The encoding is done only to
+prevent inadvertent password compromises (i.e., a
+system administrator accidentally looking at the file),
+and will not prevent even a naive attacker from gaining
+the password.
+</p>
+<p>The separate <small>CVS</small> password file (see section [[#SEC30|Setting
up the server for password authentication]]) allows people
+to use a different password for repository access than
+for login access. On the other hand, once a user has
+non-read-only
+access to the repository, she can execute programs on
+the server system through a variety of means. Thus, repository
+access implies fairly broad system access as well. It
+might be possible to modify <small>CVS</small> to prevent that,
+but no one has done so as of this writing.
+</p>
+<p>Note that because the ‘<tt>$CVSROOT/CVSROOT</tt>’ directory
+contains ‘<tt>passwd</tt>’ and other files which are used
+to check security, you must control the permissions on
+this directory as tightly as the permissions on
+‘<tt>/etc</tt>’. The same applies to the
‘<tt>$CVSROOT</tt>’
+directory itself and any directory
+above it in the tree. Anyone who has write access to
+such a directory will have the ability to become any
+user on the system. Note that these permissions are
+typically tighter than you would use if you are not
+using pserver.
+</p>
+<p>In summary, anyone who gets the password gets
+repository access (which may imply some measure of general system
+access as well). The password is available to anyone
+who can sniff network packets or read a protected
+(i.e., user read-only) file. If you want real
+security, get Kerberos.
+</p>
+<hr size="6">
+<div id="GSSAPI-authenticated"></div>
+<div id="SEC33"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC32| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC34| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC9| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC26| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC38| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+==== Direct connection with GSSAPI ====
+
+<p>GSSAPI is a generic interface to network security
+systems such as Kerberos 5.
+If you have a working GSSAPI library, you can have
+<small>CVS</small> connect via a direct <small>TCP</small> connection,
+authenticating with GSSAPI.
+</p>
+<p>To do this, <small>CVS</small> needs to be compiled with GSSAPI
+support; when configuring <small>CVS</small> it tries to detect
+whether GSSAPI libraries using kerberos version 5 are
+present. You can also use the ‘<tt>--with-gssapi</tt>’
+flag to configure.
+</p>
+<p>The connection is authenticated using GSSAPI, but the
+message stream is <em>not</em> authenticated by default.
+You must use the <code>-a</code> global option to request
+stream authentication.
+</p>
+<p>The data transmitted is <em>not</em> encrypted by
+default. Encryption support must be compiled into both
+the client and the server; use the
+‘<tt>--enable-encrypt</tt>’ configure option to turn it on.
+You must then use the <code>-x</code> global option to
+request encryption.
+</p>
+<p>GSSAPI connections are handled on the server side by
+the same server which handles the password
+authentication server; see [[#SEC30|Setting up the server for password
authentication]]. If you are using a GSSAPI mechanism such as
+Kerberos which provides for strong authentication, you
+will probably want to disable the ability to
+authenticate via cleartext passwords. To do so, create
+an empty ‘<tt>CVSROOT/passwd</tt>’ password file, and set
+<code>SystemAuth=no</code> in the config file
+(see section [[#SEC180|The CVSROOT/config configuration file]]).
+</p>
+<p>The GSSAPI server uses a principal name of
+cvs/<var>hostname</var>, where <var>hostname</var> is the
+canonical name of the server host. You will have to
+set this up as required by your GSSAPI mechanism.
+</p>
+<p>To connect using GSSAPI, use ‘<samp>:gserver:</samp>’. For
+example,
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>cvs -d
:gserver:faun.example.org:/usr/local/cvsroot checkout foo
+</nowiki></pre></td></tr></table>
+
+<hr size="6">
+<div id="Kerberos-authenticated"></div>
+<div id="SEC34"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC33| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC35| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC9| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC26| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC38| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+==== Direct connection with kerberos ====
+
+<p>The easiest way to use kerberos is to use the kerberos
+<code>rsh</code>, as described in [[#SEC28|Connecting with rsh]].
+The main disadvantage of using rsh is that all the data
+needs to pass through additional programs, so it may be
+slower. So if you have kerberos installed you can
+connect via a direct <small>TCP</small> connection,
+authenticating with kerberos.
+</p>
+<p>This section concerns the kerberos network security
+system, version 4. Kerberos version 5 is supported via
+the GSSAPI generic network security interface, as
+described in the previous section.
+</p>
+<p>To do this, <small>CVS</small> needs to be compiled with kerberos
+support; when configuring <small>CVS</small> it tries to detect
+whether kerberos is present or you can use the
+‘<tt>--with-krb4</tt>’ flag to configure.
+</p>
+<p>The data transmitted is <em>not</em> encrypted by
+default. Encryption support must be compiled into both
+the client and server; use the
+‘<tt>--enable-encryption</tt>’ configure option to turn it
+on. You must then use the <code>-x</code> global option to
+request encryption.
+</p>
+<div id="IDX87"></div>
+<p>You need to edit ‘<tt>inetd.conf</tt>’ on the server
+machine to run <code>cvs kserver</code>. The client uses
+port 1999 by default; if you want to use another port
+specify it in the <code>CVSROOT</code> (see section [[#SEC26|Remote
repositories]])
+or the <code>CVS_CLIENT_PORT</code> environment variable
+(see section [[#SEC181|All environment variables which affect CVS]]) on the
client.
+</p>
+<div id="IDX88"></div>
+<p>When you want to use <small>CVS</small>, get a ticket in the
+usual way (generally <code>kinit</code>); it must be a ticket
+which allows you to log into the server machine. Then
+you are ready to go:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>cvs -d
:kserver:faun.example.org:/usr/local/cvsroot checkout foo
+</nowiki></pre></td></tr></table>
+
+<p>Previous versions of <small>CVS</small> would fall back to a
+connection via rsh; this version will not do so.
+</p>
+<hr size="6">
+<div id="Connecting-via-fork"></div>
+<div id="SEC35"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC34| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC36| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC9| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC26| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC38| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+==== Connecting with fork ====
+
+<p>This access method allows you to connect to a
+repository on your local disk via the remote protocol.
+In other words it does pretty much the same thing as
+<code>:local:</code>, but various quirks, bugs and the like are
+those of the remote <small>CVS</small> rather than the local
+<small>CVS</small>.
+</p>
+<p>For day-to-day operations you might prefer either
+<code>:local:</code> or <code>:fork:</code>, depending on your
+preferences. Of course <code>:fork:</code> comes in
+particularly handy in testing or
+debugging <code>cvs</code> and the remote protocol.
+Specifically, we avoid all of the network-related
+setup/configuration, timeouts, and authentication
+inherent in the other remote access methods but still
+create a connection which uses the remote protocol.
+</p>
+<p>To connect using the <code>fork</code> method, use
+‘<samp>:fork:</samp>’ and the pathname to your local
+repository. For example:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>cvs -d
:fork:/usr/local/cvsroot checkout foo
+</nowiki></pre></td></tr></table>
+
+<div id="IDX89"></div>
+<p>As with <code>:ext:</code>, the server is called
‘<samp>cvs</samp>’
+by default, or the value of the <code>CVS_SERVER</code>
+environment variable.
+</p>
+<hr size="6">
+<div id="Read_002donly-access"></div>
+<div id="SEC36"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC35| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC37| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC9| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC9| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC38| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== Read-only repository access ===
+
+<p> It is possible to grant read-only repository
+access to people using the password-authenticated
+server (see section [[#SEC29|Direct connection with password
authentication]]). (The
+other access methods do not have explicit support for
+read-only users because those methods all assume login
+access to the repository machine anyway, and therefore
+the user can do whatever local file permissions allow
+her to do.)
+</p>
+<p> A user who has read-only access can do only
+those <small>CVS</small> operations which do not modify the
+repository, except for certain “administrative” files
+(such as lock files and the history file). It may be
+desirable to use this feature in conjunction with
+user-aliasing (see section [[#SEC30|Setting up the server for password
authentication]]).
+</p>
+<p>Unlike with previous versions of <small>CVS</small>, read-only
+users should be able merely to read the repository, and
+not to execute programs on the server or otherwise gain
+unexpected levels of access. Or to be more accurate,
+the <em>known</em> holes have been plugged. Because this
+feature is new and has not received a comprehensive
+security audit, you should use whatever level of
+caution seems warranted given your attitude concerning
+security.
+</p>
+<p> There are two ways to specify read-only access
+for a user: by inclusion, and by exclusion.
+</p>
+<p> "Inclusion" means listing that user
+specifically in the ‘<tt>$CVSROOT/CVSROOT/readers</tt>’
+file, which is simply a newline-separated list of
+users. Here is a sample ‘<tt>readers</tt>’ file:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>melissa
+splotnik
+jrandom
+</nowiki></pre></td></tr></table>
+
+<p> (Don’t forget the newline after the last user.)
+</p>
+<p> "Exclusion" means explicitly listing everyone
+who has <em>write</em> access—if the file
+</p>
+<table><tr><td> </td><td><pre
class="example"><nowiki>$CVSROOT/CVSROOT/writers
+</nowiki></pre></td></tr></table>
+
+<p>exists, then only
+those users listed in it have write access, and
+everyone else has read-only access (of course, even the
+read-only users still need to be listed in the
+<small>CVS</small> ‘<tt>passwd</tt>’ file). The
+‘<tt>writers</tt>’ file has the same format as the
+‘<tt>readers</tt>’ file.
+</p>
+<p> Note: if your <small>CVS</small> ‘<tt>passwd</tt>’
+file maps cvs users onto system users (see section [[#SEC30|Setting up the
server for password authentication]]), make sure you deny or grant
+read-only access using the <em>cvs</em> usernames, not
+the system usernames. That is, the ‘<tt>readers</tt>’ and
+‘<tt>writers</tt>’ files contain cvs usernames, which may
+or may not be the same as system usernames.
+</p>
+<p> Here is a complete description of the server’s
+behavior in deciding whether to grant read-only or
+read-write access:
+</p>
+<p> If ‘<tt>readers</tt>’ exists, and this user is
+listed in it, then she gets read-only access. Or if
+‘<tt>writers</tt>’ exists, and this user is NOT listed in
+it, then she also gets read-only access (this is true
+even if ‘<tt>readers</tt>’ exists but she is not listed
+there). Otherwise, she gets full read-write access.
+</p>
+<p> Of course there is a conflict if the user is
+listed in both files. This is resolved in the more
+conservative way, it being better to protect the
+repository too much than too little: such a user gets
+read-only access.
+</p>
+<hr size="6">
+<div id="Server-temporary-directory"></div>
+<div id="SEC37"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC36| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC38| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC9| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC9| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC38| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== Temporary directories for the server ===
+
+<p>While running, the <small>CVS</small> server creates temporary
+directories. They are named
+</p>
+<table><tr><td> </td><td><pre
class="example"><nowiki>cvs-serv<var>pid</var>
+</nowiki></pre></td></tr></table>
+
+<p>where <var>pid</var> is the process identification number of
+the server.
+They are located in the directory specified by
+the ‘<samp>-T</samp>’ global option (see section [[#SEC118|Global
options]]),
+the <code>TMPDIR</code> environment variable (see section [[#SEC181|All
environment variables which affect CVS]]),
+or, failing that, ‘<tt>/tmp</tt>’.
+</p>
+<p>In most cases the server will remove the temporary
+directory when it is done, whether it finishes normally
+or abnormally. However, there are a few cases in which
+the server does not or cannot remove the temporary
+directory, for example:
+</p>
+<ul>
+<li>
+If the server aborts due to an internal server error,
+it may preserve the directory to aid in debugging
+
+</li><li>
+If the server is killed in a way that it has no way of
+cleaning up (most notably, ‘<samp>kill -KILL</samp>’ on unix).
+
+</li><li>
+If the system shuts down without an orderly shutdown,
+which tells the server to clean up.
+</li></ul>
+
+<p>In cases such as this, you will need to manually remove
+the ‘<tt>cvs-serv<var>pid</var></tt>’ directories. As long as
+there is no server running with process identification
+number <var>pid</var>, it is safe to do so.
+</p>
+<hr size="6">
+<div id="Starting-a-new-project"></div>
+<div id="SEC38"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC37| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC39| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC9| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC_Top| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC44| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+== Starting a project with CVS ==
+
+<p>Because renaming files and moving them between
+directories is somewhat inconvenient, the first thing
+you do when you start a new project should be to think
+through your file organization. It is not impossible
+to rename or move files, but it does increase the
+potential for confusion and <small>CVS</small> does have some
+quirks particularly in the area of renaming
+directories. See section [[#SEC70|Moving and renaming files]].
+</p>
+<p>What to do next depends on the situation at hand.
+</p>
+<pre class="menu-preformatted"><nowiki></nowiki>•[[#SEC39| Setting up the
files]]::<nowiki> Getting the files into the repository
+</nowiki>•[[#SEC43| Defining the module]]::<nowiki> How to make a
module of the files
+</nowiki></pre>
+<hr size="6">
+<div id="Setting-up-the-files"></div>
+<div id="SEC39"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC38| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC40| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC38| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC38| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC44| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== Setting up the files ===
+
+<p>The first step is to create the files inside the repository. This can
+be done in a couple of different ways.
+</p>
+<pre class="menu-preformatted"><nowiki></nowiki>•[[#SEC40| From
files]]::<nowiki> This method is useful with old projects
+ where files already exists.
+</nowiki>•[[#SEC41| From other version control systems]]::<nowiki> Old
projects where you want to
+ preserve history from another system.
+</nowiki>•[[#SEC42| From scratch]]::<nowiki> Creating a
directory tree from scratch.
+</nowiki></pre>
+<hr size="6">
+<div id="From-files"></div>
+<div id="SEC40"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC39| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC41| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC38| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC39| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC44| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+==== Creating a directory tree from a number of files ====
+
+<p>When you begin using <small>CVS</small>, you will probably already have
several
+projects that can be
+put under <small>CVS</small> control. In these cases the easiest way is to
use the
+<code>import</code> command. An example is probably the easiest way to
+explain how to use it. If the files you want to install in
+<small>CVS</small> reside in ‘<tt><var>wdir</var></tt>’, and you
want them to appear in the
+repository as ‘<tt>$CVSROOT/yoyodyne/<var>rdir</var></tt>’, you
can do this:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>$ cd <var>wdir</var>
+$ cvs import -m "Imported sources" yoyodyne/<var>rdir</var> yoyo
start
+</nowiki></pre></td></tr></table>
+
+<p>Unless you supply a log message with the ‘<samp>-m</samp>’
+flag, <small>CVS</small> starts an editor and prompts for a
+message. The string ‘<samp>yoyo</samp>’ is a <em>vendor tag</em>,
+and ‘<samp>start</samp>’ is a <em>release tag</em>. They may fill
+no purpose in this context, but since <small>CVS</small> requires
+them they must be present. See section [[#SEC105|Tracking third-party
sources]], for
+more information about them.
+</p>
+<p>You can now verify that it worked, and remove your
+original source directory.
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>$ cd ..
+$ cvs checkout yoyodyne/<var>rdir</var> # <span
class="roman">Explanation below</span>
+$ diff -r <var>wdir</var> yoyodyne/<var>rdir</var>
+$ rm -r <var>wdir</var>
+</nowiki></pre></td></tr></table>
+
+<p>Erasing the original sources is a good idea, to make sure that you do
+not accidentally edit them in <var>wdir</var>, bypassing <small>CVS</small>.
+Of course, it would be wise to make sure that you have
+a backup of the sources before you remove them.
+</p>
+<p>The <code>checkout</code> command can either take a module
+name as argument (as it has done in all previous
+examples) or a path name relative to <code>$CVSROOT</code>,
+as it did in the example above.
+</p>
+<p>It is a good idea to check that the permissions
+<small>CVS</small> sets on the directories inside <code>$CVSROOT</code>
+are reasonable, and that they belong to the proper
+groups. See section [[#SEC13|File permissions]].
+</p>
+<p>If some of the files you want to import are binary, you
+may want to use the wrappers features to specify which
+files are binary and which are not. See section [[#SEC165|The cvswrappers
file]].
+</p>
+<hr size="6">
+<div id="From-other-version-control-systems"></div>
+<div id="SEC41"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC40| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC42| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC38| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC39| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC44| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+==== Creating Files From Other Version Control Systems ====
+
+<p>If you have a project which you are maintaining with
+another version control system, such as <small>RCS</small>, you
+may wish to put the files from that project into
+<small>CVS</small>, and preserve the revision history of the
+files.
+</p>
+<dl compact="compact">
+<dd><div id="IDX90"></div>
+</dd>
+<dt> From RCS</dt>
+<dd><p>If you have been using <small>RCS</small>, find the <small>RCS</small>
+files—usually a file named ‘<tt>foo.c</tt>’ will have its
+<small>RCS</small> file in ‘<tt>RCS/foo.c,v</tt>’ (but it could be
+other places; consult the <small>RCS</small> documentation for
+details). Then create the appropriate directories in
+<small>CVS</small> if they do not already exist. Then copy the
+files into the appropriate directories in the <small>CVS</small>
+repository (the name in the repository must be the name
+of the source file with ‘<samp>,v</samp>’ added; the files go
+directly in the appropriate directory of the repository,
+not in an ‘<tt>RCS</tt>’ subdirectory). This is one of the
+few times when it is a good idea to access the <small>CVS</small>
+repository directly, rather than using <small>CVS</small>
+commands. Then you are ready to check out a new
+working directory.
+</p>
+<p>The <small>RCS</small> file should not be locked when you move it
+into <small>CVS</small>; if it is, <small>CVS</small> will have trouble
+letting you operate on it.
+</p>
+</dd>
+<dt> From another version control system</dt>
+<dd><p>Many version control systems have the ability to export
+<small>RCS</small> files in the standard format. If yours does,
+export the <small>RCS</small> files and then follow the above
+instructions.
+</p>
+<p>Failing that, probably your best bet is to write a
+script that will check out the files one revision at a
+time using the command line interface to the other
+system, and then check the revisions into <small>CVS</small>.
+The ‘<tt>sccs2rcs</tt>’ script mentioned below may be a
+useful example to follow.
+</p>
+<div id="IDX91"></div>
+</dd>
+<dt> From SCCS</dt>
+<dd><p>There is a script in the ‘<tt>contrib</tt>’ directory of
+the <small>CVS</small> source distribution called
‘<tt>sccs2rcs</tt>’
+which converts <small>SCCS</small> files to <small>RCS</small> files.
+Note: you must run it on a machine which has both
+<small>SCCS</small> and <small>RCS</small> installed, and like everything
+else in contrib it is unsupported (your mileage may
+vary).
+</p>
+<div id="IDX92"></div>
+</dd>
+<dt> From PVCS</dt>
+<dd><p>There is a script in the ‘<tt>contrib</tt>’ directory of
+the <small>CVS</small> source distribution called
‘<tt>pvcs_to_rcs</tt>’
+which converts <small>PVCS</small> archives to <small>RCS</small> files.
+You must run it on a machine which has both
+<small>PVCS</small> and <small>RCS</small> installed, and like everything
+else in contrib it is unsupported (your mileage may
+vary). See the comments in the script for details.
+</p></dd>
+</dl>
+
+<hr size="6">
+<div id="From-scratch"></div>
+<div id="SEC42"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC41| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC43| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC38| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC39| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC44| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+==== Creating a directory tree from scratch ====
+
+<p>For a new project, the easiest thing to do is probably
+to create an empty directory structure, like this:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>$ mkdir tc
+$ mkdir tc/man
+$ mkdir tc/testing
+</nowiki></pre></td></tr></table>
+
+<p>After that, you use the <code>import</code> command to create
+the corresponding (empty) directory structure inside
+the repository:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>$ cd tc
+$ cvs import -m "Created directory structure"
yoyodyne/<var>dir</var> yoyo start
+</nowiki></pre></td></tr></table>
+
+<p>Then, use <code>add</code> to add files (and new directories)
+as they appear.
+</p>
+<p>Check that the permissions <small>CVS</small> sets on the
+directories inside <code>$CVSROOT</code> are reasonable.
+</p>
+<hr size="6">
+<div id="Defining-the-module"></div>
+<div id="SEC43"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC42| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC44| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC38| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC38| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC44| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== Defining the module ===
+
+<p>The next step is to define the module in the
+‘<tt>modules</tt>’ file. This is not strictly necessary,
+but modules can be convenient in grouping together
+related files and directories.
+</p>
+<p>In simple cases these steps are sufficient to define a module.
+</p>
+<ol>
+<li>
+Get a working copy of the modules file.
+
+<table><tr><td> </td><td><pre class="example"><nowiki>$ cvs checkout
CVSROOT/modules
+$ cd CVSROOT
+</nowiki></pre></td></tr></table>
+
+</li><li>
+Edit the file and insert a line that defines the module. See section
[[#SEC20|The administrative files]], for an introduction. See section
[[#SEC158|The modules file]], for a full
+description of the modules file. You can use the
+following line to define the module ‘<samp>tc</samp>’:
+
+<table><tr><td> </td><td><pre class="example"><nowiki>tc yoyodyne/tc
+</nowiki></pre></td></tr></table>
+
+</li><li>
+Commit your changes to the modules file.
+
+<table><tr><td> </td><td><pre class="example"><nowiki>$ cvs commit -m
"Added the tc module." modules
+</nowiki></pre></td></tr></table>
+
+</li><li>
+Release the modules module.
+
+<table><tr><td> </td><td><pre class="example"><nowiki>$ cd ..
+$ cvs release -d CVSROOT
+</nowiki></pre></td></tr></table>
+</li></ol>
+
+<hr size="6">
+<div id="Revisions"></div>
+<div id="SEC44"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC43| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC45| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC38| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC_Top| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC54| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+== Revisions ==
+
+<p>For many uses of <small>CVS</small>, one doesn’t need to worry
+too much about revision numbers; <small>CVS</small> assigns
+numbers such as <code>1.1</code>, <code>1.2</code>, and so on, and
+that is all one needs to know. However, some people
+prefer to have more knowledge and control concerning
+how <small>CVS</small> assigns revision numbers.
+</p>
+<p>If one wants to keep track of a set of revisions
+involving more than one file, such as which revisions
+went into a particular release, one uses a <em>tag</em>,
+which is a symbolic revision which can be assigned to a
+numeric revision in each file.
+</p>
+<pre class="menu-preformatted"><nowiki></nowiki>•[[#SEC45| Revision
numbers]]::<nowiki> The meaning of a revision number
+</nowiki>•[[#SEC46| Versions revisions releases]]::<nowiki> Terminology
used in this manual
+</nowiki>•[[#SEC47| Assigning revisions]]::<nowiki> Assigning
revisions
+</nowiki>•[[#SEC48| Tags]]::<nowiki>
Tags--Symbolic revisions
+</nowiki>•[[#SEC49| Tagging the working directory]]::<nowiki> The cvs
tag command
+</nowiki>•[[#SEC50| Tagging by date/tag]]::<nowiki> The cvs rtag
command
+</nowiki>•[[#SEC51| Modifying tags]]::<nowiki> Adding,
renaming, and deleting tags
+</nowiki>•[[#SEC52| Tagging add/remove]]::<nowiki> Tags with
adding and removing files
+</nowiki>•[[#SEC53| Sticky tags]]::<nowiki> Certain tags
are persistent
+</nowiki></pre>
+<hr size="6">
+<div id="Revision-numbers"></div>
+<div id="SEC45"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC44| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC46| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC44| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC44| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC54| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== Revision numbers ===
+
+<p>Each version of a file has a unique <em>revision
+number</em>. Revision numbers look like ‘<samp>1.1</samp>’,
+‘<samp>1.2</samp>’, ‘<samp>1.3.2.2</samp>’ or even
‘<samp>1.3.2.2.4.5</samp>’.
+A revision number always has an even number of
+period-separated decimal integers. By default revision
+1.1 is the first revision of a file. Each successive
+revision is given a new number by increasing the
+rightmost number by one. The following figure displays
+a few revisions, with newer revisions to the right.
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki> +-----+
+-----+ +-----+ +-----+ +-----+
+ ! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 !
+ +-----+ +-----+ +-----+ +-----+ +-----+
+</nowiki></pre></td></tr></table>
+
+<p>It is also possible to end up with numbers containing
+more than one period, for example ‘<samp>1.3.2.2</samp>’. Such
+revisions represent revisions on branches
+(see section [[#SEC54|Branching and merging]]); such revision numbers
+are explained in detail in [[#SEC58|Branches and revisions]].
+</p>
+<hr size="6">
+<div id="Versions-revisions-releases"></div>
+<div id="SEC46"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC45| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC47| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC44| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC44| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC54| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== Versions, revisions and releases ===
+
+<p>A file can have several versions, as described above.
+Likewise, a software product can have several versions.
+A software product is often given a version number such
+as ‘<samp>4.1.1</samp>’.
+</p>
+<p>Versions in the first sense are called <em>revisions</em>
+in this document, and versions in the second sense are
+called <em>releases</em>. To avoid confusion, the word
+<em>version</em> is almost never used in this document.
+</p>
+<hr size="6">
+<div id="Assigning-revisions"></div>
+<div id="SEC47"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC46| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC48| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC44| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC44| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC54| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== Assigning revisions ===
+
+<p>By default, <small>CVS</small> will assign numeric revisions by
+leaving the first number the same and incrementing the
+second number. For example, <code>1.1</code>, <code>1.2</code>,
+<code>1.3</code>, etc.
+</p>
+<p>When adding a new file, the second number will always
+be one and the first number will equal the highest
+first number of any file in that directory. For
+example, the current directory contains files whose
+highest numbered revisions are <code>1.7</code>, <code>3.1</code>,
+and <code>4.12</code>, then an added file will be given the
+numeric revision <code>4.1</code>.
+</p>
+<p>Normally there is no reason to care
+about the revision numbers—it is easier to treat them
+as internal numbers that <small>CVS</small> maintains, and tags
+provide a better way to distinguish between things like
+release 1 versus release 2 of your product
+(see section [[#SEC48|Tags–Symbolic revisions]]). However, if you want
to set the
+numeric revisions, the ‘<samp>-r</samp>’ option to <code>cvs
+commit</code> can do that. The ‘<samp>-r</samp>’ option implies
the
+‘<samp>-f</samp>’ option, in the sense that it causes the
+files to be committed even if they are not modified.
+</p>
+<p>For example, to bring all your files up to
+revision 3.0 (including those that haven’t changed),
+you might invoke:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>$ cvs commit -r 3.0
+</nowiki></pre></td></tr></table>
+
+<p>Note that the number you specify with ‘<samp>-r</samp>’ must be
+larger than any existing revision number. That is, if
+revision 3.0 exists, you cannot ‘<samp>cvs commit
+-r 1.3</samp>’. If you want to maintain several releases in
+parallel, you need to use a branch (see section [[#SEC54|Branching and
merging]]).
+</p>
+<hr size="6">
+<div id="Tags"></div>
+<div id="SEC48"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC47| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC49| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC44| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC44| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC54| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== Tags–Symbolic revisions ===
+
+<p>The revision numbers live a life of their own. They
+need not have anything at all to do with the release
+numbers of your software product. Depending
+on how you use <small>CVS</small> the revision numbers might change several
times
+between two releases. As an example, some of the
+source files that make up <small>RCS</small> 5.6 have the following
+revision numbers:
+<div id="IDX93"></div>
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>ci.c 5.21
+co.c 5.9
+ident.c 5.3
+rcs.c 5.12
+rcsbase.h 5.11
+rcsdiff.c 5.10
+rcsedit.c 5.11
+rcsfcmp.c 5.9
+rcsgen.c 5.10
+rcslex.c 5.11
+rcsmap.c 5.2
+rcsutil.c 5.10
+</nowiki></pre></td></tr></table>
+
+<div id="IDX94"></div>
+<div id="IDX95"></div>
+<div id="IDX96"></div>
+<div id="IDX97"></div>
+<div id="IDX98"></div>
+<div id="IDX99"></div>
+<p>You can use the <code>tag</code> command to give a symbolic name to a
+certain revision of a file. You can use the ‘<samp>-v</samp>’
flag to the
+<code>status</code> command to see all tags that a file has, and
+which revision numbers they represent. Tag names must
+start with an uppercase or lowercase letter and can
+contain uppercase and lowercase letters, digits,
+‘<samp>-</samp>’, and ‘<samp>_</samp>’. The two tag
names <code>BASE</code>
+and <code>HEAD</code> are reserved for use by <small>CVS</small>. It
+is expected that future names which are special to
+<small>CVS</small> will be specially named, for example by
+starting with ‘<samp>.</samp>’, rather than being named
analogously to
+<code>BASE</code> and <code>HEAD</code>, to avoid conflicts with
+actual tag names.
+</p>
+<p>You’ll want to choose some convention for naming tags,
+based on information such as the name of the program
+and the version number of the release. For example,
+one might take the name of the program, immediately
+followed by the version number with ‘<samp>.</samp>’ changed to
+‘<samp>-</samp>’, so that <small>CVS</small> 1.9 would be tagged
with the name
+<code>cvs1-9</code>. If you choose a consistent convention,
+then you won’t constantly be guessing whether a tag is
+<code>cvs-1-9</code> or <code>cvs1_9</code> or what. You might
+even want to consider enforcing your convention in the
+taginfo file (see section [[#SEC78|User-defined logging]]).
+</p>
+<div id="IDX100"></div>
+<div id="IDX101"></div>
+<p>The following example shows how you can add a tag to a
+file. The commands must be issued inside your working
+directory. That is, you should issue the
+command in the directory where ‘<tt>backend.c</tt>’
+resides.
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>$ cvs tag rel-0-4
backend.c
+T backend.c
+$ cvs status -v backend.c
+===================================================================
+File: backend.c Status: Up-to-date
+
+ Version: 1.4 Tue Dec 1 14:39:01 1992
+ RCS Version: 1.4 /u/cvsroot/yoyodyne/tc/backend.c,v
+ Sticky Tag: (none)
+ Sticky Date: (none)
+ Sticky Options: (none)
+
+ Existing Tags:
+ rel-0-4 (revision: 1.4)
+
+</nowiki></pre></td></tr></table>
+
+<p>For a complete summary of the syntax of <code>cvs tag</code>,
+including the various options, see [[#SEC156|Quick reference to CVS commands]].
+</p>
+<p>There is seldom reason to tag a file in isolation. A more common use is
+to tag all the files that constitute a module with the same tag at
+strategic points in the development life-cycle, such as when a release
+is made.
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>$ cvs tag rel-1-0 .
+cvs tag: Tagging .
+T Makefile
+T backend.c
+T driver.c
+T frontend.c
+T parser.c
+</nowiki></pre></td></tr></table>
+
+<p>(When you give <small>CVS</small> a directory as argument, it generally
applies the
+operation to all the files in that directory, and (recursively), to any
+subdirectories that it may contain. See section [[#SEC65|Recursive
behavior]].)
+</p>
+<div id="IDX102"></div>
+<div id="IDX103"></div>
+<p>The <code>checkout</code> command has a flag,
‘<samp>-r</samp>’, that lets you check out
+a certain revision of a module. This flag makes it easy to
+retrieve the sources that make up release 1.0 of the module
‘<samp>tc</samp>’ at
+any time in the future:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>$ cvs checkout -r
rel-1-0 tc
+</nowiki></pre></td></tr></table>
+
+<p>This is useful, for instance, if someone claims that there is a bug in
+that release, but you cannot find the bug in the current working copy.
+</p>
+<p>You can also check out a module as it was at any given date.
+See section [[#SEC123|checkout options]]. When specifying
‘<samp>-r</samp>’ to
+any of these commands, you will need beware of sticky
+tags; see [[#SEC53|Sticky tags]].
+</p>
+<p>When you tag more than one file with the same tag you
+can think about the tag as "a curve drawn through a
+matrix of filename vs. revision number." Say we have 5
+files with the following revisions:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki> file1
file2 file3 file4 file5
+
+ 1.1 1.1 1.1 1.1 /--1.1* <-*- TAG
+ 1.2*- 1.2 1.2 -1.2*-
+ 1.3 \- 1.3*- 1.3 / 1.3
+ 1.4 \ 1.4 / 1.4
+ \-1.5*- 1.5
+ 1.6
+</nowiki></pre></td></tr></table>
+
+<p>At some time in the past, the <code>*</code> versions were tagged.
+You can think of the tag as a handle attached to the curve
+drawn through the tagged revisions. When you pull on
+the handle, you get all the tagged revisions. Another
+way to look at it is that you "sight" through a set of
+revisions that is "flat" along the tagged revisions,
+like this:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki> file1
file2 file3 file4 file5
+
+ 1.1
+ 1.2
+ 1.1 1.3 _
+ 1.1 1.2 1.4 1.1 /
+ 1.2*----1.3*----1.5*----1.2*----1.1 (--- <--- Look here
+ 1.3 1.6 1.3 \_
+ 1.4 1.4
+ 1.5
+</nowiki></pre></td></tr></table>
+
+<hr size="6">
+<div id="Tagging-the-working-directory"></div>
+<div id="SEC49"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC48| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC50| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC44| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC44| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC54| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== Specifying what to tag from the working directory ===
+
+<p>The example in the previous section demonstrates one of
+the most common ways to choose which revisions to tag.
+Namely, running the <code>cvs tag</code> command without
+arguments causes <small>CVS</small> to select the revisions which
+are checked out in the current working directory. For
+example, if the copy of ‘<tt>backend.c</tt>’ in working
+directory was checked out from revision 1.4, then
+<small>CVS</small> will tag revision 1.4. Note that the tag is
+applied immediately to revision 1.4 in the repository;
+tagging is not like modifying a file, or other
+operations in which one first modifies the working
+directory and then runs <code>cvs commit</code> to transfer
+that modification to the repository.
+</p>
+<p>One potentially surprising aspect of the fact that
+<code>cvs tag</code> operates on the repository is that you
+are tagging the checked-in revisions, which may differ
+from locally modified files in your working directory.
+If you want to avoid doing this by mistake, specify the
+‘<samp>-c</samp>’ option to <code>cvs tag</code>. If there are any
+locally modified files, <small>CVS</small> will abort with an
+error before it tags any files:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>$ cvs tag -c rel-0-4
+cvs tag: backend.c is locally modified
+cvs [tag aborted]: correct the above errors first!
+</nowiki></pre></td></tr></table>
+
+<hr size="6">
+<div id="Tagging-by-date_002ftag"></div>
+<div id="SEC50"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC49| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC51| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC44| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC44| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC54| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== Specifying what to tag by date or revision ===
+
+<p>The <code>cvs rtag</code> command tags the repository as of a
+certain date or time (or can be used to tag the latest
+revision). <code>rtag</code> works directly on the
+repository contents (it requires no prior checkout and
+does not look for a working directory).
+</p>
+<p>The following options specify which date or revision to
+tag. See [[#SEC119|Common command options]], for a complete
+description of them.
+</p>
+<dl compact="compact">
+<dt> <code>-D <var>date</var></code></dt>
+<dd><p>Tag the most recent revision no later than <var>date</var>.
+</p>
+</dd>
+<dt> <code>-f</code></dt>
+<dd><p>Only useful with the ‘<samp>-D <var>date</var></samp>’ or
‘<samp>-r <var>tag</var></samp>’
+flags. If no matching revision is found, use the most
+recent revision (instead of ignoring the file).
+</p>
+</dd>
+<dt> <code>-r <var>tag</var></code></dt>
+<dd><p>Only tag those files that contain existing tag <var>tag</var>.
+</p></dd>
+</dl>
+
+<p>The <code>cvs tag</code> command also allows one to specify
+files by revision or date, using the same ‘<samp>-r</samp>’,
+‘<samp>-D</samp>’, and ‘<samp>-f</samp>’ options.
However, this
+feature is probably not what you want. The reason is
+that <code>cvs tag</code> chooses which files to tag based on
+the files that exist in the working directory, rather
+than the files which existed as of the given tag/date.
+Therefore, you are generally better off using <code>cvs
+rtag</code>. The exceptions might be cases like:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>cvs tag -r 1.4
stable backend.c
+</nowiki></pre></td></tr></table>
+
+<hr size="6">
+<div id="Modifying-tags"></div>
+<div id="SEC51"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC50| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC52| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC44| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC44| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC54| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== Deleting, moving, and renaming tags ===
+
+
+<p>Normally one does not modify tags. They exist in order
+to record the history of the repository and so deleting
+them or changing their meaning would, generally, not be
+what you want.
+</p>
+<p>However, there might be cases in which one uses a tag
+temporarily or accidentally puts one in the wrong
+place. Therefore, one might delete, move, or rename a
+tag.
+</p>
+<p><strong>WARNING: the commands in this section are
+dangerous; they permanently discard historical
+information and it can be difficult or impossible to
+recover from errors. If you are a <small>CVS</small>
+administrator, you may consider restricting these
+commands with taginfo (see section [[#SEC78|User-defined logging]]).</strong>
+</p>
+<div id="IDX104"></div>
+<div id="IDX105"></div>
+<div id="IDX106"></div>
+<div id="IDX107"></div>
+<div id="IDX108"></div>
+<div id="IDX109"></div>
+<p>To delete a tag, specify the ‘<samp>-d</samp>’ option to either
+<code>cvs tag</code> or <code>cvs rtag</code>. For example:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>cvs rtag -d rel-0-4
tc
+</nowiki></pre></td></tr></table>
+
+<p>deletes the non-branch tag <code>rel-0-4</code> from the module
<code>tc</code>.
+In the event that branch tags are encountered within the repository
+with the given name, a warning message will be issued and the branch
+tag will not be deleted. If you are absolutely certain you know what
+you are doing, the <code>-B</code> option may be specified to allow deletion
+of branch tags. In that case, any non-branch tags encountered will
+trigger warnings and will not be deleted.
+</p>
+<p><strong>WARNING: Moving branch tags is very dangerous! If you think
+you need the <code>-B</code> option, think again and ask your
<small>CVS</small>
+administrator about it (if that isn’t you). There is almost certainly
+another way to accomplish what you want to accomplish.</strong>
+</p>
+<div id="IDX110"></div>
+<div id="IDX111"></div>
+<div id="IDX112"></div>
+<div id="IDX113"></div>
+<p>When we say <em>move</em> a tag, we mean to make the same
+name point to different revisions. For example, the
+<code>stable</code> tag may currently point to revision 1.4
+of ‘<tt>backend.c</tt>’ and perhaps we want to make it
+point to revision 1.6. To move a non-branch tag, specify the
+‘<samp>-F</samp>’ option to either <code>cvs tag</code> or
<code>cvs
+rtag</code>. For example, the task just mentioned might be
+accomplished as:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>cvs tag -r 1.6 -F
stable backend.c
+</nowiki></pre></td></tr></table>
+
+<p>If any branch tags are encountered in the repository
+with the given name, a warning is issued and the branch
+tag is not disturbed. If you are absolutely certain you
+wish to move the branch tag, the <code>-B</code> option may be specified.
+In that case, non-branch tags encountered with the given
+name are ignored with a warning message.
+</p>
+<p><strong>WARNING: Moving branch tags is very dangerous! If you think you
+need the <code>-B</code> option, think again and ask your <small>CVS</small>
+administrator about it (if that isn’t you). There is almost certainly
+another way to accomplish what you want to accomplish.</strong>
+</p>
+<div id="IDX114"></div>
+<div id="IDX115"></div>
+<p>When we say <em>rename</em> a tag, we mean to make a
+different name point to the same revisions as the old
+tag. For example, one may have misspelled the tag name
+and want to correct it (hopefully before others are
+relying on the old spelling). To rename a tag, first
+create a new tag using the ‘<samp>-r</samp>’ option to
+<code>cvs rtag</code>, and then delete the old name. (Caution:
+this method will not work with branch tags.)
+This leaves the new tag on exactly the
+same files as the old tag. For example:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>cvs rtag -r
old-name-0-4 rel-0-4 tc
+cvs rtag -d old-name-0-4 tc
+</nowiki></pre></td></tr></table>
+
+<hr size="6">
+<div id="Tagging-add_002fremove"></div>
+<div id="SEC52"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC51| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC53| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC44| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC44| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC54| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== Tagging and adding and removing files ===
+
+<p>The subject of exactly how tagging interacts with
+adding and removing files is somewhat obscure; for the
+most part <small>CVS</small> will keep track of whether files
+exist or not without too much fussing. By default,
+tags are applied to only files which have a revision
+corresponding to what is being tagged. Files which did
+not exist yet, or which were already removed, simply
+omit the tag, and <small>CVS</small> knows to treat the absence
+of a tag as meaning that the file didn’t exist as of
+that tag.
+</p>
+<p>However, this can lose a small amount of information.
+For example, suppose a file was added and then removed.
+Then, if the tag is missing for that file, there is no
+way to know whether the tag refers to the time before
+the file was added, or the time after it was removed.
+If you specify the ‘<samp>-r</samp>’ option to <code>cvs
rtag</code>,
+then <small>CVS</small> tags the files which have been removed,
+and thereby avoids this problem. For example, one
+might specify <code>-r HEAD</code> to tag the head.
+</p>
+<p>On the subject of adding and removing files, the
+<code>cvs rtag</code> command has a ‘<samp>-a</samp>’ option which
+means to clear the tag from removed files that would
+not otherwise be tagged. For example, one might
+specify this option in conjunction with ‘<samp>-F</samp>’ when
+moving a tag. If one moved a tag without ‘<samp>-a</samp>’,
+then the tag in the removed files might still refer to
+the old revision, rather than reflecting the fact that
+the file had been removed. I don’t think this is
+necessary if ‘<samp>-r</samp>’ is specified, as noted above.
+</p>
+<hr size="6">
+<div id="Sticky-tags"></div>
+<div id="SEC53"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC52| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC54| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC44| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC44| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC54| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== Sticky tags ===
+
+
+<p>Sometimes a working copy’s revision has extra data
+associated with it, for example it might be on a branch
+(see section [[#SEC54|Branching and merging]]), or restricted to
+versions prior to a certain date by ‘<samp>checkout -D</samp>’
+or ‘<samp>update -D</samp>’. Because this data persists –
+that is, it applies to subsequent commands in the
+working copy – we refer to it as <em>sticky</em>.
+</p>
+<p>Most of the time, stickiness is an obscure aspect of
+<small>CVS</small> that you don’t need to think about. However,
+even if you don’t want to use the feature, you may need
+to know <em>something</em> about sticky tags (for
+example, how to avoid them!).
+</p>
+<p>You can use the <code>status</code> command to see if any
+sticky tags or dates are set:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>$ cvs status
driver.c
+===================================================================
+File: driver.c Status: Up-to-date
+
+ Version: 1.7.2.1 Sat Dec 5 19:35:03 1992
+ RCS Version: 1.7.2.1 /u/cvsroot/yoyodyne/tc/driver.c,v
+ Sticky Tag: rel-1-0-patches (branch: 1.7.2)
+ Sticky Date: (none)
+ Sticky Options: (none)
+
+</nowiki></pre></td></tr></table>
+
+<div id="IDX116"></div>
+<div id="IDX117"></div>
+<div id="IDX118"></div>
+<p>The sticky tags will remain on your working files until
+you delete them with ‘<samp>cvs update -A</samp>’. The
+‘<samp>-A</samp>’ option merges local changes into the version of
the
+file from the head of the trunk, removing any sticky tags,
+dates, or options. See [[#SEC153|update—Bring work tree in sync with
repository]] for more on the operation
+of <code>cvs update</code>.
+</p>
+<div id="IDX119"></div>
+<p>The most common use of sticky tags is to identify which
+branch one is working on, as described in
+[[#SEC57|Accessing branches]]. However, non-branch
+sticky tags have uses as well. For example,
+suppose that you want to avoid updating your working
+directory, to isolate yourself from possibly
+destabilizing changes other people are making. You
+can, of course, just refrain from running <code>cvs
+update</code>. But if you want to avoid updating only a
+portion of a larger tree, then sticky tags can help.
+If you check out a certain revision (such as 1.4) it
+will become sticky. Subsequent <code>cvs update</code>
+commands will
+not retrieve the latest revision until you reset the
+tag with <code>cvs update -A</code>. Likewise, use of the
+‘<samp>-D</samp>’ option to <code>update</code> or
<code>checkout</code>
+sets a <em>sticky date</em>, which, similarly, causes that
+date to be used for future retrievals.
+</p>
+<p>People often want to retrieve an old version of
+a file without setting a sticky tag. This can
+be done with the ‘<samp>-p</samp>’ option to <code>checkout</code>
or
+<code>update</code>, which sends the contents of the file to
+standard output. For example:
+</p><table><tr><td> </td><td><pre class="example"><nowiki>$ cvs update -p
-r 1.1 file1 >file1
+===================================================================
+Checking out file1
+RCS: /tmp/cvs-sanity/cvsroot/first-dir/Attic/file1,v
+VERS: 1.1
+***************
+$
+</nowiki></pre></td></tr></table>
+
+<p>However, this isn’t the easiest way, if you are asking
+how to undo a previous checkin (in this example, put
+‘<tt>file1</tt>’ back to the way it was as of revision
+1.1). In that case you are better off using the
+‘<samp>-j</samp>’ option to <code>update</code>; for further
+discussion see [[#SEC62|Merging differences between any two revisions]].
+</p>
+<hr size="6">
+<div id="Branching-and-merging"></div>
+<div id="SEC54"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC53| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC55| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC44| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC_Top| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC65| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+== Branching and merging ==
+
+<p><small>CVS</small> allows you to isolate changes onto a separate
+line of development, known as a <em>branch</em>. When you
+change files on a branch, those changes do not appear
+on the main trunk or other branches.
+</p>
+<p>Later you can move changes from one branch to another
+branch (or the main trunk) by <em>merging</em>. Merging
+involves first running <code>cvs update -j</code>, to merge
+the changes into the working directory.
+You can then commit that revision, and thus effectively
+copy the changes onto another branch.
+</p>
+<pre class="menu-preformatted"><nowiki></nowiki>•[[#SEC55| Branches
motivation]]::<nowiki> What branches are good for
+</nowiki>•[[#SEC56| Creating a branch]]::<nowiki> Creating a
branch
+</nowiki>•[[#SEC57| Accessing branches]]::<nowiki> Checking out
and updating branches
+</nowiki>•[[#SEC58| Branches and revisions]]::<nowiki> Branches are
reflected in revision numbers
+</nowiki>•[[#SEC59| Magic branch numbers]]::<nowiki> Magic branch
numbers
+</nowiki>•[[#SEC60| Merging a branch]]::<nowiki> Merging an
entire branch
+</nowiki>•[[#SEC61| Merging more than once]]::<nowiki> Merging from
a branch several times
+</nowiki>•[[#SEC62| Merging two revisions]]::<nowiki> Merging
differences between two revisions
+</nowiki>•[[#SEC63| Merging adds and removals]]::<nowiki> What if files
are added or removed?
+</nowiki>•[[#SEC64| Merging and keywords]]::<nowiki> Avoiding
conflicts due to keyword substitution
+</nowiki></pre>
+<hr size="6">
+<div id="Branches-motivation"></div>
+<div id="SEC55"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC54| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC56| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC54| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC54| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC65| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== What branches are good for ===
+
+<p>Suppose that release 1.0 of tc has been made. You are continuing to
+develop tc, planning to create release 1.1 in a couple of months. After a
+while your customers start to complain about a fatal bug. You check
+out release 1.0 (see section [[#SEC48|Tags–Symbolic revisions]]) and
find the bug
+(which turns out to have a trivial fix). However, the current revision
+of the sources are in a state of flux and are not expected to be stable
+for at least another month. There is no way to make a
+bugfix release based on the newest sources.
+</p>
+<p>The thing to do in a situation like this is to create a <em>branch</em> on
+the revision trees for all the files that make up
+release 1.0 of tc. You can then make
+modifications to the branch without disturbing the main trunk. When the
+modifications are finished you can elect to either incorporate them on
+the main trunk, or leave them on the branch.
+</p>
+<hr size="6">
+<div id="Creating-a-branch"></div>
+<div id="SEC56"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC55| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC57| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC54| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC54| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC65| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== Creating a branch ===
+
+<p>You can create a branch with <code>tag -b</code>; for
+example, assuming you’re in a working copy:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>$ cvs tag -b
rel-1-0-patches
+</nowiki></pre></td></tr></table>
+
+
+<p>This splits off a branch based on the current revisions
+in the working copy, assigning that branch the name
+‘<samp>rel-1-0-patches</samp>’.
+</p>
+<p>It is important to understand that branches get created
+in the repository, not in the working copy. Creating a
+branch based on current revisions, as the above example
+does, will <em>not</em> automatically switch the working
+copy to be on the new branch. For information on how
+to do that, see [[#SEC57|Accessing branches]].
+</p>
+<p>You can also create a branch without reference to any
+working copy, by using <code>rtag</code>:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>$ cvs rtag -b -r
rel-1-0 rel-1-0-patches tc
+</nowiki></pre></td></tr></table>
+
+<p>‘<samp>-r rel-1-0</samp>’ says that this branch should be
+rooted at the revision that
+corresponds to the tag ‘<samp>rel-1-0</samp>’. It need not
+be the most recent revision – it’s often useful to
+split a branch off an old revision (for example, when
+fixing a bug in a past release otherwise known to be
+stable).
+</p>
+<p>As with ‘<samp>tag</samp>’, the ‘<samp>-b</samp>’
flag tells
+<code>rtag</code> to create a branch (rather than just a
+symbolic revision name). Note that the numeric
+revision number that matches ‘<samp>rel-1-0</samp>’ will
+probably be different from file to file.
+</p>
+<p>So, the full effect of the command is to create a new
+branch – named ‘<samp>rel-1-0-patches</samp>’ – in
module
+‘<samp>tc</samp>’, rooted in the revision tree at the point tagged
+by ‘<samp>rel-1-0</samp>’.
+</p>
+<hr size="6">
+<div id="Accessing-branches"></div>
+<div id="SEC57"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC56| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC58| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC54| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC54| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC65| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== Accessing branches ===
+
+<p>You can retrieve a branch in one of two ways: by
+checking it out fresh from the repository, or by
+switching an existing working copy over to the branch.
+</p>
+<p>To check out a branch from the repository, invoke
+‘<samp>checkout</samp>’ with the ‘<samp>-r</samp>’
flag, followed by
+the tag name of the branch (see section [[#SEC56|Creating a branch]]):
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>$ cvs checkout -r
rel-1-0-patches tc
+</nowiki></pre></td></tr></table>
+
+<p>Or, if you already have a working copy, you can switch
+it to a given branch with ‘<samp>update -r</samp>’:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>$ cvs update -r
rel-1-0-patches tc
+</nowiki></pre></td></tr></table>
+
+<p>or equivalently:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>$ cd tc
+$ cvs update -r rel-1-0-patches
+</nowiki></pre></td></tr></table>
+
+<p>It does not matter if the working copy was originally
+on the main trunk or on some other branch – the above
+command will switch it to the named branch. And
+similarly to a regular ‘<samp>update</samp>’ command,
+‘<samp>update -r</samp>’ merges any changes you have made,
+notifying you of conflicts where they occur.
+</p>
+<p>Once you have a working copy tied to a particular
+branch, it remains there until you tell it otherwise.
+This means that changes checked in from the working
+copy will add new revisions on that branch, while
+leaving the main trunk and other branches unaffected.
+</p>
+<div id="IDX120"></div>
+<p>To find out what branch a working copy is on, you can
+use the ‘<samp>status</samp>’ command. In its output, look for
+the field named ‘<samp>Sticky tag</samp>’ (see section
[[#SEC53|Sticky tags]])
+– that’s <small>CVS</small>’s way of telling you the branch,
if
+any, of the current working files:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>$ cvs status -v
driver.c backend.c
+===================================================================
+File: driver.c Status: Up-to-date
+
+ Version: 1.7 Sat Dec 5 18:25:54 1992
+ RCS Version: 1.7 /u/cvsroot/yoyodyne/tc/driver.c,v
+ Sticky Tag: rel-1-0-patches (branch: 1.7.2)
+ Sticky Date: (none)
+ Sticky Options: (none)
+
+ Existing Tags:
+ rel-1-0-patches (branch: 1.7.2)
+ rel-1-0 (revision: 1.7)
+
+===================================================================
+File: backend.c Status: Up-to-date
+
+ Version: 1.4 Tue Dec 1 14:39:01 1992
+ RCS Version: 1.4 /u/cvsroot/yoyodyne/tc/backend.c,v
+ Sticky Tag: rel-1-0-patches (branch: 1.4.2)
+ Sticky Date: (none)
+ Sticky Options: (none)
+
+ Existing Tags:
+ rel-1-0-patches (branch: 1.4.2)
+ rel-1-0 (revision: 1.4)
+ rel-0-4 (revision: 1.4)
+
+</nowiki></pre></td></tr></table>
+
+<p>Don’t be confused by the fact that the branch numbers
+for each file are different (‘<samp>1.7.2</samp>’ and
+‘<samp>1.4.2</samp>’ respectively). The branch tag is the
+same, ‘<samp>rel-1-0-patches</samp>’, and the files are
+indeed on the same branch. The numbers simply reflect
+the point in each file’s revision history at which the
+branch was made. In the above example, one can deduce
+that ‘<samp>driver.c</samp>’ had been through more changes than
+‘<samp>backend.c</samp>’ before this branch was created.
+</p>
+<p>See [[#SEC58|Branches and revisions]] for details about how
+branch numbers are constructed.
+</p>
+<hr size="6">
+<div id="Branches-and-revisions"></div>
+<div id="SEC58"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC57| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC59| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC54| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC54| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC65| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== Branches and revisions ===
+
+<p>Ordinarily, a file’s revision history is a linear
+series of increments (see section [[#SEC45|Revision numbers]]):
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki> +-----+
+-----+ +-----+ +-----+ +-----+
+ ! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 !
+ +-----+ +-----+ +-----+ +-----+ +-----+
+</nowiki></pre></td></tr></table>
+
+<p>However, <small>CVS</small> is not limited to linear development. The
+<em>revision tree</em> can be split into <em>branches</em>,
+where each branch is a self-maintained line of
+development. Changes made on one branch can easily be
+moved back to the main trunk.
+</p>
+<p>Each branch has a <em>branch number</em>, consisting of an
+odd number of period-separated decimal integers. The
+branch number is created by appending an integer to the
+revision number where the corresponding branch forked
+off. Having branch numbers allows more than one branch
+to be forked off from a certain revision.
+</p>
+<p>All revisions on a branch have revision numbers formed
+by appending an ordinal number to the branch number.
+The following figure illustrates branching with an
+example.
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>
+-------------+
+ Branch 1.2.2.3.2 -> ! 1.2.2.3.2.1 !
+ / +-------------+
+ /
+ /
+ +---------+ +---------+ +---------+
+Branch 1.2.2 -> _! 1.2.2.1 !----! 1.2.2.2 !----! 1.2.2.3 !
+ / +---------+ +---------+ +---------+
+ /
+ /
++-----+ +-----+ +-----+ +-----+ +-----+
+! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 ! <- The main trunk
++-----+ +-----+ +-----+ +-----+ +-----+
+ !
+ !
+ ! +---------+ +---------+ +---------+
+Branch 1.2.4 -> +---! 1.2.4.1 !----! 1.2.4.2 !----! 1.2.4.3 !
+ +---------+ +---------+ +---------+
+
+</nowiki></pre></td></tr></table>
+
+
+
+<p>The exact details of how the branch number is
+constructed is not something you normally need to be
+concerned about, but here is how it works: When
+<small>CVS</small> creates a branch number it picks the first
+unused even integer, starting with 2. So when you want
+to create a branch from revision 6.4 it will be
+numbered 6.4.2. All branch numbers ending in a zero
+(such as 6.4.0) are used internally by <small>CVS</small>
+(see section [[#SEC59|Magic branch numbers]]). The branch 1.1.1 has a
+special meaning. See section [[#SEC105|Tracking third-party sources]].
+</p>
+<hr size="6">
+<div id="Magic-branch-numbers"></div>
+<div id="SEC59"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC58| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC60| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC54| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC54| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC65| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== Magic branch numbers ===
+
+
+<p>This section describes a <small>CVS</small> feature called
+<em>magic branches</em>. For most purposes, you need not
+worry about magic branches; <small>CVS</small> handles them for
+you. However, they are visible to you in certain
+circumstances, so it may be useful to have some idea of
+how it works.
+</p>
+<p>Externally, branch numbers consist of an odd number of
+dot-separated decimal integers. See section [[#SEC45|Revision numbers]].
That is not the whole truth, however. For
+efficiency reasons <small>CVS</small> sometimes inserts an extra 0
+in the second rightmost position (1.2.4 becomes
+1.2.0.4, 8.9.10.11.12 becomes 8.9.10.11.0.12 and so
+on).
+</p>
+<p><small>CVS</small> does a pretty good job at hiding these so
+called magic branches, but in a few places the hiding
+is incomplete:
+</p>
+<ul>
+<li>
+The magic branch number appears in the output from
+<code>cvs log</code>.
+
+</li><li>
+You cannot specify a symbolic branch name to <code>cvs
+admin</code>.
+
+</li></ul>
+
+<p>You can use the <code>admin</code> command to reassign a
+symbolic name to a branch the way <small>RCS</small> expects it
+to be. If <code>R4patches</code> is assigned to the branch
+1.4.2 (magic branch number 1.4.0.2) in file
+‘<tt>numbers.c</tt>’ you can do this:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>$ cvs admin
-NR4patches:1.4.2 numbers.c
+</nowiki></pre></td></tr></table>
+
+<p>It only works if at least one revision is already
+committed on the branch. Be very careful so that you
+do not assign the tag to the wrong number. (There is
+no way to see how the tag was assigned yesterday).
+</p>
+<hr size="6">
+<div id="Merging-a-branch"></div>
+<div id="SEC60"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC59| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC61| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC54| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC54| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC65| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== Merging an entire branch ===
+
+<p>You can merge changes made on a branch into your working copy by giving
+the ‘<samp>-j <var>branchname</var></samp>’ flag to the
<code>update</code> subcommand. With one
+‘<samp>-j <var>branchname</var></samp>’ option it merges the
changes made between the
+greatest common ancestor (GCA) of the branch and the destination revision (in
+the simple case below the GCA is the point where the branch forked) and the
+newest revision on that branch into your working copy.
+</p>
+<div id="IDX121"></div>
+<p>The ‘<samp>-j</samp>’ stands for “join”.
+</p>
+<div id="IDX122"></div>
+<div id="IDX123"></div>
+<div id="IDX124"></div>
+<p>Consider this revision tree:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>+-----+ +-----+
+-----+ +-----+
+! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 ! <- The main trunk
++-----+ +-----+ +-----+ +-----+
+ !
+ !
+ ! +---------+ +---------+
+Branch R1fix -> +---! 1.2.2.1 !----! 1.2.2.2 !
+ +---------+ +---------+
+</nowiki></pre></td></tr></table>
+
+<p>The branch 1.2.2 has been given the tag (symbolic name)
‘<samp>R1fix</samp>’. The
+following example assumes that the module ‘<samp>mod</samp>’
contains only one
+file, ‘<tt>m.c</tt>’.
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>$ cvs checkout mod
# <span class="roman">Retrieve the latest revision, 1.4</span>
+
+$ cvs update -j R1fix m.c # <span class="roman">Merge all changes made
on the branch,</span>
+ # <span class="roman">i.e. the changes
between revision 1.2</span>
+ # <span class="roman">and 1.2.2.2, into your
working copy</span>
+ # <span class="roman">of the file.</span>
+
+$ cvs commit -m "Included R1fix" # <span class="roman">Create
revision 1.5.</span>
+</nowiki></pre></td></tr></table>
+
+<p>A conflict can result from a merge operation. If that
+happens, you should resolve it before committing the
+new revision. See section [[#SEC86|Conflicts example]].
+</p>
+<p>If your source files contain keywords (see section [[#SEC98|Keyword
substitution]]),
+you might be getting more conflicts than strictly necessary. See
+[[#SEC64|Merging and keywords]], for information on how to avoid this.
+</p>
+<p>The <code>checkout</code> command also supports the ‘<samp>-j
<var>branchname</var></samp>’ flag. The
+same effect as above could be achieved with this:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>$ cvs checkout -j
R1fix mod
+$ cvs commit -m "Included R1fix"
+</nowiki></pre></td></tr></table>
+
+<p>It should be noted that <code>update -j <var>tagname</var></code> will also
work but may
+not produce the desired result. See section [[#SEC63|Merging can add or
remove files]], for more.
+</p>
+<hr size="6">
+<div id="Merging-more-than-once"></div>
+<div id="SEC61"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC60| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC62| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC54| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC54| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC65| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== Merging from a branch several times ===
+
+<p>Continuing our example, the revision tree now looks
+like this:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>+-----+ +-----+
+-----+ +-----+ +-----+
+! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 ! <- The main trunk
++-----+ +-----+ +-----+ +-----+ +-----+
+ ! *
+ ! *
+ ! +---------+ +---------+
+Branch R1fix -> +---! 1.2.2.1 !----! 1.2.2.2 !
+ +---------+ +---------+
+</nowiki></pre></td></tr></table>
+
+<p>where the starred line represents the merge from the
+‘<samp>R1fix</samp>’ branch to the main trunk, as just
+discussed.
+</p>
+<p>Now suppose that development continues on the
+‘<samp>R1fix</samp>’ branch:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>+-----+ +-----+
+-----+ +-----+ +-----+
+! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 ! <- The main trunk
++-----+ +-----+ +-----+ +-----+ +-----+
+ ! *
+ ! *
+ ! +---------+ +---------+ +---------+
+Branch R1fix -> +---! 1.2.2.1 !----! 1.2.2.2 !----! 1.2.2.3 !
+ +---------+ +---------+ +---------+
+</nowiki></pre></td></tr></table>
+
+<p>and then you want to merge those new changes onto the
+main trunk. If you just use the <code>cvs update -j
+R1fix m.c</code> command again, <small>CVS</small> will attempt to
+merge again the changes which you have already merged,
+which can have undesirable side effects.
+</p>
+<p>So instead you need to specify that you only want to
+merge the changes on the branch which have not yet been
+merged into the trunk. To do that you specify two
+‘<samp>-j</samp>’ options, and <small>CVS</small> merges the
changes from
+the first revision to the second revision. For
+example, in this case the simplest way would be
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>cvs update -j
1.2.2.2 -j R1fix m.c # <span class="roman">Merge changes from 1.2.2.2 to
the</span>
+ # <span class="roman">head of the R1fix
branch</span>
+</nowiki></pre></td></tr></table>
+
+<p>The problem with this is that you need to specify the
+1.2.2.2 revision manually. A slightly better approach
+might be to use the date the last merge was done:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>cvs update -j
R1fix:yesterday -j R1fix m.c
+</nowiki></pre></td></tr></table>
+
+<p>Better yet, tag the R1fix branch after every merge into
+the trunk, and then use that tag for subsequent merges:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>cvs update -j
merged_from_R1fix_to_trunk -j R1fix m.c
+</nowiki></pre></td></tr></table>
+
+<hr size="6">
+<div id="Merging-two-revisions"></div>
+<div id="SEC62"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC61| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC63| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC54| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC54| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC65| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== Merging differences between any two revisions ===
+
+<p>With two ‘<samp>-j <var>revision</var></samp>’ flags, the
<code>update</code>
+(and <code>checkout</code>) command can merge the differences
+between any two revisions into your working file.
+</p>
+<div id="IDX125"></div>
+<div id="IDX126"></div>
+<table><tr><td> </td><td><pre class="example"><nowiki>$ cvs update -j 1.5
-j 1.3 backend.c
+</nowiki></pre></td></tr></table>
+
+<p>will undo all changes made between revision
+1.3 and 1.5. Note the order of the revisions!
+</p>
+<p>If you try to use this option when operating on
+multiple files, remember that the numeric revisions will
+probably be very different between the various files.
+You almost always use symbolic
+tags rather than revision numbers when operating on
+multiple files.
+</p>
+<div id="IDX127"></div>
+<div id="IDX128"></div>
+<p>Specifying two ‘<samp>-j</samp>’ options can also undo file
+removals or additions. For example, suppose you have
+a file
+named ‘<tt>file1</tt>’ which existed as revision 1.1, and
+you then removed it (thus adding a dead revision 1.2).
+Now suppose you want to add it again, with the same
+contents it had previously. Here is how to do it:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>$ cvs update -j 1.2
-j 1.1 file1
+U file1
+$ cvs commit -m test
+Checking in file1;
+/tmp/cvs-sanity/cvsroot/first-dir/file1,v <-- file1
+new revision: 1.3; previous revision: 1.2
+done
+$
+</nowiki></pre></td></tr></table>
+
+<hr size="6">
+<div id="Merging-adds-and-removals"></div>
+<div id="SEC63"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC62| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC64| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC54| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC54| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC65| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== Merging can add or remove files ===
+
+<p>If the changes which you are merging involve removing
+or adding some files, <code>update -j</code> will reflect
+such additions or removals.
+</p>
+<p>For example:
+</p><table><tr><td> </td><td><pre class="example"><nowiki>cvs update -A
+touch a b c
+cvs add a b c ; cvs ci -m "added" a b c
+cvs tag -b branchtag
+cvs update -r branchtag
+touch d ; cvs add d
+rm a ; cvs rm a
+cvs ci -m "added d, removed a"
+cvs update -A
+cvs update -jbranchtag
+</nowiki></pre></td></tr></table>
+
+<p>After these commands are executed and a ‘<samp>cvs
commit</samp>’ is done,
+file ‘<tt>a</tt>’ will be removed and file
‘<tt>d</tt>’ added in the main branch.
+</p>
+<p>Note that using a single static tag (‘<samp>-j
<var>tagname</var></samp>’)
+rather than a dynamic tag (‘<samp>-j
<var>branchname</var></samp>’) to merge
+changes from a branch will usually not remove files which were removed on the
+branch since <small>CVS</small> does not automatically add static tags to dead
revisions.
+The exception to this rule occurs when
+a static tag has been attached to a dead revision manually. Use the branch tag
+to merge all changes from the branch or use two static tags as merge endpoints
+to be sure that all intended changes are propagated in the merge.
+</p>
+<hr size="6">
+<div id="Merging-and-keywords"></div>
+<div id="SEC64"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC63| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC65| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC54| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC54| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC65| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== Merging and keywords ===
+
+<p>If you merge files containing keywords (see section [[#SEC98|Keyword
substitution]]), you will normally get numerous
+conflicts during the merge, because the keywords are
+expanded differently in the revisions which you are
+merging.
+</p>
+<p>Therefore, you will often want to specify the
+‘<samp>-kk</samp>’ (see section [[#SEC102|Substitution modes]])
switch to the
+merge command line. By substituting just the name of
+the keyword, not the expanded value of that keyword,
+this option ensures that the revisions which you are
+merging will be the same as each other, and avoid
+spurious conflicts.
+</p>
+<p>For example, suppose you have a file like this:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki> +---------+
+ _! 1.1.2.1 ! <- br1
+ / +---------+
+ /
+ /
++-----+ +-----+
+! 1.1 !----! 1.2 !
++-----+ +-----+
+</nowiki></pre></td></tr></table>
+
+<p>and your working directory is currently on the trunk
+(revision 1.2). Then you might get the following
+results from a merge:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>$ cat file1
+key $<i></i>Revision: 1.2 $
+. . .
+$ cvs update -j br1
+U file1
+RCS file: /cvsroot/first-dir/file1,v
+retrieving revision 1.1
+retrieving revision 1.1.2.1
+Merging differences between 1.1 and 1.1.2.1 into file1
+rcsmerge: warning: conflicts during merge
+$ cat file1
+<<<<<<< file1
+key $<i></i>Revision: 1.2 $
+=======
+key $<i></i>Revision: 1.1.2.1 $
+>>>>>>> 1.1.2.1
+. . .
+</nowiki></pre></td></tr></table>
+
+<p>What happened was that the merge tried to merge the
+differences between 1.1 and 1.1.2.1 into your working
+directory. So, since the keyword changed from
+<code>Revision: 1.1</code> to <code>Revision: 1.1.2.1</code>,
+<small>CVS</small> tried to merge that change into your working
+directory, which conflicted with the fact that your
+working directory had contained <code>Revision: 1.2</code>.
+</p>
+<p>Here is what happens if you had used ‘<samp>-kk</samp>’:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>$ cat file1
+key $<i></i>Revision: 1.2 $
+. . .
+$ cvs update -kk -j br1
+U file1
+RCS file: /cvsroot/first-dir/file1,v
+retrieving revision 1.1
+retrieving revision 1.1.2.1
+Merging differences between 1.1 and 1.1.2.1 into file1
+$ cat file1
+key $<i></i>Revision$
+. . .
+</nowiki></pre></td></tr></table>
+
+<p>What is going on here is that revision 1.1 and 1.1.2.1
+both expand as plain <code>Revision</code>, and therefore
+merging the changes between them into the working
+directory need not change anything. Therefore, there
+is no conflict.
+</p>
+<p><strong>WARNING: In versions of <small>CVS</small> prior to 1.12.2, there
was a
+major problem with using ‘<samp>-kk</samp>’ on merges. Namely,
‘<samp>-kk</samp>’
+overrode any default keyword expansion mode set in the archive file in
+the repository. This could, unfortunately for some users, cause data
+corruption in binary files (with a default keyword expansion mode set
+to ‘<samp>-kb</samp>’). Therefore, when a repository contained
binary files,
+conflicts had to be dealt with manually rather than using
‘<samp>-kk</samp>’ in
+a merge command.</strong>
+</p>
+<p>In <small>CVS</small> version 1.12.2 and later, the keyword expansion mode
+provided on the command line to any <small>CVS</small> command no longer
+overrides the ‘<samp>-kb</samp>’ keyword expansion mode setting
for binary
+files, though it will still override other default keyword expansion
+modes. You can now safely merge using ‘<samp>-kk</samp>’ to avoid
spurious conflicts
+on lines containing RCS keywords, even when your repository contains
+binary files.
+</p>
+<hr size="6">
+<div id="Recursive-behavior"></div>
+<div id="SEC65"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC64| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC66| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC54| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC_Top| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC66| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+== Recursive behavior ==
+
+<p>Almost all of the subcommands of <small>CVS</small> work
+recursively when you specify a directory as an
+argument. For instance, consider this directory
+structure:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>
<code>$HOME</code>
+ |
+ +--<tt>tc</tt>
+ | |
+ +--<tt>CVS</tt>
+ | (internal CVS files)
+ +--<tt>Makefile</tt>
+ +--<tt>backend.c</tt>
+ +--<tt>driver.c</tt>
+ +--<tt>frontend.c</tt>
+ +--<tt>parser.c</tt>
+ +--<tt>man</tt>
+ | |
+ | +--<tt>CVS</tt>
+ | | (internal CVS files)
+ | +--<tt>tc.1</tt>
+ |
+ +--<tt>testing</tt>
+ |
+ +--<tt>CVS</tt>
+ | (internal CVS files)
+ +--<tt>testpgm.t</tt>
+ +--<tt>test2.t</tt>
+</nowiki></pre></td></tr></table>
+
+<p>If ‘<tt>tc</tt>’ is the current working directory, the
+following is true:
+</p>
+<ul>
+<li>
+‘<samp>cvs update testing</samp>’ is equivalent to
+
+<table><tr><td> </td><td><pre class="example"><nowiki>cvs update
testing/testpgm.t testing/test2.t
+</nowiki></pre></td></tr></table>
+
+</li><li>
+‘<samp>cvs update testing man</samp>’ updates all files in the
+subdirectories
+
+</li><li>
+‘<samp>cvs update .</samp>’ or just ‘<samp>cvs
update</samp>’ updates
+all files in the <code>tc</code> directory
+</li></ul>
+
+<p>If no arguments are given to <code>update</code> it will
+update all files in the current working directory and
+all its subdirectories. In other words, ‘<tt>.</tt>’ is a
+default argument to <code>update</code>. This is also true
+for most of the <small>CVS</small> subcommands, not only the
+<code>update</code> command.
+</p>
+<p>The recursive behavior of the <small>CVS</small> subcommands can be
+turned off with the ‘<samp>-l</samp>’ option.
+Conversely, the ‘<samp>-R</samp>’ option can be used to force
recursion if
+‘<samp>-l</samp>’ is specified in ‘<tt>~/.cvsrc</tt>’
(see section [[#SEC117|Default options and the ~/.cvsrc file]]).
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>$ cvs update -l
# <span class="roman">Don't update files in subdirectories</span>
+</nowiki></pre></td></tr></table>
+
+<hr size="6">
+<div id="Adding-and-removing"></div>
+<div id="SEC66"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC65| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC67| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC65| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC_Top| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC75| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+== Adding, removing, and renaming files and directories ==
+
+<p>In the course of a project, one will often add new
+files. Likewise with removing or renaming, or with
+directories. The general concept to keep in mind in
+all these cases is that instead of making an
+irreversible change you want <small>CVS</small> to record the
+fact that a change has taken place, just as with
+modifying an existing file. The exact mechanisms to do
+this in <small>CVS</small> vary depending on the situation.
+</p>
+<pre class="menu-preformatted"><nowiki></nowiki>•[[#SEC67| Adding
files]]::<nowiki> Adding files
+</nowiki>•[[#SEC68| Removing files]]::<nowiki> Removing files
+</nowiki>•[[#SEC69| Removing directories]]::<nowiki> Removing
directories
+</nowiki>•[[#SEC70| Moving files]]::<nowiki> Moving and
renaming files
+</nowiki>•[[#SEC74| Moving directories]]::<nowiki> Moving and
renaming directories
+</nowiki></pre>
+<hr size="6">
+<div id="Adding-files"></div>
+<div id="SEC67"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC66| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC68| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC66| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC66| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC75| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== Adding files to a directory ===
+
+<p>To add a new file to a directory, follow these steps.
+</p>
+<ul>
+<li>
+You must have a working copy of the directory.
+See section [[#SEC5|Getting the source]].
+
+</li><li>
+Create the new file inside your working copy of the directory.
+
+</li><li>
+Use ‘<samp>cvs add <var>filename</var></samp>’ to tell
<small>CVS</small> that you
+want to version control the file. If the file contains
+binary data, specify ‘<samp>-kb</samp>’ (see section
[[#SEC80|Handling binary files]]).
+
+</li><li>
+Use ‘<samp>cvs commit <var>filename</var></samp>’ to actually check
+in the file into the repository. Other developers
+cannot see the file until you perform this step.
+</li></ul>
+
+<p>You can also use the <code>add</code> command to add a new
+directory.
+</p>
+<p>Unlike most other commands, the <code>add</code> command is
+not recursive. You cannot even type ‘<samp>cvs add
+foo/bar</samp>’! Instead, you have to
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>$ cd foo
+$ cvs add bar
+</nowiki></pre></td></tr></table>
+
+<div id="IDX129"></div>
+<dl>
+<dt><u>Command:</u> <b>cvs add</b><i> [<code>-k</code> kflag] [<code>-m</code>
message] files …</i>
+<div id="IDX130"></div>
+</dt>
+<dd><p>Schedule <var>files</var> to be added to the repository.
+The files or directories specified with <code>add</code> must
+already exist in the current directory. To add a whole
+new directory hierarchy to the source repository (for
+example, files received from a third-party vendor), use
+the <code>import</code> command instead. See section
[[#SEC139|import—Import sources into CVS, using vendor branches]].
+</p>
+<p>The added files are not placed in the source repository
+until you use <code>commit</code> to make the change
+permanent. Doing an <code>add</code> on a file that was
+removed with the <code>remove</code> command will undo the
+effect of the <code>remove</code>, unless a <code>commit</code>
+command intervened. See section [[#SEC68|Removing files]], for an
+example.
+</p>
+<p>The ‘<samp>-k</samp>’ option specifies the default way that
+this file will be checked out; for more information see
+[[#SEC102|Substitution modes]].
+</p>
+<p>The ‘<samp>-m</samp>’ option specifies a description for the
+file. This description appears in the history log (if
+it is enabled, see section [[#SEC178|The history file]]). It will also be
+saved in the version history inside the repository when
+the file is committed. The <code>log</code> command displays
+this description. The description can be changed using
+‘<samp>admin -t</samp>’. See section
[[#SEC120|admin—Administration]]. If you omit the
+‘<samp>-m <var>description</var></samp>’ flag, an empty string will
+be used. You will not be prompted for a description.
+</p></dd></dl>
+
+<p>For example, the following commands add the file
+‘<tt>backend.c</tt>’ to the repository:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>$ cvs add backend.c
+$ cvs commit -m "Early version. Not yet compilable." backend.c
+</nowiki></pre></td></tr></table>
+
+<p>When you add a file it is added only on the branch
+which you are working on (see section [[#SEC54|Branching and merging]]). You
can
+later merge the additions to another branch if you want
+(see section [[#SEC63|Merging can add or remove files]]).
+</p>
+<hr size="6">
+<div id="Removing-files"></div>
+<div id="SEC68"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC67| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC69| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC66| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC66| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC75| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== Removing files ===
+
+<p>Directories change. New files are added, and old files
+disappear. Still, you want to be able to retrieve an
+exact copy of old releases.
+</p>
+<p>Here is what you can do to remove a file,
+but remain able to retrieve old revisions:
+</p>
+<ul>
+<li>
+Make sure that you have not made any uncommitted
+modifications to the file. See section [[#SEC8|Viewing differences]],
+for one way to do that. You can also use the
+<code>status</code> or <code>update</code> command. If you remove
+the file without committing your changes, you will of
+course not be able to retrieve the file as it was
+immediately before you deleted it.
+
+</li><li>
+Remove the file from your working copy of the directory.
+You can for instance use <code>rm</code>.
+
+</li><li>
+Use ‘<samp>cvs remove <var>filename</var></samp>’ to tell
<small>CVS</small> that
+you really want to delete the file.
+
+</li><li>
+Use ‘<samp>cvs commit <var>filename</var></samp>’ to actually
+perform the removal of the file from the repository.
+</li></ul>
+
+<p>When you commit the removal of the file, <small>CVS</small>
+records the fact that the file no longer exists. It is
+possible for a file to exist on only some branches and
+not on others, or to re-add another file with the same
+name later. <small>CVS</small> will correctly create or not create
+the file, based on the ‘<samp>-r</samp>’ and
‘<samp>-D</samp>’ options
+specified to <code>checkout</code> or <code>update</code>.
+</p>
+<div id="IDX131"></div>
+<dl>
+<dt><u>Command:</u> <b>cvs remove</b><i> [options] files …</i>
+<div id="IDX132"></div>
+</dt>
+<dd><p>Schedule file(s) to be removed from the repository
+(files which have not already been removed from the
+working directory are not processed). This command
+does not actually remove the file from the repository
+until you commit the removal. For a full list of
+options, see [[#SEC156|Quick reference to CVS commands]].
+</p></dd></dl>
+
+<p>Here is an example of removing several files:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>$ cd test
+$ rm *.c
+$ cvs remove
+cvs remove: Removing .
+cvs remove: scheduling a.c for removal
+cvs remove: scheduling b.c for removal
+cvs remove: use 'cvs commit' to remove these files permanently
+$ cvs ci -m "Removed unneeded files"
+cvs commit: Examining .
+cvs commit: Committing .
+</nowiki></pre></td></tr></table>
+
+<p>As a convenience you can remove the file and <code>cvs
+remove</code> it in one step, by specifying the ‘<samp>-f</samp>’
+option. For example, the above example could also be
+done like this:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>$ cd test
+$ cvs remove -f *.c
+cvs remove: scheduling a.c for removal
+cvs remove: scheduling b.c for removal
+cvs remove: use 'cvs commit' to remove these files permanently
+$ cvs ci -m "Removed unneeded files"
+cvs commit: Examining .
+cvs commit: Committing .
+</nowiki></pre></td></tr></table>
+
+<p>If you execute <code>remove</code> for a file, and then
+change your mind before you commit, you can undo the
+<code>remove</code> with an <code>add</code> command.
+</p>
+
+<table><tr><td> </td><td><pre class="example"><nowiki>$ ls
+CVS ja.h oj.c
+$ rm oj.c
+$ cvs remove oj.c
+cvs remove: scheduling oj.c for removal
+cvs remove: use 'cvs commit' to remove this file permanently
+$ cvs add oj.c
+U oj.c
+cvs add: oj.c, version 1.1.1.1, resurrected
+</nowiki></pre></td></tr></table>
+
+<p>If you realize your mistake before you run the
+<code>remove</code> command you can use <code>update</code> to
+resurrect the file:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>$ rm oj.c
+$ cvs update oj.c
+cvs update: warning: oj.c was lost
+U oj.c
+</nowiki></pre></td></tr></table>
+
+<p>When you remove a file it is removed only on the branch
+which you are working on (see section [[#SEC54|Branching and merging]]). You
can
+later merge the removals to another branch if you want
+(see section [[#SEC63|Merging can add or remove files]]).
+</p>
+<hr size="6">
+<div id="Removing-directories"></div>
+<div id="SEC69"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC68| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC70| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC66| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC66| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC75| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== Removing directories ===
+
+<p>In concept removing directories is somewhat similar to
+removing files—you want the directory to not exist in
+your current working directories, but you also want to
+be able to retrieve old releases in which the directory
+existed.
+</p>
+<p>The way that you remove a directory is to remove all
+the files in it. You don’t remove the directory
+itself; there is no way to do that.
+Instead you specify the ‘<samp>-P</samp>’ option to
+<code>cvs update</code> or <code>cvs checkout</code>,
+which will cause <small>CVS</small> to remove empty
+directories from working directories.
+(Note that <code>cvs export</code> always removes empty directories.)
+Probably the
+best way to do this is to always specify ‘<samp>-P</samp>’; if
+you want an empty directory then put a dummy file (for
+example ‘<tt>.keepme</tt>’) in it to prevent
‘<samp>-P</samp>’ from
+removing it.
+</p>
+<p>Note that ‘<samp>-P</samp>’ is implied by the
‘<samp>-r</samp>’ or ‘<samp>-D</samp>’
+options of <code>checkout</code>. This way
+<small>CVS</small> will be able to correctly create the directory
+or not depending on whether the particular version you
+are checking out contains any files in that directory.
+</p>
+<hr size="6">
+<div id="Moving-files"></div>
+<div id="SEC70"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC69| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC71| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC66| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC66| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC75| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== Moving and renaming files ===
+
+<p>Moving files to a different directory or renaming them
+is not difficult, but some of the ways in which this
+works may be non-obvious. (Moving or renaming a
+directory is even harder. See section [[#SEC74|Moving and renaming
directories]].).
+</p>
+<p>The examples below assume that the file <var>old</var> is renamed to
+<var>new</var>.
+</p>
+<pre class="menu-preformatted"><nowiki></nowiki>•[[#SEC71|
Outside]]::<nowiki> The normal way to Rename
+</nowiki>•[[#SEC72| Inside]]::<nowiki> A tricky,
alternative way
+</nowiki>•[[#SEC73| Rename by copying]]::<nowiki> Another
tricky, alternative way
+</nowiki></pre>
+<hr size="6">
+<div id="Outside"></div>
+<div id="SEC71"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC70| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC72| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC66| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC70| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC75| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+==== The Normal way to Rename ====
+
+
+<p>The normal way to move a file is to copy <var>old</var> to
+<var>new</var>, and then issue the normal <small>CVS</small> commands
+to remove <var>old</var> from the repository, and add
+<var>new</var> to it.
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>$ mv <var>old</var>
<var>new</var>
+$ cvs remove <var>old</var>
+$ cvs add <var>new</var>
+$ cvs commit -m "Renamed <var>old</var> to <var>new</var>"
<var>old</var> <var>new</var>
+</nowiki></pre></td></tr></table>
+
+<p>This is the simplest way to move a file, it is not
+error-prone, and it preserves the history of what was
+done. Note that to access the history of the file you
+must specify the old or the new name, depending on what
+portion of the history you are accessing. For example,
+<code>cvs log <var>old</var></code> will give the log up until the
+time of the rename.
+</p>
+<p>When <var>new</var> is committed its revision numbers will
+start again, usually at 1.1, so if that bothers you,
+use the ‘<samp>-r rev</samp>’ option to commit. For more
+information see [[#SEC47|Assigning revisions]].
+</p>
+<hr size="6">
+<div id="Inside"></div>
+<div id="SEC72"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC71| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC73| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC66| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC70| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC75| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+==== Moving the history file ====
+
+<p>This method is more dangerous, since it involves moving
+files inside the repository. Read this entire section
+before trying it out!
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>$ cd
$CVSROOT/<var>dir</var>
+$ mv <var>old</var>,v <var>new</var>,v
+</nowiki></pre></td></tr></table>
+
+<p>Advantages:
+</p>
+<ul>
+<li>
+The log of changes is maintained intact.
+
+</li><li>
+The revision numbers are not affected.
+</li></ul>
+
+<p>Disadvantages:
+</p>
+<ul>
+<li>
+Old releases cannot easily be fetched from the
+repository. (The file will show up as <var>new</var> even
+in revisions from the time before it was renamed).
+
+</li><li>
+There is no log information of when the file was renamed.
+
+</li><li>
+Nasty things might happen if someone accesses the history file
+while you are moving it. Make sure no one else runs any of the
<small>CVS</small>
+commands while you move it.
+</li></ul>
+
+<hr size="6">
+<div id="Rename-by-copying"></div>
+<div id="SEC73"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC72| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC74| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC66| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC70| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC75| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+==== Copying the history file ====
+
+<p>This way also involves direct modifications to the
+repository. It is safe, but not without drawbacks.
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki># <span
class="roman">Copy the RCS file inside the repository</span>
+$ cd $CVSROOT/<var>dir</var>
+$ cp <var>old</var>,v <var>new</var>,v
+# <span class="roman">Remove the old file</span>
+$ cd ~/<var>dir</var>
+$ rm <var>old</var>
+$ cvs remove <var>old</var>
+$ cvs commit <var>old</var>
+# <span class="roman">Remove all tags from <var>new</var></span>
+$ cvs update <var>new</var>
+$ cvs log <var>new</var> # <span class="roman">Remember the
non-branch tag names</span>
+$ cvs tag -d <var>tag1</var> <var>new</var>
+$ cvs tag -d <var>tag2</var> <var>new</var>
+…
+</nowiki></pre></td></tr></table>
+
+<p>By removing the tags you will be able to check out old
+revisions.
+</p>
+<p>Advantages:
+</p>
+<ul>
+<li>
+Checking out old revisions works correctly, as long as
+you use ‘<samp>-r<var>tag</var></samp>’ and not
‘<samp>-D<var>date</var></samp>’
+to retrieve the revisions.
+
+</li><li>
+The log of changes is maintained intact.
+
+</li><li>
+The revision numbers are not affected.
+</li></ul>
+
+<p>Disadvantages:
+</p>
+<ul>
+<li>
+You cannot easily see the history of the file across the rename.
+
+</li></ul>
+
+<hr size="6">
+<div id="Moving-directories"></div>
+<div id="SEC74"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC73| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC75| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC66| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC66| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC75| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== Moving and renaming directories ===
+
+<p>The normal way to rename or move a directory is to
+rename or move each file within it as described in
+[[#SEC71|The Normal way to Rename]]. Then check out with the
‘<samp>-P</samp>’
+option, as described in [[#SEC69|Removing directories]].
+</p>
+<p>If you really want to hack the repository to rename or
+delete a directory in the repository, you can do it
+like this:
+</p>
+<ol>
+<li>
+Inform everyone who has a checked out copy of the directory that the
+directory will be renamed. They should commit all
+their changes, and remove their working copies,
+before you take the steps below.
+
+</li><li>
+Rename the directory inside the repository.
+
+<table><tr><td> </td><td><pre class="example"><nowiki>$ cd
$CVSROOT/<var>parent-dir</var>
+$ mv <var>old-dir</var> <var>new-dir</var>
+</nowiki></pre></td></tr></table>
+
+</li><li>
+Fix the <small>CVS</small> administrative files, if necessary (for
+instance if you renamed an entire module).
+
+</li><li>
+Tell everyone that they can check out again and continue
+working.
+
+</li></ol>
+
+<p>If someone had a working copy the <small>CVS</small> commands will
+cease to work for him, until he removes the directory
+that disappeared inside the repository.
+</p>
+<p>It is almost always better to move the files in the
+directory instead of moving the directory. If you move the
+directory you are unlikely to be able to retrieve old
+releases correctly, since they probably depend on the
+name of the directories.
+</p>
+<hr size="6">
+<div id="History-browsing"></div>
+<div id="SEC75"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC74| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC76| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC66| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC_Top| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC80| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+== History browsing ==
+
+
+<p>Once you have used <small>CVS</small> to store a version control
+history—what files have changed when, how, and by
+whom, there are a variety of mechanisms for looking
+through the history.
+</p>
+<pre class="menu-preformatted"><nowiki></nowiki>•[[#SEC76| log
messages]]::<nowiki> Log messages
+</nowiki>•[[#SEC77| history database]]::<nowiki> The history
database
+</nowiki>•[[#SEC78| user-defined logging]]::<nowiki> User-defined
logging
+</nowiki>•[[#SEC79| annotate]]::<nowiki> What revision
modified each line of a file?
+</nowiki></pre>
+<hr size="6">
+<div id="log-messages"></div>
+<div id="SEC76"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC75| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC77| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC75| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC75| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC80| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== Log messages ===
+
+<p>Whenever you commit a file you specify a log message.
+</p>
+<p>To look through the log messages which have been
+specified for every revision which has been committed,
+use the <code>cvs log</code> command (see section [[#SEC143|log—Print
out log information for files]]).
+</p>
+<hr size="6">
+<div id="history-database"></div>
+<div id="SEC77"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC76| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC78| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC75| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC75| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC80| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== The history database ===
+
+<p>You can use the history file (see section [[#SEC178|The history file]]) to
+log various <small>CVS</small> actions. To retrieve the
+information from the history file, use the <code>cvs
+history</code> command (see section [[#SEC137|history—Show status of
files and users]]).
+</p>
+<p>Note: you can control what is logged to this file by using the
+‘<samp>LogHistory</samp>’ keyword in the
‘<tt>CVSROOT/config</tt>’ file
+(see section [[#SEC180|The CVSROOT/config configuration file]]).
+</p>
+
+<hr size="6">
+<div id="user_002ddefined-logging"></div>
+<div id="SEC78"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC77| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC79| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC75| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC75| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC80| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== User-defined logging ===
+
+<p>You can customize <small>CVS</small> to log various kinds of
+actions, in whatever manner you choose. These
+mechanisms operate by executing a script at various
+times. The script might append a message to a file
+listing the information and the programmer who created
+it, or send mail to a group of developers, or, perhaps,
+post a message to a particular newsgroup. To log
+commits, use the ‘<tt>loginfo</tt>’ file (see section
[[#SEC172|Loginfo]]).
+To log commits, checkouts, exports, and tags,
+respectively, you can also use the ‘<samp>-i</samp>’,
+‘<samp>-o</samp>’, ‘<samp>-e</samp>’, and
‘<samp>-t</samp>’ options in the
+modules file. For a more flexible way of giving
+notifications to various users, which requires less in
+the way of keeping centralized scripts up to date, use
+the <code>cvs watch add</code> command (see section [[#SEC91|Telling CVS to
notify you]]); this command is useful even if you are not
+using <code>cvs watch on</code>.
+</p>
+<div id="IDX133"></div>
+<div id="IDX134"></div>
+<p>The ‘<tt>taginfo</tt>’ file defines programs to execute
+when someone executes a <code>tag</code> or <code>rtag</code>
+command. The ‘<tt>taginfo</tt>’ file has the standard form
+for administrative files (see section [[#SEC157|Reference manual for
Administrative files]]), where each line is a regular expression
+followed by a command to execute. The arguments passed
+to the command are, in order, the <var>tagname</var>,
+<var>operation</var> (<code>add</code> for <code>tag</code>,
+<code>mov</code> for <code>tag -F</code>, and <code>del</code> for
+<code>tag -d</code>), <var>repository</var>, and any remaining are
+pairs of <var>filename</var> <var>revision</var>. A non-zero
+exit of the filter program will cause the tag to be
+aborted.
+</p>
+<p>Here is an example of using taginfo to log tag and rtag
+commands. In the taginfo file put:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>ALL
/usr/local/cvsroot/CVSROOT/loggit
+</nowiki></pre></td></tr></table>
+
+<p>Where ‘<tt>/usr/local/cvsroot/CVSROOT/loggit</tt>’ contains the
+following script:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>#!/bin/sh
+echo "$@" >>/home/kingdon/cvsroot/CVSROOT/taglog
+</nowiki></pre></td></tr></table>
+
+<hr size="6">
+<div id="annotate"></div>
+<div id="SEC79"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC78| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC80| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC75| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC75| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC80| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== Annotate command ===
+
+<dl>
+<dt><u>Command:</u> <b>cvs annotate</b><i> [<code>-FflR</code>] [<code>-r
rev</code>|<code>-D date</code>] files …</i>
+<div id="IDX135"></div>
+</dt>
+<dd><p>For each file in <var>files</var>, print the head revision
+of the trunk, together with information on the last
+modification for each line. For example:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>$ cvs annotate
ssfile
+Annotations for ssfile
+***************
+1.1 (mary 27-Mar-96): ssfile line 1
+1.2 (joe 28-Mar-96): ssfile line 2
+</nowiki></pre></td></tr></table>
+
+<p>The file ‘<tt>ssfile</tt>’ currently contains two lines.
+The <code>ssfile line 1</code> line was checked in by
+<code>mary</code> on March 27. Then, on March 28, <code>joe</code>
+added a line <code>ssfile line 2</code>, without modifying
+the <code>ssfile line 1</code> line. This report doesn’t
+tell you anything about lines which have been deleted
+or replaced; you need to use <code>cvs diff</code> for that
+(see section [[#SEC130|diff—Show differences between revisions]]).
+</p>
+</dd></dl>
+
+<p>The options to <code>cvs annotate</code> are listed in
+[[#SEC156|Quick reference to CVS commands]], and can be used to select the
files
+and revisions to annotate. The options are described
+in more detail there and in [[#SEC119|Common command options]].
+</p>
+
+<hr size="6">
+<div id="Binary-files"></div>
+<div id="SEC80"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC79| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC81| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC75| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC_Top| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC83| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+== Handling binary files ==
+
+<p>The most common use for <small>CVS</small> is to store text
+files. With text files, <small>CVS</small> can merge revisions,
+display the differences between revisions in a
+human-visible fashion, and other such operations.
+However, if you are willing to give up a few of these
+abilities, <small>CVS</small> can store binary files. For
+example, one might store a web site in <small>CVS</small>
+including both text files and binary images.
+</p>
+<pre class="menu-preformatted"><nowiki></nowiki>•[[#SEC81| Binary
why]]::<nowiki> More details on issues with binary files
+</nowiki>•[[#SEC82| Binary howto]]::<nowiki> How to store them
+</nowiki></pre>
+<hr size="6">
+<div id="Binary-why"></div>
+<div id="SEC81"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC80| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC82| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC80| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC80| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC83| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== The issues with binary files ===
+
+<p>While the need to manage binary files may seem obvious
+if the files that you customarily work with are binary,
+putting them into version control does present some
+additional issues.
+</p>
+<p>One basic function of version control is to show the
+differences between two revisions. For example, if
+someone else checked in a new version of a file, you
+may wish to look at what they changed and determine
+whether their changes are good. For text files,
+<small>CVS</small> provides this functionality via the <code>cvs
+diff</code> command. For binary files, it may be possible to
+extract the two revisions and then compare them with a
+tool external to <small>CVS</small> (for example, word processing
+software often has such a feature). If there is no
+such tool, one must track changes via other mechanisms,
+such as urging people to write good log messages, and
+hoping that the changes they actually made were the
+changes that they intended to make.
+</p>
+<p>Another ability of a version control system is the
+ability to merge two revisions. For <small>CVS</small> this
+happens in two contexts. The first is when users make
+changes in separate working directories
+(see section [[#SEC83|Multiple developers]]). The second is when one
+merges explicitly with the ‘<samp>update -j</samp>’ command
+(see section [[#SEC54|Branching and merging]]).
+</p>
+<p>In the case of text
+files, <small>CVS</small> can merge changes made independently,
+and signal a conflict if the changes conflict. With
+binary files, the best that <small>CVS</small> can do is present
+the two different copies of the file, and leave it to
+the user to resolve the conflict. The user may choose
+one copy or the other, or may run an external merge
+tool which knows about that particular file format, if
+one exists.
+Note that having the user merge relies primarily on the
+user to not accidentally omit some changes, and thus is
+potentially error prone.
+</p>
+<p>If this process is thought to be undesirable, the best
+choice may be to avoid merging. To avoid the merges
+that result from separate working directories, see the
+discussion of reserved checkouts (file locking) in
+[[#SEC83|Multiple developers]]. To avoid the merges
+resulting from branches, restrict use of branches.
+</p>
+<hr size="6">
+<div id="Binary-howto"></div>
+<div id="SEC82"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC81| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC83| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC80| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC80| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC83| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== How to store binary files ===
+
+<p>There are two issues with using <small>CVS</small> to store
+binary files. The first is that <small>CVS</small> by default
+converts line endings between the canonical form in
+which they are stored in the repository (linefeed
+only), and the form appropriate to the operating system
+in use on the client (for example, carriage return
+followed by line feed for Windows NT).
+</p>
+<p>The second is that a binary file might happen to
+contain data which looks like a keyword (see section [[#SEC98|Keyword
substitution]]), so keyword expansion must be turned
+off.
+</p>
+
+<p>The ‘<samp>-kb</samp>’ option available with some
<small>CVS</small>
+commands insures that neither line ending conversion
+nor keyword expansion will be done.
+</p>
+<p>Here is an example of how you can create a new file
+using the ‘<samp>-kb</samp>’ flag:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>$ echo
'$<i></i>Id$' > kotest
+$ cvs add -kb -m"A test file" kotest
+$ cvs ci -m"First checkin; contains a keyword" kotest
+</nowiki></pre></td></tr></table>
+
+<p>If a file accidentally gets added without ‘<samp>-kb</samp>’,
+one can use the <code>cvs admin</code> command to recover.
+For example:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>$ echo
'$<i></i>Id$' > kotest
+$ cvs add -m"A test file" kotest
+$ cvs ci -m"First checkin; contains a keyword" kotest
+$ cvs admin -kb kotest
+$ cvs update -A kotest
+# <span class="roman">For non-unix systems:</span>
+# <span class="roman">Copy in a good copy of the file from outside CVS</span>
+$ cvs commit -m "make it binary" kotest
+</nowiki></pre></td></tr></table>
+
+<p>When you check in the file ‘<tt>kotest</tt>’ the file is
+not preserved as a binary file, because you did not
+check it in as a binary file. The <code>cvs
+admin -kb</code> command sets the default keyword
+substitution method for this file, but it does not
+alter the working copy of the file that you have. If you need to
+cope with line endings (that is, you are using
+<small>CVS</small> on a non-unix system), then you need to
+check in a new copy of the file, as shown by the
+<code>cvs commit</code> command above.
+On unix, the <code>cvs update -A</code> command suffices.
+(Note that you can use <code>cvs log</code> to determine the default keyword
+substitution method for a file and <code>cvs status</code> to determine
+the keyword substitution method for a working copy.)
+</p>
+<p>However, in using <code>cvs admin -k</code> to change the
+keyword expansion, be aware that the keyword expansion
+mode is not version controlled. This means that, for
+example, that if you have a text file in old releases,
+and a binary file with the same name in new releases,
+<small>CVS</small> provides no way to check out the file in text
+or binary mode depending on what version you are
+checking out. There is no good workaround for this
+problem.
+</p>
+<p>You can also set a default for whether <code>cvs add</code>
+and <code>cvs import</code> treat a file as binary based on
+its name; for example you could say that files who
+names end in ‘<samp>.exe</samp>’ are binary. See section
[[#SEC165|The cvswrappers file]].
+There is currently no way to have <small>CVS</small> detect
+whether a file is binary based on its contents. The
+main difficulty with designing such a feature is that
+it is not clear how to distinguish between binary and
+non-binary files, and the rules to apply would vary
+considerably with the operating system.
+</p>
+<hr size="6">
+<div id="Multiple-developers"></div>
+<div id="SEC83"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC82| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC84| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC80| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC_Top| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC96| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+== Multiple developers ==
+
+<p>When more than one person works on a software project
+things often get complicated. Often, two people try to
+edit the same file simultaneously. One solution, known
+as <em>file locking</em> or <em>reserved checkouts</em>, is
+to allow only one person to edit each file at a time.
+This is the only solution with some version control
+systems, including <small>RCS</small> and <small>SCCS</small>. Currently
+the usual way to get reserved checkouts with <small>CVS</small>
+is the <code>cvs admin -l</code> command (see section [[#SEC121|admin
options]]). This is not as nicely integrated into
+<small>CVS</small> as the watch features, described below, but it
+seems that most people with a need for reserved
+checkouts find it adequate.
+It also may be possible to use the watches
+features described below, together with suitable
+procedures (not enforced by software), to avoid having
+two people edit at the same time.
+</p>
+<p>The default model with <small>CVS</small> is known as
+<em>unreserved checkouts</em>. In this model, developers
+can edit their own <em>working copy</em> of a file
+simultaneously. The first person that commits his
+changes has no automatic way of knowing that another
+has started to edit it. Others will get an error
+message when they try to commit the file. They must
+then use <small>CVS</small> commands to bring their working copy
+up to date with the repository revision. This process
+is almost automatic.
+</p>
+<p><small>CVS</small> also supports mechanisms which facilitate
+various kinds of communication, without actually
+enforcing rules like reserved checkouts do.
+</p>
+<p>The rest of this chapter describes how these various
+models work, and some of the issues involved in
+choosing between them.
+</p>
+
+<pre class="menu-preformatted"><nowiki></nowiki>•[[#SEC84| File
status]]::<nowiki> A file can be in several states
+</nowiki>•[[#SEC85| Updating a file]]::<nowiki> Bringing a
file up-to-date
+</nowiki>•[[#SEC86| Conflicts example]]::<nowiki> An
informative example
+</nowiki>•[[#SEC87| Informing others]]::<nowiki> To cooperate
you must inform
+</nowiki>•[[#SEC88| Concurrency]]::<nowiki> Simultaneous
repository access
+</nowiki>•[[#SEC89| Watches]]::<nowiki> Mechanisms to
track who is editing files
+</nowiki>•[[#SEC95| Choosing a model]]::<nowiki> Reserved or
unreserved checkouts?
+</nowiki></pre>
+<hr size="6">
+<div id="File-status"></div>
+<div id="SEC84"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC83| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC85| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC83| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC83| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC96| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== File status ===
+
+<p>Based on what operations you have performed on a
+checked out file, and what operations others have
+performed to that file in the repository, one can
+classify a file in a number of states. The states, as
+reported by the <code>status</code> command, are:
+</p>
+<dl compact="compact">
+<dd><div id="IDX136"></div>
+</dd>
+<dt> Up-to-date</dt>
+<dd><p>The file is identical with the latest revision in the
+repository for the branch in use.
+</p>
+</dd>
+<dt> Locally Modified</dt>
+<dd><div id="IDX137"></div>
+<p>You have edited the file, and not yet committed your changes.
+</p>
+</dd>
+<dt> Locally Added</dt>
+<dd><div id="IDX138"></div>
+<p>You have added the file with <code>add</code>, and not yet
+committed your changes.
+</p>
+</dd>
+<dt> Locally Removed</dt>
+<dd><div id="IDX139"></div>
+<p>You have removed the file with <code>remove</code>, and not yet
+committed your changes.
+</p>
+</dd>
+<dt> Needs Checkout</dt>
+<dd><div id="IDX140"></div>
+<p>Someone else has committed a newer revision to the
+repository. The name is slightly misleading; you will
+ordinarily use <code>update</code> rather than
+<code>checkout</code> to get that newer revision.
+</p>
+</dd>
+<dt> Needs Patch</dt>
+<dd><div id="IDX141"></div>
+<p>Like Needs Checkout, but the <small>CVS</small> server will send
+a patch rather than the entire file. Sending a patch or
+sending an entire file accomplishes the same thing.
+</p>
+</dd>
+<dt> Needs Merge</dt>
+<dd><div id="IDX142"></div>
+<p>Someone else has committed a newer revision to the repository, and you
+have also made modifications to the file.
+</p>
+</dd>
+<dt> Unresolved Conflict</dt>
+<dd><div id="IDX143"></div>
+<p>A file with the same name as this new file has been added to the repository
+from a second workspace. This file will need to be moved out of the way
+to allow an <code>update</code> to complete.
+</p>
+</dd>
+<dt> File had conflicts on merge</dt>
+<dd><div id="IDX144"></div>
+<p>This is like Locally Modified, except that a previous
+<code>update</code> command gave a conflict. If you have not
+already done so, you need to
+resolve the conflict as described in [[#SEC86|Conflicts example]].
+</p>
+</dd>
+<dt> Unknown</dt>
+<dd><div id="IDX145"></div>
+<p><small>CVS</small> doesn’t know anything about this file. For
+example, you have created a new file and have not run
+<code>add</code>.
+</p>
+</dd>
+</dl>
+
+<p>To help clarify the file status, <code>status</code> also
+reports the <code>Working revision</code> which is the
+revision that the file in the working directory derives
+from, and the <code>Repository revision</code> which is the
+latest revision in the repository for the branch in
+use.
+</p>
+<p>The options to <code>status</code> are listed in
+[[#SEC156|Quick reference to CVS commands]]. For information on its
<code>Sticky tag</code>
+and <code>Sticky date</code> output, see [[#SEC53|Sticky tags]].
+For information on its <code>Sticky options</code> output,
+see the ‘<samp>-k</samp>’ option in [[#SEC154|update options]].
+</p>
+<p>You can think of the <code>status</code> and <code>update</code>
+commands as somewhat complementary. You use
+<code>update</code> to bring your files up to date, and you
+can use <code>status</code> to give you some idea of what an
+<code>update</code> would do (of course, the state of the
+repository might change before you actually run
+<code>update</code>). In fact, if you want a command to
+display file status in a more brief format than is
+displayed by the <code>status</code> command, you can invoke
+</p>
+<div id="IDX146"></div>
+<table><tr><td> </td><td><pre class="example"><nowiki>$ cvs -n -q update
+</nowiki></pre></td></tr></table>
+
+<p>The ‘<samp>-n</samp>’ option means to not actually do the
+update, but merely to display statuses; the ‘<samp>-q</samp>’
+option avoids printing the name of each directory. For
+more information on the <code>update</code> command, and
+these options, see [[#SEC156|Quick reference to CVS commands]].
+</p>
+<hr size="6">
+<div id="Updating-a-file"></div>
+<div id="SEC85"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC84| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC86| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC83| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC83| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC96| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== Bringing a file up to date ===
+
+<p>When you want to update or merge a file, use the <code>update</code>
+command. For files that are not up to date this is roughly equivalent
+to a <code>checkout</code> command: the newest revision of the file is
+extracted from the repository and put in your working directory.
+</p>
+<p>Your modifications to a file are never lost when you
+use <code>update</code>. If no newer revision exists,
+running <code>update</code> has no effect. If you have
+edited the file, and a newer revision is available,
+<small>CVS</small> will merge all changes into your working copy.
+</p>
+<p>For instance, imagine that you checked out revision 1.4 and started
+editing it. In the meantime someone else committed revision 1.5, and
+shortly after that revision 1.6. If you run <code>update</code> on the file
+now, <small>CVS</small> will incorporate all changes between revision 1.4 and
1.6 into
+your file.
+</p>
+<div id="IDX147"></div>
+<p>If any of the changes between 1.4 and 1.6 were made too
+close to any of the changes you have made, an
+<em>overlap</em> occurs. In such cases a warning is
+printed, and the resulting file includes both
+versions of the lines that overlap, delimited by
+special markers.
+See section [[#SEC153|update—Bring work tree in sync with repository]],
for a complete description of the
+<code>update</code> command.
+</p>
+<hr size="6">
+<div id="Conflicts-example"></div>
+<div id="SEC86"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC85| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC87| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC83| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC83| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC96| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== Conflicts example ===
+
+<p>Suppose revision 1.4 of ‘<tt>driver.c</tt>’ contains this:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>#include
<stdio.h>
+
+void main()
+{
+ parse();
+ if (nerr == 0)
+ gencode();
+ else
+ fprintf(stderr, "No code generated.\n");
+ exit(nerr == 0 ? 0 : 1);
+}
+</nowiki></pre></td></tr></table>
+
+<p>Revision 1.6 of ‘<tt>driver.c</tt>’ contains this:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>#include
<stdio.h>
+
+int main(int argc,
+ char **argv)
+{
+ parse();
+ if (argc != 1)
+ {
+ fprintf(stderr, "tc: No args expected.\n");
+ exit(1);
+ }
+ if (nerr == 0)
+ gencode();
+ else
+ fprintf(stderr, "No code generated.\n");
+ exit(!!nerr);
+}
+</nowiki></pre></td></tr></table>
+
+<p>Your working copy of ‘<tt>driver.c</tt>’, based on revision
+1.4, contains this before you run ‘<samp>cvs update</samp>’:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>#include
<stdlib.h>
+#include <stdio.h>
+
+void main()
+{
+ init_scanner();
+ parse();
+ if (nerr == 0)
+ gencode();
+ else
+ fprintf(stderr, "No code generated.\n");
+ exit(nerr == 0 ? EXIT_SUCCESS : EXIT_FAILURE);
+}
+</nowiki></pre></td></tr></table>
+
+<p>You run ‘<samp>cvs update</samp>’:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>$ cvs update
driver.c
+RCS file: /usr/local/cvsroot/yoyodyne/tc/driver.c,v
+retrieving revision 1.4
+retrieving revision 1.6
+Merging differences between 1.4 and 1.6 into driver.c
+rcsmerge warning: overlaps during merge
+cvs update: conflicts found in driver.c
+C driver.c
+</nowiki></pre></td></tr></table>
+
+<div id="IDX148"></div>
+<p><small>CVS</small> tells you that there were some conflicts.
+Your original working file is saved unmodified in
+‘<tt>.#driver.c.1.4</tt>’. The new version of
+‘<tt>driver.c</tt>’ contains this:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>#include
<stdlib.h>
+#include <stdio.h>
+
+int main(int argc,
+ char **argv)
+{
+ init_scanner();
+ parse();
+ if (argc != 1)
+ {
+ fprintf(stderr, "tc: No args expected.\n");
+ exit(1);
+ }
+ if (nerr == 0)
+ gencode();
+ else
+ fprintf(stderr, "No code generated.\n");
+<<<<<<< driver.c
+ exit(nerr == 0 ? EXIT_SUCCESS : EXIT_FAILURE);
+=======
+ exit(!!nerr);
+>>>>>>> 1.6
+}
+</nowiki></pre></td></tr></table>
+
+<div id="IDX149"></div>
+<div id="IDX150"></div>
+<div id="IDX151"></div>
+<div id="IDX152"></div>
+<div id="IDX153"></div>
+
+<p>Note how all non-overlapping modifications are incorporated in your working
+copy, and that the overlapping section is clearly marked with
+‘<samp><<<<<<<</samp>’,
‘<samp>=======</samp>’ and
‘<samp>>>>>>>></samp>’.
+</p>
+<div id="IDX154"></div>
+<div id="IDX155"></div>
+<p>You resolve the conflict by editing the file, removing the markers and
+the erroneous line. Suppose you end up with this file:
+</p><table><tr><td> </td><td><pre class="example"><nowiki>#include
<stdlib.h>
+#include <stdio.h>
+
+int main(int argc,
+ char **argv)
+{
+ init_scanner();
+ parse();
+ if (argc != 1)
+ {
+ fprintf(stderr, "tc: No args expected.\n");
+ exit(1);
+ }
+ if (nerr == 0)
+ gencode();
+ else
+ fprintf(stderr, "No code generated.\n");
+ exit(nerr == 0 ? EXIT_SUCCESS : EXIT_FAILURE);
+}
+</nowiki></pre></td></tr></table>
+
+<p>You can now go ahead and commit this as revision 1.7.
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>$ cvs commit -m
"Initialize scanner. Use symbolic exit values." driver.c
+Checking in driver.c;
+/usr/local/cvsroot/yoyodyne/tc/driver.c,v <-- driver.c
+new revision: 1.7; previous revision: 1.6
+done
+</nowiki></pre></td></tr></table>
+
+<p>For your protection, <small>CVS</small> will refuse to check in a
+file if a conflict occurred and you have not resolved
+the conflict. Currently to resolve a conflict, you
+must change the timestamp on the file. In previous
+versions of <small>CVS</small>, you also needed to
+insure that the file contains no conflict markers.
+Because
+your file may legitimately contain conflict markers (that
+is, occurrences of ‘<samp>>>>>>>> </samp>’ at
the start of a
+line that don’t mark a conflict), the current
+version of <small>CVS</small> will print a warning and proceed to
+check in the file.
+</p>
+<div id="IDX156"></div>
+<p>If you use release 1.04 or later of pcl-cvs (a <small>GNU</small>
+Emacs front-end for <small>CVS</small>) you can use an Emacs
+package called emerge to help you resolve conflicts.
+See the documentation for pcl-cvs.
+</p>
+<hr size="6">
+<div id="Informing-others"></div>
+<div id="SEC87"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC86| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC88| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC83| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC83| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC96| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== Informing others about commits ===
+
+<p>It is often useful to inform others when you commit a
+new revision of a file. The ‘<samp>-i</samp>’ option of the
+‘<tt>modules</tt>’ file, or the ‘<tt>loginfo</tt>’
file, can be
+used to automate this process. See section [[#SEC158|The modules file]].
+See section [[#SEC172|Loginfo]]. You can use these features of
<small>CVS</small>
+to, for instance, instruct <small>CVS</small> to mail a
+message to all developers, or post a message to a local
+newsgroup.
+</p>
+<hr size="6">
+<div id="Concurrency"></div>
+<div id="SEC88"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC87| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC89| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC83| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC83| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC96| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== Several developers simultaneously attempting to run CVS ===
+
+<p>If several developers try to run <small>CVS</small> at the same
+time, one may get the following message:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>[11:43:23] waiting
for bach's lock in /usr/local/cvsroot/foo
+</nowiki></pre></td></tr></table>
+
+<div id="IDX157"></div>
+<div id="IDX158"></div>
+<div id="IDX159"></div>
+<p><small>CVS</small> will try again every 30 seconds, and either
+continue with the operation or print the message again,
+if it still needs to wait. If a lock seems to stick
+around for an undue amount of time, find the person
+holding the lock and ask them about the cvs command
+they are running. If they aren’t running a cvs
+command, look in the repository directory mentioned in
+the message and remove files which they own whose names
+start with ‘<tt>#cvs.rfl</tt>’,
+‘<tt>#cvs.wfl</tt>’, or ‘<tt>#cvs.lock</tt>’.
+</p>
+<p>Note that these locks are to protect <small>CVS</small>’s
+internal data structures and have no relationship to
+the word <em>lock</em> in the sense used by
+<small>RCS</small>—which refers to reserved checkouts
+(see section [[#SEC83|Multiple developers]]).
+</p>
+<p>Any number of people can be reading from a given
+repository at a time; only when someone is writing do
+the locks prevent other people from reading or writing.
+</p>
+<div id="IDX160"></div>
+<div id="IDX161"></div>
+<p>One might hope for the following property:
+</p>
+<blockquote><p>If someone commits some changes in one cvs command,
+then an update by someone else will either get all the
+changes, or none of them.
+</p></blockquote>
+
+<p>but <small>CVS</small> does <em>not</em> have this property. For
+example, given the files
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>a/one.c
+a/two.c
+b/three.c
+b/four.c
+</nowiki></pre></td></tr></table>
+
+<p>if someone runs
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>cvs ci a/two.c
b/three.c
+</nowiki></pre></td></tr></table>
+
+<p>and someone else runs <code>cvs update</code> at the same
+time, the person running <code>update</code> might get only
+the change to ‘<tt>b/three.c</tt>’ and not the change to
+‘<tt>a/two.c</tt>’.
+</p>
+<hr size="6">
+<div id="Watches"></div>
+<div id="SEC89"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC88| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC90| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC83| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC83| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC96| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== Mechanisms to track who is editing files ===
+
+<p>For many groups, use of <small>CVS</small> in its default mode is
+perfectly satisfactory. Users may sometimes go to
+check in a modification only to find that another
+modification has intervened, but they deal with it and
+proceed with their check in. Other groups prefer to be
+able to know who is editing what files, so that if two
+people try to edit the same file they can choose to
+talk about who is doing what when rather than be
+surprised at check in time. The features in this
+section allow such coordination, while retaining the
+ability of two developers to edit the same file at the
+same time.
+</p>
+<p>For maximum benefit developers should use <code>cvs
+edit</code> (not <code>chmod</code>) to make files read-write to
+edit them, and <code>cvs release</code> (not <code>rm</code>) to
+discard a working directory which is no longer in use,
+but <small>CVS</small> is not able to enforce this behavior.
+</p>
+
+<pre class="menu-preformatted"><nowiki></nowiki>•[[#SEC90| Setting a
watch]]::<nowiki> Telling CVS to watch certain files
+</nowiki>•[[#SEC91| Getting Notified]]::<nowiki> Telling CVS
to notify you
+</nowiki>•[[#SEC92| Editing files]]::<nowiki> How to edit a
file which is being watched
+</nowiki>•[[#SEC93| Watch information]]::<nowiki> Information
about who is watching and editing
+</nowiki>•[[#SEC94| Watches Compatibility]]::<nowiki> Watches
interact poorly with CVS 1.6 or earlier
+</nowiki></pre>
+<hr size="6">
+<div id="Setting-a-watch"></div>
+<div id="SEC90"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC89| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC91| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC83| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC89| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC96| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+==== Telling CVS to watch certain files ====
+
+<p>To enable the watch features, you first specify that
+certain files are to be watched.
+</p>
+<div id="IDX162"></div>
+<dl>
+<dt><u>Command:</u> <b>cvs watch on</b><i> [<code>-lR</code>]
[<var>files</var>]…</i>
+<div id="IDX163"></div>
+</dt>
+<dd><div id="IDX164"></div>
+<p>Specify that developers should run <code>cvs edit</code>
+before editing <var>files</var>. <small>CVS</small> will create working
+copies of <var>files</var> read-only, to remind developers
+to run the <code>cvs edit</code> command before working on
+them.
+</p>
+<p>If <var>files</var> includes the name of a directory, <small>CVS</small>
+arranges to watch all files added to the corresponding
+repository directory, and sets a default for files
+added in the future; this allows the user to set
+notification policies on a per-directory basis. The
+contents of the directory are processed recursively,
+unless the <code>-l</code> option is given.
+The <code>-R</code> option can be used to force recursion if the
<code>-l</code>
+option is set in ‘<tt>~/.cvsrc</tt>’ (see section
[[#SEC117|Default options and the ~/.cvsrc file]]).
+</p>
+<p>If <var>files</var> is omitted, it defaults to the current directory.
+</p>
+<div id="IDX165"></div>
+</dd></dl>
+
+<dl>
+<dt><u>Command:</u> <b>cvs watch off</b><i> [<code>-lR</code>]
[<var>files</var>]…</i>
+<div id="IDX166"></div>
+</dt>
+<dd><p>Do not create <var>files</var> read-only on checkout; thus,
+developers will not be reminded to use <code>cvs edit</code>
+and <code>cvs unedit</code>.
+</p>
+<p>The <var>files</var> and options are processed as for <code>cvs
+watch on</code>.
+</p>
+</dd></dl>
+
+<hr size="6">
+<div id="Getting-Notified"></div>
+<div id="SEC91"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC90| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC92| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC83| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC89| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC96| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+==== Telling CVS to notify you ====
+
+<p>You can tell <small>CVS</small> that you want to receive
+notifications about various actions taken on a file.
+You can do this without using <code>cvs watch on</code> for
+the file, but generally you will want to use <code>cvs
+watch on</code>, to remind developers to use the <code>cvs edit</code>
+command.
+</p>
+<div id="IDX167"></div>
+<dl>
+<dt><u>Command:</u> <b>cvs watch add</b><i> [<code>-lR</code>]
[<code>-a</code> <var>action</var>]… [<var>files</var>]…</i>
+<div id="IDX168"></div>
+</dt>
+<dd><p>Add the current user to the list of people to receive notification of
+work done on <var>files</var>.
+</p>
+<p>The <code>-a</code> option specifies what kinds of events
<small>CVS</small> should notify
+the user about. <var>action</var> is one of the following:
+</p>
+<dl compact="compact">
+<dt> <code>edit</code></dt>
+<dd><p>Another user has applied the <code>cvs edit</code> command (described
+below) to a watched file.
+</p>
+</dd>
+<dt> <code>commit</code></dt>
+<dd><p>Another user has committed changes to one of the named <var>files</var>.
+</p>
+</dd>
+<dt> <code>unedit</code></dt>
+<dd><p>Another user has abandoned editing a file (other than by committing
changes).
+They can do this in several ways, by:
+</p>
+<ul>
+<li>
+applying the <code>cvs unedit</code> command (described below) to the file
+
+</li><li>
+applying the <code>cvs release</code> command (see section
[[#SEC149|release—Indicate that a Module is no longer in use]]) to the
file’s parent directory
+(or recursively to a directory more than one level up)
+
+</li><li>
+deleting the file and allowing <code>cvs update</code> to recreate it
+
+</li></ul>
+
+</dd>
+<dt> <code>all</code></dt>
+<dd><p>All of the above.
+</p>
+</dd>
+<dt> <code>none</code></dt>
+<dd><p>None of the above. (This is useful with <code>cvs edit</code>,
+described below.)
+</p>
+</dd>
+</dl>
+
+<p>The <code>-a</code> option may appear more than once, or not at all. If
+omitted, the action defaults to <code>all</code>.
+</p>
+<p>The <var>files</var> and options are processed as for
+<code>cvs watch on</code>.
+</p>
+</dd></dl>
+
+
+<div id="IDX169"></div>
+<dl>
+<dt><u>Command:</u> <b>cvs watch remove</b><i> [<code>-lR</code>]
[<code>-a</code> <var>action</var>]… [<var>files</var>]…</i>
+<div id="IDX170"></div>
+</dt>
+<dd><p>Remove a notification request established using <code>cvs watch
add</code>;
+the arguments are the same. If the <code>-a</code> option is present, only
+watches for the specified actions are removed.
+</p>
+</dd></dl>
+
+<div id="IDX171"></div>
+<p>When the conditions exist for notification, <small>CVS</small>
+calls the ‘<tt>notify</tt>’ administrative file. Edit
+‘<tt>notify</tt>’ as one edits the other administrative
+files (see section [[#SEC20|The administrative files]]). This
+file follows the usual conventions for administrative
+files (see section [[#SEC167|The common syntax]]), where each line is a regular
+expression followed by a command to execute. The
+command should contain a single occurrence of ‘<samp>%s</samp>’
+which will be replaced by the user to notify; the rest
+of the information regarding the notification will be
+supplied to the command on standard input. The
+standard thing to put in the <code>notify</code> file is the
+single line:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>ALL mail %s -s
"CVS notification"
+</nowiki></pre></td></tr></table>
+
+<p>This causes users to be notified by electronic mail.
+</p>
+<div id="IDX172"></div>
+<p>Note that if you set this up in the straightforward
+way, users receive notifications on the server machine.
+One could of course write a ‘<tt>notify</tt>’ script which
+directed notifications elsewhere, but to make this
+easy, <small>CVS</small> allows you to associate a notification
+address for each user. To do so create a file
+‘<tt>users</tt>’ in ‘<tt>CVSROOT</tt>’ with a line for
each
+user in the format <var>user</var>:<var>value</var>. Then
+instead of passing the name of the user to be notified
+to ‘<tt>notify</tt>’, <small>CVS</small> will pass the
<var>value</var>
+(normally an email address on some other machine).
+</p>
+<p><small>CVS</small> does not notify you for your own changes.
+Currently this check is done based on whether the user
+name of the person taking the action which triggers
+notification matches the user name of the person
+getting notification. In fact, in general, the watches
+features only track one edit by each user. It probably
+would be more useful if watches tracked each working
+directory separately, so this behavior might be worth
+changing.
+</p>
+<hr size="6">
+<div id="Editing-files"></div>
+<div id="SEC92"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC91| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC93| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC83| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC89| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC96| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+==== How to edit a file which is being watched ====
+
+<p>Since a file which is being watched is checked out
+read-only, you cannot simply edit it. To make it
+read-write, and inform others that you are planning to
+edit it, use the <code>cvs edit</code> command. Some systems
+call this a <em>checkout</em>, but <small>CVS</small> uses that term
+for obtaining a copy of the sources (see section [[#SEC5|Getting the
source]]), an operation which those systems call a
+<em>get</em> or a <em>fetch</em>.
+</p>
+<div id="IDX173"></div>
+<dl>
+<dt><u>Command:</u> <b>cvs edit</b><i> [<code>-lR</code>] [<code>-a</code>
<var>action</var>]… [<var>files</var>]…</i>
+<div id="IDX174"></div>
+</dt>
+<dd><p>Prepare to edit the working files <var>files</var>. <small>CVS</small>
makes the
+<var>files</var> read-write, and notifies users who have requested
+<code>edit</code> notification for any of <var>files</var>.
+</p>
+<p>The <code>cvs edit</code> command accepts the same options as the
+<code>cvs watch add</code> command, and establishes a temporary watch for the
+user on <var>files</var>; <small>CVS</small> will remove the watch when
<var>files</var> are
+<code>unedit</code>ed or <code>commit</code>ted. If the user does not wish to
+receive notifications, she should specify <code>-a none</code>.
+</p>
+<p>The <var>files</var> and the options are processed as for the <code>cvs
+watch</code> commands.
+</p>
+
+</dd></dl>
+
+<p>Normally when you are done with a set of changes, you
+use the <code>cvs commit</code> command, which checks in your
+changes and returns the watched files to their usual
+read-only state. But if you instead decide to abandon
+your changes, or not to make any changes, you can use
+the <code>cvs unedit</code> command.
+</p>
+<div id="IDX175"></div>
+<div id="IDX176"></div>
+<div id="IDX177"></div>
+<dl>
+<dt><u>Command:</u> <b>cvs unedit</b><i> [<code>-lR</code>]
[<var>files</var>]…</i>
+<div id="IDX178"></div>
+</dt>
+<dd><p>Abandon work on the working files <var>files</var>, and revert them to
the
+repository versions on which they are based. <small>CVS</small> makes those
+<var>files</var> read-only for which users have requested notification using
+<code>cvs watch on</code>. <small>CVS</small> notifies users who have
requested <code>unedit</code>
+notification for any of <var>files</var>.
+</p>
+<p>The <var>files</var> and options are processed as for the
+<code>cvs watch</code> commands.
+</p>
+<p>If watches are not in use, the <code>unedit</code> command
+probably does not work, and the way to revert to the
+repository version is with the command <code>cvs update -C file</code>
+(see section [[#SEC153|update—Bring work tree in sync with repository]]).
+The meaning is
+not precisely the same; the latter may also
+bring in some changes which have been made in the
+repository since the last time you updated.
+</p></dd></dl>
+
+<p>When using client/server <small>CVS</small>, you can use the
+<code>cvs edit</code> and <code>cvs unedit</code> commands even if
+<small>CVS</small> is unable to successfully communicate with the
+server; the notifications will be sent upon the next
+successful <small>CVS</small> command.
+</p>
+<hr size="6">
+<div id="Watch-information"></div>
+<div id="SEC93"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC92| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC94| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC83| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC89| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC96| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+==== Information about who is watching and editing ====
+
+<dl>
+<dt><u>Command:</u> <b>cvs watchers</b><i> [<code>-lR</code>]
[<var>files</var>]…</i>
+<div id="IDX179"></div>
+</dt>
+<dd><p>List the users currently watching changes to <var>files</var>. The
report
+includes the files being watched, and the mail address of each watcher.
+</p>
+<p>The <var>files</var> and options are processed as for the
+<code>cvs watch</code> commands.
+</p>
+</dd></dl>
+
+
+<div id="IDX180"></div>
+<dl>
+<dt><u>Command:</u> <b>cvs editors</b><i> [<code>-lR</code>]
[<var>files</var>]…</i>
+<div id="IDX181"></div>
+</dt>
+<dd><p>List the users currently working on <var>files</var>. The report
+includes the mail address of each user, the time when the user began
+working with the file, and the host and path of the working directory
+containing the file.
+</p>
+<p>The <var>files</var> and options are processed as for the
+<code>cvs watch</code> commands.
+</p>
+</dd></dl>
+
+<hr size="6">
+<div id="Watches-Compatibility"></div>
+<div id="SEC94"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC93| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC95| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC83| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC89| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC96| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+==== Using watches with old versions of CVS ====
+
+<p>If you use the watch features on a repository, it
+creates ‘<tt>CVS</tt>’ directories in the repository and
+stores the information about watches in that directory.
+If you attempt to use <small>CVS</small> 1.6 or earlier with the
+repository, you get an error message such as the
+following (all on one line):
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>cvs update: cannot
open CVS/Entries for reading:
+No such file or directory
+</nowiki></pre></td></tr></table>
+
+<p>and your operation will likely be aborted. To use the
+watch features, you must upgrade all copies of <small>CVS</small>
+which use that repository in local or server mode. If
+you cannot upgrade, use the <code>watch off</code> and
+<code>watch remove</code> commands to remove all watches, and
+that will restore the repository to a state which
+<small>CVS</small> 1.6 can cope with.
+</p>
+<hr size="6">
+<div id="Choosing-a-model"></div>
+<div id="SEC95"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC94| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC96| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC83| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC83| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC96| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== Choosing between reserved or unreserved checkouts ===
+
+<p>Reserved and unreserved checkouts each have pros and
+cons. Let it be said that a lot of this is a matter of
+opinion or what works given different groups’ working
+styles, but here is a brief description of some of the
+issues. There are many ways to organize a team of
+developers. <small>CVS</small> does not try to enforce a certain
+organization. It is a tool that can be used in several
+ways.
+</p>
+<p>Reserved checkouts can be very counter-productive. If
+two persons want to edit different parts of a file,
+there may be no reason to prevent either of them from
+doing so. Also, it is common for someone to take out a
+lock on a file, because they are planning to edit it,
+but then forget to release the lock.
+</p>
+<p>People, especially people who are familiar with
+reserved checkouts, often wonder how often conflicts
+occur if unreserved checkouts are used, and how
+difficult they are to resolve. The experience with
+many groups is that they occur rarely and usually are
+relatively straightforward to resolve.
+</p>
+<p>The rarity of serious conflicts may be surprising, until one realizes
+that they occur only when two developers disagree on the proper design
+for a given section of code; such a disagreement suggests that the
+team has not been communicating properly in the first place. In order
+to collaborate under <em>any</em> source management regimen, developers
+must agree on the general design of the system; given this agreement,
+overlapping changes are usually straightforward to merge.
+</p>
+<p>In some cases unreserved checkouts are clearly
+inappropriate. If no merge tool exists for the kind of
+file you are managing (for example word processor files
+or files edited by Computer Aided Design programs), and
+it is not desirable to change to a program which uses a
+mergeable data format, then resolving conflicts is
+going to be unpleasant enough that you generally will
+be better off to simply avoid the conflicts instead, by
+using reserved checkouts.
+</p>
+<p>The watches features described above in [[#SEC89|Mechanisms to track who is
editing files]]
+can be considered to be an intermediate model between
+reserved checkouts and unreserved checkouts. When you
+go to edit a file, it is possible to find out who else
+is editing it. And rather than having the system
+simply forbid both people editing the file, it can tell
+you what the situation is and let you figure out
+whether it is a problem in that particular case or not.
+Therefore, for some groups it can be considered the
+best of both the reserved checkout and unreserved
+checkout worlds.
+</p>
+<hr size="6">
+<div id="Revision-management"></div>
+<div id="SEC96"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC95| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC97| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC83| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC_Top| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC98| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+== Revision management ==
+
+
+<p>If you have read this far, you probably have a pretty
+good grasp on what <small>CVS</small> can do for you. This
+chapter talks a little about things that you still have
+to decide.
+</p>
+<p>If you are doing development on your own using <small>CVS</small>
+you could probably skip this chapter. The questions
+this chapter takes up become more important when more
+than one person is working in a repository.
+</p>
+<pre class="menu-preformatted"><nowiki></nowiki>•[[#SEC97| When to
commit]]::<nowiki> Some discussion on the subject
+</nowiki></pre>
+<hr size="6">
+<div id="When-to-commit"></div>
+<div id="SEC97"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC96| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC98| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC96| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC96| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC98| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== When to commit? ===
+
+<p>Your group should decide which policy to use regarding
+commits. Several policies are possible, and as your
+experience with <small>CVS</small> grows you will probably find
+out what works for you.
+</p>
+<p>If you commit files too quickly you might commit files
+that do not even compile. If your partner updates his
+working sources to include your buggy file, he will be
+unable to compile the code. On the other hand, other
+persons will not be able to benefit from the
+improvements you make to the code if you commit very
+seldom, and conflicts will probably be more common.
+</p>
+<p>It is common to only commit files after making sure
+that they can be compiled. Some sites require that the
+files pass a test suite. Policies like this can be
+enforced using the commitinfo file
+(see section [[#SEC168|Commitinfo]]), but you should think twice before
+you enforce such a convention. By making the
+development environment too controlled it might become
+too regimented and thus counter-productive to the real
+goal, which is to get software written.
+</p>
+<hr size="6">
+<div id="Keyword-substitution"></div>
+<div id="SEC98"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC97| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC99| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC96| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC_Top| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC105| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+== Keyword substitution ==
+
+
+<p>As long as you edit source files inside a working
+directory you can always find out the state of
+your files via ‘<samp>cvs status</samp>’ and ‘<samp>cvs
log</samp>’.
+But as soon as you export the files from your
+development environment it becomes harder to identify
+which revisions they are.
+</p>
+<p><small>CVS</small> can use a mechanism known as <em>keyword
+substitution</em> (or <em>keyword expansion</em>) to help
+identifying the files. Embedded strings of the form
+<code>$<var>keyword</var>$</code> and
+<code>$<var>keyword</var>:…$</code> in a file are replaced
+with strings of the form
+<code>$<var>keyword</var>:<var>value</var>$</code> whenever you obtain
+a new revision of the file.
+</p>
+<pre class="menu-preformatted"><nowiki></nowiki>•[[#SEC99| Keyword
list]]::<nowiki> Keywords
+</nowiki>•[[#SEC100| Using keywords]]::<nowiki> Using
keywords
+</nowiki>•[[#SEC101| Avoiding substitution]]::<nowiki> Avoiding
substitution
+</nowiki>•[[#SEC102| Substitution modes]]::<nowiki>
Substitution modes
+</nowiki>•[[#SEC103| Configuring keyword expansion]]::<nowiki>
Configuring keyword expansion
+</nowiki>•[[#SEC104| Log keyword]]::<nowiki> Problems
with the $<i></i>Log$ keyword.
+</nowiki></pre>
+<hr size="6">
+<div id="Keyword-list"></div>
+<div id="SEC99"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC98| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC100| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC98| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC98| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC105| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== Keyword List ===
+
+
+<p>This is a list of the keywords:
+</p>
+<dl compact="compact">
+<dd><div id="IDX182"></div>
+</dd>
+<dt> <code>$<i></i>Author$</code></dt>
+<dd><p>The login name of the user who checked in the revision.
+</p>
+<div id="IDX183"></div>
+</dd>
+<dt> <code>$<i></i>CVSHeader</code></dt>
+<dd><p>A standard header (similar to $<i></i>Header$, but with
+the CVS root stripped off). It contains the relative
+pathname of the <small>RCS</small> file to the CVS root, the
+revision number, the date (UTC), the author, the state,
+and the locker (if locked). Files will normally never
+be locked when you use <small>CVS</small>.
+</p>
+<p>Note that this keyword has only been recently
+introduced to <small>CVS</small> and may cause problems with
+existing installations if $<i></i>CVSHeader$ is already
+in the files for a different purpose. This keyword may
+be excluded using the <code>KeywordExpansion=eCVSHeader</code>
+in the ‘<tt>CVSROOT/config</tt>’ file.
+See [[#SEC103|Configuring Keyord Expansion]] for more details.
+</p>
+<div id="IDX184"></div>
+</dd>
+<dt> <code>$<i></i>Date$</code></dt>
+<dd><p>The date and time (UTC) the revision was checked in.
+</p>
+<div id="IDX185"></div>
+</dd>
+<dt> <code>$<i></i>Header$</code></dt>
+<dd><p>A standard header containing the full pathname of the
+<small>RCS</small> file, the revision number, the date (UTC), the
+author, the state, and the locker (if locked). Files
+will normally never be locked when you use <small>CVS</small>.
+</p>
+<div id="IDX186"></div>
+</dd>
+<dt> <code>$<i></i>Id$</code></dt>
+<dd><p>Same as <code>$<i></i>Header$</code>, except that the <small>RCS</small>
+filename is without a path.
+</p>
+<div id="IDX187"></div>
+</dd>
+<dt> <code>$<i></i>Name$</code></dt>
+<dd><p>Tag name used to check out this file. The keyword is
+expanded only if one checks out with an explicit tag
+name. For example, when running the command <code>cvs
+co -r first</code>, the keyword expands to ‘<samp>Name:
first</samp>’.
+</p>
+<div id="IDX188"></div>
+</dd>
+<dt> <code>$<i></i>Locker$</code></dt>
+<dd><p>The login name of the user who locked the revision
+(empty if not locked, which is the normal case unless
+<code>cvs admin -l</code> is in use).
+</p>
+<div id="IDX189"></div>
+</dd>
+<dt> <code>$<i></i>Log$</code></dt>
+<dd><p>The log message supplied during commit, preceded by a
+header containing the <small>RCS</small> filename, the revision
+number, the author, and the date (UTC). Existing log
+messages are <em>not</em> replaced. Instead, the new log
+message is inserted after <code>$<i></i>Log:…$</code>.
+Each new line is prefixed with the same string which
+precedes the <code>$Log</code> keyword. For example, if the
+file contains:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki> /* Here is what
people have been up to:
+ *
+ * $<i></i>Log: frob.c,v $
+ * Revision 1.1 1997/01/03 14:23:51 joe
+ * Add the superfrobnicate option
+ *
+ */
+</nowiki></pre></td></tr></table>
+
+<p>then additional lines which are added when expanding
+the <code>$Log</code> keyword will be preceded by ‘<samp> *
</samp>’.
+Unlike previous versions of <small>CVS</small> and <small>RCS</small>, the
+<em>comment leader</em> from the <small>RCS</small> file is not used.
+The <code>$Log</code> keyword is useful for
+accumulating a complete change log in a source file,
+but for several reasons it can be problematic.
+See section [[#SEC104|Problems with the $<i></i>Log$ keyword.]].
+</p>
+<div id="IDX190"></div>
+</dd>
+<dt> <code>$<i></i>RCSfile$</code></dt>
+<dd><p>The name of the RCS file without a path.
+</p>
+<div id="IDX191"></div>
+</dd>
+<dt> <code>$<i></i>Revision$</code></dt>
+<dd><p>The revision number assigned to the revision.
+</p>
+<div id="IDX192"></div>
+</dd>
+<dt> <code>$<i></i>Source$</code></dt>
+<dd><p>The full pathname of the RCS file.
+</p>
+<div id="IDX193"></div>
+</dd>
+<dt> <code>$<i></i>State$</code></dt>
+<dd><p>The state assigned to the revision. States can be
+assigned with <code>cvs admin -s</code>—see [[#SEC121|admin options]].
+</p>
+<div id="IDX194"></div>
+</dd>
+<dt> <code>Local keyword</code></dt>
+<dd><p>The <code>LocalKeyword</code> option in the
‘<tt>CVSROOT/config</tt>’ file
+may be used to specify a local keyword which is to be
+used as an alias for one of the other keywords. For
+example, if the ‘<tt>CVSROOT/config</tt>’ file contains
+a line with <code>LocalKeyword=MYBSD=CVSHeader</code>, then a
+file with the local keyword $<i></i>MYBSD$ will be
+expanded as if it were a $<i></i>CVSHeader$ keyword. If
+the src/frob.c file contained this keyword, it might
+look something like this:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki> /*
+ * $<i></i>MYBSD: src/frob.c,v 1.1 2003/05/04 09:27:45 john Exp $
+ */
+</nowiki></pre></td></tr></table>
+
+<p>Many repositories make use of a such a “local
+keyword” feature. An old patch to <small>CVS</small> provided
+the <code>LocalKeyword</code> feature using a <code>tag=</code>
+option and called this the “custom tag” or “local
+tag” feature. It was used in conjunction with the
+what they called the <code>tagexpand=</code> option. In
+<small>CVS</small> this other option is known as the
+<code>KeywordExpand</code> option.
+See [[#SEC103|Configuring Keyord Expansion]] for more
+details.
+</p>
+<p>Examples from popular projects include:
+$<i></i>FreeBSD$, $<i></i>NetBSD$,
+$<i></i>OpenBSD$, $<i></i>XFree86$,
+$<i></i>Xorg$.
+</p>
+<p>The advantage of this is that you can include your
+local version information in a file using this local
+keyword without disrupting the upstream version
+information (which may be a different local keyword or
+a standard keyword). Allowing bug reports and the like
+to more properly identify the source of the original
+bug to the third-party and reducing the number of
+conflicts that arise during an import of a new version.
+</p>
+<p>All keyword expansion except the local keyword may be
+disabled using the <code>KeywordExpansion</code> option in
+the ‘<tt>CVSROOT/config</tt>’ file—see
+[[#SEC103|Configuring Keyord Expansion]] for more details.
+</p>
+</dd>
+</dl>
+
+<hr size="6">
+<div id="Using-keywords"></div>
+<div id="SEC100"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC99| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC101| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC98| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC98| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC105| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== Using keywords ===
+
+<p>To include a keyword string you simply include the
+relevant text string, such as <code>$<i></i>Id$</code>, inside the
+file, and commit the file. <small>CVS</small> will automatically
+expand the string as part of the commit operation.
+</p>
+<p>It is common to embed the <code>$<i></i>Id$</code> string in
+the source files so that it gets passed through to
+generated files. For example, if you are managing
+computer program source code, you might include a
+variable which is initialized to contain that string.
+Or some C compilers may provide a <code>#pragma ident</code>
+directive. Or a document management system might
+provide a way to pass a string through to generated
+files.
+</p>
+
+<div id="IDX195"></div>
+<p>The <code>ident</code> command (which is part of the <small>RCS</small>
+package) can be used to extract keywords and their
+values from a file. This can be handy for text files,
+but it is even more useful for extracting keywords from
+binary files.
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>$ ident samp.c
+samp.c:
+ $<i></i>Id: samp.c,v 1.5 1993/10/19 14:57:32 ceder Exp $
+$ gcc samp.c
+$ ident a.out
+a.out:
+ $<i></i>Id: samp.c,v 1.5 1993/10/19 14:57:32 ceder Exp $
+</nowiki></pre></td></tr></table>
+
+<div id="IDX196"></div>
+<p>S<small>CCS</small> is another popular revision control system.
+It has a command, <code>what</code>, which is very similar to
+<code>ident</code> and used for the same purpose. Many sites
+without <small>RCS</small> have <small>SCCS</small>. Since <code>what</code>
+looks for the character sequence <code>@(#)</code> it is
+easy to include keywords that are detected by either
+command. Simply prefix the keyword with the
+magic <small>SCCS</small> phrase, like this:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>static char
*id="@(#) $<i></i>Id: ab.c,v 1.5 1993/10/19 14:57:32 ceder Exp $";
+</nowiki></pre></td></tr></table>
+
+<hr size="6">
+<div id="Avoiding-substitution"></div>
+<div id="SEC101"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC100| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC102| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC98| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC98| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC105| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== Avoiding substitution ===
+
+<p>Keyword substitution has its disadvantages. Sometimes
+you might want the literal text string
+‘<samp>$<i></i>Author$</samp>’ to appear inside a file without
+<small>CVS</small> interpreting it as a keyword and expanding it
+into something like ‘<samp>$<i></i>Author: ceder $</samp>’.
+</p>
+<p>There is unfortunately no way to selectively turn off
+keyword substitution. You can use ‘<samp>-ko</samp>’
+(see section [[#SEC102|Substitution modes]]) to turn off keyword
+substitution entirely.
+</p>
+<p>In many cases you can avoid using keywords in
+the source, even though they appear in the final
+product. For example, the source for this manual
+contains ‘<samp>address@hidden</samp>’ whenever the text
+‘<samp>$<i></i>Author$</samp>’ should appear. In
<code>nroff</code>
+and <code>troff</code> you can embed the null-character
+<code>\&</code> inside the keyword for a similar effect.
+</p>
+<p>It is also possible to specify an explicit list of
+keywords to include or exclude using the
+<code>KeywordExpand</code> option in the
+‘<tt>CVSROOT/config</tt>’ file–see [[#SEC103|Configuring
Keyord Expansion]]
+for more details. This feature is intended primarily
+for use with the <code>LocalKeyword</code> option–see
+[[#SEC99|Keyword List]].
+</p>
+<hr size="6">
+<div id="Substitution-modes"></div>
+<div id="SEC102"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC101| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC103| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC98| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC98| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC105| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== Substitution modes ===
+
+<p>Each file has a stored default substitution mode, and
+each working directory copy of a file also has a
+substitution mode. The former is set by the ‘<samp>-k</samp>’
+option to <code>cvs add</code> and <code>cvs admin</code>; the
+latter is set by the ‘<samp>-k</samp>’ or
‘<samp>-A</samp>’ options to <code>cvs
+checkout</code> or <code>cvs update</code>. <code>cvs diff</code> also
+has a ‘<samp>-k</samp>’ option. For some examples,
+see [[#SEC80|Handling binary files]], and [[#SEC64|Merging and keywords]].
+</p>
+<p>The modes available are:
+</p>
+<dl compact="compact">
+<dt> ‘<samp>-kkv</samp>’</dt>
+<dd><p>Generate keyword strings using the default form, e.g.
+<code>$<i></i>Revision: 5.7 $</code> for the <code>Revision</code>
+keyword.
+</p>
+</dd>
+<dt> ‘<samp>-kkvl</samp>’</dt>
+<dd><p>Like ‘<samp>-kkv</samp>’, except that a locker’s name
is always
+inserted if the given revision is currently locked.
+The locker’s name is only relevant if <code>cvs admin
+-l</code> is in use.
+</p>
+</dd>
+<dt> ‘<samp>-kk</samp>’</dt>
+<dd><p>Generate only keyword names in keyword strings; omit
+their values. For example, for the <code>Revision</code>
+keyword, generate the string <code>$<i></i>Revision$</code>
+instead of <code>$<i></i>Revision: 5.7 $</code>. This option
+is useful to ignore differences due to keyword
+substitution when comparing different revisions of a
+file (see section [[#SEC64|Merging and keywords]]).
+</p>
+</dd>
+<dt> ‘<samp>-ko</samp>’</dt>
+<dd><p>Generate the old keyword string, present in the working
+file just before it was checked in. For example, for
+the <code>Revision</code> keyword, generate the string
+<code>$<i></i>Revision: 1.1 $</code> instead of
+<code>$<i></i>Revision: 5.7 $</code> if that is how the
+string appeared when the file was checked in.
+</p>
+</dd>
+<dt> ‘<samp>-kb</samp>’</dt>
+<dd><p>Like ‘<samp>-ko</samp>’, but also inhibit conversion of line
+endings between the canonical form in which they are
+stored in the repository (linefeed only), and the form
+appropriate to the operating system in use on the
+client. For systems, like unix, which use linefeed
+only to terminate lines, this is very similar to
+‘<samp>-ko</samp>’. For more information on binary files, see
+[[#SEC80|Handling binary files]]. In <small>CVS</small> version 1.12.2 and
later
+‘<samp>-kb</samp>’, as set by <code>cvs add</code>, <code>cvs
admin</code>, or
+<code>cvs import</code> may not be overridden by a
‘<samp>-k</samp>’ option
+specified on the command line.
+</p>
+</dd>
+<dt> ‘<samp>-kv</samp>’</dt>
+<dd><p>Generate only keyword values for keyword strings. For
+example, for the <code>Revision</code> keyword, generate the string
+<code>5.7</code> instead of <code>$<i></i>Revision: 5.7 $</code>.
+This can help generate files in programming languages
+where it is hard to strip keyword delimiters like
+<code>$<i></i>Revision: $</code> from a string. However,
+further keyword substitution cannot be performed once
+the keyword names are removed, so this option should be
+used with care.
+</p>
+<p>One often would like to use ‘<samp>-kv</samp>’ with <code>cvs
+export</code>—see section [[#SEC135|export—Export sources from
CVS, similar to checkout]]. But be aware that doesn’t
+handle an export containing binary files correctly.
+</p>
+</dd>
+</dl>
+
+<hr size="6">
+<div id="Configuring-keyword-expansion"></div>
+<div id="SEC103"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC102| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC104| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC98| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC98| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC105| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== Configuring Keyord Expansion ===
+
+<p>In a repository that includes third-party software on
+vendor branches, it is sometimes helpful to configure
+CVS to use a local keyword instead of the standard
+$<i></i>Id$ or $<i></i>Header$ keywords. Examples from
+real projects includ, $<i></i>Xorg$, $<i></i>XFree86$,
+$<i></i>FreeBSD$, $<i></i>NetBSD$,
+$<i></i>OpenBSD$, and even $<i></i>dotat$.
+The advantage of this is that
+you can include your local version information in a
+file using this local keyword (sometimes called a
+“custom tag” or a “local tag”) without disrupting
+the upstream version information (which may be a
+different local keyword or a standard keyword). In
+these cases, it is typically desirable to disable the
+expansion of all keywords except the configured local
+keyword.
+</p>
+<p>The <code>KeywordExpansion</code> option in the
+‘<tt>CVSROOT/config</tt>’ file is intended to allow for the
+either the explicit exclusion of a keyword or list of
+keywords, or for the explicit inclusion of a keyword or
+a list of keywords. This list may include the
+<code>LocalKeyword</code> that has been configured.
+</p>
+<p>The <code>KeywordExpansion</code> option is followed by
+<code>=</code> and the next character may either be <code>i</code>
+to start an inclusion list or <code>e</code> to start an
+exclusion list. If the following lines were added to
+the ‘<tt>CVSROOT/config</tt>’ file:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki> # Add a
"MyBSD" keyword and restrict keyword
+ # expansion
+ LocalKeyword=MyBSD=CVSHeader
+ KeywordExpand=iMyBSD
+</nowiki></pre></td></tr></table>
+
+<p>then only the $<i></i>MyBSD$ keyword would be expanded.
+A list may be used. The this example:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki> # Add a
"MyBSD" keyword and restrict keyword
+ # expansion to the MyBSD, Name and Date keywords.
+ LocalKeyword=MyBSD=CVSHeader
+ KeywordExpand=iMyBSD,Name,Date
+</nowiki></pre></td></tr></table>
+
+<p>would allow $<i></i>MyBSD$, $<i></i>Name$, and
+$<i></i>Date$ to be expanded.
+</p>
+<p>It is also possible to configure an exclusion list
+using the following:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki> # Do not
expand the non-RCS keyword CVSHeader
+ KeywordExpand=eCVSHeader
+</nowiki></pre></td></tr></table>
+
+<p>This allows <small>CVS</small> to ignore the recently introduced
+$<i></i>CVSHeader$ keyword and retain all of the
+others. The exclusion entry could also contain the
+standard RCS keyword list, but this could be confusing
+to users that expect RCS keywords to be expanded, so
+ycare should be taken to properly set user expectations
+for a repository that is configured in that manner.
+</p>
+<p>If there is a desire to not have any RCS keywords
+expanded and not use the <code>-ko</code> flags everywhere,
+an administrator may disable all keyword expansion
+using the ‘<tt>CVSROOT/config</tt>’ line:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki> # Do not expand
any RCS keywords
+ KeywordExpand=i
+</nowiki></pre></td></tr></table>
+
+<p>this could be confusing to users that expect RCS
+keywords like $<i></i>Id$ to be expanded properly,
+so care should be taken to properly set user
+expectations for a repository so configured.
+</p>
+<p>It should be noted that a patch to provide both the
+<code>KeywordExpand</code> and <code>LocalKeyword</code> features
+has been around a long time. However, that patch
+implemented these features using <code>tag=</code> and
+<code>tagexpand=</code> keywords and those keywords are NOT
+recognized.
+</p>
+<hr size="6">
+<div id="Log-keyword"></div>
+<div id="SEC104"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC103| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC105| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC98| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC98| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC105| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== Problems with the $<i></i>Log$ keyword. ===
+
+<p>The <code>$<i></i>Log$</code> keyword is somewhat
+controversial. As long as you are working on your
+development system the information is easily accessible
+even if you do not use the <code>$<i></i>Log$</code>
+keyword—just do a <code>cvs log</code>. Once you export
+the file the history information might be useless
+anyhow.
+</p>
+<p>A more serious concern is that <small>CVS</small> is not good at
+handling <code>$<i></i>Log$</code> entries when a branch is
+merged onto the main trunk. Conflicts often result
+from the merging operation.
+</p>
+<p>People also tend to "fix" the log entries in the file
+(correcting spelling mistakes and maybe even factual
+errors). If that is done the information from
+<code>cvs log</code> will not be consistent with the
+information inside the file. This may or may not be a
+problem in real life.
+</p>
+<p>It has been suggested that the <code>$<i></i>Log$</code>
+keyword should be inserted <em>last</em> in the file, and
+not in the files header, if it is to be used at all.
+That way the long list of change messages will not
+interfere with everyday source file browsing.
+</p>
+<hr size="6">
+<div id="Tracking-sources"></div>
+<div id="SEC105"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC104| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC106| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC98| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC_Top| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC112| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+== Tracking third-party sources ==
+
+<p>If you modify a program to better fit your site, you
+probably want to include your modifications when the next
+release of the program arrives. <small>CVS</small> can help you with
+this task.
+</p>
+<div id="IDX197"></div>
+<div id="IDX198"></div>
+<div id="IDX199"></div>
+<p>In the terminology used in <small>CVS</small>, the supplier of the
+program is called a <em>vendor</em>. The unmodified
+distribution from the vendor is checked in on its own
+branch, the <em>vendor branch</em>. <small>CVS</small> reserves branch
+1.1.1 for this use.
+</p>
+<p>When you modify the source and commit it, your revision
+will end up on the main trunk. When a new release is
+made by the vendor, you commit it on the vendor branch
+and copy the modifications onto the main trunk.
+</p>
+<p>Use the <code>import</code> command to create and update
+the vendor branch. When you import a new file,
+the vendor branch is made the ‘head’ revision, so
+anyone that checks out a copy of the file gets that
+revision. When a local modification is committed it is
+placed on the main trunk, and made the ‘head’
+revision.
+</p>
+<pre class="menu-preformatted"><nowiki></nowiki>•[[#SEC106| First
import]]::<nowiki> Importing for the first time
+</nowiki>•[[#SEC107| Update imports]]::<nowiki> Updating
with the import command
+</nowiki>•[[#SEC108| Reverting local changes]]::<nowiki> Reverting to
the latest vendor release
+</nowiki>•[[#SEC109| Binary files in imports]]::<nowiki> Binary files
require special handling
+</nowiki>•[[#SEC110| Keywords in imports]]::<nowiki> Keyword
substitution might be undesirable
+</nowiki>•[[#SEC111| Multiple vendor branches]]::<nowiki> What if you
get sources from several places?
+</nowiki></pre>
+<hr size="6">
+<div id="First-import"></div>
+<div id="SEC106"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC105| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC107| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC105| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC105| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC112| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== Importing for the first time ===
+
+<p>Use the <code>import</code> command to check in the sources
+for the first time. When you use the <code>import</code>
+command to track third-party sources, the <em>vendor
+tag</em> and <em>release tags</em> are useful. The
+<em>vendor tag</em> is a symbolic name for the branch
+(which is always 1.1.1, unless you use the ‘<samp>-b
+<var>branch</var></samp>’ flag—see [[#SEC111|Multiple vendor
branches]].). The
+<em>release tags</em> are symbolic names for a particular
+release, such as ‘<samp>FSF_0_04</samp>’.
+</p>
+<p>Note that <code>import</code> does <em>not</em> change the
+directory in which you invoke it. In particular, it
+does not set up that directory as a <small>CVS</small> working
+directory; if you want to work with the sources import
+them first and then check them out into a different
+directory (see section [[#SEC5|Getting the source]]).
+</p>
+<div id="IDX200"></div>
+<p>Suppose you have the sources to a program called
+<code>wdiff</code> in a directory ‘<tt>wdiff-0.04</tt>’,
+and are going to make private modifications that you
+want to be able to use even when new releases are made
+in the future. You start by importing the source to
+your repository:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>$ cd wdiff-0.04
+$ cvs import -m "Import of FSF v. 0.04" fsf/wdiff FSF_DIST WDIFF_0_04
+</nowiki></pre></td></tr></table>
+
+<p>The vendor tag is named ‘<samp>FSF_DIST</samp>’ in the above
+example, and the only release tag assigned is
+‘<samp>WDIFF_0_04</samp>’.
+</p>
+<hr size="6">
+<div id="Update-imports"></div>
+<div id="SEC107"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC106| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC108| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC105| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC105| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC112| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== Updating with the import command ===
+
+<p>When a new release of the source arrives, you import it into the
+repository with the same <code>import</code> command that you used to set up
+the repository in the first place. The only difference is that you
+specify a different release tag this time:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>$ tar xfz
wdiff-0.05.tar.gz
+$ cd wdiff-0.05
+$ cvs import -m "Import of FSF v. 0.05" fsf/wdiff FSF_DIST WDIFF_0_05
+</nowiki></pre></td></tr></table>
+
+<p>For files that have not been modified locally, the newly created
+revision becomes the head revision. If you have made local
+changes, <code>import</code> will warn you that you must merge the changes
+into the main trunk, and tell you to use ‘<samp>checkout
-j</samp>’ to do so:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>$ cvs checkout
-jFSF_DIST:yesterday -jFSF_DIST wdiff
+</nowiki></pre></td></tr></table>
+
+<p>The above command will check out the latest revision of
+‘<samp>wdiff</samp>’, merging the changes made on the vendor
branch ‘<samp>FSF_DIST</samp>’
+since yesterday into the working copy. If any conflicts arise during
+the merge they should be resolved in the normal way (see section
[[#SEC86|Conflicts example]]). Then, the modified files may be committed.
+</p>
+<p>However, it is much better to use the two release tags rather than using
+a date on the branch as suggested above:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>$ cvs checkout
-jWDIFF_0_04 -jWDIFF_0_05 wdiff
+</nowiki></pre></td></tr></table>
+
+<p>The reason this is better is that
+using a date, as suggested above, assumes that you do
+not import more than one release of a product per day.
+More importantly, using the release tags allows <small>CVS</small> to detect
files
+that were removed between the two vendor releases and mark them for
+removal. Since <code>import</code> has no way to detect removed files, you
+should do a merge like this even if <code>import</code> doesn’t tell you
to.
+</p>
+<hr size="6">
+<div id="Reverting-local-changes"></div>
+<div id="SEC108"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC107| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC109| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC105| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC105| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC112| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== Reverting to the latest vendor release ===
+
+<p>You can also revert local changes completely and return
+to the latest vendor release by changing the ‘head’
+revision back to the vendor branch on all files. For
+example, if you have a checked-out copy of the sources
+in ‘<tt>~/work.d/wdiff</tt>’, and you want to revert to the
+vendor’s version for all the files in that directory,
+you would type:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>$ cd ~/work.d/wdiff
+$ cvs admin -bWDIFF .
+</nowiki></pre></td></tr></table>
+
+<p>You must specify the ‘<samp>-bWDIFF</samp>’ without any space
+after the ‘<samp>-b</samp>’. See section [[#SEC121|admin
options]].
+</p>
+<hr size="6">
+<div id="Binary-files-in-imports"></div>
+<div id="SEC109"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC108| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC110| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC105| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC105| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC112| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== How to handle binary files with cvs import ===
+
+<p>Use the ‘<samp>-k</samp>’ wrapper option to tell import which
+files are binary. See section [[#SEC165|The cvswrappers file]].
+</p>
+<hr size="6">
+<div id="Keywords-in-imports"></div>
+<div id="SEC110"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC109| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC111| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC105| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC105| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC112| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== How to handle keyword substitution with cvs import ===
+
+<p>The sources which you are importing may contain
+keywords (see section [[#SEC98|Keyword substitution]]). For example,
+the vendor may use <small>CVS</small> or some other system
+which uses similar keyword expansion syntax. If you
+just import the files in the default fashion, then
+the keyword expansions supplied by the vendor will
+be replaced by keyword expansions supplied by your
+own copy of <small>CVS</small>. It may be more convenient to
+maintain the expansions supplied by the vendor, so
+that this information can supply information about
+the sources that you imported from the vendor.
+</p>
+<p>To maintain the keyword expansions supplied by the
+vendor, supply the ‘<samp>-ko</samp>’ option to <code>cvs
+import</code> the first time you import the file.
+This will turn off keyword expansion
+for that file entirely, so if you want to be more
+selective you’ll have to think about what you want
+and use the ‘<samp>-k</samp>’ option to <code>cvs update</code> or
+<code>cvs admin</code> as appropriate.
+</p>
+<hr size="6">
+<div id="Multiple-vendor-branches"></div>
+<div id="SEC111"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC110| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC112| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC105| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC105| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC112| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== Multiple vendor branches ===
+
+<p>All the examples so far assume that there is only one
+vendor from which you are getting sources. In some
+situations you might get sources from a variety of
+places. For example, suppose that you are dealing with
+a project where many different people and teams are
+modifying the software. There are a variety of ways to
+handle this, but in some cases you have a bunch of
+source trees lying around and what you want to do more
+than anything else is just to all put them in <small>CVS</small> so
+that you at least have them in one place.
+</p>
+<p>For handling situations in which there may be more than
+one vendor, you may specify the ‘<samp>-b</samp>’ option to
+<code>cvs import</code>. It takes as an argument the vendor
+branch to import to. The default is ‘<samp>-b 1.1.1</samp>’.
+</p>
+<p>For example, suppose that there are two teams, the red
+team and the blue team, that are sending you sources.
+You want to import the red team’s efforts to branch
+1.1.1 and use the vendor tag RED. You want to import
+the blue team’s efforts to branch 1.1.3 and use the
+vendor tag BLUE. So the commands you might use are:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>$ cvs import dir
RED RED_1-0
+$ cvs import -b 1.1.3 dir BLUE BLUE_1-5
+</nowiki></pre></td></tr></table>
+
+<p>Note that if your vendor tag does not match your
+‘<samp>-b</samp>’ option, <small>CVS</small> will not detect this
case! For
+example,
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>$ cvs import -b
1.1.3 dir RED RED_1-0
+</nowiki></pre></td></tr></table>
+
+<p>Be careful; this kind of mismatch is sure to sow
+confusion or worse. I can’t think of a useful purpose
+for the ability to specify a mismatch here, but if you
+discover such a use, don’t. <small>CVS</small> is likely to make this
+an error in some future release.
+</p>
+
+<hr size="6">
+<div id="Builds"></div>
+<div id="SEC112"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC111| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC113| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC105| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC_Top| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC113| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+== How your build system interacts with CVS ==
+
+<p>As mentioned in the introduction, <small>CVS</small> does not
+contain software for building your software from source
+code. This section describes how various aspects of
+your build system might interact with <small>CVS</small>.
+</p>
+<p>One common question, especially from people who are
+accustomed to <small>RCS</small>, is how to make their build get
+an up to date copy of the sources. The answer to this
+with <small>CVS</small> is two-fold. First of all, since
+<small>CVS</small> itself can recurse through directories, there
+is no need to modify your ‘<tt>Makefile</tt>’ (or whatever
+configuration file your build tool uses) to make sure
+each file is up to date. Instead, just use two
+commands, first <code>cvs -q update</code> and then
+<code>make</code> or whatever the command is to invoke your
+build tool. Secondly, you do not necessarily
+<em>want</em> to get a copy of a change someone else made
+until you have finished your own work. One suggested
+approach is to first update your sources, then
+implement, build and
+test the change you were thinking of, and then commit
+your sources (updating first if necessary). By
+periodically (in between changes, using the approach
+just described) updating your entire tree, you ensure
+that your sources are sufficiently up to date.
+</p>
+<div id="IDX201"></div>
+<p>One common need is to record which versions of which
+source files went into a particular build. This kind
+of functionality is sometimes called <em>bill of
+materials</em> or something similar. The best way to do
+this with <small>CVS</small> is to use the <code>tag</code> command to
+record which versions went into a given build
+(see section [[#SEC48|Tags–Symbolic revisions]]).
+</p>
+<p>Using <small>CVS</small> in the most straightforward manner
+possible, each developer will have a copy of the entire
+source tree which is used in a particular build. If
+the source tree is small, or if developers are
+geographically dispersed, this is the preferred
+solution. In fact one approach for larger projects is
+to break a project down into smaller
+separately-compiled subsystems, and arrange a way of
+releasing them internally so that each developer need
+check out only those subsystems which they are
+actively working on.
+</p>
+<p>Another approach is to set up a structure which allows
+developers to have their own copies of some files, and
+for other files to access source files from a central
+location. Many people have come up with some such a
+system using features such as the symbolic link feature
+found in many operating systems, or the <code>VPATH</code>
+feature found in many versions of <code>make</code>. One build
+tool which is designed to help with this kind of thing
+is Odin (see
+<code>ftp://ftp.cs.colorado.edu/pub/distribs/odin</code>).
+</p>
+<hr size="6">
+<div id="Special-Files"></div>
+<div id="SEC113"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC112| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC114| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC112| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC_Top| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC114| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+== Special Files ==
+
+
+<p>In normal circumstances, <small>CVS</small> works only with regular
+files. Every file in a project is assumed to be
+persistent; it must be possible to open, read and close
+them; and so on. <small>CVS</small> also ignores file permissions and
+ownerships, leaving such issues to be resolved by the
+developer at installation time. In other words, it is
+not possible to "check in" a device into a repository;
+if the device file cannot be opened, <small>CVS</small> will refuse to
+handle it. Files also lose their ownerships and
+permissions during repository transactions.
+</p>
+
+<hr size="6">
+<div id="CVS-commands"></div>
+<div id="SEC114"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC113| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC115| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC113| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC_Top| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC156| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+== Guide to CVS commands ==
+
+<p>This appendix describes the overall structure of
+<small>CVS</small> commands, and describes some commands in
+detail (others are described elsewhere; for a quick
+reference to <small>CVS</small> commands, see section [[#SEC156|Quick
reference to CVS commands]]).
+</p>
+<pre class="menu-preformatted"><nowiki></nowiki>•[[#SEC115|
Structure]]::<nowiki> Overall structure of CVS commands
+</nowiki>•[[#SEC116| Exit status]]::<nowiki> Indicating
CVS's success or failure
+</nowiki>•[[#SEC117| ~/.cvsrc]]::<nowiki> Default
options with the ~/.csvrc file
+</nowiki>•[[#SEC118| Global options]]::<nowiki> Options you
give to the left of cvs_command
+</nowiki>•[[#SEC119| Common options]]::<nowiki> Options you
give to the right of cvs_command
+</nowiki>•[[#SEC120| admin]]::<nowiki>
Administration
+</nowiki>•[[#SEC122| checkout]]::<nowiki> Checkout
sources for editing
+</nowiki>•[[#SEC125| commit]]::<nowiki> Check files
into the repository
+</nowiki>•[[#SEC130| diff]]::<nowiki> Show
differences between revisions
+</nowiki>•[[#SEC135| export]]::<nowiki> Export
sources from CVS, similar to checkout
+</nowiki>•[[#SEC137| history]]::<nowiki> Show status
of files and users
+</nowiki>•[[#SEC139| import]]::<nowiki> Import
sources into CVS, using vendor branches
+</nowiki>•[[#SEC143| log]]::<nowiki> Show log
messages for files
+</nowiki>•[[#SEC146| rdiff]]::<nowiki> 'patch'
format diffs between releases
+</nowiki>•[[#SEC149| release]]::<nowiki> Indicate
that a directory is no longer in use
+</nowiki>•[[#SEC153| update]]::<nowiki> Bring work
tree in sync with repository
+</nowiki></pre>
+<hr size="6">
+<div id="Structure"></div>
+<div id="SEC115"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC114| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC116| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC114| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC114| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC156| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== Overall structure of CVS commands ===
+
+<p>The overall format of all <small>CVS</small> commands is:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>cvs [ cvs_options ]
cvs_command [ command_options ] [ command_args ]
+</nowiki></pre></td></tr></table>
+
+<dl compact="compact">
+<dt> <code>cvs</code></dt>
+<dd><p>The name of the <small>CVS</small> program.
+</p>
+</dd>
+<dt> <code>cvs_options</code></dt>
+<dd><p>Some options that affect all sub-commands of <small>CVS</small>. These
are
+described below.
+</p>
+</dd>
+<dt> <code>cvs_command</code></dt>
+<dd><p>One of several different sub-commands. Some of the commands have
+aliases that can be used instead; those aliases are noted in the
+reference manual for that command. There are only two situations
+where you may omit ‘<samp>cvs_command</samp>’: ‘<samp>cvs
-H</samp>’ elicits a
+list of available commands, and ‘<samp>cvs -v</samp>’ displays
version
+information on <small>CVS</small> itself.
+</p>
+</dd>
+<dt> <code>command_options</code></dt>
+<dd><p>Options that are specific for the command.
+</p>
+</dd>
+<dt> <code>command_args</code></dt>
+<dd><p>Arguments to the commands.
+</p></dd>
+</dl>
+
+<p>There is unfortunately some confusion between
+<code>cvs_options</code> and <code>command_options</code>.
+‘<samp>-l</samp>’, when given as a <code>cvs_option</code>, only
+affects some of the commands. When it is given as a
+<code>command_option</code> is has a different meaning, and
+is accepted by more commands. In other words, do not
+take the above categorization too seriously. Look at
+the documentation instead.
+</p>
+<hr size="6">
+<div id="Exit-status"></div>
+<div id="SEC116"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC115| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC117| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC114| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC114| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC156| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== CVS’s exit status ===
+
+<p><small>CVS</small> can indicate to the calling environment whether it
+succeeded or failed by setting its <em>exit status</em>.
+The exact way of testing the exit status will vary from
+one operating system to another. For example in a unix
+shell script the ‘<samp>$?</samp>’ variable will be 0 if the
+last command returned a successful exit status, or
+greater than 0 if the exit status indicated failure.
+</p>
+<p>If <small>CVS</small> is successful, it returns a successful status;
+if there is an error, it prints an error message and
+returns a failure status. The one exception to this is
+the <code>cvs diff</code> command. It will return a
+successful status if it found no differences, or a
+failure status if there were differences or if there
+was an error. Because this behavior provides no good
+way to detect errors, in the future it is possible that
+<code>cvs diff</code> will be changed to behave like the
+other <small>CVS</small> commands.
+</p>
+<hr size="6">
+<div id="g_t_007e_002f_002ecvsrc"></div>
+<div id="SEC117"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC116| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC118| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC114| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC114| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC156| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== Default options and the ~/.cvsrc file ===
+
+<p>There are some <code>command_options</code> that are used so
+often that you might have set up an alias or some other
+means to make sure you always specify that option. One
+example (the one that drove the implementation of the
+‘<tt>.cvsrc</tt>’ support, actually) is that many people find the
+default output of the ‘<samp>diff</samp>’ command to be very
+hard to read, and that either context diffs or unidiffs
+are much easier to understand.
+</p>
+<p>The ‘<tt>~/.cvsrc</tt>’ file is a way that you can add
+default options to <code>cvs_commands</code> within cvs,
+instead of relying on aliases or other shell scripts.
+</p>
+<p>The format of the ‘<tt>~/.cvsrc</tt>’ file is simple. The
+file is searched for a line that begins with the same
+name as the <code>cvs_command</code> being executed. If a
+match is found, then the remainder of the line is split
+up (at whitespace characters) into separate options and
+added to the command arguments <em>before</em> any
+options from the command line.
+</p>
+<p>If a command has two names (e.g., <code>checkout</code> and
+<code>co</code>), the official name, not necessarily the one
+used on the command line, will be used to match against
+the file. So if this is the contents of the user’s
+‘<tt>~/.cvsrc</tt>’ file:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>log -N
+diff -uN
+rdiff -u
+update -Pd
+checkout -P
+release -d
+</nowiki></pre></td></tr></table>
+
+<p>the command ‘<samp>cvs checkout foo</samp>’ would have the
+‘<samp>-P</samp>’ option added to the arguments, as well as
+‘<samp>cvs co foo</samp>’.
+</p>
+<p>With the example file above, the output from ‘<samp>cvs
+diff foobar</samp>’ will be in unidiff format. ‘<samp>cvs diff
+-c foobar</samp>’ will provide context diffs, as usual.
+Getting "old" format diffs would be slightly more
+complicated, because <code>diff</code> doesn’t have an option
+to specify use of the "old" format, so you would need
+‘<samp>cvs -f diff foobar</samp>’.
+</p>
+<p>In place of the command name you can use <code>cvs</code> to
+specify global options (see section [[#SEC118|Global options]]). For
+example the following line in ‘<tt>.cvsrc</tt>’
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>cvs -z6
+</nowiki></pre></td></tr></table>
+
+<p>causes <small>CVS</small> to use compression level 6.
+</p>
+<hr size="6">
+<div id="Global-options"></div>
+<div id="SEC118"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC117| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC119| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC114| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC114| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC156| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== Global options ===
+
+<p>The available ‘<samp>cvs_options</samp>’ (that are given to the
+left of ‘<samp>cvs_command</samp>’) are:
+</p>
+<dl compact="compact">
+<dt> <code>--allow-root=<var>rootdir</var></code></dt>
+<dd><p>Specify legal <small>CVSROOT</small> directory. See
+[[#SEC30|Setting up the server for password authentication]].
+</p>
+<div id="IDX202"></div>
+<div id="IDX203"></div>
+</dd>
+<dt> <code>-a</code></dt>
+<dd><p>Authenticate all communication between the client and
+the server. Only has an effect on the <small>CVS</small> client.
+As of this writing, this is only implemented when using
+a GSSAPI connection (see section [[#SEC33|Direct connection with GSSAPI]]).
+Authentication prevents certain sorts of attacks
+involving hijacking the active <small>TCP</small> connection.
+Enabling authentication does not enable encryption.
+</p>
+<div id="IDX204"></div>
+<div id="IDX205"></div>
+</dd>
+<dt> <code>-b <var>bindir</var></code></dt>
+<dd><p>In <small>CVS</small> 1.9.18 and older, this specified that
+<small>RCS</small> programs are in the <var>bindir</var> directory.
+Current versions of <small>CVS</small> do not run <small>RCS</small>
+programs; for compatibility this option is accepted,
+but it does nothing.
+</p>
+<div id="IDX206"></div>
+<div id="IDX207"></div>
+</dd>
+<dt> <code>-T <var>tempdir</var></code></dt>
+<dd><p>Use <var>tempdir</var> as the directory where temporary files are
+located. Overrides the setting of the <code>$TMPDIR</code> environment
+variable and any precompiled directory. This parameter should be
+specified as an absolute pathname.
+(When running client/server, ‘<samp>-T</samp>’ affects only the
local process;
+specifying ‘<samp>-T</samp>’ for the client has no effect on the
server and
+vice versa.)
+</p>
+<div id="IDX208"></div>
+<div id="IDX209"></div>
+</dd>
+<dt> <code>-d <var>cvs_root_directory</var></code></dt>
+<dd><p>Use <var>cvs_root_directory</var> as the root directory
+pathname of the repository. Overrides the setting of
+the <code>$CVSROOT</code> environment variable. See section [[#SEC9|The
Repository]].
+</p>
+<div id="IDX210"></div>
+<div id="IDX211"></div>
+</dd>
+<dt> <code>-e <var>editor</var></code></dt>
+<dd><p>Use <var>editor</var> to enter revision log information. Overrides the
+setting of the <code>$CVSEDITOR</code> and <code>$EDITOR</code>
+environment variables. For more information, see
+[[#SEC6|Committing your changes]].
+</p>
+</dd>
+<dt> <code>-f</code></dt>
+<dd><p>Do not read the ‘<tt>~/.cvsrc</tt>’ file. This
+option is most often used because of the
+non-orthogonality of the <small>CVS</small> option set. For
+example, the ‘<samp>cvs log</samp>’ option
‘<samp>-N</samp>’ (turn off
+display of tag names) does not have a corresponding
+option to turn the display on. So if you have
+‘<samp>-N</samp>’ in the ‘<tt>~/.cvsrc</tt>’ entry for
‘<samp>log</samp>’,
+you may need to use ‘<samp>-f</samp>’ to show the tag names.
+</p>
+</dd>
+<dt> <code>-H</code></dt>
+<dt> <code>--help</code></dt>
+<dd><p>Display usage information about the specified
‘<samp>cvs_command</samp>’
+(but do not actually execute the command). If you don’t specify
+a command name, ‘<samp>cvs -H</samp>’ displays overall help for
+<small>CVS</small>, including a list of other help options.
+</p>
+</dd>
+<dt> <code>-l</code></dt>
+<dd><p>Do not log the ‘<samp>cvs_command</samp>’ in the command
history (but execute it
+anyway). See section [[#SEC137|history—Show status of files and
users]], for information on command history.
+</p>
+<div id="IDX212"></div>
+</dd>
+<dt> <code>-R</code></dt>
+<dd><p>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 CDROM
+repository.
+</p>
+<p>Same effect as if the <code>CVSREADONLYFS</code> environment
+variable is set. Using ‘<samp>-R</samp>’ can also considerably
+speed up checkout’s over NFS.
+</p>
+<div id="IDX213"></div>
+</dd>
+<dt> <code>-n</code></dt>
+<dd><p>Do not change any files. Attempt to execute the
+‘<samp>cvs_command</samp>’, but only to issue reports; do not
remove,
+update, or merge any existing files, or create any new files.
+</p>
+<p>Note that <small>CVS</small> will not necessarily produce exactly
+the same output as without ‘<samp>-n</samp>’. In some cases
+the output will be the same, but in other cases
+<small>CVS</small> will skip some of the processing that would
+have been required to produce the exact same output.
+</p>
+</dd>
+<dt> <code>-Q</code></dt>
+<dd><p>Cause the command to be really quiet; the command will only
+generate output for serious problems.
+</p>
+</dd>
+<dt> <code>-q</code></dt>
+<dd><p>Cause the command to be somewhat quiet; informational messages,
+such as reports of recursion through subdirectories, are
+suppressed.
+</p>
+<div id="IDX214"></div>
+</dd>
+<dt> <code>-r</code></dt>
+<dd><p>Make new working files read-only. Same effect
+as if the <code>$CVSREAD</code> environment variable is set
+(see section [[#SEC181|All environment variables which affect CVS]]). The
default is to
+make working files writable, unless watches are on
+(see section [[#SEC89|Mechanisms to track who is editing files]]).
+</p>
+</dd>
+<dt> <code>-s <var>variable</var>=<var>value</var></code></dt>
+<dd><p>Set a user variable (see section [[#SEC179|Expansions in administrative
files]]).
+</p>
+<div id="IDX215"></div>
+</dd>
+<dt> <code>-t</code></dt>
+<dd><p>Trace program execution; display messages showing the steps of
+<small>CVS</small> activity. Particularly useful with
‘<samp>-n</samp>’ to explore the
+potential impact of an unfamiliar command.
+</p>
+</dd>
+<dt> <code>-v</code></dt>
+<dt> <code>--version</code></dt>
+<dd><p>Display version and copyright information for <small>CVS</small>.
+</p>
+<div id="IDX216"></div>
+<div id="IDX217"></div>
+</dd>
+<dt> <code>-w</code></dt>
+<dd><p>Make new working files read-write. Overrides the
+setting of the <code>$CVSREAD</code> environment variable.
+Files are created read-write by default, unless <code>$CVSREAD</code> is
+set or ‘<samp>-r</samp>’ is given.
+</p>
+</dd>
+<dt> <code>-x</code></dt>
+<dd><div id="IDX218"></div>
+<p>Encrypt all communication between the client and the
+server. Only has an effect on the <small>CVS</small> client. As
+of this writing, this is only implemented when using a
+GSSAPI connection (see section [[#SEC33|Direct connection with GSSAPI]]) or a
+Kerberos connection (see section [[#SEC34|Direct connection with kerberos]]).
+Enabling encryption implies that message traffic is
+also authenticated. Encryption support is not
+available by default; it must be enabled using a
+special configure option, ‘<tt>--enable-encryption</tt>’,
+when you build <small>CVS</small>.
+</p>
+</dd>
+<dt> <code>-z <var>gzip-level</var></code></dt>
+<dd><div id="IDX219"></div>
+<div id="IDX220"></div>
+<p>Set the compression level.
+Valid levels are 1 (high speed, low compression) to
+9 (low speed, high compression), or 0 to disable
+compression (the default).
+Only has an effect on the <small>CVS</small> client.
+</p>
+</dd>
+</dl>
+
+<hr size="6">
+<div id="Common-options"></div>
+<div id="SEC119"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC118| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC120| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC114| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC114| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC156| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== Common command options ===
+
+<p>This section describes the ‘<samp>command_options</samp>’ that
+are available across several <small>CVS</small> commands. These
+options are always given to the right of
+‘<samp>cvs_command</samp>’. Not all
+commands support all of these options; each option is
+only supported for commands where it makes sense.
+However, when a command has one of these options you
+can almost always count on the same behavior of the
+option as in other commands. (Other command options,
+which are listed with the individual commands, may have
+different behavior from one <small>CVS</small> command to the other).
+</p>
+<p><strong>Note: the ‘<samp>history</samp>’ command is an
exception; it supports
+many options that conflict even with these standard options.</strong>
+</p>
+<dl compact="compact">
+<dd><div id="IDX221"></div>
+<div id="IDX222"></div>
+<div id="IDX223"></div>
+</dd>
+<dt> <code>-D <var>date_spec</var></code></dt>
+<dd><p>Use the most recent revision no later than <var>date_spec</var>.
+<var>date_spec</var> is a single argument, a date description
+specifying a date in the past.
+</p>
+<p>The specification is <em>sticky</em> when you use it to make a
+private copy of a source file; that is, when you get a working
+file using ‘<samp>-D</samp>’, <small>CVS</small> records the date
you specified, so that
+further updates in the same directory will use the same date
+(for more information on sticky tags/dates, see section [[#SEC53|Sticky
tags]]).
+</p>
+<p>‘<samp>-D</samp>’ is available with the <code>annotate</code>,
<code>checkout</code>,
+<code>diff</code>, <code>export</code>, <code>history</code>,
+<code>rdiff</code>, <code>rtag</code>, <code>tag</code>, and
<code>update</code> commands.
+(The <code>history</code> command uses this option in a
+slightly different way; see section [[#SEC138|history options]]).
+</p>
+
+<div id="IDX224"></div>
+<div id="IDX225"></div>
+<p>A wide variety of date formats are supported by
+<small>CVS</small>. The most standard ones are ISO8601 (from the
+International Standards Organization) and the Internet
+e-mail standard (specified in RFC822 as amended by
+RFC1123).
+</p>
+<p>ISO8601 dates have many variants but a few examples
+are:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>1972-09-24
+1972-09-24 20:05
+</nowiki></pre></td></tr></table>
+
+<p>There are a lot more ISO8601 date formats, and <small>CVS</small>
+accepts many of them, but you probably don’t want to
+hear the <em>whole</em> long story :-).
+</p>
+
+<p>In addition to the dates allowed in Internet e-mail
+itself, <small>CVS</small> also allows some of the fields to be
+omitted. For example:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>24 Sep 1972 20:05
+24 Sep
+</nowiki></pre></td></tr></table>
+
+<p>The date is interpreted as being in the
+local timezone, unless a specific timezone is
+specified.
+</p>
+<p>These two date formats are preferred. However,
+<small>CVS</small> currently accepts a wide variety of other date
+formats. They are intentionally not documented here in
+any detail, and future versions of <small>CVS</small> might not
+accept all of them.
+</p>
+<p>One such format is
+<code><var>month</var>/<var>day</var>/<var>year</var></code>. This may
+confuse people who are accustomed to having the month
+and day in the other order; ‘<samp>1/4/96</samp>’ is January 4,
+not April 1.
+</p>
+<p>Remember to quote the argument to the ‘<samp>-D</samp>’
+flag so that your shell doesn’t interpret spaces as
+argument separators. A command using the ‘<samp>-D</samp>’
+flag can look like this:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>$ cvs diff -D
"1 hour ago" cvs.texinfo
+</nowiki></pre></td></tr></table>
+
+<div id="IDX226"></div>
+</dd>
+<dt> <code>-f</code></dt>
+<dd><p>When you specify a particular date or tag to <small>CVS</small>
commands, they
+normally ignore files that do not contain the tag (or did not
+exist prior to the date) that you specified. Use the
‘<samp>-f</samp>’ option
+if you want files retrieved even when there is no match for the
+tag or date. (The most recent revision of the file
+will be used).
+</p>
+<p>Note that even with ‘<samp>-f</samp>’, a tag that you specify
+must exist (that is, in some file, not necessary in
+every file). This is so that <small>CVS</small> will continue to
+give an error if you mistype a tag name.
+</p>
+<p>‘<samp>-f</samp>’ is available with these commands:
+<code>annotate</code>, <code>checkout</code>, <code>export</code>,
+<code>rdiff</code>, <code>rtag</code>, and <code>update</code>.
+</p>
+<p><strong>WARNING: The <code>commit</code> and <code>remove</code>
+commands also have a
+‘<samp>-f</samp>’ option, but it has a different behavior for
+those commands. See [[#SEC126|commit options]], and
+[[#SEC68|Removing files]].</strong>
+</p>
+</dd>
+<dt> <code>-k <var>kflag</var></code></dt>
+<dd><p>Override the default processing of RCS keywords other than
+‘<samp>-kb</samp>’. See section [[#SEC98|Keyword substitution]],
for the meaning of
+<var>kflag</var>. Used with the <code>checkout</code> and <code>update</code>
+commands, your <var>kflag</var> specification is
+<em>sticky</em>; that is, when you use this option
+with a <code>checkout</code> or <code>update</code> command,
+<small>CVS</small> associates your selected <var>kflag</var> with any files
+it operates on, and continues to use that <var>kflag</var> with future
+commands on the same files until you specify otherwise.
+</p>
+<p>The ‘<samp>-k</samp>’ option is available with the
<code>add</code>,
+<code>checkout</code>, <code>diff</code>, <code>export</code>,
<code>import</code> and
+<code>update</code> commands.
+</p>
+<p><strong>WARNING: Prior to CVS version 1.12.2, the
‘<samp>-k</samp>’ flag
+overrode the ‘<samp>-kb</samp>’ indication for a binary file.
This could
+sometimes corrupt binary files. See section [[#SEC64|Merging and keywords]],
for
+more.</strong>
+</p>
+</dd>
+<dt> <code>-l</code></dt>
+<dd><p>Local; run only in current working directory, rather than
+recursing through subdirectories.
+</p>
+<p>Available with the following commands: <code>annotate</code>,
<code>checkout</code>,
+<code>commit</code>, <code>diff</code>, <code>edit</code>,
<code>editors</code>, <code>export</code>,
+<code>log</code>, <code>rdiff</code>, <code>remove</code>, <code>rtag</code>,
+<code>status</code>, <code>tag</code>, <code>unedit</code>,
<code>update</code>, <code>watch</code>,
+and <code>watchers</code>.
+</p>
+<div id="IDX227"></div>
+<div id="IDX228"></div>
+</dd>
+<dt> <code>-m <var>message</var></code></dt>
+<dd><p>Use <var>message</var> as log information, instead of
+invoking an editor.
+</p>
+<p>Available with the following commands: <code>add</code>,
+<code>commit</code> and <code>import</code>.
+</p>
+</dd>
+<dt> <code>-n</code></dt>
+<dd><p>Do not run any tag program. (A program can be
+specified to run in the modules
+database (see section [[#SEC158|The modules file]]); this option bypasses it).
+</p>
+<p><strong>Note: this is not the same as the ‘<samp>cvs -n</samp>’
+program option, which you can specify to the left of a cvs command!</strong>
+</p>
+<p>Available with the <code>checkout</code>, <code>commit</code>,
<code>export</code>,
+and <code>rtag</code> commands.
+</p>
+</dd>
+<dt> <code>-P</code></dt>
+<dd><p>Prune empty directories. See [[#SEC69|Removing directories]].
+</p>
+</dd>
+<dt> <code>-p</code></dt>
+<dd><p>Pipe the files retrieved from the repository to standard output,
+rather than writing them in the current directory. Available
+with the <code>checkout</code> and <code>update</code> commands.
+</p>
+</dd>
+<dt> <code>-R</code></dt>
+<dd><p>Process directories recursively. This is on by default.
+</p>
+<p>Available with the following commands: <code>annotate</code>,
<code>checkout</code>,
+<code>commit</code>, <code>diff</code>, <code>edit</code>,
<code>editors</code>, <code>export</code>,
+<code>rdiff</code>, <code>remove</code>, <code>rtag</code>,
+<code>status</code>, <code>tag</code>, <code>unedit</code>,
<code>update</code>, <code>watch</code>,
+and <code>watchers</code>.
+</p>
+</dd>
+<dt> <code>-r <var>tag</var></code></dt>
+<dd><div id="IDX229"></div>
+<div id="IDX230"></div>
+<p>Use the revision specified by the <var>tag</var> argument instead of the
+default <em>head</em> revision. As well as arbitrary tags defined
+with the <code>tag</code> or <code>rtag</code> command, two special tags are
+always available: ‘<samp>HEAD</samp>’ refers to the most recent
version
+available in the repository, and ‘<samp>BASE</samp>’ refers to the
+revision you last checked out into the current working directory.
+</p>
+
+<p>The tag specification is sticky when you use this
+with <code>checkout</code> or <code>update</code> to make your own
+copy of a file: <small>CVS</small> remembers the tag and continues to use it on
+future update commands, until you specify otherwise (for more information
+on sticky tags/dates, see section [[#SEC53|Sticky tags]]).
+</p>
+<p>The tag can be either a symbolic or numeric tag, as
+described in [[#SEC48|Tags–Symbolic revisions]], or the name of a
branch, as
+described in [[#SEC54|Branching and merging]].
+</p>
+<p>Specifying the ‘<samp>-q</samp>’ global option along with the
+‘<samp>-r</samp>’ command option is often useful, to suppress
+the warning messages when the <small>RCS</small> file
+does not contain the specified tag.
+</p>
+<p><strong>Note: this is not the same as the overall ‘<samp>cvs
-r</samp>’ option,
+which you can specify to the left of a <small>CVS</small> command!</strong>
+</p>
+<p>‘<samp>-r</samp>’ is available with the <code>checkout</code>,
<code>commit</code>,
+<code>diff</code>, <code>history</code>, <code>export</code>,
<code>rdiff</code>,
+<code>rtag</code>, and <code>update</code> commands.
+</p>
+</dd>
+<dt> <code>-W</code></dt>
+<dd><p>Specify file names that should be filtered. You can
+use this option repeatedly. The spec can be a file
+name pattern of the same type that you can specify in
+the ‘<tt>.cvswrappers</tt>’ file.
+Available with the following commands: <code>import</code>,
+and <code>update</code>.
+</p>
+</dd>
+</dl>
+
+<hr size="6">
+<div id="admin"></div>
+<div id="SEC120"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC119| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC121| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC114| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC114| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC156| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== admin—Administration ===
+
+<ul>
+<li>
+Requires: repository, working directory.
+</li><li>
+Changes: repository.
+</li><li>
+Synonym: rcs
+</li></ul>
+
+<p>This is the <small>CVS</small> interface to assorted
+administrative facilities. Some of them have
+questionable usefulness for <small>CVS</small> but exist for
+historical purposes. Some of the questionable options
+are likely to disappear in the future. This command
+<em>does</em> work recursively, so extreme care should be
+used.
+</p>
+<div id="IDX231"></div>
+<div id="IDX232"></div>
+<p>On unix, if there is a group named <code>cvsadmin</code>,
+only members of that group can run <code>cvs admin</code>
+commands, except for those specified using the
+<code>UserAdminOptions</code> configuration option in the
+‘<tt>CVSROOT/config</tt>’ file. Options specified using
+<code>UserAdminOptions</code> can be run by any user. See
+[[#SEC180|The CVSROOT/config configuration file]] for more on
<code>UserAdminOptions</code>.
+</p>
+<p>The <code>cvsadmin</code> group should exist on the server,
+or any system running the non-client/server <small>CVS</small>.
+To disallow <code>cvs admin</code> for all users, create a
+group with no users in it. On NT, the <code>cvsadmin</code>
+feature does not exist and all users
+can run <code>cvs admin</code>.
+</p>
+<pre class="menu-preformatted"><nowiki></nowiki>•[[#SEC121| admin
options]]::<nowiki> admin options
+</nowiki></pre>
+<hr size="6">
+<div id="admin-options"></div>
+<div id="SEC121"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC120| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC122| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC114| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC120| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC156| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+==== admin options ====
+
+<p>Some of these options have questionable usefulness for
+<small>CVS</small> but exist for historical purposes. Some even
+make it impossible to use <small>CVS</small> until you undo the
+effect!
+</p>
+<dl compact="compact">
+<dt> <code>-A<var>oldfile</var></code></dt>
+<dd><p>Might not work together with <small>CVS</small>. Append the
+access list of <var>oldfile</var> to the access list of the
+<small>RCS</small> file.
+</p>
+</dd>
+<dt> <code>-a<var>logins</var></code></dt>
+<dd><p>Might not work together with <small>CVS</small>. Append the
+login names appearing in the comma-separated list
+<var>logins</var> to the access list of the <small>RCS</small> file.
+</p>
+</dd>
+<dt> <code>-b[<var>rev</var>]</code></dt>
+<dd><p>Set the default branch to <var>rev</var>. In <small>CVS</small>, you
+normally do not manipulate default branches; sticky
+tags (see section [[#SEC53|Sticky tags]]) are a better way to decide
+which branch you want to work on. There is one reason
+to run <code>cvs admin -b</code>: to revert to the vendor’s
+version when using vendor branches (see section [[#SEC108|Reverting to the
latest vendor release]]).
+There can be no space between ‘<samp>-b</samp>’ and its argument.
+</p>
+<div id="IDX233"></div>
+</dd>
+<dt> <code>-c<var>string</var></code></dt>
+<dd><p>Sets the comment leader to <var>string</var>. The comment
+leader is not used by current versions of <small>CVS</small> or
+<small>RCS</small> 5.7. Therefore, you can almost surely not
+worry about it. See section [[#SEC98|Keyword substitution]].
+</p>
+</dd>
+<dt> <code>-e[<var>logins</var>]</code></dt>
+<dd><p>Might not work together with <small>CVS</small>. Erase the login
+names appearing in the comma-separated list
+<var>logins</var> from the access list of the RCS file. If
+<var>logins</var> is omitted, erase the entire access list.
+There can be no space between ‘<samp>-e</samp>’ and its argument.
+</p>
+</dd>
+<dt> <code>-I</code></dt>
+<dd><p>Run interactively, even if the standard input is not a
+terminal. This option does not work with the
+client/server <small>CVS</small> and is likely to disappear in
+a future release of <small>CVS</small>.
+</p>
+</dd>
+<dt> <code>-i</code></dt>
+<dd><p>Useless with <small>CVS</small>. This creates and initializes a
+new <small>RCS</small> file, without depositing a revision. With
+<small>CVS</small>, add files with the <code>cvs add</code> command
+(see section [[#SEC67|Adding files to a directory]]).
+</p>
+</dd>
+<dt> <code>-k<var>subst</var></code></dt>
+<dd><p>Set the default keyword
+substitution to <var>subst</var>. See section [[#SEC98|Keyword
substitution]]. Giving an explicit ‘<samp>-k</samp>’ option to
+<code>cvs update</code>, <code>cvs export</code>, or <code>cvs
+checkout</code> overrides this default.
+</p>
+</dd>
+<dt> <code>-l[<var>rev</var>]</code></dt>
+<dd><p>Lock the revision with number <var>rev</var>. If a branch
+is given, lock the latest revision on that branch. If
+<var>rev</var> is omitted, lock the latest revision on the
+default branch. There can be no space between
+‘<samp>-l</samp>’ and its argument.
+</p>
+<p>This can be used in conjunction with the
+‘<tt>rcslock.pl</tt>’ script in the ‘<tt>contrib</tt>’
+directory of the <small>CVS</small> source distribution to
+provide reserved checkouts (where only one user can be
+editing a given file at a time). See the comments in
+that file for details (and see the ‘<tt>README</tt>’ file
+in that directory for disclaimers about the unsupported
+nature of contrib). According to comments in that
+file, locking must set to strict (which is the default).
+</p>
+</dd>
+<dt> <code>-L</code></dt>
+<dd><p>Set locking to strict. Strict locking means that the
+owner of an RCS file is not exempt from locking for
+checkin. For use with <small>CVS</small>, strict locking must be
+set; see the discussion under the ‘<samp>-l</samp>’ option above.
+</p>
+<div id="IDX234"></div>
+<div id="IDX235"></div>
+<div id="IDX236"></div>
+<div id="IDX237"></div>
+<div id="IDX238"></div>
+</dd>
+<dt> <code>-m<var>rev</var>:<var>msg</var></code></dt>
+<dd><p>Replace the log message of revision <var>rev</var> with
+<var>msg</var>.
+</p>
+
+</dd>
+<dt> <code>-N<var>name</var>[:[<var>rev</var>]]</code></dt>
+<dd><p>Act like ‘<samp>-n</samp>’, except override any previous
+assignment of <var>name</var>. For use with magic branches,
+see [[#SEC59|Magic branch numbers]].
+</p>
+</dd>
+<dt> <code>-n<var>name</var>[:[<var>rev</var>]]</code></dt>
+<dd><p>Associate the symbolic name <var>name</var> with the branch
+or revision <var>rev</var>. It is normally better to use
+‘<samp>cvs tag</samp>’ or ‘<samp>cvs rtag</samp>’
instead. Delete the
+symbolic name if both ‘<samp>:</samp>’ and <var>rev</var> are
+omitted; otherwise, print an error message if
+<var>name</var> is already associated with another number.
+If <var>rev</var> is symbolic, it is expanded before
+association. A <var>rev</var> consisting of a branch number
+followed by a ‘<samp>.</samp>’ stands for the current latest
+revision in the branch. A ‘<samp>:</samp>’ with an empty
+<var>rev</var> stands for the current latest revision on the
+default branch, normally the trunk. For example,
+‘<samp>cvs admin -n<var>name</var>:</samp>’ associates
<var>name</var> with the
+current latest revision of all the RCS files;
+this contrasts with ‘<samp>cvs admin -n<var>name</var>:$</samp>’
which
+associates <var>name</var> with the revision numbers
+extracted from keyword strings in the corresponding
+working files.
+</p>
+<div id="IDX239"></div>
+<div id="IDX240"></div>
+<div id="IDX241"></div>
+</dd>
+<dt> <code>-o<var>range</var></code></dt>
+<dd><p>Deletes (<em>outdates</em>) the revisions given by
+<var>range</var>.
+</p>
+<p>Note that this command can be quite dangerous unless
+you know <em>exactly</em> what you are doing (for example
+see the warnings below about how the
+<var>rev1</var>:<var>rev2</var> syntax is confusing).
+</p>
+<p>If you are short on disc this option might help you.
+But think twice before using it—there is no way short
+of restoring the latest backup to undo this command!
+If you delete different revisions than you planned,
+either due to carelessness or (heaven forbid) a <small>CVS</small>
+bug, there is no opportunity to correct the error
+before the revisions are deleted. It probably would be
+a good idea to experiment on a copy of the repository
+first.
+</p>
+<p>Specify <var>range</var> in one of the following ways:
+</p>
+<dl compact="compact">
+<dt> <code><var>rev1</var>::<var>rev2</var></code></dt>
+<dd><p>Collapse all revisions between rev1 and rev2, so that
+<small>CVS</small> only stores the differences associated with going
+from rev1 to rev2, not intermediate steps. For
+example, after ‘<samp>-o 1.3::1.5</samp>’ one can retrieve
+revision 1.3, revision 1.5, or the differences to get
+from 1.3 to 1.5, but not the revision 1.4, or the
+differences between 1.3 and 1.4. Other examples:
+‘<samp>-o 1.3::1.4</samp>’ and ‘<samp>-o
1.3::1.3</samp>’ have no
+effect, because there are no intermediate revisions to
+remove.
+</p>
+</dd>
+<dt> <code>::<var>rev</var></code></dt>
+<dd><p>Collapse revisions between the beginning of the branch
+containing <var>rev</var> and <var>rev</var> itself. The
+branchpoint and <var>rev</var> are left intact. For
+example, ‘<samp>-o ::1.3.2.6</samp>’ deletes revision 1.3.2.1,
+revision 1.3.2.5, and everything in between, but leaves
+1.3 and 1.3.2.6 intact.
+</p>
+</dd>
+<dt> <code><var>rev</var>::</code></dt>
+<dd><p>Collapse revisions between <var>rev</var> and the end of the
+branch containing <var>rev</var>. Revision <var>rev</var> is
+left intact but the head revision is deleted.
+</p>
+</dd>
+<dt> <code><var>rev</var></code></dt>
+<dd><p>Delete the revision <var>rev</var>. For example, ‘<samp>-o
+1.3</samp>’ is equivalent to ‘<samp>-o 1.2::1.4</samp>’.
+</p>
+</dd>
+<dt> <code><var>rev1</var>:<var>rev2</var></code></dt>
+<dd><p>Delete the revisions from <var>rev1</var> to <var>rev2</var>,
+inclusive, on the same branch. One will not be able to
+retrieve <var>rev1</var> or <var>rev2</var> or any of the
+revisions in between. For example, the command
+‘<samp>cvs admin -oR_1_01:R_1_02 .</samp>’ is rarely useful.
+It means to delete revisions up to, and including, the
+tag R_1_02. But beware! If there are files that have not
+changed between R_1_02 and R_1_03 the file will have
+<em>the same</em> numerical revision number assigned to
+the tags R_1_02 and R_1_03. So not only will it be
+impossible to retrieve R_1_02; R_1_03 will also have to
+be restored from the tapes! In most cases you want to
+specify <var>rev1</var>::<var>rev2</var> instead.
+</p>
+</dd>
+<dt> <code>:<var>rev</var></code></dt>
+<dd><p>Delete revisions from the beginning of the
+branch containing <var>rev</var> up to and including
+<var>rev</var>.
+</p>
+</dd>
+<dt> <code><var>rev</var>:</code></dt>
+<dd><p>Delete revisions from revision <var>rev</var>, including
+<var>rev</var> itself, to the end of the branch containing
+<var>rev</var>.
+</p></dd>
+</dl>
+
+<p>None of the revisions to be deleted may have
+branches or locks.
+</p>
+<p>If any of the revisions to be deleted have symbolic
+names, and one specifies one of the ‘<samp>::</samp>’ syntaxes,
+then <small>CVS</small> will give an error and not delete any
+revisions. If you really want to delete both the
+symbolic names and the revisions, first delete the
+symbolic names with <code>cvs tag -d</code>, then run
+<code>cvs admin -o</code>. If one specifies the
+non-‘<samp>::</samp>’ syntaxes, then <small>CVS</small> will
delete the
+revisions but leave the symbolic names pointing to
+nonexistent revisions. This behavior is preserved for
+compatibility with previous versions of <small>CVS</small>, but
+because it isn’t very useful, in the future it may
+change to be like the ‘<samp>::</samp>’ case.
+</p>
+<p>Due to the way <small>CVS</small> handles branches <var>rev</var>
+cannot be specified symbolically if it is a branch.
+See section [[#SEC59|Magic branch numbers]], for an explanation.
+</p>
+<p>Make sure that no-one has checked out a copy of the
+revision you outdate. Strange things will happen if he
+starts to edit it and tries to check it back in. For
+this reason, this option is not a good way to take back
+a bogus commit; commit a new revision undoing the bogus
+change instead (see section [[#SEC62|Merging differences between any two
revisions]]).
+</p>
+</dd>
+<dt> <code>-q</code></dt>
+<dd><p>Run quietly; do not print diagnostics.
+</p>
+</dd>
+<dt> <code>-s<var>state</var>[:<var>rev</var>]</code></dt>
+<dd><p>Useful with <small>CVS</small>. Set the state attribute of the
+revision <var>rev</var> to <var>state</var>. If <var>rev</var> is a
+branch number, assume the latest revision on that
+branch. If <var>rev</var> is omitted, assume the latest
+revision on the default branch. Any identifier is
+acceptable for <var>state</var>. A useful set of states is
+‘<samp>Exp</samp>’ (for experimental),
‘<samp>Stab</samp>’ (for
+stable), and ‘<samp>Rel</samp>’ (for released). By default,
+the state of a new revision is set to ‘<samp>Exp</samp>’ when
+it is created. The state is visible in the output from
+<var>cvs log</var> (see section [[#SEC143|log—Print out log information
for files]]), and in the
+‘<samp>$<i></i>Log$</samp>’ and
‘<samp>$<i></i>State$</samp>’ keywords
+(see section [[#SEC98|Keyword substitution]]). Note that <small>CVS</small>
+uses the <code>dead</code> state for its own purposes; to
+take a file to or from the <code>dead</code> state use
+commands like <code>cvs remove</code> and <code>cvs add</code>, not
+<code>cvs admin -s</code>.
+</p>
+</dd>
+<dt> <code>-t[<var>file</var>]</code></dt>
+<dd><p>Useful with <small>CVS</small>. Write descriptive text from the
+contents of the named <var>file</var> into the RCS file,
+deleting the existing text. The <var>file</var> pathname
+may not begin with ‘<samp>-</samp>’. The descriptive text can be
seen in the
+output from ‘<samp>cvs log</samp>’ (see section
[[#SEC143|log—Print out log information for files]]).
+There can be no space between ‘<samp>-t</samp>’ and its argument.
+</p>
+<p>If <var>file</var> is omitted,
+obtain the text from standard input, terminated by
+end-of-file or by a line containing ‘<samp>.</samp>’ by itself.
+Prompt for the text if interaction is possible; see
+‘<samp>-I</samp>’.
+</p>
+</dd>
+<dt> <code>-t-<var>string</var></code></dt>
+<dd><p>Similar to ‘<samp>-t<var>file</var></samp>’. Write
descriptive text
+from the <var>string</var> into the <small>RCS</small> file, deleting
+the existing text.
+There can be no space between ‘<samp>-t</samp>’ and its argument.
+</p>
+
+</dd>
+<dt> <code>-U</code></dt>
+<dd><p>Set locking to non-strict. Non-strict locking means
+that the owner of a file need not lock a revision for
+checkin. For use with <small>CVS</small>, strict locking must be
+set; see the discussion under the ‘<samp>-l</samp>’ option
+above.
+</p>
+</dd>
+<dt> <code>-u[<var>rev</var>]</code></dt>
+<dd><p>See the option ‘<samp>-l</samp>’ above, for a discussion of
+using this option with <small>CVS</small>. Unlock the revision
+with number <var>rev</var>. If a branch is given, unlock
+the latest revision on that branch. If <var>rev</var> is
+omitted, remove the latest lock held by the caller.
+Normally, only the locker of a revision may unlock it;
+somebody else unlocking a revision breaks the lock.
+This causes the original locker to be sent a <code>commit</code>
+notification (see section [[#SEC91|Telling CVS to notify you]]).
+There can be no space between ‘<samp>-u</samp>’ and its argument.
+</p>
+</dd>
+<dt> <code>-V<var>n</var></code></dt>
+<dd><p>In previous versions of <small>CVS</small>, this option meant to
+write an <small>RCS</small> file which would be acceptable to
+<small>RCS</small> version <var>n</var>, but it is now obsolete and
+specifying it will produce an error.
+</p>
+</dd>
+<dt> <code>-x<var>suffixes</var></code></dt>
+<dd><p>In previous versions of <small>CVS</small>, this was documented
+as a way of specifying the names of the <small>RCS</small>
+files. However, <small>CVS</small> has always required that the
+<small>RCS</small> files used by <small>CVS</small> end in
‘<samp>,v</samp>’, so
+this option has never done anything useful.
+</p>
+</dd>
+</dl>
+
+
+<hr size="6">
+<div id="checkout"></div>
+<div id="SEC122"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC121| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC123| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC114| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC114| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC156| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== checkout—Check out sources for editing ===
+
+<ul>
+<li>
+Synopsis: checkout [options] modules…
+</li><li>
+Requires: repository.
+</li><li>
+Changes: working directory.
+</li><li>
+Synonyms: co, get
+</li></ul>
+
+<p>Create or update a working directory containing copies of the
+source files specified by <var>modules</var>. You must execute
+<code>checkout</code> before using most of the other <small>CVS</small>
+commands, since most of them operate on your working
+directory.
+</p>
+<p>The <var>modules</var> are either
+symbolic names for some
+collection of source directories and files, or paths to
+directories or files in the repository. The symbolic
+names are defined in the ‘<samp>modules</samp>’ file.
+See section [[#SEC158|The modules file]].
+</p>
+<p>Depending on the modules you specify, <code>checkout</code> may
+recursively create directories and populate them with
+the appropriate source files. You can then edit these
+source files at any time (regardless of whether other
+software developers are editing their own copies of the
+sources); update them to include new changes applied by
+others to the source repository; or commit your work as
+a permanent change to the source repository.
+</p>
+<p>Note that <code>checkout</code> is used to create
+directories. The top-level directory created is always
+added to the directory where <code>checkout</code> is
+invoked, and usually has the same name as the specified
+module. In the case of a module alias, the created
+sub-directory may have a different name, but you can be
+sure that it will be a sub-directory, and that
+<code>checkout</code> will show the relative path leading to
+each file as it is extracted into your private work
+area (unless you specify the ‘<samp>-Q</samp>’ global option).
+</p>
+<p>The files created by <code>checkout</code> are created
+read-write, unless the ‘<samp>-r</samp>’ option to
<small>CVS</small>
+(see section [[#SEC118|Global options]]) is specified, the
+<code>CVSREAD</code> environment variable is specified
+(see section [[#SEC181|All environment variables which affect CVS]]), or a
watch is in
+effect for that file (see section [[#SEC89|Mechanisms to track who is editing
files]]).
+</p>
+<p>Note that running <code>checkout</code> on a directory that was already
+built by a prior <code>checkout</code> is also permitted.
+This is similar to specifying the ‘<samp>-d</samp>’ option
+to the <code>update</code> command in the sense that new
+directories that have been created in the repository
+will appear in your work area.
+However, <code>checkout</code> takes a module name whereas
+<code>update</code> takes a directory name. Also
+to use <code>checkout</code> this way it must be run from the
+top level directory (where you originally ran
+<code>checkout</code> from), so before you run
+<code>checkout</code> to update an existing directory, don’t
+forget to change your directory to the top level
+directory.
+</p>
+<p>For the output produced by the <code>checkout</code> command
+see [[#SEC155|update output]].
+</p>
+<pre class="menu-preformatted"><nowiki></nowiki>•[[#SEC123| checkout
options]]::<nowiki> checkout options
+</nowiki>•[[#SEC124| checkout examples]]::<nowiki> checkout
examples
+</nowiki></pre>
+<hr size="6">
+<div id="checkout-options"></div>
+<div id="SEC123"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC122| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC124| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC114| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC122| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC156| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+==== checkout options ====
+
+<p>These standard options are supported by <code>checkout</code>
+(see section [[#SEC119|Common command options]], for a complete description of
+them):
+</p>
+<dl compact="compact">
+<dt> <code>-D <var>date</var></code></dt>
+<dd><p>Use the most recent revision no later than <var>date</var>.
+This option is sticky, and implies ‘<samp>-P</samp>’. See
+[[#SEC53|Sticky tags]], for more information on sticky tags/dates.
+</p>
+</dd>
+<dt> <code>-f</code></dt>
+<dd><p>Only useful with the ‘<samp>-D <var>date</var></samp>’ or
‘<samp>-r
+<var>tag</var></samp>’ flags. If no matching revision is found,
+retrieve the most recent revision (instead of ignoring
+the file).
+</p>
+</dd>
+<dt> <code>-k <var>kflag</var></code></dt>
+<dd><p>Process keywords according to <var>kflag</var>. See
+[[#SEC98|Keyword substitution]].
+This option is sticky; future updates of
+this file in this working directory will use the same
+<var>kflag</var>. The <code>status</code> command can be viewed
+to see the sticky options. See [[#SEC156|Quick reference to CVS commands]],
for
+more information on the <code>status</code> command.
+</p>
+</dd>
+<dt> <code>-l</code></dt>
+<dd><p>Local; run only in current working directory.
+</p>
+</dd>
+<dt> <code>-n</code></dt>
+<dd><p>Do not run any checkout program (as specified
+with the ‘<samp>-o</samp>’ option in the modules file;
+see section [[#SEC158|The modules file]]).
+</p>
+</dd>
+<dt> <code>-P</code></dt>
+<dd><p>Prune empty directories. See [[#SEC74|Moving and renaming
directories]].
+</p>
+</dd>
+<dt> <code>-p</code></dt>
+<dd><p>Pipe files to the standard output.
+</p>
+</dd>
+<dt> <code>-R</code></dt>
+<dd><p>Checkout directories recursively. This option is on by default.
+</p>
+</dd>
+<dt> <code>-r <var>tag</var></code></dt>
+<dd><p>Use revision <var>tag</var>. This option is sticky, and implies
‘<samp>-P</samp>’.
+See [[#SEC53|Sticky tags]], for more information on sticky tags/dates.
+</p></dd>
+</dl>
+
+<p>In addition to those, you can use these special command
+options with <code>checkout</code>:
+</p>
+<dl compact="compact">
+<dt> <code>-A</code></dt>
+<dd><p>Reset any sticky tags, dates, or ‘<samp>-k</samp>’ options.
+See [[#SEC53|Sticky tags]], for more information on sticky tags/dates.
+</p>
+</dd>
+<dt> <code>-c</code></dt>
+<dd><p>Copy the module file, sorted, to the standard output,
+instead of creating or modifying any files or
+directories in your working directory.
+</p>
+</dd>
+<dt> <code>-d <var>dir</var></code></dt>
+<dd><p>Create a directory called <var>dir</var> for the working
+files, instead of using the module name. In general,
+using this flag is equivalent to using ‘<samp>mkdir
+<var>dir</var>; cd <var>dir</var></samp>’ followed by the checkout
+command without the ‘<samp>-d</samp>’ flag.
+</p>
+<p>There is an important exception, however. It is very
+convenient when checking out a single item to have the
+output appear in a directory that doesn’t contain empty
+intermediate directories. In this case <em>only</em>,
+<small>CVS</small> tries to “shorten” pathnames to avoid those
empty
+directories.
+</p>
+<p>For example, given a module ‘<samp>foo</samp>’ that contains
+the file ‘<samp>bar.c</samp>’, the command ‘<samp>cvs co -d
dir
+foo</samp>’ will create directory ‘<samp>dir</samp>’ and
place
+‘<samp>bar.c</samp>’ inside. Similarly, given a module
+‘<samp>bar</samp>’ which has subdirectory
‘<samp>baz</samp>’ wherein
+there is a file ‘<samp>quux.c</samp>’, the command
‘<samp>cvs co
+-d dir bar/baz</samp>’ will create directory
‘<samp>dir</samp>’ and
+place ‘<samp>quux.c</samp>’ inside.
+</p>
+<p>Using the ‘<samp>-N</samp>’ flag will defeat this behavior.
+Given the same module definitions above, ‘<samp>cvs co
+-N -d dir foo</samp>’ will create directories
‘<samp>dir/foo</samp>’
+and place ‘<samp>bar.c</samp>’ inside, while ‘<samp>cvs co
-N -d
+dir bar/baz</samp>’ will create directories
‘<samp>dir/bar/baz</samp>’
+and place ‘<samp>quux.c</samp>’ inside.
+</p>
+</dd>
+<dt> <code>-j <var>tag</var></code></dt>
+<dd><p>With two ‘<samp>-j</samp>’ options, merge changes from the
+revision specified with the first ‘<samp>-j</samp>’ option to
+the revision specified with the second ‘<samp>j</samp>’ option,
+into the working directory.
+</p>
+<p>With one ‘<samp>-j</samp>’ option, merge changes from the
+ancestor revision to the revision specified with the
+‘<samp>-j</samp>’ 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 ‘<samp>-j</samp>’ option.
+</p>
+<p>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:
+‘<samp>-j<var>Symbolic_Tag</var>:<var>Date_Specifier</var></samp>’.
+</p>
+<p>See section [[#SEC54|Branching and merging]].
+</p>
+</dd>
+<dt> <code>-N</code></dt>
+<dd><p>Only useful together with ‘<samp>-d <var>dir</var></samp>’.
With
+this option, <small>CVS</small> will not “shorten” module paths
+in your working directory when you check out a single
+module. See the ‘<samp>-d</samp>’ flag for examples and a
+discussion.
+</p>
+</dd>
+<dt> <code>-s</code></dt>
+<dd><p>Like ‘<samp>-c</samp>’, but include the status of all
modules,
+and sort it by the status string. See section [[#SEC158|The modules file]],
for
+info about the ‘<samp>-s</samp>’ option that is used inside the
+modules file to set the module status.
+</p></dd>
+</dl>
+
+<hr size="6">
+<div id="checkout-examples"></div>
+<div id="SEC124"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC123| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC125| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC114| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC122| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC156| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+==== checkout examples ====
+
+<p>Get a copy of the module ‘<samp>tc</samp>’:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>$ cvs checkout tc
+</nowiki></pre></td></tr></table>
+
+<p>Get a copy of the module ‘<samp>tc</samp>’ as it looked one day
+ago:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>$ cvs checkout -D
yesterday tc
+</nowiki></pre></td></tr></table>
+
+<hr size="6">
+<div id="commit"></div>
+<div id="SEC125"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC124| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC126| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC114| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC114| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC156| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== commit—Check files into the repository ===
+
+<ul>
+<li>
+Synopsis: commit [-lnRf] [-m ’log_message’ |
+-F file] [-r revision] [files…]
+</li><li>
+Requires: working directory, repository.
+</li><li>
+Changes: repository.
+</li><li>
+Synonym: ci
+</li></ul>
+
+<p>Use <code>commit</code> when you want to incorporate changes
+from your working source files into the source
+repository.
+</p>
+<p>If you don’t specify particular files to commit, all of
+the files in your working current directory are
+examined. <code>commit</code> is careful to change in the
+repository only those files that you have really
+changed. By default (or if you explicitly specify the
+‘<samp>-R</samp>’ option), files in subdirectories are also
+examined and committed if they have changed; you can
+use the ‘<samp>-l</samp>’ option to limit <code>commit</code> to
the
+current directory only.
+</p>
+<p><code>commit</code> verifies that the selected files are up
+to date with the current revisions in the source
+repository; it will notify you, and exit without
+committing, if any of the specified files must be made
+current first with <code>update</code> (see section
[[#SEC153|update—Bring work tree in sync with repository]]).
+<code>commit</code> does not call the <code>update</code> command
+for you, but rather leaves that for you to do when the
+time is right.
+</p>
+<p>When all is well, an editor is invoked to allow you to
+enter a log message that will be written to one or more
+logging programs (see section [[#SEC158|The modules file]], and see section
[[#SEC172|Loginfo]])
+and placed in the <small>RCS</small> file inside the
+repository. This log message can be retrieved with the
+<code>log</code> command; see [[#SEC143|log—Print out log information
for files]]. You can specify the
+log message on the command line with the ‘<samp>-m
+<var>message</var></samp>’ option, and thus avoid the editor invocation,
+or use the ‘<samp>-F <var>file</var></samp>’ option to specify
+that the argument file contains the log message.
+</p>
+<pre class="menu-preformatted"><nowiki></nowiki>•[[#SEC126| commit
options]]::<nowiki> commit options
+</nowiki>•[[#SEC127| commit examples]]::<nowiki> commit
examples
+</nowiki></pre>
+<hr size="6">
+<div id="commit-options"></div>
+<div id="SEC126"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC125| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC127| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC114| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC125| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC156| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+==== commit options ====
+
+<p>These standard options are supported by <code>commit</code>
+(see section [[#SEC119|Common command options]], for a complete description of
+them):
+</p>
+<dl compact="compact">
+<dt> <code>-l</code></dt>
+<dd><p>Local; run only in current working directory.
+</p>
+</dd>
+<dt> <code>-R</code></dt>
+<dd><p>Commit directories recursively. This is on by default.
+</p>
+</dd>
+<dt> <code>-r <var>revision</var></code></dt>
+<dd><p>Commit to <var>revision</var>. <var>revision</var> must be
+either a branch, or a revision on the main trunk that
+is higher than any existing revision number
+(see section [[#SEC47|Assigning revisions]]). You
+cannot commit to a specific revision on a branch.
+</p></dd>
+</dl>
+
+<p><code>commit</code> also supports these options:
+</p>
+<dl compact="compact">
+<dt> <code>-F <var>file</var></code></dt>
+<dd><p>Read the log message from <var>file</var>, instead
+of invoking an editor.
+</p>
+</dd>
+<dt> <code>-f</code></dt>
+<dd><p>Note that this is not the standard behavior of
+the ‘<samp>-f</samp>’ option as defined in [[#SEC119|Common
command options]].
+</p>
+<p>Force <small>CVS</small> to commit a new revision even if you haven’t
+made any changes to the file. If the current revision
+of <var>file</var> is 1.7, then the following two commands
+are equivalent:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>$ cvs commit -f
<var>file</var>
+$ cvs commit -r 1.8 <var>file</var>
+</nowiki></pre></td></tr></table>
+
+<p>The ‘<samp>-f</samp>’ option disables recursion (i.e., it
+implies ‘<samp>-l</samp>’). To force <small>CVS</small> to commit
a new
+revision for all files in all subdirectories, you must
+use ‘<samp>-f -R</samp>’.
+</p>
+</dd>
+<dt> <code>-m <var>message</var></code></dt>
+<dd><p>Use <var>message</var> as the log message, instead of
+invoking an editor.
+</p></dd>
+</dl>
+
+<hr size="6">
+<div id="commit-examples"></div>
+<div id="SEC127"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC126| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC128| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC114| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC125| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC156| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+==== commit examples ====
+
+
+<hr size="6">
+<div id="SEC128"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC127| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC129| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC114| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC127| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC156| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+===== Committing to a branch =====
+
+<p>You can commit to a branch revision (one that has an
+even number of dots) with the ‘<samp>-r</samp>’ option. To
+create a branch revision, use the ‘<samp>-b</samp>’ option
+of the <code>rtag</code> or <code>tag</code> commands
+(see section [[#SEC54|Branching and merging]]). Then, either
<code>checkout</code> or
+<code>update</code> can be used to base your sources on the
+newly created branch. From that point on, all
+<code>commit</code> 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:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>$ 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
+</nowiki></pre></td></tr></table>
+
+<p>This works automatically since the ‘<samp>-r</samp>’ option is
+sticky.
+</p>
+<hr size="6">
+<div id="SEC129"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC128| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC130| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC114| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC127| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC156| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+===== Creating the branch after editing =====
+
+<p>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 <small>CVS</small> conflict resolution. The scenario might
+look like:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>[[ hacked sources
are present ]]
+$ cvs tag -b EXPR1
+$ cvs update -r EXPR1
+$ cvs commit
+</nowiki></pre></td></tr></table>
+
+<p>The <code>update</code> command will make the ‘<samp>-r
+EXPR1</samp>’ option sticky on all files. Note that your
+changes to the files will never be removed by the
+<code>update</code> command. The <code>commit</code> will
+automatically commit to the correct branch, because the
+‘<samp>-r</samp>’ is sticky. You could also do like this:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>[[ hacked sources
are present ]]
+$ cvs tag -b EXPR1
+$ cvs commit -r EXPR1
+</nowiki></pre></td></tr></table>
+
+<p>but then, only those files that were changed by you
+will have the ‘<samp>-r EXPR1</samp>’ sticky flag. If you hack
+away, and commit without specifying the ‘<samp>-r EXPR1</samp>’
+flag, some files may accidentally end up on the main
+trunk.
+</p>
+<p>To work with you on the experimental change, others
+would simply do
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>$ cvs checkout -r
EXPR1 whatever_module
+</nowiki></pre></td></tr></table>
+
+<hr size="6">
+<div id="diff"></div>
+<div id="SEC130"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC129| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC131| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC114| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC114| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC156| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== diff—Show differences between revisions ===
+
+<ul>
+<li>
+Synopsis: diff [-lR] [-k kflag] [format_options] [[-r rev1 | -D date1] [-r
rev2 | -D date2]] [files…]
+</li><li>
+Requires: working directory, repository.
+</li><li>
+Changes: nothing.
+</li></ul>
+
+<p>The <code>diff</code> 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.
+</p>
+<p>If any file names are given, only those files are
+compared. If any directories are given, all files
+under them will be compared.
+</p>
+<p>The exit status for diff is different than for other
+<small>CVS</small> commands; for details [[#SEC116|CVS’s exit status]].
+</p>
+<pre class="menu-preformatted"><nowiki></nowiki>•[[#SEC131| diff
options]]::<nowiki> diff options
+</nowiki>•[[#SEC134| diff examples]]::<nowiki> diff examples
+</nowiki></pre>
+<hr size="6">
+<div id="diff-options"></div>
+<div id="SEC131"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC130| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC132| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC114| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC130| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC156| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+==== diff options ====
+
+<p>These standard options are supported by <code>diff</code>
+(see section [[#SEC119|Common command options]], for a complete description of
+them):
+</p>
+<dl compact="compact">
+<dt> <code>-D <var>date</var></code></dt>
+<dd><p>Use the most recent revision no later than <var>date</var>.
+See ‘<samp>-r</samp>’ for how this affects the comparison.
+</p>
+</dd>
+<dt> <code>-k <var>kflag</var></code></dt>
+<dd><p>Process keywords according to <var>kflag</var>. See
+[[#SEC98|Keyword substitution]].
+</p>
+</dd>
+<dt> <code>-l</code></dt>
+<dd><p>Local; run only in current working directory.
+</p>
+</dd>
+<dt> <code>-R</code></dt>
+<dd><p>Examine directories recursively. This option is on by
+default.
+</p>
+</dd>
+<dt> <code>-r <var>tag</var></code></dt>
+<dd><p>Compare with revision <var>tag</var>. Zero, one or two
+‘<samp>-r</samp>’ options can be present. With no
‘<samp>-r</samp>’
+option, the working file will be compared with the
+revision it was based on. With one ‘<samp>-r</samp>’, that
+revision will be compared to your current working file.
+With two ‘<samp>-r</samp>’ options those two revisions will be
+compared (and your working file will not affect the
+outcome in any way).
+</p>
+<p>One or both ‘<samp>-r</samp>’ options can be replaced by a
+‘<samp>-D <var>date</var></samp>’ option, described above.
+</p></dd>
+</dl>
+
+<p>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 ‘<samp>-</samp>’, and the other of which is a long
name preceded by
+‘<samp>--</samp>’.
+</p>
+<dl compact="compact">
+<dt> ‘<samp>-<var>lines</var></samp>’</dt>
+<dd><p>Show <var>lines</var> (an integer) lines of context. This option does
not
+specify an output format by itself; it has no effect unless it is
+combined with ‘<samp>-c</samp>’ or ‘<samp>-u</samp>’.
This option is obsolete. For proper
+operation, <code>patch</code> typically needs at least two lines of context.
+</p>
+</dd>
+<dt> ‘<samp>-a</samp>’</dt>
+<dd><p>Treat all files as text and compare them line-by-line, even if they
+do not seem to be text.
+</p>
+</dd>
+<dt> ‘<samp>-b</samp>’</dt>
+<dd><p>Ignore trailing white space and consider all other sequences of one or
+more white space characters to be equivalent.
+</p>
+</dd>
+<dt> ‘<samp>-B</samp>’</dt>
+<dd><p>Ignore changes that just insert or delete blank lines.
+</p>
+</dd>
+<dt> ‘<samp>--binary</samp>’</dt>
+<dd><p>Read and write data in binary mode.
+</p>
+</dd>
+<dt> ‘<samp>--brief</samp>’</dt>
+<dd><p>Report only whether the files differ, not the details of the
+differences.
+</p>
+</dd>
+<dt> ‘<samp>-c</samp>’</dt>
+<dd><p>Use the context output format.
+</p>
+</dd>
+<dt> ‘<samp>-C <var>lines</var></samp>’</dt>
+<dt> ‘<samp>--context<span class="roman">[</span>=<var>lines</var><span
class="roman">]</span></samp>’</dt>
+<dd><p>Use the context output format, showing <var>lines</var> (an integer)
lines of
+context, or three if <var>lines</var> is not given.
+For proper operation, <code>patch</code> typically needs at least two lines of
+context.
+</p>
+</dd>
+<dt> ‘<samp>--changed-group-format=<var>format</var></samp>’</dt>
+<dd><p>Use <var>format</var> to output a line group containing differing lines
from
+both files in if-then-else format. See section [[#SEC132|Line group formats]].
+</p>
+</dd>
+<dt> ‘<samp>-d</samp>’</dt>
+<dd><p>Change the algorithm to perhaps find a smaller set of changes. This
makes
+<code>diff</code> slower (sometimes much slower).
+</p>
+</dd>
+<dt> ‘<samp>-e</samp>’</dt>
+<dt> ‘<samp>--ed</samp>’</dt>
+<dd><p>Make output that is a valid <code>ed</code> script.
+</p>
+</dd>
+<dt> ‘<samp>--expand-tabs</samp>’</dt>
+<dd><p>Expand tabs to spaces in the output, to preserve the alignment of tabs
+in the input files.
+</p>
+</dd>
+<dt> ‘<samp>-f</samp>’</dt>
+<dd><p>Make output that looks vaguely like an <code>ed</code> script but has
changes
+in the order they appear in the file.
+</p>
+</dd>
+<dt> ‘<samp>-F <var>regexp</var></samp>’</dt>
+<dd><p>In context and unified format, for each hunk of differences, show some
+of the last preceding line that matches <var>regexp</var>.
+</p>
+</dd>
+<dt> ‘<samp>--forward-ed</samp>’</dt>
+<dd><p>Make output that looks vaguely like an <code>ed</code> script but has
changes
+in the order they appear in the file.
+</p>
+</dd>
+<dt> ‘<samp>-H</samp>’</dt>
+<dd><p>Use heuristics to speed handling of large files that have numerous
+scattered small changes.
+</p>
+</dd>
+<dt> ‘<samp>--horizon-lines=<var>lines</var></samp>’</dt>
+<dd><p>Do not discard the last <var>lines</var> lines of the common prefix
+and the first <var>lines</var> lines of the common suffix.
+</p>
+</dd>
+<dt> ‘<samp>-i</samp>’</dt>
+<dd><p>Ignore changes in case; consider upper- and lower-case letters
+equivalent.
+</p>
+</dd>
+<dt> ‘<samp>-I <var>regexp</var></samp>’</dt>
+<dd><p>Ignore changes that just insert or delete lines that match
<var>regexp</var>.
+</p>
+</dd>
+<dt> ‘<samp>--ifdef=<var>name</var></samp>’</dt>
+<dd><p>Make merged if-then-else output using <var>name</var>.
+</p>
+</dd>
+<dt> ‘<samp>--ignore-all-space</samp>’</dt>
+<dd><p>Ignore white space when comparing lines.
+</p>
+</dd>
+<dt> ‘<samp>--ignore-blank-lines</samp>’</dt>
+<dd><p>Ignore changes that just insert or delete blank lines.
+</p>
+</dd>
+<dt> ‘<samp>--ignore-case</samp>’</dt>
+<dd><p>Ignore changes in case; consider upper- and lower-case to be the same.
+</p>
+</dd>
+<dt> ‘<samp>--ignore-matching-lines=<var>regexp</var></samp>’</dt>
+<dd><p>Ignore changes that just insert or delete lines that match
<var>regexp</var>.
+</p>
+</dd>
+<dt> ‘<samp>--ignore-space-change</samp>’</dt>
+<dd><p>Ignore trailing white space and consider all other sequences of one or
+more white space characters to be equivalent.
+</p>
+</dd>
+<dt> ‘<samp>--initial-tab</samp>’</dt>
+<dd><p>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.
+</p>
+</dd>
+<dt> ‘<samp>-L <var>label</var></samp>’</dt>
+<dd><p>Use <var>label</var> instead of the file name in the context format
+and unified format headers.
+</p>
+</dd>
+<dt> ‘<samp>--label=<var>label</var></samp>’</dt>
+<dd><p>Use <var>label</var> instead of the file name in the context format
+and unified format headers.
+</p>
+</dd>
+<dt> ‘<samp>--left-column</samp>’</dt>
+<dd><p>Print only the left column of two common lines in side by side format.
+</p>
+</dd>
+<dt> ‘<samp>--line-format=<var>format</var></samp>’</dt>
+<dd><p>Use <var>format</var> to output all input lines in if-then-else format.
+See section [[#SEC133|Line formats]].
+</p>
+</dd>
+<dt> ‘<samp>--minimal</samp>’</dt>
+<dd><p>Change the algorithm to perhaps find a smaller set of changes. This
+makes <code>diff</code> slower (sometimes much slower).
+</p>
+</dd>
+<dt> ‘<samp>-n</samp>’</dt>
+<dd><p>Output RCS-format diffs; like ‘<samp>-f</samp>’ except that
each command
+specifies the number of lines affected.
+</p>
+</dd>
+<dt> ‘<samp>-N</samp>’</dt>
+<dt> ‘<samp>--new-file</samp>’</dt>
+<dd><p>In directory comparison, if a file is found in only one directory,
+treat it as present but empty in the other directory.
+</p>
+</dd>
+<dt> ‘<samp>--new-group-format=<var>format</var></samp>’</dt>
+<dd><p>Use <var>format</var> to output a group of lines taken from just the
second
+file in if-then-else format. See section [[#SEC132|Line group formats]].
+</p>
+</dd>
+<dt> ‘<samp>--new-line-format=<var>format</var></samp>’</dt>
+<dd><p>Use <var>format</var> to output a line taken from just the second file
in
+if-then-else format. See section [[#SEC133|Line formats]].
+</p>
+</dd>
+<dt> ‘<samp>--old-group-format=<var>format</var></samp>’</dt>
+<dd><p>Use <var>format</var> to output a group of lines taken from just the
first
+file in if-then-else format. See section [[#SEC132|Line group formats]].
+</p>
+</dd>
+<dt> ‘<samp>--old-line-format=<var>format</var></samp>’</dt>
+<dd><p>Use <var>format</var> to output a line taken from just the first file in
+if-then-else format. See section [[#SEC133|Line formats]].
+</p>
+</dd>
+<dt> ‘<samp>-p</samp>’</dt>
+<dd><p>Show which C function each change is in.
+</p>
+</dd>
+<dt> ‘<samp>--rcs</samp>’</dt>
+<dd><p>Output RCS-format diffs; like ‘<samp>-f</samp>’ except that
each command
+specifies the number of lines affected.
+</p>
+</dd>
+<dt> ‘<samp>--report-identical-files</samp>’</dt>
+<dt> ‘<samp>-s</samp>’</dt>
+<dd><p>Report when two files are the same.
+</p>
+</dd>
+<dt> ‘<samp>--show-c-function</samp>’</dt>
+<dd><p>Show which C function each change is in.
+</p>
+</dd>
+<dt> ‘<samp>--show-function-line=<var>regexp</var></samp>’</dt>
+<dd><p>In context and unified format, for each hunk of differences, show some
+of the last preceding line that matches <var>regexp</var>.
+</p>
+</dd>
+<dt> ‘<samp>--side-by-side</samp>’</dt>
+<dd><p>Use the side by side output format.
+</p>
+</dd>
+<dt> ‘<samp>--speed-large-files</samp>’</dt>
+<dd><p>Use heuristics to speed handling of large files that have numerous
+scattered small changes.
+</p>
+</dd>
+<dt> ‘<samp>--suppress-common-lines</samp>’</dt>
+<dd><p>Do not print common lines in side by side format.
+</p>
+</dd>
+<dt> ‘<samp>-t</samp>’</dt>
+<dd><p>Expand tabs to spaces in the output, to preserve the alignment of tabs
+in the input files.
+</p>
+</dd>
+<dt> ‘<samp>-T</samp>’</dt>
+<dd><p>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.
+</p>
+</dd>
+<dt> ‘<samp>--text</samp>’</dt>
+<dd><p>Treat all files as text and compare them line-by-line, even if they
+do not appear to be text.
+</p>
+</dd>
+<dt> ‘<samp>-u</samp>’</dt>
+<dd><p>Use the unified output format.
+</p>
+</dd>
+<dt> ‘<samp>--unchanged-group-format=<var>format</var></samp>’</dt>
+<dd><p>Use <var>format</var> to output a group of common lines taken from both
files
+in if-then-else format. See section [[#SEC132|Line group formats]].
+</p>
+</dd>
+<dt> ‘<samp>--unchanged-line-format=<var>format</var></samp>’</dt>
+<dd><p>Use <var>format</var> to output a line common to both files in
if-then-else
+format. See section [[#SEC133|Line formats]].
+</p>
+</dd>
+<dt> ‘<samp>-U <var>lines</var></samp>’</dt>
+<dt> ‘<samp>--unified<span class="roman">[</span>=<var>lines</var><span
class="roman">]</span></samp>’</dt>
+<dd><p>Use the unified output format, showing <var>lines</var> (an integer)
lines of
+context, or three if <var>lines</var> is not given.
+For proper operation, <code>patch</code> typically needs at least two lines of
+context.
+</p>
+</dd>
+<dt> ‘<samp>-w</samp>’</dt>
+<dd><p>Ignore white space when comparing lines.
+</p>
+</dd>
+<dt> ‘<samp>-W <var>columns</var></samp>’</dt>
+<dt> ‘<samp>--width=<var>columns</var></samp>’</dt>
+<dd><p>Use an output width of <var>columns</var> in side by side format.
+</p>
+</dd>
+<dt> ‘<samp>-y</samp>’</dt>
+<dd><p>Use the side by side output format.
+</p></dd>
+</dl>
+
+<pre class="menu-preformatted"><nowiki></nowiki>•[[#SEC132| Line group
formats]]::<nowiki> Line group formats
+</nowiki>•[[#SEC133| Line formats]]::<nowiki> Line formats
+</nowiki></pre>
+<hr size="6">
+<div id="Line-group-formats"></div>
+<div id="SEC132"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC131| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC133| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC114| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC131| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC156| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+===== Line group formats =====
+
+<p>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.
+</p>
+<p>For example, the following command compares the TeX file
‘<tt>myfile</tt>’
+with the original version from the repository,
+and outputs a merged file in which old regions are
+surrounded by
‘<samp>\begin{em}</samp>’-‘<samp>\end{em}</samp>’
lines, and new
+regions are surrounded by
‘<samp>\begin{bf}</samp>’-‘<samp>\end{bf}</samp>’ lines.
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>cvs diff \
+ --old-group-format='\begin{em}
+%<\end{em}
+' \
+ --new-group-format='\begin{bf}
+%>\end{bf}
+' \
+ myfile
+</nowiki></pre></td></tr></table>
+
+<p>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.
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>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
+</nowiki></pre></td></tr></table>
+
+<p>Here is a more advanced example, which outputs a diff listing with
+headers containing line numbers in a “plain English” style.
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>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
+</nowiki></pre></td></tr></table>
+
+<p>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 <var>format</var>, because it
+typically contains shell metacharacters.
+</p>
+<dl compact="compact">
+<dt> ‘<samp>--old-group-format=<var>format</var></samp>’</dt>
+<dd><p>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.
+</p>
+</dd>
+<dt> ‘<samp>--new-group-format=<var>format</var></samp>’</dt>
+<dd><p>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.
+</p>
+</dd>
+<dt> ‘<samp>--changed-group-format=<var>format</var></samp>’</dt>
+<dd><p>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.
+</p>
+</dd>
+<dt> ‘<samp>--unchanged-group-format=<var>format</var></samp>’</dt>
+<dd><p>These line groups contain lines common to both files. The default
+unchanged group format is a format that outputs the line group as-is.
+</p></dd>
+</dl>
+
+<p>In a line group format, ordinary characters represent themselves;
+conversion specifications start with ‘<samp>%</samp>’ and have one
of the
+following forms.
+</p>
+<dl compact="compact">
+<dt> ‘<samp>%<</samp>’</dt>
+<dd><p>stands for the lines from the first file, including the trailing
newline.
+Each line is formatted according to the old line format (see section
[[#SEC133|Line formats]]).
+</p>
+</dd>
+<dt> ‘<samp>%></samp>’</dt>
+<dd><p>stands for the lines from the second file, including the trailing
newline.
+Each line is formatted according to the new line format.
+</p>
+</dd>
+<dt> ‘<samp>%=</samp>’</dt>
+<dd><p>stands for the lines common to both files, including the trailing
newline.
+Each line is formatted according to the unchanged line format.
+</p>
+</dd>
+<dt> ‘<samp>%%</samp>’</dt>
+<dd><p>stands for ‘<samp>%</samp>’.
+</p>
+</dd>
+<dt> ‘<samp>%c'<var>C</var>'</samp>’</dt>
+<dd><p>where <var>C</var> is a single character, stands for <var>C</var>.
+<var>C</var> may not be a backslash or an apostrophe.
+For example, ‘<samp>%c':'</samp>’ stands for a colon, even inside
+the then-part of an if-then-else format, which a colon would
+normally terminate.
+</p>
+</dd>
+<dt> ‘<samp>%c'\<var>O</var>'</samp>’</dt>
+<dd><p>where <var>O</var> is a string of 1, 2, or 3 octal digits,
+stands for the character with octal code <var>O</var>.
+For example, ‘<samp>%c'\0'</samp>’ stands for a null character.
+</p>
+</dd>
+<dt> ‘<samp><var>F</var><var>n</var></samp>’</dt>
+<dd><p>where <var>F</var> is a <code>printf</code> conversion specification
and <var>n</var> is one
+of the following letters, stands for <var>n</var>’s value formatted with
<var>F</var>.
+</p>
+<dl compact="compact">
+<dt> ‘<samp>e</samp>’</dt>
+<dd><p>The line number of the line just before the group in the old file.
+</p>
+</dd>
+<dt> ‘<samp>f</samp>’</dt>
+<dd><p>The line number of the first line in the group in the old file;
+equals <var>e</var> + 1.
+</p>
+</dd>
+<dt> ‘<samp>l</samp>’</dt>
+<dd><p>The line number of the last line in the group in the old file.
+</p>
+</dd>
+<dt> ‘<samp>m</samp>’</dt>
+<dd><p>The line number of the line just after the group in the old file;
+equals <var>l</var> + 1.
+</p>
+</dd>
+<dt> ‘<samp>n</samp>’</dt>
+<dd><p>The number of lines in the group in the old file; equals <var>l</var> -
<var>f</var> + 1.
+</p>
+</dd>
+<dt> ‘<samp>E, F, L, M, N</samp>’</dt>
+<dd><p>Likewise, for lines in the new file.
+</p>
+</dd>
+</dl>
+
+<p>The <code>printf</code> conversion specification can be
‘<samp>%d</samp>’,
+‘<samp>%o</samp>’, ‘<samp>%x</samp>’, or
‘<samp>%X</samp>’, specifying decimal, octal,
+lower case hexadecimal, or upper case hexadecimal output
+respectively. After the ‘<samp>%</samp>’ the following options
can appear in
+sequence: a ‘<samp>-</samp>’ 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, ‘<samp>%5dN</samp>’ prints the number of new lines in
the group
+in a field of width 5 characters, using the <code>printf</code> format
<code>"%5d"</code>.
+</p>
+</dd>
+<dt>
‘<samp>(<var>A</var>=<var>B</var>?<var>T</var>:<var>E</var>)</samp>’</dt>
+<dd><p>If <var>A</var> equals <var>B</var> then <var>T</var> else <var>E</var>.
+<var>A</var> and <var>B</var> are each either a decimal constant
+or a single letter interpreted as above.
+This format spec is equivalent to <var>T</var> if
+<var>A</var>’s value equals <var>B</var>’s; otherwise it is
equivalent to <var>E</var>.
+</p>
+<p>For example, ‘<samp>%(N=0?no:%dN) line%(N=1?:s)</samp>’ is
equivalent to
+‘<samp>no lines</samp>’ if <var>N</var> (the number of lines in
the group in the
+new file) is 0, to ‘<samp>1 line</samp>’ if <var>N</var> is 1, and
to ‘<samp>%dN lines</samp>’
+otherwise.
+</p></dd>
+</dl>
+
+<hr size="6">
+<div id="Line-formats"></div>
+<div id="SEC133"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC132| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC134| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC114| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC131| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC156| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+===== Line formats =====
+
+<p>Line formats control how each line taken from an input file is
+output as part of a line group in if-then-else format.
+</p>
+<p>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 ‘<samp>-</samp>’ for deleted lines,
‘<samp>|</samp>’ for added lines, and a space
+for unchanged lines. The formats contain newline characters where
+newlines are desired on output.
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>cvs diff \
+ --old-line-format='-%l
+' \
+ --new-line-format='|%l
+' \
+ --unchanged-line-format=' %l
+' \
+ myfile
+</nowiki></pre></td></tr></table>
+
+<p>To specify a line format, use one of the following options. You should
+quote <var>format</var>, since it often contains shell metacharacters.
+</p>
+<dl compact="compact">
+<dt> ‘<samp>--old-line-format=<var>format</var></samp>’</dt>
+<dd><p>formats lines just from the first file.
+</p>
+</dd>
+<dt> ‘<samp>--new-line-format=<var>format</var></samp>’</dt>
+<dd><p>formats lines just from the second file.
+</p>
+</dd>
+<dt> ‘<samp>--unchanged-line-format=<var>format</var></samp>’</dt>
+<dd><p>formats lines common to both files.
+</p>
+</dd>
+<dt> ‘<samp>--line-format=<var>format</var></samp>’</dt>
+<dd><p>formats all lines; in effect, it sets all three above options
simultaneously.
+</p></dd>
+</dl>
+
+<p>In a line format, ordinary characters represent themselves;
+conversion specifications start with ‘<samp>%</samp>’ and have one
of the
+following forms.
+</p>
+<dl compact="compact">
+<dt> ‘<samp>%l</samp>’</dt>
+<dd><p>stands for the contents of the line, not counting its trailing
+newline (if any). This format ignores whether the line is incomplete.
+</p>
+</dd>
+<dt> ‘<samp>%L</samp>’</dt>
+<dd><p>stands for the contents of the line, including its trailing newline
+(if any). If a line is incomplete, this format preserves its
+incompleteness.
+</p>
+</dd>
+<dt> ‘<samp>%%</samp>’</dt>
+<dd><p>stands for ‘<samp>%</samp>’.
+</p>
+</dd>
+<dt> ‘<samp>%c'<var>C</var>'</samp>’</dt>
+<dd><p>where <var>C</var> is a single character, stands for <var>C</var>.
+<var>C</var> may not be a backslash or an apostrophe.
+For example, ‘<samp>%c':'</samp>’ stands for a colon.
+</p>
+</dd>
+<dt> ‘<samp>%c'\<var>O</var>'</samp>’</dt>
+<dd><p>where <var>O</var> is a string of 1, 2, or 3 octal digits,
+stands for the character with octal code <var>O</var>.
+For example, ‘<samp>%c'\0'</samp>’ stands for a null character.
+</p>
+</dd>
+<dt> ‘<samp><var>F</var>n</samp>’</dt>
+<dd><p>where <var>F</var> is a <code>printf</code> conversion specification,
+stands for the line number formatted with <var>F</var>.
+For example, ‘<samp>%.5dn</samp>’ prints the line number using the
+<code>printf</code> format <code>"%.5d"</code>. See section
[[#SEC132|Line group formats]], for
+more about printf conversion specifications.
+</p>
+</dd>
+</dl>
+
+<p>The default line format is ‘<samp>%l</samp>’ followed by a
newline character.
+</p>
+<p>If the input contains tab characters and it is important that they line
+up on output, you should ensure that ‘<samp>%l</samp>’ or
‘<samp>%L</samp>’ in a line
+format is just after a tab stop (e.g. by preceding
‘<samp>%l</samp>’ or
+‘<samp>%L</samp>’ with a tab character), or you should use the
‘<samp>-t</samp>’ or
+‘<samp>--expand-tabs</samp>’ option.
+</p>
+<p>Taken together, the line and line group formats let you specify many
+different formats. For example, the following command uses a format
+similar to <code>diff</code>’s normal format. You can tailor this
command
+to get fine control over <code>diff</code>’s output.
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>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
+</nowiki></pre></td></tr></table>
+
+<hr size="6">
+<div id="diff-examples"></div>
+<div id="SEC134"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC133| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC135| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC114| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC130| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC156| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+==== diff examples ====
+
+<p>The following line produces a Unidiff (‘<samp>-u</samp>’ flag)
+between revision 1.14 and 1.19 of
+‘<tt>backend.c</tt>’. Due to the ‘<samp>-kk</samp>’
flag no
+keywords are substituted, so differences that only depend
+on keyword substitution are ignored.
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>$ cvs diff -kk -u
-r 1.14 -r 1.19 backend.c
+</nowiki></pre></td></tr></table>
+
+<p>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:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>$ cvs diff -r
RELEASE_1_0 -r EXPR1
+</nowiki></pre></td></tr></table>
+
+<p>A command like this can be used to produce a context
+diff between two releases:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>$ cvs diff -c -r
RELEASE_1_0 -r RELEASE_1_1 > diffs
+</nowiki></pre></td></tr></table>
+
+<p>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.
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>$ cvs diff -u | less
+</nowiki></pre></td></tr></table>
+
+<hr size="6">
+<div id="export"></div>
+<div id="SEC135"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC134| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC136| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC114| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC114| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC156| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== export—Export sources from CVS, similar to checkout ===
+
+<ul>
+<li>
+Synopsis: export [-flNnR] [-r rev|-D date] [-k subst] [-d dir] module…
+</li><li>
+Requires: repository.
+</li><li>
+Changes: current directory.
+</li></ul>
+
+<p>This command is a variant of <code>checkout</code>; use it
+when you want a copy of the source for module without
+the <small>CVS</small> administrative directories. For example, you
+might use <code>export</code> to prepare source for shipment
+off-site. This command requires that you specify a
+date or tag (with ‘<samp>-D</samp>’ or
‘<samp>-r</samp>’), so that you
+can count on reproducing the source you ship to others
+(and thus it always prunes empty directories).
+</p>
+<p>One often would like to use ‘<samp>-kv</samp>’ with <code>cvs
+export</code>. 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
+‘<samp>-kv</samp>’, one can no longer use the <code>ident</code>
+command (which is part of the <small>RCS</small> suite—see
+ident(1)) which looks for keyword strings. If
+you want to be able to use <code>ident</code> you must not
+use ‘<samp>-kv</samp>’.
+</p>
+<pre class="menu-preformatted"><nowiki></nowiki>•[[#SEC136| export
options]]::<nowiki> export options
+</nowiki></pre>
+<hr size="6">
+<div id="export-options"></div>
+<div id="SEC136"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC135| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC137| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC114| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC135| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC156| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+==== export options ====
+
+<p>These standard options are supported by <code>export</code>
+(see section [[#SEC119|Common command options]], for a complete description of
+them):
+</p>
+<dl compact="compact">
+<dt> <code>-D <var>date</var></code></dt>
+<dd><p>Use the most recent revision no later than <var>date</var>.
+</p>
+</dd>
+<dt> <code>-f</code></dt>
+<dd><p>If no matching revision is found, retrieve the most
+recent revision (instead of ignoring the file).
+</p>
+</dd>
+<dt> <code>-l</code></dt>
+<dd><p>Local; run only in current working directory.
+</p>
+</dd>
+<dt> <code>-n</code></dt>
+<dd><p>Do not run any checkout program.
+</p>
+</dd>
+<dt> <code>-R</code></dt>
+<dd><p>Export directories recursively. This is on by default.
+</p>
+</dd>
+<dt> <code>-r <var>tag</var></code></dt>
+<dd><p>Use revision <var>tag</var>.
+</p></dd>
+</dl>
+
+<p>In addition, these options (that are common to
+<code>checkout</code> and <code>export</code>) are also supported:
+</p>
+<dl compact="compact">
+<dt> <code>-d <var>dir</var></code></dt>
+<dd><p>Create a directory called <var>dir</var> for the working
+files, instead of using the module name.
+See section [[#SEC123|checkout options]], for complete details on how
+<small>CVS</small> handles this flag.
+</p>
+</dd>
+<dt> <code>-k <var>subst</var></code></dt>
+<dd><p>Set keyword expansion mode (see section [[#SEC102|Substitution modes]]).
+</p>
+</dd>
+<dt> <code>-N</code></dt>
+<dd><p>Only useful together with ‘<samp>-d <var>dir</var></samp>’.
+See section [[#SEC123|checkout options]], for complete details on how
+<small>CVS</small> handles this flag.
+</p></dd>
+</dl>
+
+
+<hr size="6">
+<div id="history"></div>
+<div id="SEC137"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC136| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC138| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC114| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC114| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC156| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== history—Show status of files and users ===
+
+<ul>
+<li>
+Synopsis: history [-report] [-flags] [-options args] [files…]
+</li><li>
+Requires: the file ‘<tt>$CVSROOT/CVSROOT/history</tt>’
+</li><li>
+Changes: nothing.
+</li></ul>
+
+<p><small>CVS</small> can keep a history file that tracks each use of the
+<code>checkout</code>, <code>commit</code>, <code>rtag</code>,
+<code>update</code>, and <code>release</code> commands. You can
+use <code>history</code> to display this information in
+various formats.
+</p>
+<p>Logging must be enabled by creating the file
+‘<tt>$CVSROOT/CVSROOT/history</tt>’.
+</p>
+<p><strong>Note: <code>history</code> uses ‘<samp>-f</samp>’,
‘<samp>-l</samp>’,
+‘<samp>-n</samp>’, and ‘<samp>-p</samp>’ in ways that
conflict with the
+normal use inside <small>CVS</small> (see section [[#SEC119|Common command
options]]).</strong>
+</p>
+<pre class="menu-preformatted"><nowiki></nowiki>•[[#SEC138| history
options]]::<nowiki> history options
+</nowiki></pre>
+<hr size="6">
+<div id="history-options"></div>
+<div id="SEC138"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC137| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC139| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC114| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC137| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC156| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+==== history options ====
+
+<p>Several options (shown above as ‘<samp>-report</samp>’)
control what
+kind of report is generated:
+</p>
+<dl compact="compact">
+<dt> <code>-c</code></dt>
+<dd><p>Report on each time commit was used (i.e., each time
+the repository was modified).
+</p>
+</dd>
+<dt> <code>-e</code></dt>
+<dd><p>Everything (all record types). Equivalent to
+specifying ‘<samp>-x</samp>’ with all record types. Of course,
+‘<samp>-e</samp>’ will also include record types which are
+added in a future version of <small>CVS</small>; if you are
+writing a script which can only handle certain record
+types, you’ll want to specify ‘<samp>-x</samp>’.
+</p>
+</dd>
+<dt> <code>-m <var>module</var></code></dt>
+<dd><p>Report on a particular module. (You can meaningfully
+use ‘<samp>-m</samp>’ more than once on the command line.)
+</p>
+</dd>
+<dt> <code>-o</code></dt>
+<dd><p>Report on checked-out modules. This is the default report type.
+</p>
+</dd>
+<dt> <code>-T</code></dt>
+<dd><p>Report on all tags.
+</p>
+</dd>
+<dt> <code>-x <var>type</var></code></dt>
+<dd><p>Extract a particular set of record types <var>type</var> from the
<small>CVS</small>
+history. The types are indicated by single letters,
+which you may specify in combination.
+</p>
+<p>Certain commands have a single record type:
+</p>
+<dl compact="compact">
+<dt> <code>F</code></dt>
+<dd><p>release
+</p></dd>
+<dt> <code>O</code></dt>
+<dd><p>checkout
+</p></dd>
+<dt> <code>E</code></dt>
+<dd><p>export
+</p></dd>
+<dt> <code>T</code></dt>
+<dd><p>rtag
+</p></dd>
+</dl>
+
+<p>One of four record types may result from an update:
+</p>
+<dl compact="compact">
+<dt> <code>C</code></dt>
+<dd><p>A merge was necessary but collisions were
+detected (requiring manual merging).
+</p></dd>
+<dt> <code>G</code></dt>
+<dd><p>A merge was necessary and it succeeded.
+</p></dd>
+<dt> <code>U</code></dt>
+<dd><p>A working file was copied from the repository.
+</p></dd>
+<dt> <code>W</code></dt>
+<dd><p>The working copy of a file was deleted during
+update (because it was gone from the repository).
+</p></dd>
+</dl>
+
+<p>One of three record types results from commit:
+</p>
+<dl compact="compact">
+<dt> <code>A</code></dt>
+<dd><p>A file was added for the first time.
+</p></dd>
+<dt> <code>M</code></dt>
+<dd><p>A file was modified.
+</p></dd>
+<dt> <code>R</code></dt>
+<dd><p>A file was removed.
+</p></dd>
+</dl>
+</dd>
+</dl>
+
+<p>The options shown as ‘<samp>-flags</samp>’ constrain or expand
+the report without requiring option arguments:
+</p>
+<dl compact="compact">
+<dt> <code>-a</code></dt>
+<dd><p>Show data for all users (the default is to show data
+only for the user executing <code>history</code>).
+</p>
+</dd>
+<dt> <code>-l</code></dt>
+<dd><p>Show last modification only.
+</p>
+</dd>
+<dt> <code>-w</code></dt>
+<dd><p>Show only the records for modifications done from the
+same working directory where <code>history</code> is
+executing.
+</p></dd>
+</dl>
+
+<p>The options shown as ‘<samp>-options <var>args</var></samp>’
constrain the report
+based on an argument:
+</p>
+<dl compact="compact">
+<dt> <code>-b <var>str</var></code></dt>
+<dd><p>Show data back to a record containing the string
+<var>str</var> in either the module name, the file name, or
+the repository path.
+</p>
+</dd>
+<dt> <code>-D <var>date</var></code></dt>
+<dd><p>Show data since <var>date</var>. This is slightly different
+from the normal use of ‘<samp>-D <var>date</var></samp>’, which
+selects the newest revision older than <var>date</var>.
+</p>
+</dd>
+<dt> <code>-f <var>file</var></code></dt>
+<dd><p>Show data for a particular file
+(you can specify several ‘<samp>-f</samp>’ options on the same
command line).
+This is equivalent to specifying the file on the command line.
+</p>
+</dd>
+<dt> <code>-n <var>module</var></code></dt>
+<dd><p>Show data for a particular module
+(you can specify several ‘<samp>-n</samp>’ options on the same
command line).
+</p>
+</dd>
+<dt> <code>-p <var>repository</var></code></dt>
+<dd><p>Show data for a particular source repository (you
+can specify several ‘<samp>-p</samp>’ options on the same command
+line).
+</p>
+</dd>
+<dt> <code>-r <var>rev</var></code></dt>
+<dd><p>Show records referring to revisions since the revision
+or tag named <var>rev</var> appears in individual <small>RCS</small>
+files. Each <small>RCS</small> file is searched for the revision or
+tag.
+</p>
+</dd>
+<dt> <code>-t <var>tag</var></code></dt>
+<dd><p>Show records since tag <var>tag</var> was last added to the
+history file. This differs from the ‘<samp>-r</samp>’ flag
+above in that it reads only the history file, not the
+<small>RCS</small> files, and is much faster.
+</p>
+</dd>
+<dt> <code>-u <var>name</var></code></dt>
+<dd><p>Show records for user <var>name</var>.
+</p>
+</dd>
+<dt> <code>-z <var>timezone</var></code></dt>
+<dd><p>Show times in the selected records using the specified
+time zone instead of UTC.
+</p></dd>
+</dl>
+
+
+<hr size="6">
+<div id="import"></div>
+<div id="SEC139"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC138| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC140| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC114| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC114| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC156| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== import—Import sources into CVS, using vendor branches ===
+
+
+<ul>
+<li>
+Synopsis: import [-options] repository vendortag releasetag…
+</li><li>
+Requires: Repository, source distribution directory.
+</li><li>
+Changes: repository.
+</li></ul>
+
+<p>Use <code>import</code> 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. See section [[#SEC105|Tracking third-party
sources]], for
+a discussion on this subject.
+</p>
+<p>The <var>repository</var> argument gives a directory name
+(or a path to a directory) under the <small>CVS</small> root directory
+for repositories; if the directory did not exist,
+import creates it.
+</p>
+<p>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 ‘<samp>checkout
+-j</samp>’ to reconcile the differences, as import instructs
+you to do.
+</p>
+<p>If <small>CVS</small> decides a file should be ignored
+(see section [[#SEC176|Ignoring files via cvsignore]]), it does not import it
and prints
+‘<samp>I </samp>’ followed by the filename (see section
[[#SEC141|import output]], for a
+complete description of the output).
+</p>
+<p>If the file ‘<tt>$CVSROOT/CVSROOT/cvswrappers</tt>’ 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. See section [[#SEC165|The cvswrappers file]].
+</p>
+<p>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.
+</p>
+<p>At least three arguments are required.
+<var>repository</var> is needed to identify the collection
+of source. <var>vendortag</var> is a tag for the entire
+branch (e.g., for 1.1.1). You must also specify at
+least one <var>releasetag</var> to identify the files at
+the leaves created each time you execute <code>import</code>.
+</p>
+<p>Note that <code>import</code> does <em>not</em> change the
+directory in which you invoke it. In particular, it
+does not set up that directory as a <small>CVS</small> working
+directory; if you want to work with the sources import
+them first and then check them out into a different
+directory (see section [[#SEC5|Getting the source]]).
+</p>
+<pre class="menu-preformatted"><nowiki></nowiki>•[[#SEC140| import
options]]::<nowiki> import options
+</nowiki>•[[#SEC141| import output]]::<nowiki> import output
+</nowiki>•[[#SEC142| import examples]]::<nowiki> import
examples
+</nowiki></pre>
+<hr size="6">
+<div id="import-options"></div>
+<div id="SEC140"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC139| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC141| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC114| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC139| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC156| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+==== import options ====
+
+<p>This standard option is supported by <code>import</code>
+(see section [[#SEC119|Common command options]], for a complete description):
+</p>
+<dl compact="compact">
+<dt> <code>-m <var>message</var></code></dt>
+<dd><p>Use <var>message</var> as log information, instead of
+invoking an editor.
+</p></dd>
+</dl>
+
+<p>There are the following additional special options.
+</p>
+<dl compact="compact">
+<dt> <code>-b <var>branch</var></code></dt>
+<dd><p>See [[#SEC111|Multiple vendor branches]].
+</p>
+</dd>
+<dt> <code>-k <var>subst</var></code></dt>
+<dd><p>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 [[#SEC102|Substitution modes]], for a
+list of valid ‘<samp>-k</samp>’ settings.
+</p>
+</dd>
+<dt> <code>-I <var>name</var></code></dt>
+<dd><p>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 !’.
+</p>
+<p><var>name</var> can be a file name pattern of the same type
+that you can specify in the ‘<tt>.cvsignore</tt>’ file.
+See section [[#SEC176|Ignoring files via cvsignore]].
+</p>
+</dd>
+<dt> <code>-W <var>spec</var></code></dt>
+<dd><p>Specify file names that should be filtered during
+import. You can use this option repeatedly.
+</p>
+<p><var>spec</var> can be a file name pattern of the same type
+that you can specify in the ‘<tt>.cvswrappers</tt>’
+file. See section [[#SEC165|The cvswrappers file]].
+</p></dd>
+</dl>
+
+<hr size="6">
+<div id="import-output"></div>
+<div id="SEC141"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC140| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC142| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC114| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC139| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC156| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+==== import output ====
+
+<p><code>import</code> keeps you informed of its progress by printing a line
+for each file, preceded by one character indicating the status of the file:
+</p>
+<dl compact="compact">
+<dt> <code>U <var>file</var></code></dt>
+<dd><p>The file already exists in the repository and has not been locally
+modified; a new revision has been created (if necessary).
+</p>
+</dd>
+<dt> <code>N <var>file</var></code></dt>
+<dd><p>The file is a new file which has been added to the repository.
+</p>
+</dd>
+<dt> <code>C <var>file</var></code></dt>
+<dd><p>The file already exists in the repository but has been locally modified;
+you will have to merge the changes.
+</p>
+</dd>
+<dt> <code>I <var>file</var></code></dt>
+<dd><p>The file is being ignored (see section [[#SEC176|Ignoring files via
cvsignore]]).
+</p>
+<div id="IDX242"></div>
+<div id="IDX243"></div>
+</dd>
+<dt> <code>L <var>file</var></code></dt>
+<dd><p>The file is a symbolic link; <code>cvs import</code> 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 ‘<tt>modules</tt>’ file can be used
+to recreate symbolic links on checkout, update, etc.;
+see section [[#SEC158|The modules file]].)
+</p></dd>
+</dl>
+
+<hr size="6">
+<div id="import-examples"></div>
+<div id="SEC142"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC141| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC143| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC114| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC139| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC156| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+==== import examples ====
+
+<p>See [[#SEC105|Tracking third-party sources]], and [[#SEC40|Creating a
directory tree from a number of files]].
+</p>
+<hr size="6">
+<div id="log"></div>
+<div id="SEC143"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC142| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC144| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC114| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC114| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC156| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== log—Print out log information for files ===
+
+<ul>
+<li>
+Synopsis: log [options] [files…]
+</li><li>
+Requires: repository, working directory.
+</li><li>
+Changes: nothing.
+</li></ul>
+
+<p>Display log information for files. <code>log</code> used to
+call the <small>RCS</small> utility <code>rlog</code>. 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 <small>CVS</small>
+commands.
+</p>
+<div id="IDX244"></div>
+<div id="IDX245"></div>
+<p>The output includes the location of the <small>RCS</small> file,
+the <em>head</em> revision (the latest revision on the
+trunk), all symbolic names (tags) and some other
+things. For each revision, the revision number, the
+author, the number of lines added/deleted and the log
+message are printed. All times are displayed in
+Coordinated Universal Time (UTC). (Other parts of
+<small>CVS</small> print times in the local timezone).
+</p>
+<p><strong>Note: <code>log</code> uses ‘<samp>-R</samp>’ in a way
that conflicts
+with the normal use inside <small>CVS</small> (see section [[#SEC119|Common
command options]]).</strong>
+</p>
+<pre class="menu-preformatted"><nowiki></nowiki>•[[#SEC144| log
options]]::<nowiki> log options
+</nowiki>•[[#SEC145| log examples]]::<nowiki> log examples
+</nowiki></pre>
+<hr size="6">
+<div id="log-options"></div>
+<div id="SEC144"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC143| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC145| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC114| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC143| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC156| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+==== log options ====
+
+<p>By default, <code>log</code> prints all information that is
+available. All other options restrict the output.
+</p>
+<dl compact="compact">
+<dt> <code>-b</code></dt>
+<dd><p>Print information about the revisions on the default
+branch, normally the highest branch on the trunk.
+</p>
+</dd>
+<dt> <code>-d <var>dates</var></code></dt>
+<dd><p>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 ‘<samp>-D</samp>’ option to
+many other <small>CVS</small> commands (see section [[#SEC119|Common command
options]]).
+Dates can be combined into ranges as follows:
+</p>
+<dl compact="compact">
+<dt> <code><var>d1</var><<var>d2</var></code></dt>
+<dt> <code><var>d2</var>><var>d1</var></code></dt>
+<dd><p>Select the revisions that were deposited between
+<var>d1</var> and <var>d2</var>.
+</p>
+</dd>
+<dt> <code><<var>d</var></code></dt>
+<dt> <code><var>d</var>></code></dt>
+<dd><p>Select all revisions dated <var>d</var> or earlier.
+</p>
+</dd>
+<dt> <code><var>d</var><</code></dt>
+<dt> <code>><var>d</var></code></dt>
+<dd><p>Select all revisions dated <var>d</var> or later.
+</p>
+</dd>
+<dt> <code><var>d</var></code></dt>
+<dd><p>Select the single, latest revision dated <var>d</var> or
+earlier.
+</p></dd>
+</dl>
+
+<p>The ‘<samp>></samp>’ or ‘<samp><</samp>’
characters may be followed by
+‘<samp>=</samp>’ to indicate an inclusive range rather than an
+exclusive one.
+</p>
+<p>Note that the separator is a semicolon (;).
+</p>
+</dd>
+<dt> <code>-h</code></dt>
+<dd><p>Print only the name of the <small>RCS</small> file, name
+of the file in the working directory, head,
+default branch, access list, locks, symbolic names, and
+suffix.
+</p>
+</dd>
+<dt> <code>-l</code></dt>
+<dd><p>Local; run only in current working directory. (Default
+is to run recursively).
+</p>
+</dd>
+<dt> <code>-N</code></dt>
+<dd><p>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.
+</p>
+</dd>
+<dt> <code>-R</code></dt>
+<dd><p>Print only the name of the <small>RCS</small> file.
+</p>
+</dd>
+<dt> <code>-r<var>revisions</var></code></dt>
+<dd><p>Print information about revisions given in the
+comma-separated list <var>revisions</var> of revisions and
+ranges. The following table explains the available
+range formats:
+</p>
+<dl compact="compact">
+<dt> <code><var>rev1</var>:<var>rev2</var></code></dt>
+<dd><p>Revisions <var>rev1</var> to <var>rev2</var> (which must be on
+the same branch).
+</p>
+</dd>
+<dt> <code><var>rev1</var>::<var>rev2</var></code></dt>
+<dd><p>The same, but excluding <var>rev1</var>.
+</p>
+</dd>
+<dt> <code>:<var>rev</var></code></dt>
+<dt> <code>::<var>rev</var></code></dt>
+<dd><p>Revisions from the beginning of the branch up to
+and including <var>rev</var>.
+</p>
+</dd>
+<dt> <code><var>rev</var>:</code></dt>
+<dd><p>Revisions starting with <var>rev</var> to the end of the
+branch containing <var>rev</var>.
+</p>
+</dd>
+<dt> <code><var>rev</var>::</code></dt>
+<dd><p>Revisions starting just after <var>rev</var> to the end of the
+branch containing <var>rev</var>.
+</p>
+</dd>
+<dt> <code><var>branch</var></code></dt>
+<dd><p>An argument that is a branch means all revisions on
+that branch.
+</p>
+</dd>
+<dt> <code><var>branch1</var>:<var>branch2</var></code></dt>
+<dt> <code><var>branch1</var>::<var>branch2</var></code></dt>
+<dd><p>A range of branches means all revisions
+on the branches in that range.
+</p>
+</dd>
+<dt> <code><var>branch</var>.</code></dt>
+<dd><p>The latest revision in <var>branch</var>.
+</p></dd>
+</dl>
+
+<p>A bare ‘<samp>-r</samp>’ with no revisions means the latest
+revision on the default branch, normally the trunk.
+There can be no space between the ‘<samp>-r</samp>’ option and
+its argument.
+</p>
+</dd>
+<dt> <code>-S</code></dt>
+<dd><p>Suppress the header if no revisions are selected.
+</p>
+</dd>
+<dt> <code>-s <var>states</var></code></dt>
+<dd><p>Print information about revisions whose state
+attributes match one of the states given in the
+comma-separated list <var>states</var>.
+</p>
+</dd>
+<dt> <code>-t</code></dt>
+<dd><p>Print the same as ‘<samp>-h</samp>’, plus the descriptive
text.
+</p>
+</dd>
+<dt> <code>-w<var>logins</var></code></dt>
+<dd><p>Print information about revisions checked in by users
+with login names appearing in the comma-separated list
+<var>logins</var>. If <var>logins</var> is omitted, the user’s
+login is assumed. There can be no space between the
+‘<samp>-w</samp>’ option and its argument.
+</p></dd>
+</dl>
+
+<p><code>log</code> prints the intersection of the revisions
+selected with the options ‘<samp>-d</samp>’,
‘<samp>-s</samp>’, and
+‘<samp>-w</samp>’, intersected with the union of the revisions
+selected by ‘<samp>-b</samp>’ and ‘<samp>-r</samp>’.
+</p>
+<hr size="6">
+<div id="log-examples"></div>
+<div id="SEC145"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC144| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC146| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC114| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC143| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC156| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+==== log examples ====
+
+<p>Contributed examples are gratefully accepted.
+</p>
+<hr size="6">
+<div id="rdiff"></div>
+<div id="SEC146"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC145| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC147| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC114| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC114| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC156| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== rdiff—’patch’ format diffs between releases ===
+
+<ul>
+<li>
+rdiff [-flags] [-V vn] [-r t|-D d [-r t2|-D d2]] modules…
+</li><li>
+Requires: repository.
+</li><li>
+Changes: nothing.
+</li><li>
+Synonym: patch
+</li></ul>
+
+<p>Builds a Larry Wall format patch(1) file between two
+releases, that can be fed directly into the <code>patch</code>
+program to bring an old release up-to-date with the new
+release. (This is one of the few <small>CVS</small> commands that
+operates directly from the repository, and doesn’t
+require a prior checkout.) The diff output is sent to
+the standard output device.
+</p>
+<p>You can specify (using the standard ‘<samp>-r</samp>’ and
+‘<samp>-D</samp>’ 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 <small>RCS</small> file.
+</p>
+<p>Note that if the software release affected is contained
+in more than one directory, then it may be necessary to
+specify the ‘<samp>-p</samp>’ option to the <code>patch</code>
command when
+patching the old sources, so that <code>patch</code> is able to find
+the files that are located in other directories.
+</p>
+<pre class="menu-preformatted"><nowiki></nowiki>•[[#SEC147| rdiff
options]]::<nowiki> rdiff options
+</nowiki>•[[#SEC148| rdiff examples]]::<nowiki> rdiff
examples
+</nowiki></pre>
+<hr size="6">
+<div id="rdiff-options"></div>
+<div id="SEC147"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC146| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC148| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC114| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC146| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC156| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+==== rdiff options ====
+
+<p>These standard options are supported by <code>rdiff</code>
+(see section [[#SEC119|Common command options]], for a complete description of
+them):
+</p>
+<dl compact="compact">
+<dt> <code>-D <var>date</var></code></dt>
+<dd><p>Use the most recent revision no later than <var>date</var>.
+</p>
+</dd>
+<dt> <code>-f</code></dt>
+<dd><p>If no matching revision is found, retrieve the most
+recent revision (instead of ignoring the file).
+</p>
+</dd>
+<dt> <code>-l</code></dt>
+<dd><p>Local; don’t descend subdirectories.
+</p>
+</dd>
+<dt> <code>-R</code></dt>
+<dd><p>Examine directories recursively. This option is on by default.
+</p>
+</dd>
+<dt> <code>-r <var>tag</var></code></dt>
+<dd><p>Use revision <var>tag</var>.
+</p></dd>
+</dl>
+
+<p>In addition to the above, these options are available:
+</p>
+<dl compact="compact">
+<dt> <code>-c</code></dt>
+<dd><p>Use the context diff format. This is the default format.
+</p>
+</dd>
+<dt> <code>-s</code></dt>
+<dd><p>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.
+</p>
+</dd>
+<dt> <code>-t</code></dt>
+<dd><p>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.
+</p>
+</dd>
+<dt> <code>-u</code></dt>
+<dd><p>Use the unidiff format for the context diffs.
+Remember that old versions
+of the <code>patch</code> program can’t handle the unidiff
+format, so if you plan to post this patch to the net
+you should probably not use ‘<samp>-u</samp>’.
+</p>
+</dd>
+<dt> <code>-V <var>vn</var></code></dt>
+<dd><p>Expand keywords according to the rules current in
+<small>RCS</small> version <var>vn</var> (the expansion format changed with
+<small>RCS</small> version 5). Note that this option is no
+longer accepted. <small>CVS</small> will always expand keywords the
+way that <small>RCS</small> version 5 does.
+</p></dd>
+</dl>
+
+<hr size="6">
+<div id="rdiff-examples"></div>
+<div id="SEC148"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC147| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC149| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC114| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC146| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC156| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+==== rdiff examples ====
+
+<p>Suppose you receive mail from <tt>address@hidden</tt> asking for an
+update from release 1.2 to 1.4 of the tc compiler. You
+have no such patches on hand, but with <small>CVS</small> that can
+easily be fixed with a command such as this:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>$ cvs rdiff -c -r
FOO1_2 -r FOO1_4 tc | \
+$$ Mail -s 'The patches you asked for' address@hidden
+</nowiki></pre></td></tr></table>
+
+<p>Suppose you have made release 1.3, and forked a branch
+called ‘<samp>R_1_3fix</samp>’ for bugfixes.
‘<samp>R_1_3_1</samp>’
+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:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>$ 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
+</nowiki></pre></td></tr></table>
+
+<hr size="6">
+<div id="release"></div>
+<div id="SEC149"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC148| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC150| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC114| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC114| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC156| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== release—Indicate that a Module is no longer in use ===
+
+<ul>
+<li>
+release [-d] directories…
+</li><li>
+Requires: Working directory.
+</li><li>
+Changes: Working directory, history log.
+</li></ul>
+
+<p>This command is meant to safely cancel the effect of
+‘<samp>cvs checkout</samp>’. Since <small>CVS</small>
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 <small>CVS</small> history
+file (see section [[#SEC178|The history file]]) that you’ve abandoned
your
+checkout.
+</p>
+<p>Use ‘<samp>cvs release</samp>’ to avoid these problems. This
+command checks that no uncommitted changes are
+present; that you are executing it from immediately
+above a <small>CVS</small> working directory; and that the repository
+recorded for your files is the same as the repository
+defined in the module database.
+</p>
+<p>If all these conditions are true, ‘<samp>cvs release</samp>’
+leaves a record of its execution (attesting to your
+intentionally abandoning your checkout) in the <small>CVS</small>
+history log.
+</p>
+<pre class="menu-preformatted"><nowiki></nowiki>•[[#SEC150| release
options]]::<nowiki> release options
+</nowiki>•[[#SEC151| release output]]::<nowiki> release
output
+</nowiki>•[[#SEC152| release examples]]::<nowiki> release
examples
+</nowiki></pre>
+<hr size="6">
+<div id="release-options"></div>
+<div id="SEC150"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC149| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC151| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC114| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC149| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC156| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+==== release options ====
+
+<p>The <code>release</code> command supports one command option:
+</p>
+<dl compact="compact">
+<dt> <code>-d</code></dt>
+<dd><p>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.
+</p>
+<p><strong>WARNING: The <code>release</code> 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 <code>add</code>
+command; see section [[#SEC67|Adding files to a directory]]) will be silently
deleted—even
+if it is non-empty!</strong>
+</p></dd>
+</dl>
+
+<hr size="6">
+<div id="release-output"></div>
+<div id="SEC151"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC150| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC152| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC114| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC149| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC156| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+==== release output ====
+
+<p>Before <code>release</code> releases your sources it will
+print a one-line message for any file that is not
+up-to-date.
+</p>
+<dl compact="compact">
+<dt> <code>U <var>file</var></code></dt>
+<dt> <code>P <var>file</var></code></dt>
+<dd><p>There exists a newer revision of this file in the
+repository, and you have not modified your local copy
+of the file (‘<samp>U</samp>’ and ‘<samp>P</samp>’
mean the same thing).
+</p>
+</dd>
+<dt> <code>A <var>file</var></code></dt>
+<dd><p>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.
+</p>
+</dd>
+<dt> <code>R <var>file</var></code></dt>
+<dd><p>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. See section [[#SEC125|commit—Check files into the repository]].
+</p>
+</dd>
+<dt> <code>M <var>file</var></code></dt>
+<dd><p>The file is modified in your working directory. There
+might also be a newer revision inside the repository.
+</p>
+</dd>
+<dt> <code>? <var>file</var></code></dt>
+<dd><p><var>file</var> is in your working directory, but does not
+correspond to anything in the source repository, and is
+not in the list of files for <small>CVS</small> to ignore (see the
+description of the ‘<samp>-I</samp>’ option, and
+see section [[#SEC176|Ignoring files via cvsignore]]). If you remove your
working
+sources, this file will be lost.
+</p></dd>
+</dl>
+
+<hr size="6">
+<div id="release-examples"></div>
+<div id="SEC152"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC151| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC153| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC114| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC149| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC156| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+==== release examples ====
+
+<p>Release the ‘<tt>tc</tt>’ directory, and delete your local
working copy
+of the files.
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>$ cd .. #
<span class="roman">You must stand immediately above the</span>
+ # <span class="roman">sources when you issue ‘<samp>cvs
release</samp>’.</span>
+$ cvs release -d tc
+You have [0] altered files in this repository.
+Are you sure you want to release (and delete) directory `tc': y
+$
+</nowiki></pre></td></tr></table>
+
+<hr size="6">
+<div id="update"></div>
+<div id="SEC153"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC152| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC154| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC114| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC114| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC156| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== update—Bring work tree in sync with repository ===
+
+<ul>
+<li>
+update [-ACdflPpR] [-I name] [-j rev [-j rev]] [-k kflag] [-r tag|-D date] [-W
spec] files…
+</li><li>
+Requires: repository, working directory.
+</li><li>
+Changes: working directory.
+</li></ul>
+
+<p>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 <code>update</code> 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 <code>-C</code>
+option, <code>update</code> will also merge any differences
+between the local copy of files and their base revisions
+into any destination revisions specified with <code>-r</code>,
+<code>-D</code>, or <code>-A</code>.
+</p>
+<pre class="menu-preformatted"><nowiki></nowiki>•[[#SEC154| update
options]]::<nowiki> update options
+</nowiki>•[[#SEC155| update output]]::<nowiki> update output
+</nowiki></pre>
+<hr size="6">
+<div id="update-options"></div>
+<div id="SEC154"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC153| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC155| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC114| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC153| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC156| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+==== update options ====
+
+<p>These standard options are available with <code>update</code>
+(see section [[#SEC119|Common command options]], for a complete description of
+them):
+</p>
+<dl compact="compact">
+<dt> <code>-D date</code></dt>
+<dd><p>Use the most recent revision no later than <var>date</var>.
+This option is sticky, and implies ‘<samp>-P</samp>’.
+See [[#SEC53|Sticky tags]], for more information on sticky tags/dates.
+</p>
+</dd>
+<dt> <code>-f</code></dt>
+<dd><p>Only useful with the ‘<samp>-D <var>date</var></samp>’ or
‘<samp>-r
+<var>tag</var></samp>’ flags. If no matching revision is found,
+retrieve the most recent revision (instead of ignoring
+the file).
+</p>
+</dd>
+<dt> <code>-k <var>kflag</var></code></dt>
+<dd><p>Process keywords according to <var>kflag</var>. See
+[[#SEC98|Keyword substitution]].
+This option is sticky; future updates of
+this file in this working directory will use the same
+<var>kflag</var>. The <code>status</code> command can be viewed
+to see the sticky options. See [[#SEC156|Quick reference to CVS commands]],
for
+more information on the <code>status</code> command.
+</p>
+</dd>
+<dt> <code>-l</code></dt>
+<dd><p>Local; run only in current working directory. See section
[[#SEC65|Recursive behavior]].
+</p>
+</dd>
+<dt> <code>-P</code></dt>
+<dd><p>Prune empty directories. See [[#SEC74|Moving and renaming
directories]].
+</p>
+</dd>
+<dt> <code>-p</code></dt>
+<dd><p>Pipe files to the standard output.
+</p>
+</dd>
+<dt> <code>-R</code></dt>
+<dd><p>Update directories recursively (default). See section
[[#SEC65|Recursive behavior]].
+</p>
+</dd>
+<dt> <code>-r rev</code></dt>
+<dd><p>Retrieve revision/tag <var>rev</var>. This option is sticky,
+and implies ‘<samp>-P</samp>’.
+See [[#SEC53|Sticky tags]], for more information on sticky tags/dates.
+</p></dd>
+</dl>
+
+<p>These special options are also available with
+<code>update</code>.
+</p>
+<dl compact="compact">
+<dt> <code>-A</code></dt>
+<dd><p>Reset any sticky tags, dates, or ‘<samp>-k</samp>’ options.
+See [[#SEC53|Sticky tags]], for more information on sticky tags/dates.
+</p>
+</dd>
+<dt> <code>-C</code></dt>
+<dd><p>Overwrite locally modified files with clean copies from
+the repository (the modified file is saved in
+‘<tt>.#<var>file</var>.<var>revision</var></tt>’, however).
+</p>
+</dd>
+<dt> <code>-d</code></dt>
+<dd><p>Create any directories that exist in the repository if
+they’re missing from the working directory. Normally,
+<code>update</code> acts only on directories and files that
+were already enrolled in your working directory.
+</p>
+<p>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 ‘<samp>-d</samp>’ will create
+those directories, which may not be what you want.
+</p>
+</dd>
+<dt> <code>-I <var>name</var></code></dt>
+<dd><p>Ignore files whose names match <var>name</var> (in your
+working directory) during the update. You can specify
+‘<samp>-I</samp>’ more than once on the command line to specify
+several files to ignore. Use ‘<samp>-I !</samp>’ to avoid
+ignoring any files at all. See section [[#SEC176|Ignoring files via
cvsignore]], for other
+ways to make <small>CVS</small> ignore some files.
+</p>
+</dd>
+<dt> <code>-W<var>spec</var></code></dt>
+<dd><p>Specify file names that should be filtered during
+update. You can use this option repeatedly.
+</p>
+<p><var>spec</var> can be a file name pattern of the same type
+that you can specify in the ‘<tt>.cvswrappers</tt>’
+file. See section [[#SEC165|The cvswrappers file]].
+</p>
+</dd>
+<dt> <code>-j<var>revision</var></code></dt>
+<dd><p>With two ‘<samp>-j</samp>’ options, merge changes from the
+revision specified with the first ‘<samp>-j</samp>’ option to
+the revision specified with the second ‘<samp>j</samp>’ option,
+into the working directory.
+</p>
+<p>With one ‘<samp>-j</samp>’ option, merge changes from the
+ancestor revision to the revision specified with the
+‘<samp>-j</samp>’ 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 ‘<samp>-j</samp>’ option.
+</p>
+<p>Note that using a single ‘<samp>-j <var>tagname</var></samp>’
option rather than
+‘<samp>-j <var>branchname</var></samp>’ to merge changes from a
branch will
+often not remove files which were removed on the branch.
+See section [[#SEC63|Merging can add or remove files]], for more.
+</p>
+<p>In addition, each ‘<samp>-j</samp>’ 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:
+‘<samp>-j<var>Symbolic_Tag</var>:<var>Date_Specifier</var></samp>’.
+</p>
+<p>See section [[#SEC54|Branching and merging]].
+</p>
+</dd>
+</dl>
+
+<hr size="6">
+<div id="update-output"></div>
+<div id="SEC155"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC154| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC156| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC114| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC153| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC156| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+==== update output ====
+
+<p><code>update</code> and <code>checkout</code> keep you informed of
+their progress by printing a line for each file, preceded
+by one character indicating the status of the file:
+</p>
+<dl compact="compact">
+<dt> <code>U <var>file</var></code></dt>
+<dd><p>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 source, and for files
+that you haven’t changed but are not the most recent
+versions available in the repository.
+</p>
+</dd>
+<dt> <code>P <var>file</var></code></dt>
+<dd><p>Like ‘<samp>U</samp>’, but the <small>CVS</small> server
sends a patch instead of an entire
+file. This accomplishes the same thing as ‘<samp>U</samp>’ using
less bandwidth.
+</p>
+</dd>
+<dt> <code>A <var>file</var></code></dt>
+<dd><p>The file has been added to your private copy of the
+sources, and will be added to the source repository
+when you run <code>commit</code> on the file. This is a
+reminder to you that the file needs to be committed.
+</p>
+</dd>
+<dt> <code>R <var>file</var></code></dt>
+<dd><p>The file has been removed from your private copy of the
+sources, and will be removed from the source repository
+when you run <code>commit</code> on the file. This is a
+reminder to you that the file needs to be committed.
+</p>
+</dd>
+<dt> <code>M <var>file</var></code></dt>
+<dd><p>The file is modified in your working directory.
+</p>
+<p>‘<samp>M</samp>’ 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.
+</p>
+<p><small>CVS</small> will print some messages if it merges your work,
+and a backup copy of your working file (as it looked
+before you ran <code>update</code>) will be made. The exact
+name of that file is printed while <code>update</code> runs.
+</p>
+</dd>
+<dt> <code>C <var>file</var></code></dt>
+<dd><div id="IDX246"></div>
+<div id="IDX247"></div>
+<p>A conflict was detected while trying to merge your
+changes to <var>file</var> with changes from the source
+repository. <var>file</var> (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
+‘<tt>.#<var>file</var>.<var>revision</var></tt>’ where
<var>revision</var>
+is the revision that your modified file started
+from. Resolve the conflict as described in
+[[#SEC86|Conflicts example]].
+(Note that some systems automatically purge
+files that begin with ‘<tt>.#</tt>’ 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 <small>VMS</small>, the file name starts with
+‘<tt>__</tt>’ rather than ‘<tt>.#</tt>’.
+</p>
+</dd>
+<dt> <code>? <var>file</var></code></dt>
+<dd><p><var>file</var> is in your working directory, but does not
+correspond to anything in the source repository, and is
+not in the list of files for <small>CVS</small> to ignore (see the
+description of the ‘<samp>-I</samp>’ option, and
+see section [[#SEC176|Ignoring files via cvsignore]]).
+</p></dd>
+</dl>
+
+<hr size="6">
+<div id="Invoking-CVS"></div>
+<div id="SEC156"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC155| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC157| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC114| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC_Top| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC157| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+== Quick reference to CVS commands ==
+
+<p>This appendix describes how to invoke <small>CVS</small>, with
+references to where each command or feature is
+described in detail. For other references run the
+<code>cvs --help</code> command, or see [[#SEC189|Index]].
+</p>
+<p>A <small>CVS</small> command looks like:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>cvs [
<var>global_options</var> ] <var>command</var> [ <var>command_options</var> ] [
<var>command_args</var> ]
+</nowiki></pre></td></tr></table>
+
+<p>Global options:
+</p>
+<dl compact="compact">
+<dt> <code>--allow-root=<var>rootdir</var></code></dt>
+<dd><p>Specify legal <small>CVSROOT</small> directory (server only) (not
+in <small>CVS</small> 1.9 and older). See [[#SEC30|Setting up the server for
password authentication]].
+</p>
+</dd>
+<dt> <code>-a</code></dt>
+<dd><p>Authenticate all communication (client only) (not in <small>CVS</small>
+1.9 and older). See [[#SEC118|Global options]].
+</p>
+</dd>
+<dt> <code>-b</code></dt>
+<dd><p>Specify RCS location (<small>CVS</small> 1.9 and older). See
+[[#SEC118|Global options]].
+</p>
+</dd>
+<dt> <code>-d <var>root</var></code></dt>
+<dd><p>Specify the <small>CVSROOT</small>. See [[#SEC9|The Repository]].
+</p>
+</dd>
+<dt> <code>-e <var>editor</var></code></dt>
+<dd><p>Edit messages with <var>editor</var>. See [[#SEC6|Committing your
changes]].
+</p>
+</dd>
+<dt> <code>-f</code></dt>
+<dd><p>Do not read the ‘<tt>~/.cvsrc</tt>’ file. See
[[#SEC118|Global options]].
+</p>
+</dd>
+<dt> <code>-H</code></dt>
+<dt> <code>--help</code></dt>
+<dd><p>Print a help message. See [[#SEC118|Global options]].
+</p>
+</dd>
+<dt> <code>-l</code></dt>
+<dd><p>Do not log in ‘<tt>$CVSROOT/CVSROOT/history</tt>’ file.
See [[#SEC118|Global options]].
+</p>
+</dd>
+<dt> <code>-n</code></dt>
+<dd><p>Do not change any files. See [[#SEC118|Global options]].
+</p>
+</dd>
+<dt> <code>-Q</code></dt>
+<dd><p>Be really quiet. See [[#SEC118|Global options]].
+</p>
+</dd>
+<dt> <code>-q</code></dt>
+<dd><p>Be somewhat quiet. See [[#SEC118|Global options]].
+</p>
+</dd>
+<dt> <code>-r</code></dt>
+<dd><p>Make new working files read-only. See [[#SEC118|Global options]].
+</p>
+</dd>
+<dt> <code>-s <var>variable</var>=<var>value</var></code></dt>
+<dd><p>Set a user variable. See [[#SEC179|Expansions in administrative
files]].
+</p>
+</dd>
+<dt> <code>-T <var>tempdir</var></code></dt>
+<dd><p>Put temporary files in <var>tempdir</var>. See [[#SEC118|Global
options]].
+</p>
+</dd>
+<dt> <code>-t</code></dt>
+<dd><p>Trace <small>CVS</small> execution. See [[#SEC118|Global options]].
+</p>
+</dd>
+<dt> <code>-v</code></dt>
+<dt> <code>--version</code></dt>
+<dd><p>Display version and copyright information for <small>CVS</small>.
+</p>
+</dd>
+<dt> <code>-w</code></dt>
+<dd><p>Make new working files read-write. See [[#SEC118|Global options]].
+</p>
+</dd>
+<dt> <code>-x</code></dt>
+<dd><p>Encrypt all communication (client only).
+See [[#SEC118|Global options]].
+</p>
+</dd>
+<dt> <code>-z <var>gzip-level</var></code></dt>
+<dd><div id="IDX248"></div>
+<div id="IDX249"></div>
+<p>Set the compression level (client only).
+See [[#SEC118|Global options]].
+</p></dd>
+</dl>
+
+<p>Keyword expansion modes (see section [[#SEC102|Substitution modes]]):
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>-kkv $<i></i>Id:
file1,v 1.1 1993/12/09 03:21:13 joe Exp $
+-kkvl $<i></i>Id: file1,v 1.1 1993/12/09 03:21:13 joe Exp harry $
+-kk $<i></i>Id$
+-kv file1,v 1.1 1993/12/09 03:21:13 joe Exp
+-ko <i>no expansion</i>
+-kb <i>no expansion, file is binary</i>
+</nowiki></pre></td></tr></table>
+
+<p>Keywords (see section [[#SEC99|Keyword List]]):
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>$<i></i>Author: joe
$
+$<i></i>Date: 1993/12/09 03:21:13 $
+$<i></i>CVSHeader: files/file1,v 1.1 1993/12/09 03:21:13 joe Exp harry $
+$<i></i>Header: /home/files/file1,v 1.1 1993/12/09 03:21:13 joe Exp harry $
+$<i></i>Id: file1,v 1.1 1993/12/09 03:21:13 joe Exp harry $
+$<i></i>Locker: harry $
+$<i></i>Name: snapshot_1_14 $
+$<i></i>RCSfile: file1,v $
+$<i></i>Revision: 1.1 $
+$<i></i>Source: /home/files/file1,v $
+$<i></i>State: Exp $
+$<i></i>Log: file1,v $
+Revision 1.1 1993/12/09 03:30:17 joe
+Initial revision
+
+</nowiki></pre></td></tr></table>
+
+<p>Commands, command options, and command arguments:
+</p>
+<dl compact="compact">
+<dt> <code>add [<var>options</var>] [<var>files</var>…]</code></dt>
+<dd><p>Add a new file/directory. See [[#SEC67|Adding files to a directory]].
+</p>
+<dl compact="compact">
+<dt> <code>-k <var>kflag</var></code></dt>
+<dd><p>Set keyword expansion.
+</p>
+</dd>
+<dt> <code>-m <var>msg</var></code></dt>
+<dd><p>Set file description.
+</p></dd>
+</dl>
+
+</dd>
+<dt> <code>admin [<var>options</var>] [<var>files</var>…]</code></dt>
+<dd><p>Administration of history files in the repository. See
+[[#SEC120|admin—Administration]].
+</p>
+<dl compact="compact">
+<dt> <code>-b[<var>rev</var>]</code></dt>
+<dd><p>Set default branch. See [[#SEC108|Reverting to the latest vendor
release]].
+</p>
+</dd>
+<dt> <code>-c<var>string</var></code></dt>
+<dd><p>Set comment leader.
+</p>
+</dd>
+<dt> <code>-k<var>subst</var></code></dt>
+<dd><p>Set keyword substitution. See [[#SEC98|Keyword substitution]].
+</p>
+</dd>
+<dt> <code>-l[<var>rev</var>]</code></dt>
+<dd><p>Lock revision <var>rev</var>, or latest revision.
+</p>
+</dd>
+<dt> <code>-m<var>rev</var>:<var>msg</var></code></dt>
+<dd><p>Replace the log message of revision <var>rev</var> with
+<var>msg</var>.
+</p>
+</dd>
+<dt> <code>-o<var>range</var></code></dt>
+<dd><p>Delete revisions from the repository. See
+[[#SEC121|admin options]].
+</p>
+</dd>
+<dt> <code>-q</code></dt>
+<dd><p>Run quietly; do not print diagnostics.
+</p>
+</dd>
+<dt> <code>-s<var>state</var>[:<var>rev</var>]</code></dt>
+<dd><p>Set the state.
+</p>
+</dd>
+<dt> <code>-t</code></dt>
+<dd><p>Set file description from standard input.
+</p>
+</dd>
+<dt> <code>-t<var>file</var></code></dt>
+<dd><p>Set file description from <var>file</var>.
+</p>
+</dd>
+<dt> <code>-t-<var>string</var></code></dt>
+<dd><p>Set file description to <var>string</var>.
+</p>
+</dd>
+<dt> <code>-u[<var>rev</var>]</code></dt>
+<dd><p>Unlock revision <var>rev</var>, or latest revision.
+</p></dd>
+</dl>
+
+</dd>
+<dt> <code>annotate [<var>options</var>] [<var>files</var>…]</code></dt>
+<dd><p>Show last revision where each line was modified. See
+[[#SEC79|Annotate command]].
+</p>
+<dl compact="compact">
+<dt> <code>-D <var>date</var></code></dt>
+<dd><p>Annotate the most recent revision no later than
+<var>date</var>. See [[#SEC119|Common command options]].
+</p>
+</dd>
+<dt> <code>-F</code></dt>
+<dd><p>Force annotation of binary files. (Without this option,
+binary files are skipped with a message.)
+</p>
+</dd>
+<dt> <code>-f</code></dt>
+<dd><p>Use head revision if tag/date not found. See
+[[#SEC119|Common command options]].
+</p>
+</dd>
+<dt> <code>-l</code></dt>
+<dd><p>Local; run only in current working directory. See section
[[#SEC65|Recursive behavior]].
+</p>
+</dd>
+<dt> <code>-R</code></dt>
+<dd><p>Operate recursively (default). See section [[#SEC65|Recursive
behavior]].
+</p>
+</dd>
+<dt> <code>-r <var>tag</var></code></dt>
+<dd><p>Annotate revision <var>tag</var>. See [[#SEC119|Common command
options]].
+</p></dd>
+</dl>
+
+</dd>
+<dt> <code>checkout [<var>options</var>] <var>modules</var>…</code></dt>
+<dd><p>Get a copy of the sources. See [[#SEC122|checkout—Check out
sources for editing]].
+</p>
+<dl compact="compact">
+<dt> <code>-A</code></dt>
+<dd><p>Reset any sticky tags/date/options. See [[#SEC53|Sticky tags]] and
[[#SEC98|Keyword substitution]].
+</p>
+</dd>
+<dt> <code>-c</code></dt>
+<dd><p>Output the module database. See [[#SEC123|checkout options]].
+</p>
+</dd>
+<dt> <code>-D <var>date</var></code></dt>
+<dd><p>Check out revisions as of <var>date</var> (is sticky). See
+[[#SEC119|Common command options]].
+</p>
+</dd>
+<dt> <code>-d <var>dir</var></code></dt>
+<dd><p>Check out into <var>dir</var>. See [[#SEC123|checkout options]].
+</p>
+</dd>
+<dt> <code>-f</code></dt>
+<dd><p>Use head revision if tag/date not found. See
+[[#SEC119|Common command options]].
+</p>
+</dd>
+<dt> <code>-j <var>rev</var></code></dt>
+<dd><p>Merge in changes. See [[#SEC123|checkout options]].
+</p>
+</dd>
+<dt> <code>-k <var>kflag</var></code></dt>
+<dd><p>Use <var>kflag</var> keyword expansion. See
+[[#SEC102|Substitution modes]].
+</p>
+</dd>
+<dt> <code>-l</code></dt>
+<dd><p>Local; run only in current working directory. See section
[[#SEC65|Recursive behavior]].
+</p>
+</dd>
+<dt> <code>-N</code></dt>
+<dd><p>Don’t “shorten” module paths if -d specified. See
+[[#SEC123|checkout options]].
+</p>
+</dd>
+<dt> <code>-n</code></dt>
+<dd><p>Do not run module program (if any). See [[#SEC123|checkout options]].
+</p>
+</dd>
+<dt> <code>-P</code></dt>
+<dd><p>Prune empty directories. See [[#SEC74|Moving and renaming
directories]].
+</p>
+</dd>
+<dt> <code>-p</code></dt>
+<dd><p>Check out files to standard output (avoids
+stickiness). See [[#SEC123|checkout options]].
+</p>
+</dd>
+<dt> <code>-R</code></dt>
+<dd><p>Operate recursively (default). See section [[#SEC65|Recursive
behavior]].
+</p>
+</dd>
+<dt> <code>-r <var>tag</var></code></dt>
+<dd><p>Checkout revision <var>tag</var> (is sticky). See [[#SEC119|Common
command options]].
+</p>
+</dd>
+<dt> <code>-s</code></dt>
+<dd><p>Like -c, but include module status. See [[#SEC123|checkout options]].
+</p></dd>
+</dl>
+
+</dd>
+<dt> <code>commit [<var>options</var>] [<var>files</var>…]</code></dt>
+<dd><p>Check changes into the repository. See [[#SEC125|commit—Check
files into the repository]].
+</p>
+<dl compact="compact">
+<dt> <code>-F <var>file</var></code></dt>
+<dd><p>Read log message from <var>file</var>. See [[#SEC126|commit options]].
+</p>
+</dd>
+<dt> <code>-f</code></dt>
+<dd><p>Force the file to be committed; disables recursion.
+See [[#SEC126|commit options]].
+</p>
+</dd>
+<dt> <code>-l</code></dt>
+<dd><p>Local; run only in current working directory. See [[#SEC65|Recursive
behavior]].
+</p>
+</dd>
+<dt> <code>-m <var>msg</var></code></dt>
+<dd><p>Use <var>msg</var> as log message. See [[#SEC126|commit options]].
+</p>
+</dd>
+<dt> <code>-n</code></dt>
+<dd><p>Do not run module program (if any). See [[#SEC126|commit options]].
+</p>
+</dd>
+<dt> <code>-R</code></dt>
+<dd><p>Operate recursively (default). See section [[#SEC65|Recursive
behavior]].
+</p>
+</dd>
+<dt> <code>-r <var>rev</var></code></dt>
+<dd><p>Commit to <var>rev</var>. See [[#SEC126|commit options]].
+</p></dd>
+</dl>
+
+</dd>
+<dt> <code>diff [<var>options</var>] [<var>files</var>…]</code></dt>
+<dd><p>Show differences between revisions. See [[#SEC130|diff—Show
differences between revisions]].
+In addition to the options shown below, accepts a wide
+variety of options to control output style, for example
+‘<samp>-c</samp>’ for context diffs.
+</p>
+<dl compact="compact">
+<dt> <code>-D <var>date1</var></code></dt>
+<dd><p>Diff revision for date against working file. See
+[[#SEC131|diff options]].
+</p>
+</dd>
+<dt> <code>-D <var>date2</var></code></dt>
+<dd><p>Diff <var>rev1</var>/<var>date1</var> against <var>date2</var>. See
+[[#SEC131|diff options]].
+</p>
+</dd>
+<dt> <code>-l</code></dt>
+<dd><p>Local; run only in current working directory. See [[#SEC65|Recursive
behavior]].
+</p>
+</dd>
+<dt> <code>-N</code></dt>
+<dd><p>Include diffs for added and removed files. See
+[[#SEC131|diff options]].
+</p>
+</dd>
+<dt> <code>-R</code></dt>
+<dd><p>Operate recursively (default). See section [[#SEC65|Recursive
behavior]].
+</p>
+</dd>
+<dt> <code>-r <var>rev1</var></code></dt>
+<dd><p>Diff revision for <var>rev1</var> against working file. See
+[[#SEC131|diff options]].
+</p>
+</dd>
+<dt> <code>-r <var>rev2</var></code></dt>
+<dd><p>Diff <var>rev1</var>/<var>date1</var> against <var>rev2</var>. See
[[#SEC131|diff options]].
+</p></dd>
+</dl>
+
+</dd>
+<dt> <code>edit [<var>options</var>] [<var>files</var>…]</code></dt>
+<dd><p>Get ready to edit a watched file. See [[#SEC92|How to edit a file
which is being watched]].
+</p>
+<dl compact="compact">
+<dt> <code>-a <var>actions</var></code></dt>
+<dd><p>Specify actions for temporary watch, where
+<var>actions</var> is <code>edit</code>, <code>unedit</code>,
+<code>commit</code>, <code>all</code>, or <code>none</code>. See
+[[#SEC92|How to edit a file which is being watched]].
+</p>
+</dd>
+<dt> <code>-l</code></dt>
+<dd><p>Local; run only in current working directory. See [[#SEC65|Recursive
behavior]].
+</p>
+</dd>
+<dt> <code>-R</code></dt>
+<dd><p>Operate recursively (default). See section [[#SEC65|Recursive
behavior]].
+</p></dd>
+</dl>
+
+</dd>
+<dt> <code>editors [<var>options</var>] [<var>files</var>…]</code></dt>
+<dd><p>See who is editing a watched file. See [[#SEC93|Information about who
is watching and editing]].
+</p>
+<dl compact="compact">
+<dt> <code>-l</code></dt>
+<dd><p>Local; run only in current working directory. See [[#SEC65|Recursive
behavior]].
+</p>
+</dd>
+<dt> <code>-R</code></dt>
+<dd><p>Operate recursively (default). See section [[#SEC65|Recursive
behavior]].
+</p></dd>
+</dl>
+
+</dd>
+<dt> <code>export [<var>options</var>] <var>modules</var>…</code></dt>
+<dd><p>Export files from <small>CVS</small>. See
[[#SEC135|export—Export sources from CVS, similar to checkout]].
+</p>
+<dl compact="compact">
+<dt> <code>-D <var>date</var></code></dt>
+<dd><p>Check out revisions as of <var>date</var>. See
+[[#SEC119|Common command options]].
+</p>
+</dd>
+<dt> <code>-d <var>dir</var></code></dt>
+<dd><p>Check out into <var>dir</var>. See [[#SEC136|export options]].
+</p>
+</dd>
+<dt> <code>-f</code></dt>
+<dd><p>Use head revision if tag/date not found. See
+[[#SEC119|Common command options]].
+</p>
+</dd>
+<dt> <code>-k <var>kflag</var></code></dt>
+<dd><p>Use <var>kflag</var> keyword expansion. See
+[[#SEC102|Substitution modes]].
+</p>
+</dd>
+<dt> <code>-l</code></dt>
+<dd><p>Local; run only in current working directory. See section
[[#SEC65|Recursive behavior]].
+</p>
+</dd>
+<dt> <code>-N</code></dt>
+<dd><p>Don’t “shorten” module paths if -d specified. See
+[[#SEC136|export options]].
+</p>
+</dd>
+<dt> <code>-n</code></dt>
+<dd><p>Do not run module program (if any). See [[#SEC136|export options]].
+</p>
+</dd>
+<dt> <code>-R</code></dt>
+<dd><p>Operate recursively (default). See section [[#SEC65|Recursive
behavior]].
+</p>
+</dd>
+<dt> <code>-r <var>tag</var></code></dt>
+<dd><p>Checkout revision <var>tag</var>. See [[#SEC119|Common command
options]].
+</p></dd>
+</dl>
+
+</dd>
+<dt> <code>history [<var>options</var>] [<var>files</var>…]</code></dt>
+<dd><p>Show repository access history. See [[#SEC137|history—Show
status of files and users]].
+</p>
+<dl compact="compact">
+<dt> <code>-a</code></dt>
+<dd><p>All users (default is self). See [[#SEC138|history options]].
+</p>
+</dd>
+<dt> <code>-b <var>str</var></code></dt>
+<dd><p>Back to record with <var>str</var> in module/file/repos
+field. See [[#SEC138|history options]].
+</p>
+</dd>
+<dt> <code>-c</code></dt>
+<dd><p>Report on committed (modified) files. See [[#SEC138|history options]].
+</p>
+</dd>
+<dt> <code>-D <var>date</var></code></dt>
+<dd><p>Since <var>date</var>. See [[#SEC138|history options]].
+</p>
+</dd>
+<dt> <code>-e</code></dt>
+<dd><p>Report on all record types. See [[#SEC138|history options]].
+</p>
+</dd>
+<dt> <code>-l</code></dt>
+<dd><p>Last modified (committed or modified report). See [[#SEC138|history
options]].
+</p>
+</dd>
+<dt> <code>-m <var>module</var></code></dt>
+<dd><p>Report on <var>module</var> (repeatable). See [[#SEC138|history
options]].
+</p>
+</dd>
+<dt> <code>-n <var>module</var></code></dt>
+<dd><p>In <var>module</var>. See [[#SEC138|history options]].
+</p>
+</dd>
+<dt> <code>-o</code></dt>
+<dd><p>Report on checked out modules. See [[#SEC138|history options]].
+</p>
+</dd>
+<dt> <code>-p <var>repository</var></code></dt>
+<dd><p>In <var>repository</var>. See [[#SEC138|history options]].
+</p>
+</dd>
+<dt> <code>-r <var>rev</var></code></dt>
+<dd><p>Since revision <var>rev</var>. See [[#SEC138|history options]].
+</p>
+</dd>
+<dt> <code>-T</code></dt>
+<dd><p>Produce report on all TAGs. See [[#SEC138|history options]].
+</p>
+</dd>
+<dt> <code>-t <var>tag</var></code></dt>
+<dd><p>Since tag record placed in history file (by anyone).
+See [[#SEC138|history options]].
+</p>
+</dd>
+<dt> <code>-u <var>user</var></code></dt>
+<dd><p>For user <var>user</var> (repeatable). See [[#SEC138|history options]].
+</p>
+</dd>
+<dt> <code>-w</code></dt>
+<dd><p>Working directory must match. See [[#SEC138|history options]].
+</p>
+</dd>
+<dt> <code>-x <var>types</var></code></dt>
+<dd><p>Report on <var>types</var>, one or more of
+<code>TOEFWUCGMAR</code>. See [[#SEC138|history options]].
+</p>
+</dd>
+<dt> <code>-z <var>zone</var></code></dt>
+<dd><p>Output for time zone <var>zone</var>. See [[#SEC138|history options]].
+</p></dd>
+</dl>
+
+</dd>
+<dt> <code>import [<var>options</var>] <var>repository</var>
<var>vendor-tag</var> <var>release-tags</var>…</code></dt>
+<dd><p>Import files into <small>CVS</small>, using vendor branches. See
+[[#SEC139|import—Import sources into CVS, using vendor branches]].
+</p>
+<dl compact="compact">
+<dt> <code>-b <var>bra</var></code></dt>
+<dd><p>Import to vendor branch <var>bra</var>. See
+[[#SEC111|Multiple vendor branches]].
+</p>
+</dd>
+<dt> <code>-d</code></dt>
+<dd><p>Use the file’s modification time as the time of
+import. See [[#SEC140|import options]].
+</p>
+</dd>
+<dt> <code>-k <var>kflag</var></code></dt>
+<dd><p>Set default keyword substitution mode. See
+[[#SEC140|import options]].
+</p>
+</dd>
+<dt> <code>-m <var>msg</var></code></dt>
+<dd><p>Use <var>msg</var> for log message. See
+[[#SEC140|import options]].
+</p>
+</dd>
+<dt> <code>-I <var>ign</var></code></dt>
+<dd><p>More files to ignore (! to reset). See
+[[#SEC140|import options]].
+</p>
+</dd>
+<dt> <code>-W <var>spec</var></code></dt>
+<dd><p>More wrappers. See [[#SEC140|import options]].
+</p></dd>
+</dl>
+
+</dd>
+<dt> <code>init</code></dt>
+<dd><p>Create a <small>CVS</small> repository if it doesn’t exist. See
+[[#SEC23|Creating a repository]].
+</p>
+</dd>
+<dt> <code>kserver</code></dt>
+<dd><p>Kerberos authenticated server.
+See [[#SEC34|Direct connection with kerberos]].
+</p>
+</dd>
+<dt> <code>log [<var>options</var>] [<var>files</var>…]</code></dt>
+<dd><p>Print out history information for files. See [[#SEC143|log—Print
out log information for files]].
+</p>
+<dl compact="compact">
+<dt> <code>-b</code></dt>
+<dd><p>Only list revisions on the default branch. See [[#SEC144|log options]].
+</p>
+</dd>
+<dt> <code>-d <var>dates</var></code></dt>
+<dd><p>Specify dates (<var>d1</var><<var>d2</var> for range, <var>d</var>
for
+latest before). See [[#SEC144|log options]].
+</p>
+</dd>
+<dt> <code>-h</code></dt>
+<dd><p>Only print header. See [[#SEC144|log options]].
+</p>
+</dd>
+<dt> <code>-l</code></dt>
+<dd><p>Local; run only in current working directory. See [[#SEC65|Recursive
behavior]].
+</p>
+</dd>
+<dt> <code>-N</code></dt>
+<dd><p>Do not list tags. See [[#SEC144|log options]].
+</p>
+</dd>
+<dt> <code>-R</code></dt>
+<dd><p>Only print name of RCS file. See [[#SEC144|log options]].
+</p>
+</dd>
+<dt> <code>-r<var>revs</var></code></dt>
+<dd><p>Only list revisions <var>revs</var>. See [[#SEC144|log options]].
+</p>
+</dd>
+<dt> <code>-s <var>states</var></code></dt>
+<dd><p>Only list revisions with specified states. See [[#SEC144|log options]].
+</p>
+</dd>
+<dt> <code>-t</code></dt>
+<dd><p>Only print header and descriptive text. See [[#SEC144|log options]].
+</p>
+</dd>
+<dt> <code>-w<var>logins</var></code></dt>
+<dd><p>Only list revisions checked in by specified logins. See [[#SEC144|log
options]].
+</p></dd>
+</dl>
+
+</dd>
+<dt> <code>login</code></dt>
+<dd><p>Prompt for password for authenticating server. See
+[[#SEC31|Using the client with password authentication]].
+</p>
+</dd>
+<dt> <code>logout</code></dt>
+<dd><p>Remove stored password for authenticating server. See
+[[#SEC31|Using the client with password authentication]].
+</p>
+</dd>
+<dt> <code>pserver</code></dt>
+<dd><p>Password authenticated server.
+See [[#SEC30|Setting up the server for password authentication]].
+</p>
+</dd>
+<dt> <code>rannotate [<var>options</var>]
[<var>modules</var>…]</code></dt>
+<dd><p>Show last revision where each line was modified. See
+[[#SEC79|Annotate command]].
+</p>
+<dl compact="compact">
+<dt> <code>-D <var>date</var></code></dt>
+<dd><p>Annotate the most recent revision no later than
+<var>date</var>. See [[#SEC119|Common command options]].
+</p>
+</dd>
+<dt> <code>-F</code></dt>
+<dd><p>Force annotation of binary files. (Without this option,
+binary files are skipped with a message.)
+</p>
+</dd>
+<dt> <code>-f</code></dt>
+<dd><p>Use head revision if tag/date not found. See
+[[#SEC119|Common command options]].
+</p>
+</dd>
+<dt> <code>-l</code></dt>
+<dd><p>Local; run only in current working directory. See section
[[#SEC65|Recursive behavior]].
+</p>
+</dd>
+<dt> <code>-R</code></dt>
+<dd><p>Operate recursively (default). See section [[#SEC65|Recursive
behavior]].
+</p>
+</dd>
+<dt> <code>-r <var>tag</var></code></dt>
+<dd><p>Annotate revision <var>tag</var>. See [[#SEC119|Common command
options]].
+</p></dd>
+</dl>
+
+</dd>
+<dt> <code>rdiff [<var>options</var>] <var>modules</var>…</code></dt>
+<dd><p>Show differences between releases. See
[[#SEC146|rdiff—’patch’ format diffs between releases]].
+</p>
+<dl compact="compact">
+<dt> <code>-c</code></dt>
+<dd><p>Context diff output format (default). See [[#SEC147|rdiff options]].
+</p>
+</dd>
+<dt> <code>-D <var>date</var></code></dt>
+<dd><p>Select revisions based on <var>date</var>. See [[#SEC119|Common
command options]].
+</p>
+</dd>
+<dt> <code>-f</code></dt>
+<dd><p>Use head revision if tag/date not found. See
+[[#SEC119|Common command options]].
+</p>
+</dd>
+<dt> <code>-l</code></dt>
+<dd><p>Local; run only in current working directory. See [[#SEC65|Recursive
behavior]].
+</p>
+</dd>
+<dt> <code>-R</code></dt>
+<dd><p>Operate recursively (default). See section [[#SEC65|Recursive
behavior]].
+</p>
+</dd>
+<dt> <code>-r <var>rev</var></code></dt>
+<dd><p>Select revisions based on <var>rev</var>. See [[#SEC119|Common command
options]].
+</p>
+</dd>
+<dt> <code>-s</code></dt>
+<dd><p>Short patch - one liner per file. See [[#SEC147|rdiff options]].
+</p>
+</dd>
+<dt> <code>-t</code></dt>
+<dd><p>Top two diffs - last change made to the file. See
+[[#SEC131|diff options]].
+</p>
+</dd>
+<dt> <code>-u</code></dt>
+<dd><p>Unidiff output format. See [[#SEC147|rdiff options]].
+</p>
+</dd>
+<dt> <code>-V <var>vers</var></code></dt>
+<dd><p>Use RCS Version <var>vers</var> for keyword expansion (obsolete). See
+[[#SEC147|rdiff options]].
+</p></dd>
+</dl>
+
+</dd>
+<dt> <code>release [<var>options</var>] <var>directory</var></code></dt>
+<dd><p>Indicate that a directory is no longer in use. See
+[[#SEC149|release—Indicate that a Module is no longer in use]].
+</p>
+<dl compact="compact">
+<dt> <code>-d</code></dt>
+<dd><p>Delete the given directory. See [[#SEC150|release options]].
+</p></dd>
+</dl>
+
+</dd>
+<dt> <code>remove [<var>options</var>] [<var>files</var>…]</code></dt>
+<dd><p>Remove an entry from the repository. See [[#SEC68|Removing files]].
+</p>
+<dl compact="compact">
+<dt> <code>-f</code></dt>
+<dd><p>Delete the file before removing it. See [[#SEC68|Removing files]].
+</p>
+</dd>
+<dt> <code>-l</code></dt>
+<dd><p>Local; run only in current working directory. See [[#SEC65|Recursive
behavior]].
+</p>
+</dd>
+<dt> <code>-R</code></dt>
+<dd><p>Operate recursively (default). See section [[#SEC65|Recursive
behavior]].
+</p></dd>
+</dl>
+
+</dd>
+<dt> <code>rlog [<var>options</var>] [<var>files</var>…]</code></dt>
+<dd><p>Print out history information for modules. See
[[#SEC143|log—Print out log information for files]].
+</p>
+<dl compact="compact">
+<dt> <code>-b</code></dt>
+<dd><p>Only list revisions on the default branch. See [[#SEC144|log options]].
+</p>
+</dd>
+<dt> <code>-d <var>dates</var></code></dt>
+<dd><p>Specify dates (<var>d1</var><<var>d2</var> for range, <var>d</var>
for
+latest before). See [[#SEC144|log options]].
+</p>
+</dd>
+<dt> <code>-h</code></dt>
+<dd><p>Only print header. See [[#SEC144|log options]].
+</p>
+</dd>
+<dt> <code>-l</code></dt>
+<dd><p>Local; run only in current working directory. See [[#SEC65|Recursive
behavior]].
+</p>
+</dd>
+<dt> <code>-N</code></dt>
+<dd><p>Do not list tags. See [[#SEC144|log options]].
+</p>
+</dd>
+<dt> <code>-R</code></dt>
+<dd><p>Only print name of RCS file. See [[#SEC144|log options]].
+</p>
+</dd>
+<dt> <code>-r<var>revs</var></code></dt>
+<dd><p>Only list revisions <var>revs</var>. See [[#SEC144|log options]].
+</p>
+</dd>
+<dt> <code>-s <var>states</var></code></dt>
+<dd><p>Only list revisions with specified states. See [[#SEC144|log options]].
+</p>
+</dd>
+<dt> <code>-t</code></dt>
+<dd><p>Only print header and descriptive text. See [[#SEC144|log options]].
+</p>
+</dd>
+<dt> <code>-w<var>logins</var></code></dt>
+<dd><p>Only list revisions checked in by specified logins. See [[#SEC144|log
options]].
+</p></dd>
+</dl>
+
+</dd>
+<dt> <code>rtag [<var>options</var>] <var>tag</var>
<var>modules</var>…</code></dt>
+<dd><p>Add a symbolic tag to a module.
+See [[#SEC44|Revisions]] and [[#SEC54|Branching and merging]].
+</p>
+<dl compact="compact">
+<dt> <code>-a</code></dt>
+<dd><p>Clear tag from removed files that would not otherwise
+be tagged. See [[#SEC52|Tagging and adding and removing files]].
+</p>
+</dd>
+<dt> <code>-b</code></dt>
+<dd><p>Create a branch named <var>tag</var>. See [[#SEC54|Branching and
merging]].
+</p>
+</dd>
+<dt> <code>-B</code></dt>
+<dd><p>Used in conjunction with -F or -d, enables movement and deletion of
+branch tags. Use with extreme caution.
+</p>
+</dd>
+<dt> <code>-D <var>date</var></code></dt>
+<dd><p>Tag revisions as of <var>date</var>. See [[#SEC50|Specifying what to
tag by date or revision]].
+</p>
+</dd>
+<dt> <code>-d</code></dt>
+<dd><p>Delete <var>tag</var>. See [[#SEC51|Deleting, moving, and renaming
tags]].
+</p>
+</dd>
+<dt> <code>-F</code></dt>
+<dd><p>Move <var>tag</var> if it already exists. See [[#SEC51|Deleting,
moving, and renaming tags]].
+</p>
+</dd>
+<dt> <code>-f</code></dt>
+<dd><p>Force a head revision match if tag/date not found.
+See [[#SEC50|Specifying what to tag by date or revision]].
+</p>
+</dd>
+<dt> <code>-l</code></dt>
+<dd><p>Local; run only in current working directory. See [[#SEC65|Recursive
behavior]].
+</p>
+</dd>
+<dt> <code>-n</code></dt>
+<dd><p>No execution of tag program. See [[#SEC119|Common command options]].
+</p>
+</dd>
+<dt> <code>-R</code></dt>
+<dd><p>Operate recursively (default). See section [[#SEC65|Recursive
behavior]].
+</p>
+</dd>
+<dt> <code>-r <var>rev</var></code></dt>
+<dd><p>Tag existing tag <var>rev</var>. See [[#SEC50|Specifying what to tag
by date or revision]].
+</p></dd>
+</dl>
+
+</dd>
+<dt> <code>server</code></dt>
+<dd><p>Rsh server. See [[#SEC28|Connecting with rsh]].
+</p>
+</dd>
+<dt> <code>status [<var>options</var>] <var>files</var>…</code></dt>
+<dd><p>Display status information in a working directory. See
+[[#SEC84|File status]].
+</p>
+<dl compact="compact">
+<dt> <code>-l</code></dt>
+<dd><p>Local; run only in current working directory. See [[#SEC65|Recursive
behavior]].
+</p>
+</dd>
+<dt> <code>-R</code></dt>
+<dd><p>Operate recursively (default). See section [[#SEC65|Recursive
behavior]].
+</p>
+</dd>
+<dt> <code>-v</code></dt>
+<dd><p>Include tag information for file. See [[#SEC48|Tags–Symbolic
revisions]].
+</p></dd>
+</dl>
+
+</dd>
+<dt> <code>tag [<var>options</var>] <var>tag</var>
[<var>files</var>…]</code></dt>
+<dd><p>Add a symbolic tag to checked out version of files.
+See [[#SEC44|Revisions]] and [[#SEC54|Branching and merging]].
+</p>
+<dl compact="compact">
+<dt> <code>-b</code></dt>
+<dd><p>Create a branch named <var>tag</var>. See [[#SEC54|Branching and
merging]].
+</p>
+</dd>
+<dt> <code>-c</code></dt>
+<dd><p>Check that working files are unmodified. See
+[[#SEC49|Specifying what to tag from the working directory]].
+</p>
+</dd>
+<dt> <code>-D <var>date</var></code></dt>
+<dd><p>Tag revisions as of <var>date</var>. See [[#SEC50|Specifying what to
tag by date or revision]].
+</p>
+</dd>
+<dt> <code>-d</code></dt>
+<dd><p>Delete <var>tag</var>. See [[#SEC51|Deleting, moving, and renaming
tags]].
+</p>
+</dd>
+<dt> <code>-F</code></dt>
+<dd><p>Move <var>tag</var> if it already exists. See [[#SEC51|Deleting,
moving, and renaming tags]].
+</p>
+</dd>
+<dt> <code>-f</code></dt>
+<dd><p>Force a head revision match if tag/date not found.
+See [[#SEC50|Specifying what to tag by date or revision]].
+</p>
+</dd>
+<dt> <code>-l</code></dt>
+<dd><p>Local; run only in current working directory. See [[#SEC65|Recursive
behavior]].
+</p>
+</dd>
+<dt> <code>-R</code></dt>
+<dd><p>Operate recursively (default). See section [[#SEC65|Recursive
behavior]].
+</p>
+</dd>
+<dt> <code>-r <var>rev</var></code></dt>
+<dd><p>Tag existing tag <var>rev</var>. See [[#SEC50|Specifying what to tag
by date or revision]].
+</p></dd>
+</dl>
+
+</dd>
+<dt> <code>unedit [<var>options</var>] [<var>files</var>…]</code></dt>
+<dd><p>Undo an edit command. See [[#SEC92|How to edit a file which is being
watched]].
+</p>
+<dl compact="compact">
+<dt> <code>-l</code></dt>
+<dd><p>Local; run only in current working directory. See [[#SEC65|Recursive
behavior]].
+</p>
+</dd>
+<dt> <code>-R</code></dt>
+<dd><p>Operate recursively (default). See section [[#SEC65|Recursive
behavior]].
+</p></dd>
+</dl>
+
+</dd>
+<dt> <code>update [<var>options</var>] [<var>files</var>…]</code></dt>
+<dd><p>Bring work tree in sync with repository. See
+[[#SEC153|update—Bring work tree in sync with repository]].
+</p>
+<dl compact="compact">
+<dt> <code>-A</code></dt>
+<dd><p>Reset any sticky tags/date/options. See [[#SEC53|Sticky tags]] and
[[#SEC98|Keyword substitution]].
+</p>
+</dd>
+<dt> <code>-C</code></dt>
+<dd><p>Overwrite locally modified files with clean copies from
+the repository (the modified file is saved in
+‘<tt>.#<var>file</var>.<var>revision</var></tt>’, however).
+</p>
+</dd>
+<dt> <code>-D <var>date</var></code></dt>
+<dd><p>Check out revisions as of <var>date</var> (is sticky). See
+[[#SEC119|Common command options]].
+</p>
+</dd>
+<dt> <code>-d</code></dt>
+<dd><p>Create directories. See [[#SEC154|update options]].
+</p>
+</dd>
+<dt> <code>-f</code></dt>
+<dd><p>Use head revision if tag/date not found. See
+[[#SEC119|Common command options]].
+</p>
+</dd>
+<dt> <code>-I <var>ign</var></code></dt>
+<dd><p>More files to ignore (! to reset). See
+[[#SEC140|import options]].
+</p>
+</dd>
+<dt> <code>-j <var>rev</var></code></dt>
+<dd><p>Merge in changes. See [[#SEC154|update options]].
+</p>
+</dd>
+<dt> <code>-k <var>kflag</var></code></dt>
+<dd><p>Use <var>kflag</var> keyword expansion. See
+[[#SEC102|Substitution modes]].
+</p>
+</dd>
+<dt> <code>-l</code></dt>
+<dd><p>Local; run only in current working directory. See section
[[#SEC65|Recursive behavior]].
+</p>
+</dd>
+<dt> <code>-P</code></dt>
+<dd><p>Prune empty directories. See [[#SEC74|Moving and renaming
directories]].
+</p>
+</dd>
+<dt> <code>-p</code></dt>
+<dd><p>Check out files to standard output (avoids
+stickiness). See [[#SEC154|update options]].
+</p>
+</dd>
+<dt> <code>-R</code></dt>
+<dd><p>Operate recursively (default). See section [[#SEC65|Recursive
behavior]].
+</p>
+</dd>
+<dt> <code>-r <var>tag</var></code></dt>
+<dd><p>Checkout revision <var>tag</var> (is sticky). See [[#SEC119|Common
command options]].
+</p>
+</dd>
+<dt> <code>-W <var>spec</var></code></dt>
+<dd><p>More wrappers. See [[#SEC140|import options]].
+</p></dd>
+</dl>
+
+</dd>
+<dt> <code>version</code></dt>
+<dd><div id="IDX250"></div>
+
+<p>Display the version of <small>CVS</small> being used. If the repository
+is remote, display both the client and server versions.
+</p>
+</dd>
+<dt> <code>watch [on|off|add|remove] [<var>options</var>]
[<var>files</var>…]</code></dt>
+<dd>
+<p>on/off: turn on/off read-only checkouts of files. See
+[[#SEC90|Telling CVS to watch certain files]].
+</p>
+<p>add/remove: add or remove notification on actions. See
+[[#SEC91|Telling CVS to notify you]].
+</p>
+<dl compact="compact">
+<dt> <code>-a <var>actions</var></code></dt>
+<dd><p>Specify actions for temporary watch, where
+<var>actions</var> is <code>edit</code>, <code>unedit</code>,
+<code>commit</code>, <code>all</code>, or <code>none</code>. See
+[[#SEC92|How to edit a file which is being watched]].
+</p>
+</dd>
+<dt> <code>-l</code></dt>
+<dd><p>Local; run only in current working directory. See [[#SEC65|Recursive
behavior]].
+</p>
+</dd>
+<dt> <code>-R</code></dt>
+<dd><p>Operate recursively (default). See section [[#SEC65|Recursive
behavior]].
+</p></dd>
+</dl>
+
+</dd>
+<dt> <code>watchers [<var>options</var>] [<var>files</var>…]</code></dt>
+<dd><p>See who is watching a file. See [[#SEC93|Information about who is
watching and editing]].
+</p>
+<dl compact="compact">
+<dt> <code>-l</code></dt>
+<dd><p>Local; run only in current working directory. See [[#SEC65|Recursive
behavior]].
+</p>
+</dd>
+<dt> <code>-R</code></dt>
+<dd><p>Operate recursively (default). See section [[#SEC65|Recursive
behavior]].
+</p></dd>
+</dl>
+
+</dd>
+</dl>
+
+<hr size="6">
+<div id="Administrative-files"></div>
+<div id="SEC157"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC156| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC158| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC156| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC_Top| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC181| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+== Reference manual for Administrative files ==
+
+<p>Inside the repository, in the directory
+‘<tt>$CVSROOT/CVSROOT</tt>’, there are a number of
+supportive files for <small>CVS</small>. You can use <small>CVS</small> 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 [[#SEC20|The administrative files]].
+</p>
+<p>The most important of these files is the ‘<tt>modules</tt>’
+file, which defines the modules inside the repository.
+</p>
+<pre class="menu-preformatted"><nowiki></nowiki>•[[#SEC158|
modules]]::<nowiki> Defining modules
+</nowiki>•[[#SEC165| Wrappers]]::<nowiki> Specify
binary-ness based on file name
+</nowiki>•[[#SEC166| commit files]]::<nowiki> The commit
support files (commitinfo,
+ verifymsg, editinfo, loginfo)
+</nowiki>•[[#SEC175| rcsinfo]]::<nowiki> Templates
for the log messages
+</nowiki>•[[#SEC176| cvsignore]]::<nowiki> Ignoring
files via cvsignore
+</nowiki>•[[#SEC177| checkoutlist]]::<nowiki> Adding your
own administrative files
+</nowiki>•[[#SEC178| history file]]::<nowiki> History
information
+</nowiki>•[[#SEC179| Variables]]::<nowiki> Various
variables are expanded
+</nowiki>•[[#SEC180| config]]::<nowiki>
Miscellaneous CVS configuration
+</nowiki></pre>
+<hr size="6">
+<div id="modules"></div>
+<div id="SEC158"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC157| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC159| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC157| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC157| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC181| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== The modules file ===
+
+<p>The ‘<tt>modules</tt>’ file records your definitions of
+names for collections of source code. <small>CVS</small> will
+use these definitions if you use <small>CVS</small> to update the
+modules file (use normal commands like <code>add</code>,
+<code>commit</code>, etc).
+</p>
+<p>The ‘<tt>modules</tt>’ file may contain blank lines and
+comments (lines beginning with ‘<samp>#</samp>’) as well as
+module definitions. Long lines can be continued on the
+next line by specifying a backslash (‘<samp>\</samp>’) as the
+last character on the line.
+</p>
+<p>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 ‘<tt>first-dir</tt>’, which
+contains two files, ‘<tt>file1</tt>’ and
‘<tt>file2</tt>’, and a
+directory ‘<tt>sdir</tt>’. ‘<tt>first-dir/sdir</tt>’
contains
+a file ‘<tt>sfile</tt>’.
+</p>
+
+<pre class="menu-preformatted"><nowiki></nowiki>•[[#SEC159| Alias
modules]]::<nowiki> The simplest kind of module
+</nowiki>•[[#SEC160| Regular modules]]::<nowiki>
+</nowiki>•[[#SEC161| Ampersand modules]]::<nowiki>
+</nowiki>•[[#SEC162| Excluding directories]]::<nowiki> Excluding
directories from a module
+</nowiki>•[[#SEC163| Module options]]::<nowiki> Regular and
ampersand modules can take options
+</nowiki>•[[#SEC164| Module program options]]::<nowiki> How the
modules ``program options'' programs
+ are run.
+</nowiki></pre>
+<hr size="6">
+<div id="Alias-modules"></div>
+<div id="SEC159"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC158| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC160| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC157| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC158| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC181| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+==== Alias modules ====
+
+<p>Alias modules are the simplest kind of module:
+</p>
+<dl compact="compact">
+<dt> <code><var>mname</var> -a <var>aliases</var>…</code></dt>
+<dd><p>This represents the simplest way of defining a module
+<var>mname</var>. The ‘<samp>-a</samp>’ flags the definition as a
+simple alias: <small>CVS</small> will treat any use of <var>mname</var> (as
+a command argument) as if the list of names
+<var>aliases</var> had been specified instead.
+<var>aliases</var> may contain either other module names or
+paths. When you use paths in aliases, <code>checkout</code>
+creates all intermediate directories in the working
+directory, just as if the path had been specified
+explicitly in the <small>CVS</small> arguments.
+</p></dd>
+</dl>
+
+<p>For example, if the modules file contains:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>amodule -a first-dir
+</nowiki></pre></td></tr></table>
+
+<p>then the following two commands are equivalent:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>$ cvs co amodule
+$ cvs co first-dir
+</nowiki></pre></td></tr></table>
+
+<p>and they each would provide output such as:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>cvs checkout:
Updating first-dir
+U first-dir/file1
+U first-dir/file2
+cvs checkout: Updating first-dir/sdir
+U first-dir/sdir/sfile
+</nowiki></pre></td></tr></table>
+
+<hr size="6">
+<div id="Regular-modules"></div>
+<div id="SEC160"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC159| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC161| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC157| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC158| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC181| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+==== Regular modules ====
+
+<dl compact="compact">
+<dt> <code><var>mname</var> [ options ] <var>dir</var> [
<var>files</var>… ]</code></dt>
+<dd><p>In the simplest case, this form of module definition
+reduces to ‘<samp><var>mname</var> <var>dir</var></samp>’. This
defines
+all the files in directory <var>dir</var> as module mname.
+<var>dir</var> is a relative path (from <code>$CVSROOT</code>) to a
+directory of source in the source repository. In this
+case, on checkout, a single directory called
+<var>mname</var> is created as a working directory; no
+intermediate directory levels are used by default, even
+if <var>dir</var> was a path involving several directory
+levels.
+</p></dd>
+</dl>
+
+<p>For example, if a module is defined by:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>regmodule first-dir
+</nowiki></pre></td></tr></table>
+
+<p>then regmodule will contain the files from first-dir:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>$ cvs co regmodule
+cvs checkout: Updating regmodule
+U regmodule/file1
+U regmodule/file2
+cvs checkout: Updating regmodule/sdir
+U regmodule/sdir/sfile
+$
+</nowiki></pre></td></tr></table>
+
+<p>By explicitly specifying files in the module definition
+after <var>dir</var>, you can select particular files from
+directory <var>dir</var>. Here is
+an example:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>regfiles
first-dir/sdir sfile
+</nowiki></pre></td></tr></table>
+
+<p>With this definition, getting the regfiles module
+will create a single working directory
+‘<tt>regfiles</tt>’ containing the file listed, which
+comes from a directory deeper
+in the <small>CVS</small> source repository:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>$ cvs co regfiles
+U regfiles/sfile
+$
+</nowiki></pre></td></tr></table>
+
+<hr size="6">
+<div id="Ampersand-modules"></div>
+<div id="SEC161"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC160| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC162| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC157| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC158| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC181| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+==== Ampersand modules ====
+
+<p>A module definition can refer to other modules by
+including ‘<samp>&<var>module</var></samp>’ in its definition.
+</p><table><tr><td> </td><td><pre
class="example"><nowiki><var>mname</var> [ options ]
<var>&module</var>…
+</nowiki></pre></td></tr></table>
+
+<p>Then getting the module creates a subdirectory for each such
+module, in the directory containing the module. For
+example, if modules contains
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>ampermod
&first-dir
+</nowiki></pre></td></tr></table>
+
+<p>then a checkout will create an <code>ampermod</code> directory
+which contains a directory called <code>first-dir</code>,
+which in turns contains all the directories and files
+which live there. For example, the command
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>$ cvs co ampermod
+</nowiki></pre></td></tr></table>
+
+<p>will create the following files:
+</p>
+<table><tr><td> </td><td><pre
class="example"><nowiki>ampermod/first-dir/file1
+ampermod/first-dir/file2
+ampermod/first-dir/sdir/sfile
+</nowiki></pre></td></tr></table>
+
+<p>There is one quirk/bug: the messages that <small>CVS</small>
+prints omit the ‘<tt>ampermod</tt>’, and thus do not
+correctly display the location to which it is checking
+out the files:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>$ 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
+$
+</nowiki></pre></td></tr></table>
+
+<p>Do not rely on this buggy behavior; it may get fixed in
+a future release of <small>CVS</small>.
+</p>
+
+<hr size="6">
+<div id="Excluding-directories"></div>
+<div id="SEC162"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC161| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC163| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC157| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC158| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC181| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+==== Excluding directories ====
+
+<p>An alias module may exclude particular directories from
+other modules by using an exclamation mark (‘<samp>!</samp>’)
+before the name of each directory to be excluded.
+</p>
+<p>For example, if the modules file contains:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>exmodule -a
!first-dir/sdir first-dir
+</nowiki></pre></td></tr></table>
+
+<p>then checking out the module ‘<samp>exmodule</samp>’ will check
+out everything in ‘<samp>first-dir</samp>’ except any files in
+the subdirectory ‘<samp>first-dir/sdir</samp>’.
+</p>
+<hr size="6">
+<div id="Module-options"></div>
+<div id="SEC163"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC162| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC164| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC157| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC158| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC181| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+==== Module options ====
+
+<p>Either regular modules or ampersand modules can contain
+options, which supply additional information concerning
+the module.
+</p>
+<dl compact="compact">
+<dd><div id="IDX251"></div>
+</dd>
+<dt> <code>-d <var>name</var></code></dt>
+<dd><p>Name the working directory something other than the
+module name.
+</p>
+<div id="IDX252"></div>
+<div id="IDX253"></div>
+</dd>
+<dt> <code>-e <var>prog</var></code></dt>
+<dd><p>Specify a program <var>prog</var> to run whenever files in a
+module are exported. <var>prog</var> runs with a single
+argument, the module name.
+</p>
+<div id="IDX254"></div>
+<div id="IDX255"></div>
+</dd>
+<dt> <code>-o <var>prog</var></code></dt>
+<dd><p>Specify a program <var>prog</var> to run whenever files in a
+module are checked out. <var>prog</var> runs with a single
+argument, the module name. See [[#SEC164|How the modules file “program
options” programs are run]] for
+information on how <var>prog</var> is called.
+</p>
+<div id="IDX256"></div>
+<div id="IDX257"></div>
+<div id="IDX258"></div>
+</dd>
+<dt> <code>-s <var>status</var></code></dt>
+<dd><p>Assign a status to the module. When the module file is
+printed with ‘<samp>cvs checkout -s</samp>’ 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.
+</p>
+<div id="IDX259"></div>
+<div id="IDX260"></div>
+</dd>
+<dt> <code>-t <var>prog</var></code></dt>
+<dd><p>Specify a program <var>prog</var> to run whenever files in a
+module are tagged with <code>rtag</code>. <var>prog</var> runs
+with two arguments: the module name and the symbolic
+tag specified to <code>rtag</code>. It is not run
+when <code>tag</code> is executed. Generally you will find
+that taginfo is a better solution (see section [[#SEC78|User-defined
logging]]).
+</p></dd>
+</dl>
+
+<p>You should also see see section [[#SEC164|How the modules file
“program options” programs are run]] about how the
+“program options” programs are run.
+</p>
+
+<hr size="6">
+<div id="Module-program-options"></div>
+<div id="SEC164"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC163| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC165| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC157| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC158| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC181| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+==== How the modules file “program options” programs are run ====
+
+<p>For checkout, rtag, and export, the program is server-based, and as such the
+following applies:-
+</p>
+<p>If using remote access methods (pserver, ext, etc.),
+<small>CVS</small> will execute this program on the server from a temporary
+directory. The path is searched for this program.
+</p>
+<p>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.
+</p>
+<p>The programs are all run after the operation has effectively
+completed.
+</p>
+
+<hr size="6">
+<div id="Wrappers"></div>
+<div id="SEC165"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC164| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC166| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC157| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC157| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC181| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== The cvswrappers file ===
+
+
+<p>Wrappers refers to a <small>CVS</small> feature which lets you
+control certain settings based on the name of the file
+which is being operated on. The settings are ‘<samp>-k</samp>’
+for binary files, and ‘<samp>-m</samp>’ for nonmergeable text
+files.
+</p>
+<p>The ‘<samp>-m</samp>’ option
+specifies the merge methodology that should be used when
+a non-binary file is updated. <code>MERGE</code> means the usual
+<small>CVS</small> behavior: try to merge the files. <code>COPY</code>
+means that <code>cvs update</code> will refuse to merge
+files, as it also does for files specified as binary
+with ‘<samp>-kb</samp>’ (but if the file is specified as
+binary, there is no need to specify ‘<samp>-m 'COPY'</samp>’).
+<small>CVS</small> will provide the user with the
+two versions of the files, and require the user using
+mechanisms outside <small>CVS</small>, to insert any necessary
+changes.
+</p>
+<p><strong>WARNING: do not use <code>COPY</code> with
+<small>CVS</small> 1.9 or earlier - such versions of <small>CVS</small> will
+copy one version of your file over the other, wiping
+out the previous contents.</strong>
+The ‘<samp>-m</samp>’ wrapper option only affects behavior when
+merging is done on update; it does not affect how files
+are stored. See [[#SEC80|Handling binary files]], for more on
+binary files.
+</p>
+<p>The basic format of the file ‘<tt>cvswrappers</tt>’ is:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>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.
+</nowiki></pre></td></tr></table>
+
+
+<p>For example, the following command imports a
+directory, treating files whose name ends in
+‘<samp>.exe</samp>’ as binary:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>cvs import -I ! -W
"*.exe -k 'b'" first-dir vendortag reltag
+</nowiki></pre></td></tr></table>
+
+
+<hr size="6">
+<div id="commit-files"></div>
+<div id="SEC166"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC165| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC167| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC157| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC157| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC181| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== The commit support files ===
+
+<p>The ‘<samp>-i</samp>’ flag in the
‘<tt>modules</tt>’ file can be
+used to run a certain program whenever files are
+committed (see section [[#SEC158|The modules file]]). The files described in
+this section provide other, more flexible, ways to run
+programs whenever something is committed.
+</p>
+<p>There are three kind 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.
+</p>
+<dl compact="compact">
+<dt> ‘<tt>commitinfo</tt>’</dt>
+<dd><p>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.
+</p>
+</dd>
+<dt> ‘<tt>verifymsg</tt>’</dt>
+<dd><p>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
+‘<tt>rcsinfo</tt>’ file, which can hold a log message
+template (see section [[#SEC175|Rcsinfo]]).
+</p>
+</dd>
+<dt> ‘<tt>editinfo</tt>’</dt>
+<dd><p>The specified program is used to edit the log message,
+and possibly verify that it contains all required
+fields. This is most useful in combination with the
+‘<tt>rcsinfo</tt>’ file, which can hold a log message
+template (see section [[#SEC175|Rcsinfo]]). (obsolete)
+</p>
+</dd>
+<dt> ‘<tt>loginfo</tt>’</dt>
+<dd><p>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!
+</p></dd>
+</dl>
+
+<pre class="menu-preformatted"><nowiki></nowiki>•[[#SEC167|
syntax]]::<nowiki> The common syntax
+</nowiki>•[[#SEC168| commitinfo]]::<nowiki> Pre-commit
checking
+</nowiki>•[[#SEC169| verifymsg]]::<nowiki> How are log
messages evaluated?
+</nowiki>•[[#SEC170| editinfo]]::<nowiki> Specifying
how log messages are created
+ (obsolete)
+</nowiki>•[[#SEC172| loginfo]]::<nowiki> Where should
log messages be sent?
+</nowiki></pre>
+<hr size="6">
+<div id="syntax"></div>
+<div id="SEC167"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC166| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC168| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC157| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC166| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC181| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+==== The common syntax ====
+
+
+<p>The administrative files such as ‘<tt>commitinfo</tt>’,
+‘<tt>loginfo</tt>’, ‘<tt>rcsinfo</tt>’,
‘<tt>verifymsg</tt>’, etc.,
+all have a common format. The purpose of the files are
+described later on. The common syntax is described
+here.
+</p>
+<div id="IDX261"></div>
+<p>Each line contains the following:
+</p><ul>
+<li>
+A regular expression. This is a basic regular
+expression in the syntax used by GNU emacs.
+
+</li><li>
+A whitespace separator—one or more spaces and/or tabs.
+
+</li><li>
+A file name or command-line template.
+</li></ul>
+
+<p>Blank lines are ignored. Lines that start with the
+character ‘<samp>#</samp>’ are treated as comments. Long lines
+unfortunately can <em>not</em> be broken in two parts in
+any way.
+</p>
+<p>The first regular expression that matches the current
+directory name in the repository is used. The rest of the line
+is used as a file name or command-line as appropriate.
+</p>
+
+<hr size="6">
+<div id="commitinfo"></div>
+<div id="SEC168"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC167| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC169| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC157| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC166| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC181| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+==== Commitinfo ====
+
+<p>The ‘<tt>commitinfo</tt>’ file defines programs to execute
+whenever ‘<samp>cvs commit</samp>’ 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.
+</p>
+<p>As mentioned earlier, each line in the
+‘<tt>commitinfo</tt>’ file consists of a regular expression
+and a command-line template. The template can include
+a program name and any number of arguments you wish to
+supply to it. The full path to the current source
+repository is appended to the template, followed by the
+file names of any files involved in the commit (added,
+removed, and modified files).
+</p>
+<div id="IDX262"></div>
+<p>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.
+</p>
+<div id="IDX263"></div>
+<p>If the repository name does not match any of the
+regular expressions in this file, the ‘<samp>DEFAULT</samp>’
+line is used, if it is specified.
+</p>
+<div id="IDX264"></div>
+<p>All occurrences of the name ‘<samp>ALL</samp>’ appearing as a
+regular expression are used in addition to the first
+matching regular expression or the name ‘<samp>DEFAULT</samp>’.
+</p>
+<div id="IDX265"></div>
+<div id="IDX266"></div>
+<p>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), <em>or in a copy of the workspace on
+the server (see section [[#SEC26|Remote repositories]])</em>. 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.
+</p>
+<p>Note that both the repository directory and the corresponding
+Attic (see section [[#SEC15|The 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.
+</p>
+
+<hr size="6">
+<div id="verifymsg"></div>
+<div id="SEC169"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC168| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC170| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC157| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC166| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC181| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+==== Verifying log messages ====
+
+<p>Once you have entered a log message, you can evaluate
+that message to check for specific content, such as
+a bug ID. Use the ‘<tt>verifymsg</tt>’ 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.
+</p>
+<p>The ‘<tt>verifymsg</tt>’ file is often most useful together
+with the ‘<tt>rcsinfo</tt>’ file, which can be used to
+specify a log message template.
+</p>
+<p>Each line in the ‘<tt>verifymsg</tt>’ file consists of a
+regular expression and a command-line template. The
+template must include a program name, and can include
+any number of arguments. The full path to the current
+log message template file is appended to the template.
+</p>
+<p>One thing that should be noted is that the ‘<samp>ALL</samp>’
+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.
+</p>
+<div id="IDX267"></div>
+<p>If the repository name does not match any of the
+regular expressions in this file, the ‘<samp>DEFAULT</samp>’
+line is used, if it is specified.
+</p>
+<div id="IDX268"></div>
+<p>If the verification script exits with a non-zero exit status,
+the commit is aborted.
+</p>
+<div id="IDX269"></div>
+<p>In the default configuration, CVS allows the
+verification script to change the log message. This is
+controlled via the RereadLogAfterVerify CVSROOT/config
+option.
+</p>
+<p>When ‘<samp>RereadLogAfterVerify=always</samp>’ or
+‘<samp>RereadLogAfterVerify=stat</samp>’, 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.
+</p>
+<p>See section [[#SEC180|The CVSROOT/config configuration file]], for more on
CVSROOT/config options.
+</p>
+<p>It is NOT a good idea for a ‘<tt>verifymsg</tt>’ script to
+interact directly with the user in the various
+client/server methods. For the <code>pserver</code> method,
+there is no protocol support for communicating between
+‘<tt>verifymsg</tt>’ and the client on the remote end. For the
+<code>ext</code> and <code>server</code> methods, it is possible
+for CVS to become confused by the characters going
+along the same channel as the CVS protocol
+messages. See [[#SEC26|Remote repositories]], for more
+information on client/server setups. In addition, at the time
+the ‘<tt>verifymsg</tt>’ 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.
+</p>
+<p>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 ‘<tt>verifymsg</tt>’.
+</p>
+<p>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).
+</p>
+<p>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.
+</p>
+<p>The following is a little silly example of a
+‘<tt>verifymsg</tt>’ file, together with the corresponding
+‘<tt>rcsinfo</tt>’ file, the log message template and an
+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
+‘<tt>/usr/cvssupport/tc.template</tt>’.
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>BugId:
+</nowiki></pre></td></tr></table>
+
+<p>The script ‘<tt>/usr/cvssupport/bugid.verify</tt>’ is used to
+evaluate the log message.
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>#!/bin/sh
+#
+# bugid.verify filename
+#
+# Verify that the log message contains a valid bugid
+# on the first line.
+#
+if head -1 < $1 | grep '^BugId:[ ]*[0-9][0-9]*$' > /dev/null; then
+ exit 0
+elif head -1 < $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
+</nowiki></pre></td></tr></table>
+
+<p>The ‘<tt>verifymsg</tt>’ file contains this line:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>^tc
/usr/cvssupport/bugid.verify
+</nowiki></pre></td></tr></table>
+
+<p>The ‘<tt>rcsinfo</tt>’ file contains this line:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>^tc
/usr/cvssupport/tc.template
+</nowiki></pre></td></tr></table>
+
+<p>The ‘<tt>config</tt>’ file contains this line:
+</p>
+<table><tr><td> </td><td><pre
class="example"><nowiki>RereadLogAfterVerify=always
+</nowiki></pre></td></tr></table>
+
+
+
+<hr size="6">
+<div id="editinfo"></div>
+<div id="SEC170"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC169| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC171| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC157| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC166| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC181| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+==== Editinfo ====
+
+<p><strong>Note: The ‘<tt>editinfo</tt>’ feature has been
+rendered obsolete. To set a default editor for log
+messages use the <code>CVSEDITOR</code>, <code>EDITOR</code> environment
variables
+(see section [[#SEC181|All environment variables which affect CVS]]) or the
‘<samp>-e</samp>’ global
+option (see section [[#SEC118|Global options]]). See [[#SEC169|Verifying log
messages]],
+for information on the use of the ‘<tt>verifymsg</tt>’
+feature for evaluating log messages.</strong>
+</p>
+<p>If you want to make sure that all log messages look the
+same way, you can use the ‘<tt>editinfo</tt>’ file to
+specify a program that is used to edit the log message.
+This program could be a custom-made editor that always
+enforces a certain style of the log message, or maybe a
+simple shell script that calls an editor, and checks
+that the entered message contains the required fields.
+</p>
+<p>If no matching line is found in the ‘<tt>editinfo</tt>’
+file, the editor specified in the environment variable
+<code>$CVSEDITOR</code> is used instead. If that variable is
+not set, then the environment variable <code>$EDITOR</code>
+is used instead. If that variable is not
+set a default will be used. See [[#SEC6|Committing your changes]].
+</p>
+<p>The ‘<tt>editinfo</tt>’ file is often most useful together
+with the ‘<tt>rcsinfo</tt>’ file, which can be used to
+specify a log message template.
+</p>
+<p>Each line in the ‘<tt>editinfo</tt>’ file consists of a
+regular expression and a command-line template. The
+template must include a program name, and can include
+any number of arguments. The full path to the current
+log message template file is appended to the template.
+</p>
+<p>One thing that should be noted is that the ‘<samp>ALL</samp>’
+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 edit script in a
+module, and then overriding it in a subdirectory.
+</p>
+<div id="IDX270"></div>
+<p>If the repository name does not match any of the
+regular expressions in this file, the ‘<samp>DEFAULT</samp>’
+line is used, if it is specified.
+</p>
+<p>If the edit script exits with a non-zero exit status,
+the commit is aborted.
+</p>
+<p>Note: when <small>CVS</small> is accessing a remote repository,
+or when the ‘<samp>-m</samp>’ or ‘<samp>-F</samp>’
options to <code>cvs
+commit</code> are used, ‘<tt>editinfo</tt>’ will not be consulted.
+There is no good workaround for this; use
+‘<tt>verifymsg</tt>’ instead.
+</p>
+<pre class="menu-preformatted"><nowiki></nowiki>•[[#SEC171| editinfo
example]]::<nowiki> Editinfo example
+</nowiki></pre>
+<hr size="6">
+<div id="editinfo-example"></div>
+<div id="SEC171"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC170| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC172| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC157| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC170| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC181| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+===== Editinfo example =====
+
+<p>The following is a little silly example of a
+‘<tt>editinfo</tt>’ file, together with the corresponding
+‘<tt>rcsinfo</tt>’ file, the log message template and an
+editor 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
+‘<tt>/usr/cvssupport/tc.template</tt>’.
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>BugId:
+</nowiki></pre></td></tr></table>
+
+<p>The script ‘<tt>/usr/cvssupport/bugid.edit</tt>’ is used to
+edit the log message.
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>#!/bin/sh
+#
+# bugid.edit filename
+#
+# Call $EDITOR on FILENAME, and verify that the
+# resulting file contains a valid bugid on the first
+# line.
+if [ "x$EDITOR" = "x" ]; then EDITOR=vi; fi
+if [ "x$CVSEDITOR" = "x" ]; then CVSEDITOR=$EDITOR; fi
+$CVSEDITOR $1
+until head -1|grep '^BugId:[ ]*[0-9][0-9]*$' < $1
+do echo -n "No BugId found. Edit again? ([y]/n)"
+ read ans
+ case ${ans} in
+ n*) exit 1;;
+ esac
+ $CVSEDITOR $1
+done
+</nowiki></pre></td></tr></table>
+
+<p>The ‘<tt>editinfo</tt>’ file contains this line:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>^tc
/usr/cvssupport/bugid.edit
+</nowiki></pre></td></tr></table>
+
+<p>The ‘<tt>rcsinfo</tt>’ file contains this line:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>^tc
/usr/cvssupport/tc.template
+</nowiki></pre></td></tr></table>
+
+<hr size="6">
+<div id="loginfo"></div>
+<div id="SEC172"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC171| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC173| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC157| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC166| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC181| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+==== Loginfo ====
+
+<p>The ‘<tt>loginfo</tt>’ file is used to control where
+‘<samp>cvs commit</samp>’ log information is sent. The first
+entry on a line is a regular expression which is tested
+against the directory that the change is being made to,
+relative to the <code>$CVSROOT</code>. If a match is found, then
+the remainder of the line is a filter program that
+should expect log information on its standard input.
+</p>
+<p>If the repository name does not match any of the
+regular expressions in this file, the ‘<samp>DEFAULT</samp>’
+line is used, if it is specified.
+</p>
+<p>All occurrences of the name ‘<samp>ALL</samp>’ appearing as a
+regular expression are used in addition to the first
+matching regular expression or ‘<samp>DEFAULT</samp>’.
+</p>
+<p>The first matching regular expression is used.
+</p>
+<p>See section [[#SEC166|The commit support files]], for a description of the
syntax of
+the ‘<tt>loginfo</tt>’ file.
+</p>
+<p>The user may specify a format string as
+part of the filter. The string is composed of a
+‘<samp>%</samp>’ followed by a space, or followed by a single
+format character, or followed by a set of format
+characters surrounded by ‘<samp>{</samp>’ and
‘<samp>}</samp>’ as
+separators. The format characters are:
+</p>
+<dl compact="compact">
+<dt> <tt>s</tt></dt>
+<dd><p>file name
+</p></dd>
+<dt> <tt>V</tt></dt>
+<dd><p>old version number (pre-checkin)
+</p></dd>
+<dt> <tt>v</tt></dt>
+<dd><p>new version number (post-checkin)
+</p></dd>
+</dl>
+
+<p>All other characters that appear in a format string
+expand to an empty field (commas separating fields are
+still provided).
+</p>
+<p>For example, some valid format strings are ‘<samp>%</samp>’,
+‘<samp>%s</samp>’, ‘<samp>%{s}</samp>’, and
‘<samp>%{sVv}</samp>’.
+</p>
+<p>The output will be a space separated string of tokens enclosed in
+quotation marks (<tt>"</tt>).
+Any embedded dollar signs (<tt>$</tt>), backticks (<tt>‘</tt>),
+backslashes (<tt>\</tt>), or quotation marks will be preceded
+by a backslash (this allows the shell to correctly parse it
+as a single string, regardless of the characters it contains).
+For backwards compatibility, the first
+token will be the repository subdirectory. The rest of the
+tokens will be comma-delimited lists of the information
+requested in the format string. For example, if
+‘<samp>/u/src/master/yoyodyne/tc</samp>’ is the repository,
‘<samp>%{sVv}</samp>’
+is the format string, and three files (<tt>ChangeLog</tt>,
+<tt>Makefile</tt>, <tt>foo.c</tt>) were modified, the output
+might be:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>"yoyodyne/tc
ChangeLog,1.1,1.2 Makefile,1.3,1.4 foo.c,1.12,1.13"
+</nowiki></pre></td></tr></table>
+
+<p>As another example, ‘<samp>%{}</samp>’ means that only the
+name of the repository will be generated.
+</p>
+<p>Note: when <small>CVS</small> is accessing a remote repository,
+‘<tt>loginfo</tt>’ will be run on the <em>remote</em>
+(i.e., server) side, not the client side (see section [[#SEC26|Remote
repositories]]).
+</p>
+<pre class="menu-preformatted"><nowiki></nowiki>•[[#SEC173| loginfo
example]]::<nowiki> Loginfo example
+</nowiki>•[[#SEC174| Keeping a checked out copy]]::<nowiki> Updating a
tree on every checkin
+</nowiki></pre>
+<hr size="6">
+<div id="loginfo-example"></div>
+<div id="SEC173"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC172| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC174| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC157| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC172| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC181| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+===== Loginfo example =====
+
+<p>The following ‘<tt>loginfo</tt>’ file, together with the
+tiny shell-script below, appends all log messages
+to the file ‘<tt>$CVSROOT/CVSROOT/commitlog</tt>’,
+and any commits to the administrative files (inside
+the ‘<tt>CVSROOT</tt>’ directory) are also logged in
+‘<tt>/usr/adm/cvsroot-log</tt>’.
+Commits to the ‘<tt>prog1</tt>’ directory are mailed to
<tt>ceder</tt>.
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>ALL
/usr/local/bin/cvs-log $CVSROOT/CVSROOT/commitlog $USER
+^CVSROOT /usr/local/bin/cvs-log /usr/adm/cvsroot-log
+^prog1 Mail -s %s ceder
+</nowiki></pre></td></tr></table>
+
+<p>The shell-script ‘<tt>/usr/local/bin/cvs-log</tt>’ looks
+like this:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>#!/bin/sh
+(echo "------------------------------------------------------";
+ echo -n $2" ";
+ date;
+ echo;
+ cat) >> $1
+</nowiki></pre></td></tr></table>
+
+<hr size="6">
+<div id="Keeping-a-checked-out-copy"></div>
+<div id="SEC174"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC173| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC175| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC157| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC172| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC181| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+===== Keeping a checked out copy =====
+
+
+<p>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 <small>CVS</small> and want every checkin to cause the files
+used by the web server to be updated.
+</p>
+<p>The way to do this is by having loginfo invoke
+<code>cvs update</code>. Doing so in the naive way will
+cause a problem with locks, so the <code>cvs update</code>
+must be run in the background.
+Here is an example for unix (this should all be on one line):
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>^cyclic-pages
(date; cat; (sleep 2; cd /u/www/local-docs;
+ cvs -q update -d) &) >> $CVSROOT/CVSROOT/updatelog 2>&1
+</nowiki></pre></td></tr></table>
+
+<p>This will cause checkins to repository directories
+starting with <code>cyclic-pages</code> to update the checked
+out tree in ‘<tt>/u/www/local-docs</tt>’.
+</p>
+<hr size="6">
+<div id="rcsinfo"></div>
+<div id="SEC175"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC174| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC176| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC157| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC157| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC181| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== Rcsinfo ===
+
+<p>The ‘<tt>rcsinfo</tt>’ file can be used to specify a form to
+edit when filling out the commit log. The
+‘<tt>rcsinfo</tt>’ file has a syntax similar to the
+‘<tt>verifymsg</tt>’, ‘<tt>commitinfo</tt>’ and
‘<tt>loginfo</tt>’
+files. See section [[#SEC167|The common syntax]]. Unlike the other files the
second
+part is <em>not</em> a command-line template. Instead,
+the part after the regular expression should be a full pathname to
+a file containing the log message template.
+</p>
+<p>If the repository name does not match any of the
+regular expressions in this file, the ‘<samp>DEFAULT</samp>’
+line is used, if it is specified.
+</p>
+<p>All occurrences of the name ‘<samp>ALL</samp>’ appearing as a
+regular expression are used in addition to the first
+matching regular expression or ‘<samp>DEFAULT</samp>’.
+</p>
+<p>The log message template will be used as a default log
+message. If you specify a log message with ‘<samp>cvs
+commit -m <var>message</var></samp>’ or ‘<samp>cvs commit -f
+<var>file</var></samp>’ that log message will override the
+template.
+</p>
+<p>See section [[#SEC169|Verifying log messages]], for an example
‘<tt>rcsinfo</tt>’
+file.
+</p>
+<p>When <small>CVS</small> is accessing a remote repository,
+the contents of ‘<tt>rcsinfo</tt>’ at the time a directory
+is first checked out will specify a template. This
+template will be updated on all ‘<samp>cvs update</samp>’
+commands. It will also be added to new directories
+added with a ‘<samp>cvs add new-directry</samp>’ command.
+In versions of <small>CVS</small> prior to version 1.12, the
+‘<tt>CVS/Template</tt>’ file was not updated. If the
+<small>CVS</small> server is at version 1.12 or higher an older
+client may be used and the ‘<tt>CVS/Template</tt>’ will
+be updated from the server.
+</p>
+<hr size="6">
+<div id="cvsignore"></div>
+<div id="SEC176"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC175| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC177| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC157| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC157| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC181| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== Ignoring files via cvsignore ===
+
+<p>There are certain file names that frequently occur
+inside your working copy, but that you don’t want to
+put under <small>CVS</small> control. Examples are all the object
+files that you get while you compile your sources.
+Normally, when you run ‘<samp>cvs update</samp>’, it prints a
+line for each file it encounters that it doesn’t know
+about (see section [[#SEC155|update output]]).
+</p>
+<p><small>CVS</small> has a list of files (or sh(1) file name patterns)
+that it should ignore while running <code>update</code>,
+<code>import</code> and <code>release</code>.
+This list is constructed in the following way.
+</p>
+<ul>
+<li>
+The list is initialized to include certain file name
+patterns: names associated with <small>CVS</small>
+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:
+
+<div id="IDX271"></div>
+<div id="IDX272"></div>
+<table><tr><td> </td><td><pre class="example"><nowiki> 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
+</nowiki></pre></td></tr></table>
+
+</li><li>
+The per-repository list in
+‘<tt>$CVSROOT/CVSROOT/cvsignore</tt>’ is appended to
+the list, if that file exists.
+
+</li><li>
+The per-user list in ‘<tt>.cvsignore</tt>’ in your home
+directory is appended to the list, if it exists.
+
+</li><li>
+Any entries in the environment variable
+<code>$CVSIGNORE</code> is appended to the list.
+
+</li><li>
+Any ‘<samp>-I</samp>’ options given to <small>CVS</small> is
appended.
+
+</li><li>
+As <small>CVS</small> traverses through your directories, the contents
+of any ‘<tt>.cvsignore</tt>’ will be appended to the list.
+The patterns found in ‘<tt>.cvsignore</tt>’ are only valid
+for the directory that contains them, not for
+any sub-directories.
+</li></ul>
+
+<p>In any of the 5 places listed above, a single
+exclamation mark (‘<samp>!</samp>’) clears the ignore list.
+This can be used if you want to store any file which
+normally is ignored by <small>CVS</small>.
+</p>
+<p>Specifying ‘<samp>-I !</samp>’ to <code>cvs import</code> 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 ‘<tt>.cvsignore</tt>’ files, then
+the patterns from those files will be processed even if
+‘<samp>-I !</samp>’ is specified. The only workaround is to
+remove the ‘<tt>.cvsignore</tt>’ files in order to do the
+import. Because this is awkward, in the future
+‘<samp>-I !</samp>’ might be modified to override
+‘<tt>.cvsignore</tt>’ files in each directory.
+</p>
+<p>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 ‘<tt>foo?bar</tt>’ to match a file
+named ‘<tt>foo bar</tt>’ (it also matches
‘<tt>fooxbar</tt>’
+and the like). Also note that there is currently no
+way to specify comments.
+</p>
+<hr size="6">
+<div id="checkoutlist"></div>
+<div id="SEC177"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC176| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC178| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC157| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC157| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC181| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== The checkoutlist file ===
+
+<p>It may be helpful to use <small>CVS</small> to maintain your own
+files in the ‘<tt>CVSROOT</tt>’ directory. For example,
+suppose that you have a script ‘<tt>logcommit.pl</tt>’
+which you run by including the following line in the
+‘<tt>commitinfo</tt>’ administrative file:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>ALL
$CVSROOT/CVSROOT/logcommit.pl
+</nowiki></pre></td></tr></table>
+
+<p>To maintain ‘<tt>logcommit.pl</tt>’ with <small>CVS</small> you
would
+add the following line to the ‘<tt>checkoutlist</tt>’
+administrative file:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>logcommit.pl
+</nowiki></pre></td></tr></table>
+
+<p>The format of ‘<tt>checkoutlist</tt>’ is one line for each
+file that you want to maintain using <small>CVS</small>, giving
+the name of the file.
+</p>
+<p>After setting up ‘<tt>checkoutlist</tt>’ in this fashion,
+the files listed there will function just like
+<small>CVS</small>’s built-in administrative files. For example,
+when checking in one of the files you should get a
+message such as:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>cvs commit:
Rebuilding administrative file database
+</nowiki></pre></td></tr></table>
+
+<p>and the checked out copy in the ‘<tt>CVSROOT</tt>’
+directory should be updated.
+</p>
+<p>Note that listing ‘<tt>passwd</tt>’ (see section
[[#SEC30|Setting up the server for password authentication]]) in
‘<tt>checkoutlist</tt>’ is not
+recommended for security reasons.
+</p>
+<p>For information about keeping a checkout out copy in a
+more general context than the one provided by
+‘<tt>checkoutlist</tt>’, see [[#SEC174|Keeping a checked out
copy]].
+</p>
+<hr size="6">
+<div id="history-file"></div>
+<div id="SEC178"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC177| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC179| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC157| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC157| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC181| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== The history file ===
+
+<p>The file ‘<tt>$CVSROOT/CVSROOT/history</tt>’ is used
+to log information for the <code>history</code> command
+(see section [[#SEC137|history—Show status of files and users]]). This
file must be created to turn
+on logging. This is done automatically if the
+<code>cvs init</code> command is used to set up the
+repository (see section [[#SEC23|Creating a repository]]).
+</p>
+<p>The file format of the ‘<tt>history</tt>’ file is
+documented only in comments in the <small>CVS</small> source
+code, but generally programs should use the <code>cvs
+history</code> command to access it anyway, in case the
+format changes with future releases of <small>CVS</small>.
+</p>
+<hr size="6">
+<div id="Variables"></div>
+<div id="SEC179"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC178| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC180| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC157| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC157| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC181| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== Expansions in administrative files ===
+
+<p>Sometimes in writing an administrative file, you might
+want the file to be able to know various things based
+on environment <small>CVS</small> is running in. There are
+several mechanisms to do that.
+</p>
+<p>To find the home directory of the user running <small>CVS</small>
+(from the <code>HOME</code> environment variable), use
+‘<samp>~</samp>’ followed by ‘<samp>/</samp>’ or the
end of the line.
+Likewise for the home directory of <var>user</var>, use
+‘<samp>~<var>user</var></samp>’. These variables are expanded on
+the server machine, and don’t get any reasonable
+expansion if pserver (see section [[#SEC29|Direct connection with password
authentication]])
+is in use; therefore user variables (see below) may be
+a better choice to customize behavior based on the user
+running <small>CVS</small>.
+</p>
+<p>One may want to know about various pieces of
+information internal to <small>CVS</small>. A <small>CVS</small> internal
+variable has the syntax <code>${<var>variable</var>}</code>,
+where <var>variable</var> starts with a letter and consists
+of alphanumeric characters and ‘<samp>_</samp>’. If the
+character following <var>variable</var> is a
+non-alphanumeric character other than ‘<samp>_</samp>’, the
+‘<samp>{</samp>’ and ‘<samp>}</samp>’ can be omitted.
The <small>CVS</small>
+internal variables are:
+</p>
+<dl compact="compact">
+<dt> <code>CVSROOT</code></dt>
+<dd><div id="IDX273"></div>
+<p>This is the absolute path to the current <small>CVS</small> root directory.
+See section [[#SEC9|The 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.
+</p>
+</dd>
+<dt> <code>RCSBIN</code></dt>
+<dd><div id="IDX274"></div>
+<p>In <small>CVS</small> 1.9.18 and older, this specified the
+directory where <small>CVS</small> was looking for <small>RCS</small>
+programs. Because <small>CVS</small> no longer runs <small>RCS</small>
+programs, specifying this internal variable is now an
+error.
+</p>
+</dd>
+<dt> <code>CVSEDITOR</code></dt>
+<dd><div id="IDX275"></div>
+</dd>
+<dt> <code>EDITOR</code></dt>
+<dd><div id="IDX276"></div>
+</dd>
+<dt> <code>VISUAL</code></dt>
+<dd><div id="IDX277"></div>
+<p>These all expand to the same value, which is the editor
+that <small>CVS</small> is using. See section [[#SEC118|Global options]], for
how
+to specify this.
+</p>
+</dd>
+<dt> <code>USER</code></dt>
+<dd><div id="IDX278"></div>
+<p>Username of the user running <small>CVS</small> (on the <small>CVS</small>
+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 (see section [[#SEC30|Setting up the server for password
authentication]]).
+Do not confuse this with the environment variable of the same name.
+</p></dd>
+</dl>
+
+<p>If you want to pass a value to the administrative files
+which the user who is running <small>CVS</small> can specify,
+use a user variable.
+<div id="IDX279"></div>
+To expand a user variable, the
+administrative file contains
+<code>${=<var>variable</var>}</code>. To set a user variable,
+specify the global option ‘<samp>-s</samp>’ to <small>CVS</small>,
with
+argument <code><var>variable</var>=<var>value</var></code>. It may be
+particularly useful to specify this option via
+‘<tt>.cvsrc</tt>’ (see section [[#SEC117|Default options and the
~/.cvsrc file]]).
+</p>
+<p>For example, if you want the administrative file to
+refer to a test directory you might create a user
+variable <code>TESTDIR</code>. Then if <small>CVS</small> is invoked
+as
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>cvs -s
TESTDIR=/work/local/tests
+</nowiki></pre></td></tr></table>
+
+<p>and the
+administrative file contains <code>sh
+${=TESTDIR}/runtests</code>, then that string is expanded
+to <code>sh /work/local/tests/runtests</code>.
+</p>
+<p>All other strings containing ‘<samp>$</samp>’ are reserved;
+there is no way to quote a ‘<samp>$</samp>’ character so that
+‘<samp>$</samp>’ represents itself.
+</p>
+<p>Environment variables passed to administrative files are:
+</p>
+<dl compact="compact">
+<dd><div id="IDX280"></div>
+
+</dd>
+<dt> <code>CVS_USER</code></dt>
+<dd><div id="IDX281"></div>
+<p>The <small>CVS</small>-specific username provided by the user, if it
+can be provided (currently just for the pserver access
+method), and to the empty string otherwise. (<code>CVS_USER</code>
+and <code>USER</code> may differ when
‘<tt>$CVSROOT/CVSROOT/passwd</tt>’
+is used to map <small>CVS</small> usernames to system usernames.)
+</p>
+</dd>
+<dt> <code>LOGNAME</code></dt>
+<dd><div id="IDX282"></div>
+<p>The username of the system user.
+</p>
+</dd>
+<dt> <code>USER</code></dt>
+<dd><div id="IDX283"></div>
+<p>Same as <code>LOGNAME</code>.
+Do not confuse this with the internal variable of the same name.
+</p></dd>
+</dl>
+
+<hr size="6">
+<div id="config"></div>
+<div id="SEC180"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC179| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC181| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC157| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC157| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC181| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== The CVSROOT/config configuration file ===
+
+
+<p>The administrative file ‘<tt>config</tt>’ contains various
+miscellaneous settings which affect the behavior of
+<small>CVS</small>. The syntax is slightly different from the
+other administrative files. Variables are not
+expanded. Lines which start with ‘<samp>#</samp>’ are
+considered comments.
+Other lines consist of a keyword, ‘<samp>=</samp>’, and a
+value. Note that this syntax is very strict.
+Extraneous spaces or tabs are not permitted.
+</p>
+<p>Currently defined keywords are:
+</p>
+<dl compact="compact">
+<dd><div id="IDX284"></div>
+</dd>
+<dt> <code>RCSBIN=<var>bindir</var></code></dt>
+<dd><p>For <small>CVS</small> 1.9.12 through 1.9.18, this setting told
+<small>CVS</small> to look for <small>RCS</small> programs in the
+<var>bindir</var> directory. Current versions of <small>CVS</small>
+do not run <small>RCS</small> programs; for compatibility this
+setting is accepted, but it does nothing.
+</p>
+<div id="IDX285"></div>
+</dd>
+<dt> <code>SystemAuth=<var>value</var></code></dt>
+<dd><p>If <var>value</var> is ‘<samp>yes</samp>’, then pserver
should check
+for users in the system’s user database if not found in
+‘<tt>CVSROOT/passwd</tt>’. If it is
‘<samp>no</samp>’, then all
+pserver users must exist in ‘<tt>CVSROOT/passwd</tt>’.
+The default is ‘<samp>yes</samp>’. For more on pserver, see
+[[#SEC29|Direct connection with password authentication]].
+</p>
+
+<div id="IDX286"></div>
+</dd>
+<dt> <code>TopLevelAdmin=<var>value</var></code></dt>
+<dd><p>Modify the ‘<samp>checkout</samp>’ command to create a
+‘<samp>CVS</samp>’ directory at the top level of the new
+working directory, in addition to ‘<samp>CVS</samp>’
+directories created within checked-out directories.
+The default value is ‘<samp>no</samp>’.
+</p>
+<p>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 ‘<tt>CVS</tt>’ directory created there
+will mean you don’t have to specify <code>CVSROOT</code> for
+each command. It also provides a place for the
+‘<tt>CVS/Template</tt>’ file (see section [[#SEC19|How data is
stored in the working directory]]).
+</p>
+<div id="IDX287"></div>
+</dd>
+<dt> <code>LockDir=<var>directory</var></code></dt>
+<dd><p>Put <small>CVS</small> lock files in <var>directory</var> 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 <var>directory</var>, 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 <var>directory</var>, but
+<small>CVS</small> will create subdirectories of <var>directory</var> as it
+needs them. For information on <small>CVS</small> locks, see
+[[#SEC88|Several developers simultaneously attempting to run CVS]].
+</p>
+<p>Before enabling the LockDir option, make sure that you
+have tracked down and removed any copies of <small>CVS</small> 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
+<small>CVS</small> users will put the locks one place, and others will
+put them another place, and therefore the repository
+could become corrupted. <small>CVS</small> 1.10 does not support
+LockDir but it will print a warning if run on a
+repository with LockDir enabled.
+</p>
+<div id="IDX288"></div>
+</dd>
+<dt> <code>LogHistory=<var>value</var></code></dt>
+<dd><p>Control what is logged to the ‘<tt>CVSROOT/history</tt>’
file (see section [[#SEC137|history—Show status of files and users]]).
+Default of ‘<samp>TOEFWUCGMAR</samp>’ (or simply
‘<samp>all</samp>’) will log
+all transactions. Any subset of the default is
+legal. (For example, to only log transactions that modify the
+‘<tt>*,v</tt>’ files, use
‘<samp>LogHistory=TMAR</samp>’.)
+</p>
+<div id="IDX289"></div>
+<div id="IDX290"></div>
+</dd>
+<dt> <code>RereadLogAfterVerify=<var>value</var></code></dt>
+<dd><p>Modify the ‘<samp>commit</samp>’ command such that CVS will
reread the
+log message after running the program specified by
‘<tt>verifymsg</tt>’.
+<var>value</var> may be one of ‘<samp>yes</samp>’ or
‘<samp>always</samp>’, indicating that
+the log message should always be reread; ‘<samp>no</samp>’
+or ‘<samp>never</samp>’, indicating that it should never be
+reread; or <var>value</var> may be ‘<samp>stat</samp>’, indicating
+that the file should be checked with the filesystem
+‘<samp>stat()</samp>’ function to see if it has changed (see
warning below)
+before rereading. The default value is ‘<samp>always</samp>’.
+</p>
+<p><strong>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</strong>
+</p>
+<p>See section [[#SEC169|Verifying log messages]], for more information on how
verifymsg
+may be used.
+</p>
+<div id="IDX291"></div>
+</dd>
+<dt> <code>UserAdminOptions=<var>value</var></code></dt>
+<dd><p>Control what options will be allowed with the <code>cvs admin</code>
+command (see section [[#SEC120|admin—Administration]]) for users not in
the <code>cvsadmin</code> group.
+The <var>value</var> string is a list of single character options
+which should be allowed. If a user who is not a member of the
+<code>cvsadmin</code> group tries to execute any <code>cvs admin</code>
+option which is not listed they will will receive an error message
+reporting that the option is restricted.
+</p>
+<p>If no <code>cvsadmin</code> group exists on the server, <small>CVS</small>
will
+ignore the <code>UserAdminOptions</code> keyword (see section
[[#SEC120|admin—Administration]]).
+</p>
+<p>When not specified, <code>UserAdminOptions</code> defaults to
+‘<samp>k</samp>’. In other words, it defaults to allowing
+users outside of the <code>cvsadmin</code> group to use the
+<code>cvs admin</code> command only to change the default keyword
+expansion mode for files.
+</p>
+<p>As an example, to restrict users not in the <code>cvsadmin</code>
+group to using <code>cvs admin</code> to change the default keyword
+substitution mode, lock revisions, unlock revisions, and
+replace the log message, use ‘<samp>UserAdminOptions=klum</samp>’.
+</p></dd>
+</dl>
+
+<hr size="6">
+<div id="Environment-variables"></div>
+<div id="SEC181"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC180| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC182| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC157| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC_Top| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC182| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+== All environment variables which affect CVS ==
+
+<p>This is a complete list of all environment variables
+that affect <small>CVS</small>.
+</p>
+<dl compact="compact">
+<dd><div id="IDX292"></div>
+</dd>
+<dt> <code>$CVSIGNORE</code></dt>
+<dd><p>A whitespace-separated list of file name patterns that
+<small>CVS</small> should ignore. See section [[#SEC176|Ignoring files via
cvsignore]].
+</p>
+<div id="IDX293"></div>
+</dd>
+<dt> <code>$CVSWRAPPERS</code></dt>
+<dd><p>A whitespace-separated list of file name patterns that
+<small>CVS</small> should treat as wrappers. See section [[#SEC165|The
cvswrappers file]].
+</p>
+<div id="IDX294"></div>
+<div id="IDX295"></div>
+</dd>
+<dt> <code>$CVSREAD</code></dt>
+<dd><p>If this is set, <code>checkout</code> and <code>update</code> 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.
+</p>
+<div id="IDX296"></div>
+</dd>
+<dt> <code>$CVSREADONLYFS</code></dt>
+<dd><p>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 CDROM repository.
+</p>
+<p>It has the same effect as if the ‘<samp>-R</samp>’ command-line
+option is used. This can also allow the use of
+read-only NFS repositories.
+</p>
+</dd>
+<dt> <code>$CVSUMASK</code></dt>
+<dd><p>Controls permissions of files in the repository. See
+[[#SEC13|File permissions]].
+</p>
+</dd>
+<dt> <code>$CVSROOT</code></dt>
+<dd><p>Should contain the full pathname to the root of the <small>CVS</small>
+source repository (where the <small>RCS</small> files are
+kept). This information must be available to <small>CVS</small> for
+most commands to execute; if <code>$CVSROOT</code> is not set,
+or if you wish to override it for one invocation, you
+can supply it on the command line: ‘<samp>cvs -d cvsroot
+cvs_command…</samp>’ Once you have checked out a working
+directory, <small>CVS</small> stores the appropriate root (in
+the file ‘<tt>CVS/Root</tt>’), so normally you only need to
+worry about this when initially checking out a working
+directory.
+</p>
+</dd>
+<dt> <code>$CVSEDITOR</code></dt>
+<dd><div id="IDX297"></div>
+</dd>
+<dt> <code>$EDITOR</code></dt>
+<dd><div id="IDX298"></div>
+</dd>
+<dt> <code>$VISUAL</code></dt>
+<dd><div id="IDX299"></div>
+<p>Specifies the program to use for recording log messages
+during commit. <code>$CVSEDITOR</code> overrides
+<code>$EDITOR</code>, which overrides <code>$VISUAL</code>.
+See [[#SEC6|Committing your changes]] for more or
+[[#SEC118|Global options]] for alternative ways of specifying a
+log editor.
+</p>
+<div id="IDX300"></div>
+</dd>
+<dt> <code>$PATH</code></dt>
+<dd><p>If <code>$RCSBIN</code> is not set, and no path is compiled
+into <small>CVS</small>, it will use <code>$PATH</code> to try to find all
+programs it uses.
+</p>
+<div id="IDX301"></div>
+</dd>
+<dt> <code>$HOME</code></dt>
+<dd><div id="IDX302"></div>
+</dd>
+<dt> <code>$HOMEPATH</code></dt>
+<dd><div id="IDX303"></div>
+</dd>
+<dt> <code>$HOMEDRIVE</code></dt>
+<dd><p>Used to locate the directory where the ‘<tt>.cvsrc</tt>’
+file, and other such files, are searched. On Unix, <small>CVS</small>
+just checks for <code>HOME</code>. On Windows NT, the system will
+set <code>HOMEDRIVE</code>, for example to ‘<samp>d:</samp>’ and
<code>HOMEPATH</code>,
+for example to ‘<tt>\joe</tt>’. On Windows 95, you’ll
+probably need to set <code>HOMEDRIVE</code> and <code>HOMEPATH</code> yourself.
+</p>
+<div id="IDX304"></div>
+</dd>
+<dt> <code>$CVS_RSH</code></dt>
+<dd><p>Specifies the external program which <small>CVS</small> connects with,
+when <code>:ext:</code> access method is specified.
+see section [[#SEC28|Connecting with rsh]].
+</p>
+</dd>
+<dt> <code>$CVS_SERVER</code></dt>
+<dd><p>Used in client-server mode when accessing a remote
+repository using <small>RSH</small>. It specifies the name of
+the program to start on the server side (and any
+necessary arguments) when accessing a remote repository
+using the <code>:ext:</code>, <code>:fork:</code>, or <code>:server:</code>
access methods.
+The default value for <code>:ext:</code> and <code>:server:</code> is
<code>cvs</code>;
+the default value for <code>:fork:</code> is the name used to run the client.
+see section [[#SEC28|Connecting with rsh]]
+</p>
+</dd>
+<dt> <code>$CVS_PASSFILE</code></dt>
+<dd><p>Used in client-server mode when accessing the <code>cvs
+login server</code>. Default value is ‘<tt>$HOME/.cvspass</tt>’.
+see section [[#SEC31|Using the client with password authentication]]
+</p>
+</dd>
+<dt> <code>$CVS_CLIENT_PORT</code></dt>
+<dd><p>Used in client-server mode to set the port to use when accessing the
server
+via Kerberos, GSSAPI, or <small>CVS</small>’s password authentication
protocol
+if the port is not specified in the CVSROOT.
+see section [[#SEC26|Remote repositories]]
+</p>
+<div id="IDX305"></div>
+</dd>
+<dt> <code>$CVS_RCMD_PORT</code></dt>
+<dd><p>Used in client-server mode. If set, specifies the port
+number to be used when accessing the <small>RCMD</small> demon on
+the server side. (Currently not used for Unix clients).
+</p>
+<div id="IDX306"></div>
+</dd>
+<dt> <code>$CVS_CLIENT_LOG</code></dt>
+<dd><p>Used for debugging only in client-server
+mode. If set, everything sent to the server is logged
+into ‘<tt><code>$CVS_CLIENT_LOG</code>.in</tt>’ and everything
+sent from the server is logged into
+‘<tt><code>$CVS_CLIENT_LOG</code>.out</tt>’.
+</p>
+<div id="IDX307"></div>
+</dd>
+<dt> <code>$CVS_SERVER_SLEEP</code></dt>
+<dd><p>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.
+</p>
+<div id="IDX308"></div>
+</dd>
+<dt> <code>$CVS_IGNORE_REMOTE_ROOT</code></dt>
+<dd><p>For <small>CVS</small> 1.10 and older, setting this variable
+prevents <small>CVS</small> from overwriting the
‘<tt>CVS/Root</tt>’
+file when the ‘<samp>-d</samp>’ global option is specified.
+Later versions of <small>CVS</small> do not rewrite
+‘<tt>CVS/Root</tt>’, so <code>CVS_IGNORE_REMOTE_ROOT</code> has no
+effect.
+</p>
+<div id="IDX309"></div>
+</dd>
+<dt> <code>$CVS_LOCAL_BRANCH_NUM</code></dt>
+<dd><p>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
+<code>CVS_LOCAL_BRANCH_NUM</code> 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.
+</p>
+<div id="IDX310"></div>
+</dd>
+<dt> <code>$COMSPEC</code></dt>
+<dd><p>Used under OS/2 only. It specifies the name of the
+command interpreter and defaults to <small>CMD.EXE</small>.
+</p>
+<div id="IDX311"></div>
+</dd>
+<dt> <code>$TMPDIR</code></dt>
+<dd><div id="IDX312"></div>
+</dd>
+<dt> <code>$TMP</code></dt>
+<dd><div id="IDX313"></div>
+</dd>
+<dt> <code>$TEMP</code></dt>
+<dd><div id="IDX314"></div>
+<p>Directory in which temporary files are located.
+The <small>CVS</small> server uses
+<code>TMPDIR</code>. See section [[#SEC118|Global options]], for a
+description of how to specify this.
+Some parts of <small>CVS</small> will always use ‘<tt>/tmp</tt>’
(via
+the <code>tmpnam</code> function provided by the system).
+</p>
+<p>On Windows NT, <code>TMP</code> is used (via the <code>_tempnam</code>
+function provided by the system).
+</p>
+<p>The <code>patch</code> program which is used by the <small>CVS</small>
+client uses <code>TMPDIR</code>, and if it is not set, uses
+‘<tt>/tmp</tt>’ (at least with GNU patch 2.1). Note that
+if your server and client are both running <small>CVS</small>
+1.9.10 or later, <small>CVS</small> will not invoke an external
+<code>patch</code> program.
+</p>
+<div id="IDX315"></div>
+</dd>
+<dt> <code>$CVS_PID</code></dt>
+<dd><p>This is the process identification (aka pid) number of
+the <small>CVS</small> process. It is often useful in the
+programs and/or scripts specified by the
+‘<tt>commitinfo</tt>’, ‘<tt>verifymsg</tt>’,
‘<tt>loginfo</tt>’
+files.
+</p></dd>
+</dl>
+
+<hr size="6">
+<div id="Compatibility"></div>
+<div id="SEC182"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC181| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC183| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC181| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC_Top| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC183| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+== Compatibility between CVS Versions ==
+
+<p>The repository format is compatible going back to
+<small>CVS</small> 1.3. But see [[#SEC94|Using watches with old versions of
CVS]], if
+you have copies of <small>CVS</small> 1.6 or older and you want
+to use the optional developer communication features.
+</p>
+<p>The working directory format is compatible going back
+to <small>CVS</small> 1.5. It did change between <small>CVS</small> 1.3
+and <small>CVS</small> 1.5. If you run <small>CVS</small> 1.5 or newer on
+a working directory checked out with <small>CVS</small> 1.3,
+<small>CVS</small> will convert it, but to go back to <small>CVS</small>
+1.3 you need to check out a new working directory with
+<small>CVS</small> 1.3.
+</p>
+<p>The remote protocol is interoperable going back to <small>CVS</small> 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 bugfixes, however.
+</p>
+
+<hr size="6">
+<div id="Troubleshooting"></div>
+<div id="SEC183"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC182| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC184| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC182| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC_Top| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC187| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+== Troubleshooting ==
+
+<p>If you are having trouble with <small>CVS</small>, 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.
+</p>
+<pre class="menu-preformatted"><nowiki></nowiki>•[[#SEC184| Error
messages]]::<nowiki> Partial list of CVS errors
+</nowiki>•[[#SEC185| Connection]]::<nowiki> Trouble
making a connection to a CVS server
+</nowiki>•[[#SEC186| Other problems]]::<nowiki> Problems not
readily listed by error message
+</nowiki></pre>
+
+<hr size="6">
+<div id="Error-messages"></div>
+<div id="SEC184"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC183| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC185| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC183| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC183| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC187| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== Partial list of error messages ===
+
+<p>Here is a partial list of error messages that you may
+see from <small>CVS</small>. It is not a complete
list—<small>CVS</small>
+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.
+</p>
+<p>The messages are alphabetical, but introductory text
+such as ‘<samp>cvs update: </samp>’ is not considered in
+ordering them.
+</p>
+<p>In some cases the list includes messages printed by old
+versions of <small>CVS</small> (partly because users may not be
+sure which version of <small>CVS</small> they are using at any
+particular moment).
+</p>
+<dl compact="compact">
+<dt> <code><var>file</var>:<var>line</var>: Assertion '<var>text</var>'
failed</code></dt>
+<dd><p>The exact format of this message may vary depending on
+your system. It indicates a bug in <small>CVS</small>, which can
+be handled as described in [[#SEC188|Dealing with bugs in CVS or this manual]].
+</p>
+</dd>
+<dt> <code>cvs <var>command</var>: authorization failed: server
<var>host</var> rejected access</code></dt>
+<dd><p>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 <code>CVSROOT</code> specified is allowed by
‘<samp>--allow-root</samp>’
+in ‘<tt>inetd.conf</tt>’. See [[#SEC29|Direct connection with
password authentication]].
+</p>
+</dd>
+<dt> <code>cvs <var>command</var>: conflict: removed <var>file</var> was
modified by second party</code></dt>
+<dd><p>This message indicates that you removed a file, and
+someone else modified it. To resolve the conflict,
+first run ‘<samp>cvs add <var>file</var></samp>’. 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 ‘<samp>cvs remove <var>file</var></samp>’ and commit your
+removal.
+</p>
+</dd>
+<dt> <code>cannot change permissions on temporary directory</code></dt>
+<dd><table><tr><td> </td><td><pre class="example"><nowiki>Operation not
permitted
+</nowiki></pre></td></tr></table>
+<p>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, ‘<samp>Operation not permitted</samp>’ would be
+likely to read ‘<samp>Not owner</samp>’ or whatever the system
+in question uses for the unix <code>EPERM</code> error. If
+you have any information to add, please let us know as
+described in [[#SEC188|Dealing with bugs in CVS or this manual]]. If you
experience this error
+while using <small>CVS</small>, retrying the operation which
+produced it should work fine.
+</p>
+</dd>
+<dt> <code>cvs [server aborted]: Cannot check out files into the repository
itself</code></dt>
+<dd><p>The obvious cause for this message (especially for
+non-client/server <small>CVS</small>) is that the <small>CVS</small> root
+is, for example, ‘<tt>/usr/local/cvsroot</tt>’ and you try
+to check out files when you are in a subdirectory, such
+as ‘<tt>/usr/local/cvsroot/test</tt>’. 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 ‘<tt>/var/tmp</tt>’; see <code>TMPDIR</code> in
+[[#SEC181|All environment variables which affect CVS]], for how to set the
+temporary directory.
+</p>
+</dd>
+<dt> <code>cannot commit files as 'root'</code></dt>
+<dd><p>See ‘<samp>'root' is not allowed to commit files</samp>’.
+</p>
+</dd>
+<dt> <code>cannot open CVS/Entries for reading: No such file or
directory</code></dt>
+<dd><p>This generally indicates a <small>CVS</small> internal error, and
+can be handled as with other <small>CVS</small> bugs
+(see section [[#SEC188|Dealing with bugs in CVS or this manual]]). Usually
there is a workaround—the
+exact nature of which would depend on the situation but
+which hopefully could be figured out.
+</p>
+</dd>
+<dt> <code>cvs [init aborted]: cannot open CVS/Root: No such file or
directory</code></dt>
+<dd><p>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 <small>CVS</small>, but it is documented
+here for the benefit of <small>CVS</small> 1.9 and older.
+</p>
+</dd>
+<dt> <code>cvs server: cannot open /root/.cvsignore: Permission
denied</code></dt>
+<dt> <code>cvs [server aborted]: can't chdir(/root): Permission
denied</code></dt>
+<dd><p>See [[#SEC185|Trouble making a connection to a CVS server]].
+</p>
+</dd>
+<dt> <code>cvs [checkout aborted]: cannot rename file <var>file</var> to
CVS/,,<var>file</var>: Invalid argument</code></dt>
+<dd><p>This message has been reported as intermittently
+happening with <small>CVS</small> 1.9 on Solaris 2.5. The cause is
+unknown; if you know more about what causes it, let us
+know as described in [[#SEC188|Dealing with bugs in CVS or this manual]].
+</p>
+</dd>
+<dt> <code>cvs [<var>command</var> aborted]: cannot start server via
rcmd</code></dt>
+<dd><p>This, unfortunately, is a rather nonspecific error
+message which <small>CVS</small> 1.9 will print if you are
+running the <small>CVS</small> client and it is having trouble
+connecting to the server. Current versions of <small>CVS</small>
+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
+<code>:local:</code>, as described in [[#SEC9|The Repository]].
+</p>
+</dd>
+<dt> <code>ci: <var>file</var>,v: bad diff output line: Binary files - and
/tmp/T2a22651 differ</code></dt>
+<dd><p><small>CVS</small> 1.9 and older will print this message
+when trying to check in a binary file if
+<small>RCS</small> is not correctly installed. Re-read the
+instructions that came with your <small>RCS</small> distribution
+and the <small>INSTALL</small> file in the <small>CVS</small>
+distribution. Alternately, upgrade to a current
+version of <small>CVS</small>, which checks in files itself
+rather than via <small>RCS</small>.
+</p>
+</dd>
+<dt> <code>cvs checkout: could not check out <var>file</var></code></dt>
+<dd><p>With <small>CVS</small> 1.9, this can mean that the <code>co</code>
program
+(part of <small>RCS</small>) 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 <small>CVS</small>,
+which does not run <code>co</code>, if this message occurs
+without another error message, it is definitely a <small>CVS</small>
+bug (see section [[#SEC188|Dealing with bugs in CVS or this manual]]).
+</p>
+</dd>
+<dt> <code>cvs [login aborted]: could not find out home directory</code></dt>
+<dd><p>This means that you need to set the environment
+variables that <small>CVS</small> uses to locate your home directory.
+See the discussion of <code>HOME</code>, <code>HOMEDRIVE</code>, and
<code>HOMEPATH</code> in
+[[#SEC181|All environment variables which affect CVS]].
+</p>
+</dd>
+<dt> <code>cvs update: could not merge revision <var>rev</var> of
<var>file</var>: No such file or directory</code></dt>
+<dd><p><small>CVS</small> 1.9 and older will print this message if there was
+a problem finding the <code>rcsmerge</code> program. Make
+sure that it is in your <code>PATH</code>, or upgrade to a
+current version of <small>CVS</small>, which does not require
+an external <code>rcsmerge</code> program.
+</p>
+</dd>
+<dt> <code>cvs [update aborted]: could not patch <var>file</var>: No such file
or directory</code></dt>
+<dd><p>This means that there was a problem finding the
+<code>patch</code> program. Make sure that it is in your
+<code>PATH</code>. Note that despite appearances the message
+is <em>not</em> referring to whether it can find <var>file</var>.
+If both the client and the server are running a current
+version of <small>CVS</small>, 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
+<small>CVS</small> 1.9, then you need <code>patch</code>.
+</p>
+</dd>
+<dt> <code>cvs update: could not patch <var>file</var>; will
refetch</code></dt>
+<dd><p>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 <small>CVS</small> does.
+</p>
+</dd>
+<dt> <code>dying gasps from <var>server</var> unexpected</code></dt>
+<dd><p>There is a known bug in the server for <small>CVS</small> 1.9.18
+and older which can cause this. For me, this was
+reproducible if I used the ‘<samp>-t</samp>’ 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 [[#SEC188|Dealing with bugs in CVS
or this manual]].
+</p>
+</dd>
+<dt> <code>end of file from server (consult above messages if any)</code></dt>
+<dd><p>The most common cause for this message is if you are
+using an external <code>rsh</code> program and it exited with
+an error. In this case the <code>rsh</code> program should
+have printed a message, which will appear before the
+above message. For more information on setting up a
+<small>CVS</small> client and server, see [[#SEC26|Remote repositories]].
+</p>
+</dd>
+<dt> <code>cvs [update aborted]: EOF in key in RCS file
<var>file</var>,v</code></dt>
+<dt> <code>cvs [checkout aborted]: EOF while looking for end of string in RCS
file <var>file</var>,v</code></dt>
+<dd><p>This means that there is a syntax error in the given
+<small>RCS</small> file. Note that this might be true even if
<small>RCS</small> can
+read the file OK; <small>CVS</small> does more error checking of
+errors in the RCS file. That is why you may see this
+message when upgrading from <small>CVS</small> 1.9 to <small>CVS</small>
+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 <small>CVS</small> seems to
+corrupting the file, by all means report it,
+(see section [[#SEC188|Dealing with bugs in CVS or this manual]]).
+There are quite a few variations of this error message,
+depending on exactly where in the <small>RCS</small> file <small>CVS</small>
+finds the syntax error.
+</p>
+<div id="IDX316"></div>
+</dd>
+<dt> <code>cvs commit: Executing 'mkmodules'</code></dt>
+<dd><p>This means that your repository is set up for a version
+of <small>CVS</small> prior to <small>CVS</small> 1.8. When using
<small>CVS</small>
+1.8 or later, the above message will be preceded by
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>cvs commit:
Rebuilding administrative file database
+</nowiki></pre></td></tr></table>
+
+<p>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
+<small>CVS</small> 1.7 or earlier in use, remove <code>-i mkmodules</code>
+every place it appears in your <code>modules</code>
+file. For more information on the <code>modules</code> file,
+see [[#SEC158|The modules file]].
+</p>
+</dd>
+<dt> <code>missing author</code></dt>
+<dd><p>Typically this can happen if you created an RCS file
+with your username set to empty. <small>CVS</small> 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.
+</p>
+</dd>
+<dt> <code>cvs [checkout aborted]: no such tag <var>tag</var></code></dt>
+<dd><p>This message means that <small>CVS</small> isn’t familiar with
+the tag <var>tag</var>. Usually this means that you have
+mistyped a tag name; however there are (relatively
+obscure) cases in which <small>CVS</small> will require you to
+try a few other <small>CVS</small> commands involving that tag,
+before you find one which will cause <small>CVS</small> to update
+the ‘<tt>val-tags</tt>’ file; see discussion of val-tags in
+[[#SEC13|File permissions]]. You only need to worry about
+this once for a given tag; when a tag is listed in
+‘<tt>val-tags</tt>’, it stays there. Note that using
+‘<samp>-f</samp>’ to not require tag matches does not override
+this check; see [[#SEC119|Common command options]].
+</p>
+</dd>
+<dt> <code>*PANIC* administration files missing</code></dt>
+<dd><p>This typically means that there is a directory named
+<small>CVS</small> but it does not contain the administrative files
+which <small>CVS</small> puts in a CVS directory. If the problem is
+that you created a CVS directory via some mechanism
+other than <small>CVS</small>, then the answer is simple, use a name
+other than <small>CVS</small>. If not, it indicates a <small>CVS</small> bug
+(see section [[#SEC188|Dealing with bugs in CVS or this manual]]).
+</p>
+</dd>
+<dt> <code>rcs error: Unknown option: -x,v/</code></dt>
+<dd><p>This message will be followed by a usage message for
+<small>RCS</small>. It means that you have an old version of
+<small>RCS</small> (probably supplied with your operating
+system), as well as an old version of <small>CVS</small>.
+<small>CVS</small> 1.9.18 and earlier only work with <small>RCS</small>
version 5 and
+later; current versions of <small>CVS</small> do not run <small>RCS</small>
programs.
+</p>
+</dd>
+<dt> <code>cvs [server aborted]: received broken pipe signal</code></dt>
+<dd><p>This message seems to be caused by a hard-to-track-down
+bug in <small>CVS</small> or the systems it runs on (we don’t
+know—we haven’t tracked it down yet!). It seems to
+happen only after a <small>CVS</small> command has completed, and
+you should be able to just ignore the message.
+However, if you have discovered information concerning its
+cause, please let us know as described in [[#SEC188|Dealing with bugs in CVS
or this manual]].
+</p>
+</dd>
+<dt> <code>'root' is not allowed to commit files</code></dt>
+<dd><p>When committing a permanent change, <small>CVS</small> 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),
+<small>CVS</small> cannot determine who is actually making the change.
+As such, by default, <small>CVS</small> disallows changes to be committed by
users
+logged in as "root". (You can disable this option by passing the
+<code>--enable-rootcommit</code> option to ‘<tt>configure</tt>’
and recompiling <small>CVS</small>.
+On some systems this means editing the appropriate
‘<tt>config.h</tt>’ file
+before building <small>CVS</small>.)
+</p>
+</dd>
+<dt> <code>Too many arguments!</code></dt>
+<dd><p>This message is typically printed by the ‘<tt>log.pl</tt>’
+script which is in the ‘<tt>contrib</tt>’ directory in the
+<small>CVS</small> source distribution. In some versions of
+<small>CVS</small>, ‘<tt>log.pl</tt>’ has been part of the default
+<small>CVS</small> installation. The ‘<tt>log.pl</tt>’ script gets
+called from the ‘<tt>loginfo</tt>’ administrative file.
+Check that the arguments passed in ‘<tt>loginfo</tt>’ match
+what your version of ‘<tt>log.pl</tt>’ expects. In
+particular, the ‘<tt>log.pl</tt>’ from <small>CVS</small> 1.3 and
+older expects the logfile as an argument whereas the
+‘<tt>log.pl</tt>’ from <small>CVS</small> 1.5 and newer expects the
+logfile to be specified with a ‘<samp>-f</samp>’ option. Of
+course, if you don’t need ‘<tt>log.pl</tt>’ you can just
+comment it out of ‘<tt>loginfo</tt>’.
+</p>
+</dd>
+<dt> <code>cvs [update aborted]: unexpected EOF reading
<var>file</var>,v</code></dt>
+<dd><p>See ‘<samp>EOF in key in RCS file</samp>’.
+</p>
+</dd>
+<dt> <code>cvs [login aborted]: unrecognized auth response from
<var>server</var></code></dt>
+<dd><p>This message typically means that the server is not set
+up properly. For example, if ‘<tt>inetd.conf</tt>’ points
+to a nonexistent cvs executable. To debug it further,
+find the log file which inetd writes
+(‘<tt>/var/log/messages</tt>’ or whatever inetd uses on
+your system). For details, see [[#SEC185|Trouble making a connection to a CVS
server]], and
+[[#SEC30|Setting up the server for password authentication]].
+</p>
+</dd>
+<dt> <code>cvs commit: Up-to-date check failed for
`<var>file</var>'</code></dt>
+<dd><p>This means that someone else has committed a change to
+that file since the last time that you did a <code>cvs
+update</code>. So before proceeding with your <code>cvs
+commit</code> you need to <code>cvs update</code>. <small>CVS</small> 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 ‘<samp>M <var>file</var></samp>’ and you are ready
+to <code>cvs commit</code>. If it detects conflicts it will
+print a message saying so, will report ‘<samp>C
<var>file</var></samp>’,
+and you need to manually resolve the
+conflict. For more details on this process see
+[[#SEC86|Conflicts example]].
+</p>
+</dd>
+<dt> <code>Usage: diff3 [-exEX3 [-i | -m] [-L label1 -L label3]] file1
file2 file3</code></dt>
+<dd><table><tr><td> </td><td><pre class="example"><nowiki>Only one of
[exEX3] allowed
+</nowiki></pre></td></tr></table>
+<p>This indicates a problem with the installation of
+<code>diff3</code> and <code>rcsmerge</code>. Specifically
+<code>rcsmerge</code> 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
+<small>CVS</small>, which does not rely on external
+<code>rcsmerge</code> or <code>diff3</code> programs.
+</p>
+</dd>
+<dt> <code>warning: unrecognized response `<var>text</var>' from cvs
server</code></dt>
+<dd><p>If <var>text</var> contains a valid response (such as
+‘<samp>ok</samp>’) 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 ‘<samp>:ext:</samp>’
+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 ‘<samp>:server:</samp>’ instead of
+‘<samp>:ext:</samp>’. If <var>text</var> is something else, this
+may signify a problem with your <small>CVS</small> server.
+Double-check your installation against the instructions
+for setting up the <small>CVS</small> server.
+</p>
+</dd>
+<dt> <code>cvs commit: [<var>time</var>] waiting for <var>user</var>'s lock in
<var>directory</var></code></dt>
+<dd><p>This is a normal message, not an error. See
+[[#SEC88|Several developers simultaneously attempting to run CVS]], for more
details.
+</p>
+</dd>
+<dt> <code>cvs commit: warning: editor session failed</code></dt>
+<dd><div id="IDX317"></div>
+<p>This means that the editor which <small>CVS</small> 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
+<code>CVSEDITOR</code> environment variable to a small script
+such as:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>#!/bin/sh
+vi $*
+exit 0
+</nowiki></pre></td></tr></table>
+
+</dd>
+</dl>
+
+<hr size="6">
+<div id="Connection"></div>
+<div id="SEC185"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC184| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC186| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC183| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC183| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC187| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== Trouble making a connection to a CVS server ===
+
+<p>This section concerns what to do if you are having
+trouble making a connection to a <small>CVS</small> server. If
+you are running the <small>CVS</small> command line client
+running on Windows, first upgrade the client to
+<small>CVS</small> 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,
+<small>CVS</small> 1.9 should be fine.
+</p>
+<p>If the error messages are not sufficient to track down
+the problem, the next steps depend largely on which
+access method you are using.
+</p>
+<dl compact="compact">
+<dd><div id="IDX318"></div>
+</dd>
+<dt> <code>:ext:</code></dt>
+<dd><p>Try running the rsh program from the command line. For
+example: "rsh servername cvs -v" should print <small>CVS</small>
+version information. If this doesn’t work, you need to
+fix it before you can worry about <small>CVS</small> problems.
+</p>
+<div id="IDX319"></div>
+</dd>
+<dt> <code>:server:</code></dt>
+<dd><p>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:.
+</p>
+<div id="IDX320"></div>
+</dd>
+<dt> <code>:pserver:</code></dt>
+<dd><p>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 <small>CVS</small> (this is frequently
+caused by having an incorrect path in ‘<tt>inetd.conf</tt>’
+or by firewall software rejecting the connection).
+"unrecognized auth response" errors are caused by a bad command
+line in ‘<tt>inetd.conf</tt>’, typically an invalid option or
forgetting
+to put the ‘<samp>pserver</samp>’ command at the end of the line.
+Another less common problem is invisible control characters that
+your editor "helpfully" added without you noticing.
+</p>
+<p>One good debugging tool is to "telnet servername
+2401". After connecting, send any text (for example
+"foo" followed by return). If <small>CVS</small> is working
+correctly, it will respond with
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>cvs [pserver
aborted]: bad auth protocol start: foo
+</nowiki></pre></td></tr></table>
+
+<p>If instead you get:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>Usage: cvs
[cvs-options] command [command-options-and-arguments]
+...
+</nowiki></pre></td></tr></table>
+
+<p>then you’re missing the ‘<samp>pserver</samp>’ command at
the end of the
+line in ‘<tt>inetd.conf</tt>’; check to make sure that the entire
command
+is on one line and that it’s complete.
+</p>
+<p>Likewise, if you get something like:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>Unknown command:
`pserved'
+
+CVS commands are:
+ add Add a new file/directory to the repository
+...
+</nowiki></pre></td></tr></table>
+
+<p>then you’ve misspelled ‘<samp>pserver</samp>’ in some
way. If it isn’t
+obvious, check for invisible control characters (particularly
+carriage returns) in ‘<tt>inetd.conf</tt>’.
+</p>
+<p>If it fails to work at all, then make sure inetd is working
+right. Change the invocation in ‘<tt>inetd.conf</tt>’ to run the
+echo program instead of cvs. For example:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>2401 stream tcp
nowait root /bin/echo echo hello
+</nowiki></pre></td></tr></table>
+
+<p>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
+<small>CVS</small> problems.
+</p>
+<p>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
+<small>CVS</small>. I hear that there is an AIX patch available
+to address this problem.
+</p>
+<p>Another good debugging tool is the ‘<samp>-d</samp>’
+(debugging) option to inetd. Consult your system
+documentation for more information.
+</p>
+<p>If you seem to be connecting but get errors like:
+</p>
+<table><tr><td> </td><td><pre class="example"><nowiki>cvs server: cannot
open /root/.cvsignore: Permission denied
+cvs [server aborted]: can't chdir(/root): Permission denied
+</nowiki></pre></td></tr></table>
+
+<p>then you probably haven’t specified ‘<samp>-f</samp>’ in
‘<tt>inetd.conf</tt>’.
+(In releases prior to <small>CVS</small> 1.11.1, this problem can be caused by
+your system setting the <code>$HOME</code> environment variable
+for programs being run by inetd. In this case, you can either
+have inetd run a shell script that unsets <code>$HOME</code> and then runs
+<small>CVS</small>, or you can use <code>env</code> to run <small>CVS</small>
with a pristine
+environment.)
+</p>
+<p>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.)
+</p></dd>
+</dl>
+
+<hr size="6">
+<div id="Other-problems"></div>
+<div id="SEC186"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC185| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC187| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC183| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC183| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC187| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+=== Other common problems ===
+
+<p>Here is a list of problems which do not fit into the
+above categories. They are in no particular order.
+</p>
+<ul>
+<li>
+On Windows, if there is a 30 second or so delay when
+you run a <small>CVS</small> command, it may mean that you have
+your home directory set to ‘<tt>C:/</tt>’, for example (see
+<code>HOMEDRIVE</code> and <code>HOMEPATH</code> in
+[[#SEC181|All environment variables which affect CVS]]). <small>CVS</small>
expects the home
+directory to not end in a slash, for example ‘<tt>C:</tt>’
+or ‘<tt>C:\cvs</tt>’.
+
+</li><li>
+If you are running <small>CVS</small> 1.9.18 or older, and
+<code>cvs update</code> finds a conflict and tries to
+merge, as described in [[#SEC86|Conflicts example]], but
+doesn’t tell you there were conflicts, then you may
+have an old version of <small>RCS</small>. The easiest solution
+probably is to upgrade to a current version of
+<small>CVS</small>, which does not rely on external <small>RCS</small>
+programs.
+</li></ul>
+
+<hr size="6">
+<div id="Credits"></div>
+<div id="SEC187"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC186| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC188| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC183| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC_Top| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC188| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+== Credits ==
+
+<p>Roland Pesch, then of Cygnus Support <<tt>address@hidden</tt>>
+wrote the manual pages which were distributed with
+<small>CVS</small> 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.
+</p>
+<p>The mailing-list <code>info-cvs</code> is sometimes
+informative. I have included information from postings
+made by the following persons:
+David G. Grubbs <<tt>address@hidden</tt>>.
+</p>
+<p>Some text has been extracted from the man pages for
+<small>RCS</small>.
+</p>
+<p>The <small>CVS</small> <small>FAQ</small> by David G. Grubbs has provided
+useful material. The <small>FAQ</small> 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 <small>CVS</small>, at least).
+</p>
+<p>In addition, the following persons have helped by
+telling me about mistakes I’ve made:
+</p>
+<table><tr><td> </td><td><pre class="display"><nowiki>Roxanne Brunskill
<<tt>address@hidden</tt>>,
+Kathy Dyer <<tt>address@hidden</tt>>,
+Karl Pingle <<tt>address@hidden</tt>>,
+Thomas A Peterson <<tt>address@hidden</tt>>,
+Inge Wallin <<tt>address@hidden</tt>>,
+Dirk Koschuetzki <<tt>address@hidden</tt>>
+and Michael Brown <<tt>address@hidden</tt>>.
+</nowiki></pre></td></tr></table>
+
+<p>The list of contributors here is not comprehensive; for a more
+complete list of who has contributed to this manual see
+the file ‘<tt>doc/ChangeLog</tt>’ in the <small>CVS</small> source
+distribution.
+</p>
+<hr size="6">
+<div id="BUGS"></div>
+<div id="SEC188"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC187| < ]]|</td>
+<td valign="middle" align="left">|[[#SEC189| > ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC187| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC_Top| Up ]]|</td>
+<td valign="middle" align="left">|[[#SEC189| >> ]]|</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+== Dealing with bugs in CVS or this manual ==
+
+<p>Neither <small>CVS</small> nor this manual is perfect, and they
+probably never will be. If you are having trouble
+using <small>CVS</small>, 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 <small>CVS</small> itself.
+</p>
+<div id="IDX321"></div>
+<div id="IDX322"></div>
+<div id="IDX323"></div>
+<ul>
+<li>
+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:
+
+<div id="IDX324"></div>
+<div id="IDX325"></div>
+<table><tr><td> </td><td><pre class="example"><nowiki>Ximbiot
+319 S. River St.
+Harrisburg, PA 17104-1657
+USA
+Email: address@hidden
+Phone: (717) 579-6168
+Fax: (717) 234-3125
+http://ximbiot.com/
+
+</nowiki></pre></td></tr></table>
+
+</li><li>
+If you got <small>CVS</small> through a distributor, such as an
+operating system vendor or a vendor of freeware
+<small>CD-ROM</small>s, 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.
+
+</li><li>
+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 <small>CVS</small>, see
+the file <small>HACKING</small> in the <small>CVS</small> source
+distribution. It contains much more information on the
+process of submitting fixes.
+
+</li><li>
+There may be resources on the net which can help. Two
+good places to start are:
+
+<table><tr><td> </td><td><pre
class="example"><nowiki>http://www.cvshome.org
+http://www.loria.fr/~molli/cvs-index.html
+</nowiki></pre></td></tr></table>
+
+<p>If you are so inspired, increasing the information
+available on the net is likely to be appreciated. For
+example, before the standard <small>CVS</small> distribution
+worked on Windows 95, there was a web page with some
+explanation and patches for running <small>CVS</small> on Windows
+95, and various people helped out by mentioning this
+page on mailing lists or newsgroups when the subject
+came up.
+</p>
+</li><li>
+It is also possible to report bugs to <code>bug-cvs</code>.
+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 <code>address@hidden</code>. Note
+that submissions to <code>bug-cvs</code> may be distributed
+under the terms of the <small>GNU</small> 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 <small>CVS</small> maintainers rather than to
+<code>bug-cvs</code>; those maintainers who want to hear
+about such bug reports read <code>bug-cvs</code>. Also note
+that sending a bug report to other mailing lists or
+newsgroups is <em>not</em> a substitute for sending it to
+<code>bug-cvs</code>. It is fine to discuss <small>CVS</small> bugs on
+whatever forum you prefer, but there are not
+necessarily any maintainers reading bug reports sent
+anywhere except <code>bug-cvs</code>.
+</li></ul>
+
+<div id="IDX326"></div>
+<p>People often ask if there is a list of known bugs or
+whether a particular bug is a known one. The file
+<small>BUGS</small> in the <small>CVS</small> 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.
+</p>
+<hr size="6">
+<div id="Index"></div>
+<div id="SEC189"></div>
+<table cellpadding="1" cellspacing="1" border="0">
+<tr><td valign="middle" align="left">|[[#SEC188| < ]]|</td>
+<td valign="middle" align="left">[ > ]</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC188| << ]]|</td>
+<td valign="middle" align="left">|[[#SEC_Top| Up ]]|</td>
+<td valign="middle" align="left">[ >> ]</td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left"> </td>
+<td valign="middle" align="left">|[[#SEC_Top|Top]]|</td>
+<td valign="middle" align="left">|[[#SEC_Contents|Contents]]|</td>
+<td valign="middle" align="left">|[[#SEC189|Index]]|</td>
+<td valign="middle" align="left">|[[#SEC_About| ? ]]|</td>
+</tr></table>
+== Index ==
+
+<table cellpadding="1" cellspacing="1" border="0"><tr><th valign="top">Jump
to:</th>
+<td>[[#SEC189_0|<b>!</b>]]</td>
+<td>[[#SEC189_1|<b>#</b>]]</td>
+<td>[[#SEC189_2|<b>&</b>]]</td>
+<td>[[#SEC189_3|<b>-</b>]]</td>
+<td>[[#SEC189_4|<b>.</b>]]</td>
+<td>[[#SEC189_5|<b>/</b>]]</td>
+<td>[[#SEC189_6|<b>:</b>]]</td>
+<td>[[#SEC189_7|<b><</b>]]</td>
+<td>[[#SEC189_8|<b>=</b>]]</td>
+<td>[[#SEC189_9|<b>></b>]]</td>
+<td>[[#SEC189_10|<b>_</b>]]</td>
+<td>[[#SEC189_11|<b>A</b>]]</td>
+<td>[[#SEC189_12|<b>B</b>]]</td>
+<td>[[#SEC189_13|<b>C</b>]]</td>
+<td>[[#SEC189_14|<b>D</b>]]</td>
+<td>[[#SEC189_15|<b>E</b>]]</td>
+<td>[[#SEC189_16|<b>F</b>]]</td>
+<td>[[#SEC189_17|<b>G</b>]]</td>
+<td>[[#SEC189_18|<b>H</b>]]</td>
+<td>[[#SEC189_19|<b>I</b>]]</td>
+<td>[[#SEC189_20|<b>J</b>]]</td>
+<td>[[#SEC189_21|<b>K</b>]]</td>
+<td>[[#SEC189_22|<b>L</b>]]</td>
+<td>[[#SEC189_23|<b>M</b>]]</td>
+<td>[[#SEC189_24|<b>N</b>]]</td>
+<td>[[#SEC189_25|<b>O</b>]]</td>
+<td>[[#SEC189_26|<b>P</b>]]</td>
+<td>[[#SEC189_27|<b>R</b>]]</td>
+<td>[[#SEC189_28|<b>S</b>]]</td>
+<td>[[#SEC189_29|<b>T</b>]]</td>
+<td>[[#SEC189_30|<b>U</b>]]</td>
+<td>[[#SEC189_31|<b>V</b>]]</td>
+<td>[[#SEC189_32|<b>W</b>]]</td>
+<td>[[#SEC189_33|<b>X</b>]]</td>
+<td>[[#SEC189_34|<b>Z</b>]]</td>
+<table border="0" class="index-cp">
+<tr><td></td><th align="left">Index Entry</th><th align="left">
Section</th></tr>
+<tr><td colspan="3"> <hr></td></tr>
+<tr><th><div id="SEC189_0"></div>!</th><td></td><td></td></tr>
+<tr><td></td><td valign="top">[[#SEC162|!, in modules file]]</td><td
valign="top">[[#SEC162|Excluding directories]]</td></tr>
+<tr><td colspan="3"> <hr></td></tr>
+<tr><th><div id="SEC189_1"></div>#</th><td></td><td></td></tr>
+<tr><td></td><td valign="top">[[#IDX159|#cvs.lock, removing]]</td><td
valign="top">[[#SEC88|Several developers simultaneously attempting to run
CVS]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC17|#cvs.lock, technical details]]</td><td
valign="top">[[#SEC17|CVS locks in the repository]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX63|#cvs.rfl, and backups]]</td><td
valign="top">[[#SEC24|Backing up a repository]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX157|#cvs.rfl, removing]]</td><td
valign="top">[[#SEC88|Several developers simultaneously attempting to run
CVS]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC17|#cvs.rfl, technical details]]</td><td
valign="top">[[#SEC17|CVS locks in the repository]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX29|#cvs.tfl]]</td><td
valign="top">[[#SEC17|CVS locks in the repository]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX158|#cvs.wfl, removing]]</td><td
valign="top">[[#SEC88|Several developers simultaneously attempting to run
CVS]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC17|#cvs.wfl, technical details]]</td><td
valign="top">[[#SEC17|CVS locks in the repository]]</td></tr>
+<tr><td colspan="3"> <hr></td></tr>
+<tr><th><div id="SEC189_2"></div>&</th><td></td><td></td></tr>
+<tr><td></td><td valign="top">[[#SEC161|&, in modules file]]</td><td
valign="top">[[#SEC161|Ampersand modules]]</td></tr>
+<tr><td colspan="3"> <hr></td></tr>
+<tr><th><div id="SEC189_3"></div>-</th><td></td><td></td></tr>
+<tr><td></td><td valign="top">[[#SEC159|-a, in modules file]]</td><td
valign="top">[[#SEC159|Alias modules]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX251|-d, in modules file]]</td><td
valign="top">[[#SEC163|Module options]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX253|-e, in modules file]]</td><td
valign="top">[[#SEC163|Module options]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC164|-e, in modules file]]</td><td
valign="top">[[#SEC164|How the modules file “program options”
programs are run]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC60|-j (merging branches)]]</td><td
valign="top">[[#SEC60|Merging an entire branch]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC64|-j (merging branches), and keyword
substitution]]</td><td valign="top">[[#SEC64|Merging and keywords]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC102|-k (keyword substitution)]]</td><td
valign="top">[[#SEC102|Substitution modes]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC64|-kk, to avoid conflicts during a
merge]]</td><td valign="top">[[#SEC64|Merging and keywords]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX255|-o, in modules file]]</td><td
valign="top">[[#SEC163|Module options]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC164|-o, in modules file]]</td><td
valign="top">[[#SEC164|How the modules file “program options”
programs are run]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX258|-s, in modules file]]</td><td
valign="top">[[#SEC163|Module options]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX260|-t, in modules file]]</td><td
valign="top">[[#SEC163|Module options]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC164|-t, in modules file]]</td><td
valign="top">[[#SEC164|How the modules file “program options”
programs are run]]</td></tr>
+<tr><td colspan="3"> <hr></td></tr>
+<tr><th><div id="SEC189_4"></div>.</th><td></td><td></td></tr>
+<tr><td></td><td valign="top">[[#IDX246|.# files]]</td><td
valign="top">[[#SEC155|update output]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX16|.bashrc, setting CVSROOT in]]</td><td
valign="top">[[#SEC10|Telling CVS where your repository is]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX14|.cshrc, setting CVSROOT in]]</td><td
valign="top">[[#SEC10|Telling CVS where your repository is]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC117|.cvsrc file]]</td><td
valign="top">[[#SEC117|Default options and the ~/.cvsrc file]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX13|.profile, setting CVSROOT in]]</td><td
valign="top">[[#SEC10|Telling CVS where your repository is]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX15|.tcshrc, setting CVSROOT in]]</td><td
valign="top">[[#SEC10|Telling CVS where your repository is]]</td></tr>
+<tr><td colspan="3"> <hr></td></tr>
+<tr><th><div id="SEC189_5"></div>/</th><td></td><td></td></tr>
+<tr><td></td><td valign="top">[[#SEC9|/usr/local/cvsroot, as example
repository]]</td><td valign="top">[[#SEC9|The Repository]]</td></tr>
+<tr><td colspan="3"> <hr></td></tr>
+<tr><th><div id="SEC189_6"></div>:</th><td></td><td></td></tr>
+<tr><td></td><td valign="top">[[#IDX66|:ext:, setting up]]</td><td
valign="top">[[#SEC28|Connecting with rsh]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX318|:ext:, troubleshooting]]</td><td
valign="top">[[#SEC185|Trouble making a connection to a CVS server]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC35|:fork:, setting up]]</td><td
valign="top">[[#SEC35|Connecting with fork]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC33|:gserver:, setting up]]</td><td
valign="top">[[#SEC33|Direct connection with GSSAPI]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC34|:kserver:, setting up]]</td><td
valign="top">[[#SEC34|Direct connection with kerberos]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX12|:local:, setting up]]</td><td
valign="top">[[#SEC9|The Repository]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC31|:pserver:, setting up]]</td><td
valign="top">[[#SEC31|Using the client with password authentication]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX320|:pserver:, troubleshooting]]</td><td
valign="top">[[#SEC185|Trouble making a connection to a CVS server]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX65|:server:, setting up]]</td><td
valign="top">[[#SEC28|Connecting with rsh]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX319|:server:, troubleshooting]]</td><td
valign="top">[[#SEC185|Trouble making a connection to a CVS server]]</td></tr>
+<tr><td colspan="3"> <hr></td></tr>
+<tr><th><div id="SEC189_7"></div><</th><td></td><td></td></tr>
+<tr><td></td><td valign="top">[[#IDX151|<<<<<<<]]</td><td
valign="top">[[#SEC86|Conflicts example]]</td></tr>
+<tr><td colspan="3"> <hr></td></tr>
+<tr><th><div id="SEC189_8"></div>=</th><td></td><td></td></tr>
+<tr><td></td><td valign="top">[[#IDX153|=======]]</td><td
valign="top">[[#SEC86|Conflicts example]]</td></tr>
+<tr><td colspan="3"> <hr></td></tr>
+<tr><th><div id="SEC189_9"></div>></th><td></td><td></td></tr>
+<tr><td></td><td valign="top">[[#IDX152|>>>>>>>]]</td><td
valign="top">[[#SEC86|Conflicts example]]</td></tr>
+<tr><td colspan="3"> <hr></td></tr>
+<tr><th><div id="SEC189_10"></div>_</th><td></td><td></td></tr>
+<tr><td></td><td valign="top">[[#IDX247|__ files (VMS)]]</td><td
valign="top">[[#SEC155|update output]]</td></tr>
+<tr><td colspan="3"> <hr></td></tr>
+<tr><th><div id="SEC189_11"></div>A</th><td></td><td></td></tr>
+<tr><td></td><td valign="top">[[#IDX176|Abandoning work]]</td><td
valign="top">[[#SEC92|How to edit a file which is being watched]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC57|Access a branch]]</td><td
valign="top">[[#SEC57|Accessing branches]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX129|add (subcommand)]]</td><td
valign="top">[[#SEC67|Adding files to a directory]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX100|Adding a tag]]</td><td
valign="top">[[#SEC48|Tags–Symbolic revisions]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC67|Adding files]]</td><td
valign="top">[[#SEC67|Adding files to a directory]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC120|Admin (subcommand)]]</td><td
valign="top">[[#SEC120|admin—Administration]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC20|Administrative files (intro)]]</td><td
valign="top">[[#SEC20|The administrative files]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC157|Administrative files
(reference)]]</td><td valign="top">[[#SEC157|Reference manual for
Administrative files]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC21|Administrative files, editing
them]]</td><td valign="top">[[#SEC21|Editing administrative files]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC159|Alias modules]]</td><td
valign="top">[[#SEC159|Alias modules]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX264|ALL in commitinfo]]</td><td
valign="top">[[#SEC168|Commitinfo]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC161|Ampersand modules]]</td><td
valign="top">[[#SEC161|Ampersand modules]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC79|annotate (subcommand)]]</td><td
valign="top">[[#SEC79|Annotate command]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX160|Atomic transactions, lack of]]</td><td
valign="top">[[#SEC88|Several developers simultaneously attempting to run
CVS]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC15|Attic]]</td><td
valign="top">[[#SEC15|The attic]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC31|Authenticated client, using]]</td><td
valign="top">[[#SEC31|Using the client with password authentication]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX79|Authenticating server, setting
up]]</td><td valign="top">[[#SEC30|Setting up the server for password
authentication]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX202|Authentication, stream]]</td><td
valign="top">[[#SEC118|Global options]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX182|Author keyword]]</td><td
valign="top">[[#SEC99|Keyword List]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX272|Automatically ignored files]]</td><td
valign="top">[[#SEC176|Ignoring files via cvsignore]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX228|Avoiding editor invocation]]</td><td
valign="top">[[#SEC119|Common command options]]</td></tr>
+<tr><td colspan="3"> <hr></td></tr>
+<tr><th><div id="SEC189_12"></div>B</th><td></td><td></td></tr>
+<tr><td></td><td valign="top">[[#SEC24|Backing up, repository]]</td><td
valign="top">[[#SEC24|Backing up a repository]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX53|Base directory, in CVS
directory]]</td><td valign="top">[[#SEC19|How data is stored in the working
directory]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX99|BASE, as reserved tag name]]</td><td
valign="top">[[#SEC48|Tags–Symbolic revisions]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX230|BASE, special tag]]</td><td
valign="top">[[#SEC119|Common command options]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX55|Baserev file, in CVS
directory]]</td><td valign="top">[[#SEC19|How data is stored in the working
directory]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX57|Baserev.tmp file, in CVS
directory]]</td><td valign="top">[[#SEC19|How data is stored in the working
directory]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX201|Bill of materials]]</td><td
valign="top">[[#SEC112|How your build system interacts with CVS]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC80|Binary files]]</td><td
valign="top">[[#SEC80|Handling binary files]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX122|Branch merge example]]</td><td
valign="top">[[#SEC60|Merging an entire branch]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC45|Branch number]]</td><td
valign="top">[[#SEC45|Revision numbers]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC58|Branch number]]</td><td
valign="top">[[#SEC58|Branches and revisions]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX109|Branch tags, deleting]]</td><td
valign="top">[[#SEC51|Deleting, moving, and renaming tags]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX113|Branch tags, moving]]</td><td
valign="top">[[#SEC51|Deleting, moving, and renaming tags]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC57|Branch, accessing]]</td><td
valign="top">[[#SEC57|Accessing branches]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC57|Branch, check out]]</td><td
valign="top">[[#SEC57|Accessing branches]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC56|Branch, creating a]]</td><td
valign="top">[[#SEC56|Creating a branch]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC57|Branch, identifying]]</td><td
valign="top">[[#SEC57|Accessing branches]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC57|Branch, retrieving]]</td><td
valign="top">[[#SEC57|Accessing branches]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX199|Branch, vendor-]]</td><td
valign="top">[[#SEC105|Tracking third-party sources]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC55|Branches motivation]]</td><td
valign="top">[[#SEC55|What branches are good for]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC54|Branches, copying changes
between]]</td><td valign="top">[[#SEC54|Branching and merging]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX120|Branches, sticky]]</td><td
valign="top">[[#SEC57|Accessing branches]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC54|Branching]]</td><td
valign="top">[[#SEC54|Branching and merging]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC85|Bringing a file up to date]]</td><td
valign="top">[[#SEC85|Bringing a file up to date]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC188|Bugs in this manual or CVS]]</td><td
valign="top">[[#SEC188|Dealing with bugs in CVS or this manual]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX322|Bugs, reporting]]</td><td
valign="top">[[#SEC188|Dealing with bugs in CVS or this manual]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC112|Builds]]</td><td
valign="top">[[#SEC112|How your build system interacts with CVS]]</td></tr>
+<tr><td colspan="3"> <hr></td></tr>
+<tr><th><div id="SEC189_13"></div>C</th><td></td><td></td></tr>
+<tr><td></td><td valign="top">[[#SEC54|Changes, copying between
branches]]</td><td valign="top">[[#SEC54|Branching and merging]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX234|Changing a log message]]</td><td
valign="top">[[#SEC121|admin options]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC57|Check out a branch]]</td><td
valign="top">[[#SEC57|Accessing branches]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC174|Checked out copy, keeping]]</td><td
valign="top">[[#SEC174|Keeping a checked out copy]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC5|Checking out source]]</td><td
valign="top">[[#SEC5|Getting the source]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC122|checkout (subcommand)]]</td><td
valign="top">[[#SEC122|checkout—Check out sources for editing]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX254|Checkout program]]</td><td
valign="top">[[#SEC163|Module options]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC92|Checkout, as term for getting ready to
edit]]</td><td valign="top">[[#SEC92|How to edit a file which is being
watched]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC5|Checkout, example]]</td><td
valign="top">[[#SEC5|Getting the source]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC177|checkoutlist]]</td><td
valign="top">[[#SEC177|The checkoutlist file]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC95|Choosing, reserved or unreserved
checkouts]]</td><td valign="top">[[#SEC95|Choosing between reserved or
unreserved checkouts]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC7|Cleaning up]]</td><td
valign="top">[[#SEC7|Cleaning up]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC26|Client/Server Operation]]</td><td
valign="top">[[#SEC26|Remote repositories]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC26|Client/Server Operation, port
specification]]</td><td valign="top">[[#SEC26|Remote repositories]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX73|Client/Server Operation, port
specification]]</td><td valign="top">[[#SEC30|Setting up the server for
password authentication]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC122|co (subcommand)]]</td><td
valign="top">[[#SEC122|checkout—Check out sources for editing]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC156|Command reference]]</td><td
valign="top">[[#SEC156|Quick reference to CVS commands]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC115|Command structure]]</td><td
valign="top">[[#SEC115|Overall structure of CVS commands]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX233|Comment leader]]</td><td
valign="top">[[#SEC121|admin options]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC125|commit (subcommand)]]</td><td
valign="top">[[#SEC125|commit—Check files into the repository]]</td></tr>
+<tr><td></td><td
valign="top">[[#SEC168|‘<tt>commitinfo</tt>’]]</td><td
valign="top">[[#SEC168|Commitinfo]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX266|‘<tt>commitinfo</tt>’,
command environment]]</td><td valign="top">[[#SEC168|Commitinfo]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX265|‘<tt>commitinfo</tt>’,
working directory]]</td><td valign="top">[[#SEC168|Commitinfo]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC168|Commits, precommit verification
of]]</td><td valign="top">[[#SEC168|Commitinfo]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC6|Committing changes to files]]</td><td
valign="top">[[#SEC6|Committing your changes]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC166|Committing, administrative support
files]]</td><td valign="top">[[#SEC166|The commit support files]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC97|Committing, when to]]</td><td
valign="top">[[#SEC97|When to commit?]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC119|Common options]]</td><td
valign="top">[[#SEC119|Common command options]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC167|Common syntax of info files]]</td><td
valign="top">[[#SEC167|The common syntax]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC182|Compatibility, between CVS
versions]]</td><td valign="top">[[#SEC182|Compatibility between CVS
Versions]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX219|Compression]]</td><td
valign="top">[[#SEC118|Global options]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX248|Compression]]</td><td
valign="top">[[#SEC156|Quick reference to CVS commands]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX310|COMSPEC, environment
variable]]</td><td valign="top">[[#SEC181|All environment variables which
affect CVS]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC180|config, in CVSROOT]]</td><td
valign="top">[[#SEC180|The CVSROOT/config configuration file]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC103|Configuring keyword
expansion]]</td><td valign="top">[[#SEC103|Configuring Keyord
Expansion]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX150|Conflict markers]]</td><td
valign="top">[[#SEC86|Conflicts example]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX155|Conflict resolution]]</td><td
valign="top">[[#SEC86|Conflicts example]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX148|Conflicts (merge example)]]</td><td
valign="top">[[#SEC86|Conflicts example]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX4|Contributors (CVS program)]]</td><td
valign="top">[[#SEC2|What is CVS?]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC187|Contributors (manual)]]</td><td
valign="top">[[#SEC187|Credits]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC25|Copying a repository]]</td><td
valign="top">[[#SEC25|Moving a repository]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC54|Copying changes]]</td><td
valign="top">[[#SEC54|Branching and merging]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX236|Correcting a log message]]</td><td
valign="top">[[#SEC121|admin options]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC56|Creating a branch]]</td><td
valign="top">[[#SEC56|Creating a branch]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC38|Creating a project]]</td><td
valign="top">[[#SEC38|Starting a project with CVS]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC23|Creating a repository]]</td><td
valign="top">[[#SEC23|Creating a repository]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX3|Credits (CVS program)]]</td><td
valign="top">[[#SEC2|What is CVS?]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC187|Credits (manual)]]</td><td
valign="top">[[#SEC187|Credits]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC94|CVS 1.6, and watches]]</td><td
valign="top">[[#SEC94|Using watches with old versions of CVS]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC115|CVS command structure]]</td><td
valign="top">[[#SEC115|Overall structure of CVS commands]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC16|CVS directory, in repository]]</td><td
valign="top">[[#SEC16|The CVS directory in the repository]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC19|CVS directory, in working
directory]]</td><td valign="top">[[#SEC19|How data is stored in the working
directory]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX82|CVS passwd file]]</td><td
valign="top">[[#SEC30|Setting up the server for password
authentication]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX2|CVS, history of]]</td><td
valign="top">[[#SEC2|What is CVS?]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC2|CVS, introduction to]]</td><td
valign="top">[[#SEC2|What is CVS?]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC182|CVS, versions of]]</td><td
valign="top">[[#SEC182|Compatibility between CVS Versions]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX54|CVS/Base directory]]</td><td
valign="top">[[#SEC19|How data is stored in the working directory]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX56|CVS/Baserev file]]</td><td
valign="top">[[#SEC19|How data is stored in the working directory]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX58|CVS/Baserev.tmp file]]</td><td
valign="top">[[#SEC19|How data is stored in the working directory]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX38|CVS/Entries file]]</td><td
valign="top">[[#SEC19|How data is stored in the working directory]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX42|CVS/Entries.Backup file]]</td><td
valign="top">[[#SEC19|How data is stored in the working directory]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX40|CVS/Entries.Log file]]</td><td
valign="top">[[#SEC19|How data is stored in the working directory]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX44|CVS/Entries.Static file]]</td><td
valign="top">[[#SEC19|How data is stored in the working directory]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX50|CVS/Notify file]]</td><td
valign="top">[[#SEC19|How data is stored in the working directory]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX52|CVS/Notify.tmp file]]</td><td
valign="top">[[#SEC19|How data is stored in the working directory]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX34|CVS/Repository file]]</td><td
valign="top">[[#SEC19|How data is stored in the working directory]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX19|CVS/Root file]]</td><td
valign="top">[[#SEC10|Telling CVS where your repository is]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX46|CVS/Tag file]]</td><td
valign="top">[[#SEC19|How data is stored in the working directory]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX60|CVS/Template file]]</td><td
valign="top">[[#SEC19|How data is stored in the working directory]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX306|CVS_CLIENT_LOG, environment
variable]]</td><td valign="top">[[#SEC181|All environment variables which
affect CVS]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX87|CVS_CLIENT_PORT]]</td><td
valign="top">[[#SEC34|Direct connection with kerberos]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX308|CVS_IGNORE_REMOTE_ROOT, environment
variable]]</td><td valign="top">[[#SEC181|All environment variables which
affect CVS]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX309|CVS_LOCAL_BRANCH_NUM, environment
variable]]</td><td valign="top">[[#SEC181|All environment variables which
affect CVS]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX85|CVS_PASSFILE, environment
variable]]</td><td valign="top">[[#SEC31|Using the client with password
authentication]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX315|CVS_PID, environment
variable]]</td><td valign="top">[[#SEC181|All environment variables which
affect CVS]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX305|CVS_RCMD_PORT, environment
variable]]</td><td valign="top">[[#SEC181|All environment variables which
affect CVS]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX304|CVS_RSH, environment
variable]]</td><td valign="top">[[#SEC181|All environment variables which
affect CVS]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX89|CVS_SERVER, and :fork:]]</td><td
valign="top">[[#SEC35|Connecting with fork]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX64|CVS_SERVER, environment
variable]]</td><td valign="top">[[#SEC28|Connecting with rsh]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX307|CVS_SERVER_SLEEP, environment
variable]]</td><td valign="top">[[#SEC181|All environment variables which
affect CVS]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX281|CVS_USER, environment
variable]]</td><td valign="top">[[#SEC179|Expansions in administrative
files]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX231|cvsadmin]]</td><td
valign="top">[[#SEC120|admin—Administration]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX9|CVSEDITOR, environment
variable]]</td><td valign="top">[[#SEC6|Committing your changes]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX297|CVSEDITOR, environment
variable]]</td><td valign="top">[[#SEC181|All environment variables which
affect CVS]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX275|CVSEDITOR, internal variable]]</td><td
valign="top">[[#SEC179|Expansions in administrative files]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX183|CVSHeader keyword]]</td><td
valign="top">[[#SEC99|Keyword List]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC176|cvsignore (admin file),
global]]</td><td valign="top">[[#SEC176|Ignoring files via cvsignore]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX292|CVSIGNORE, environment
variable]]</td><td valign="top">[[#SEC181|All environment variables which
affect CVS]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX294|CVSREAD, environment
variable]]</td><td valign="top">[[#SEC181|All environment variables which
affect CVS]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX216|CVSREAD, overriding]]</td><td
valign="top">[[#SEC118|Global options]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX296|CVSREADONLYFS, environment
variable]]</td><td valign="top">[[#SEC181|All environment variables which
affect CVS]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC9|cvsroot]]</td><td
valign="top">[[#SEC9|The Repository]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC157|CVSROOT (file)]]</td><td
valign="top">[[#SEC157|Reference manual for Administrative files]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX17|CVSROOT, environment variable]]</td><td
valign="top">[[#SEC10|Telling CVS where your repository is]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX273|CVSROOT, internal variable]]</td><td
valign="top">[[#SEC179|Expansions in administrative files]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC20|CVSROOT, module name]]</td><td
valign="top">[[#SEC20|The administrative files]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC22|CVSROOT, multiple
repositories]]</td><td valign="top">[[#SEC22|Multiple repositories]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX208|CVSROOT, overriding]]</td><td
valign="top">[[#SEC118|Global options]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC18|CVSROOT, storage of files]]</td><td
valign="top">[[#SEC18|How files are stored in the CVSROOT directory]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC180|CVSROOT/config]]</td><td
valign="top">[[#SEC180|The CVSROOT/config configuration file]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX36|CVSROOT/Emptydir directory]]</td><td
valign="top">[[#SEC19|How data is stored in the working directory]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX22|CVSUMASK, environment
variable]]</td><td valign="top">[[#SEC13|File permissions]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC165|cvswrappers (admin file)]]</td><td
valign="top">[[#SEC165|The cvswrappers file]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC165|CVSWRAPPERS, environment
variable]]</td><td valign="top">[[#SEC165|The cvswrappers file]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX293|CVSWRAPPERS, environment
variable]]</td><td valign="top">[[#SEC181|All environment variables which
affect CVS]]</td></tr>
+<tr><td colspan="3"> <hr></td></tr>
+<tr><th><div id="SEC189_14"></div>D</th><td></td><td></td></tr>
+<tr><td></td><td valign="top">[[#IDX184|Date keyword]]</td><td
valign="top">[[#SEC99|Keyword List]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX221|Dates]]</td><td
valign="top">[[#SEC119|Common command options]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX28|Dead state]]</td><td
valign="top">[[#SEC15|The attic]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC45|Decimal revision number]]</td><td
valign="top">[[#SEC45|Revision numbers]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX263|DEFAULT in commitinfo]]</td><td
valign="top">[[#SEC168|Commitinfo]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX270|DEFAULT in editinfo]]</td><td
valign="top">[[#SEC170|Editinfo]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX267|DEFAULT in
‘<tt>verifymsg</tt>’]]</td><td valign="top">[[#SEC169|Verifying log
messages]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC43|Defining a module]]</td><td
valign="top">[[#SEC43|Defining the module]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC20|Defining modules (intro)]]</td><td
valign="top">[[#SEC20|The administrative files]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC158|Defining modules (reference
manual)]]</td><td valign="top">[[#SEC158|The modules file]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX105|Deleting branch tags]]</td><td
valign="top">[[#SEC51|Deleting, moving, and renaming tags]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC68|Deleting files]]</td><td
valign="top">[[#SEC68|Removing files]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX239|Deleting revisions]]</td><td
valign="top">[[#SEC121|admin options]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX118|Deleting sticky tags]]</td><td
valign="top">[[#SEC53|Sticky tags]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX104|Deleting tags]]</td><td
valign="top">[[#SEC51|Deleting, moving, and renaming tags]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC65|Descending directories]]</td><td
valign="top">[[#SEC65|Recursive behavior]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC113|Device nodes]]</td><td
valign="top">[[#SEC113|Special Files]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC8|Diff]]</td><td
valign="top">[[#SEC8|Viewing differences]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC130|diff (subcommand)]]</td><td
valign="top">[[#SEC130|diff—Show differences between revisions]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC62|Differences, merging]]</td><td
valign="top">[[#SEC62|Merging differences between any two revisions]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC74|Directories, moving]]</td><td
valign="top">[[#SEC74|Moving and renaming directories]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC69|Directories, removing]]</td><td
valign="top">[[#SEC69|Removing directories]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC65|Directory, descending]]</td><td
valign="top">[[#SEC65|Recursive behavior]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC22|Disjoint repositories]]</td><td
valign="top">[[#SEC22|Multiple repositories]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC172|Distributing log messages]]</td><td
valign="top">[[#SEC172|Loginfo]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC86|driver.c (merge example)]]</td><td
valign="top">[[#SEC86|Conflicts example]]</td></tr>
+<tr><td colspan="3"> <hr></td></tr>
+<tr><th><div id="SEC189_15"></div>E</th><td></td><td></td></tr>
+<tr><td></td><td valign="top">[[#IDX173|edit (subcommand)]]</td><td
valign="top">[[#SEC92|How to edit a file which is being watched]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC170|editinfo (admin file)]]</td><td
valign="top">[[#SEC170|Editinfo]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC21|Editing administrative files]]</td><td
valign="top">[[#SEC21|Editing administrative files]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC43|Editing the modules file]]</td><td
valign="top">[[#SEC43|Defining the module]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX227|Editor, avoiding invocation
of]]</td><td valign="top">[[#SEC119|Common command options]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX10|EDITOR, environment variable]]</td><td
valign="top">[[#SEC6|Committing your changes]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX298|EDITOR, environment variable]]</td><td
valign="top">[[#SEC181|All environment variables which affect CVS]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX276|EDITOR, internal variable]]</td><td
valign="top">[[#SEC179|Expansions in administrative files]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX210|EDITOR, overriding]]</td><td
valign="top">[[#SEC118|Global options]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC170|Editor, specifying per
module]]</td><td valign="top">[[#SEC170|Editinfo]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX180|editors (subcommand)]]</td><td
valign="top">[[#SEC93|Information about who is watching and editing]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX156|emerge]]</td><td
valign="top">[[#SEC86|Conflicts example]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX35|Emptydir, in CVSROOT
directory]]</td><td valign="top">[[#SEC19|How data is stored in the working
directory]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX218|Encryption]]</td><td
valign="top">[[#SEC118|Global options]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX37|Entries file, in CVS
directory]]</td><td valign="top">[[#SEC19|How data is stored in the working
directory]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX41|Entries.Backup file, in CVS
directory]]</td><td valign="top">[[#SEC19|How data is stored in the working
directory]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX39|Entries.Log file, in CVS
directory]]</td><td valign="top">[[#SEC19|How data is stored in the working
directory]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX43|Entries.Static file, in CVS
directory]]</td><td valign="top">[[#SEC19|How data is stored in the working
directory]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC181|Environment variables]]</td><td
valign="top">[[#SEC181|All environment variables which affect CVS]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX280|environment variables, passed to
administrative files]]</td><td valign="top">[[#SEC179|Expansions in
administrative files]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX323|Errors, reporting]]</td><td
valign="top">[[#SEC188|Dealing with bugs in CVS or this manual]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC4|Example of a work-session]]</td><td
valign="top">[[#SEC4|A sample session]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC86|Example of merge]]</td><td
valign="top">[[#SEC86|Conflicts example]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX123|Example, branch merge]]</td><td
valign="top">[[#SEC60|Merging an entire branch]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC162|Excluding directories, in modules
file]]</td><td valign="top">[[#SEC162|Excluding directories]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX262|Exit status, of commitinfo]]</td><td
valign="top">[[#SEC168|Commitinfo]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC116|Exit status, of CVS]]</td><td
valign="top">[[#SEC116|CVS’s exit status]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX317|Exit status, of editor]]</td><td
valign="top">[[#SEC184|Partial list of error messages]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX134|Exit status, of taginfo]]</td><td
valign="top">[[#SEC78|User-defined logging]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX268|Exit status, of
‘<tt>verifymsg</tt>’]]</td><td valign="top">[[#SEC169|Verifying log
messages]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC135|export (subcommand)]]</td><td
valign="top">[[#SEC135|export—Export sources from CVS, similar to
checkout]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX252|Export program]]</td><td
valign="top">[[#SEC163|Module options]]</td></tr>
+<tr><td colspan="3"> <hr></td></tr>
+<tr><th><div id="SEC189_16"></div>F</th><td></td><td></td></tr>
+<tr><td></td><td valign="top">[[#SEC5|Fetching source]]</td><td
valign="top">[[#SEC5|Getting the source]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX144|File had conflicts on merge]]</td><td
valign="top">[[#SEC84|File status]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC83|File locking]]</td><td
valign="top">[[#SEC83|Multiple developers]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC13|File permissions, general]]</td><td
valign="top">[[#SEC13|File permissions]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC14|File permissions,
Windows-specific]]</td><td valign="top">[[#SEC14|File Permission issues
specific to Windows]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC84|File status]]</td><td
valign="top">[[#SEC84|File status]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC70|Files, moving]]</td><td
valign="top">[[#SEC70|Moving and renaming files]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC157|Files, reference manual]]</td><td
valign="top">[[#SEC157|Reference manual for Administrative files]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX237|Fixing a log message]]</td><td
valign="top">[[#SEC121|admin options]]</td></tr>
+<tr><td></td><td valign="top">[[#IDX226|Forcing a tag match]]</td><td
valign="top">[[#SEC119|Common command options]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC35|fork, access method]]</td><td
valign="top">[[#SEC35|Connecting with fork]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC175|Form for log message]]</td><td
valign="top">[[#SEC175|Rcsinfo]]</td></tr>
+<tr><td></td><td valign="top">[[#SEC115|Format of CVS commands]]</td><td
valign="top">[[#SEC115|Overall structure of CVS commands]]</td></tr>
+<tr><td c