Merge remaining local changes, correct build issues

10 files changed, 6574 insertions, 4442 deletions

diff --git a/gnu/usr.bin/cvs/configure b/gnu/usr.bin/cvs/configure
index fb4dc86c783..d9861075faf 100644
--- a/gnu/usr.bin/cvs/configure
+++ b/gnu/usr.bin/cvs/configure
@@ -12,6 +12,9 @@ ac_help=
 ac_default_prefix=/usr/local
 # Any additions from configure.in:
 ac_help="$ac_help
+  --disable-dependency-tracking Speeds up one-time builds
+  --enable-dependency-tracking  Do not reject slow dependency extractors"
+ac_help="$ac_help
   --with-krb4=value       set default \$(KRB4) from value"
 ac_help="$ac_help
   --with-gssapi=value     GSSAPI directory"
@@ -533,14 +536,461 @@ else
 fi
 
 
-AM_INIT_AUTOMAKE(cvs, 1.11.1p1)
+ac_aux_dir=
+for ac_dir in $srcdir $srcdir/.. $srcdir/../..; do
+  if test -f $ac_dir/install-sh; then
+    ac_aux_dir=$ac_dir
+    ac_install_sh="$ac_aux_dir/install-sh -c"
+    break
+  elif test -f $ac_dir/install.sh; then
+    ac_aux_dir=$ac_dir
+    ac_install_sh="$ac_aux_dir/install.sh -c"
+    break
+  fi
+done
+if test -z "$ac_aux_dir"; then
+  { echo "configure: error: can not find install-sh or install.sh in $srcdir $srcdir/.. $srcdir/../.." 1>&2; exit 1; }
+fi
+ac_config_guess=$ac_aux_dir/config.guess
+ac_config_sub=$ac_aux_dir/config.sub
+ac_configure=$ac_aux_dir/configure # This should be Cygnus configure.
+
+# Find a good install program.  We prefer a C program (faster),
+# so one script is as good as another.  But avoid the broken or
+# incompatible versions:
+# SysV /etc/install, /usr/sbin/install
+# SunOS /usr/etc/install
+# IRIX /sbin/install
+# AIX /bin/install
+# AIX 4 /usr/bin/installbsd, which doesn't work without a -g flag
+# AFS /usr/afsws/bin/install, which mishandles nonexistent args
+# SVR4 /usr/ucb/install, which tries to use the nonexistent group "staff"
+# ./install, which can be erroneously created by make from ./install.sh.
+echo $ac_n "checking for a BSD compatible install""... $ac_c" 1>&6
+echo "configure:571: checking for a BSD compatible install" >&5
+if test -z "$INSTALL"; then
+if eval "test \"`echo '$''{'ac_cv_path_install'+set}'`\" = set"; then
+  echo $ac_n "(cached) $ac_c" 1>&6
+else
+    IFS="${IFS= 	}"; ac_save_IFS="$IFS"; IFS=":"
+  for ac_dir in $PATH; do
+    # Account for people who put trailing slashes in PATH elements.
+    case "$ac_dir/" in
+    /|./|.//|/etc/*|/usr/sbin/*|/usr/etc/*|/sbin/*|/usr/afsws/bin/*|/usr/ucb/*) ;;
+    *)
+      # OSF1 and SCO ODT 3.0 have their own names for install.
+      # Don't use installbsd from OSF since it installs stuff as root
+      # by default.
+      for ac_prog in ginstall scoinst install; do
+        if test -f $ac_dir/$ac_prog; then
+	  if test $ac_prog = install &&
+            grep dspmsg $ac_dir/$ac_prog >/dev/null 2>&1; then
+	    # AIX install.  It has an incompatible calling convention.
+	    :
+	  else
+	    ac_cv_path_install="$ac_dir/$ac_prog -c"
+	    break 2
+	  fi
+	fi
+      done
+      ;;
+    esac
+  done
+  IFS="$ac_save_IFS"
+
+fi
+  if test "${ac_cv_path_install+set}" = set; then
+    INSTALL="$ac_cv_path_install"
+  else
+    # As a last resort, use the slow shell script.  We don't cache a
+    # path for INSTALL within a source directory, because that will
+    # break other packages using the cache if that directory is
+    # removed, or if the path is relative.
+    INSTALL="$ac_install_sh"
+  fi
+fi
+echo "$ac_t""$INSTALL" 1>&6
+
+# Use test -z because SunOS4 sh mishandles braces in ${var-val}.
+# It thinks the first close brace ends the variable substitution.
+test -z "$INSTALL_PROGRAM" && INSTALL_PROGRAM='${INSTALL}'
+
+test -z "$INSTALL_SCRIPT" && INSTALL_SCRIPT='${INSTALL_PROGRAM}'
+
+test -z "$INSTALL_DATA" && INSTALL_DATA='${INSTALL} -m 644'
+
+echo $ac_n "checking whether build environment is sane""... $ac_c" 1>&6
+echo "configure:624: checking whether build environment is sane" >&5
+# Just in case
+sleep 1
+echo timestamp > conftest.file
+# Do `set' in a subshell so we don't clobber the current shell's
+# arguments.  Must try -L first in case configure is actually a
+# symlink; some systems play weird games with the mod time of symlinks
+# (eg FreeBSD returns the mod time of the symlink's containing
+# directory).
+if (
+   set X `ls -Lt $srcdir/configure conftest.file 2> /dev/null`
+   if test "$*" = "X"; then
+      # -L didn't work.
+      set X `ls -t $srcdir/configure conftest.file`
+   fi
+   if test "$*" != "X $srcdir/configure conftest.file" \
+      && test "$*" != "X conftest.file $srcdir/configure"; then
+
+      # If neither matched, then we have a broken ls.  This can happen
+      # if, for instance, CONFIG_SHELL is bash and it inherits a
+      # broken ls alias from the environment.  This has actually
+      # happened.  Such a system could not be considered "sane".
+      { echo "configure: error: ls -t appears to fail.  Make sure there is not a broken
+alias in your environment" 1>&2; exit 1; }
+   fi
+
+   test "$2" = conftest.file
+   )
+then
+   # Ok.
+   :
+else
+   { echo "configure: error: newly created file is older than distributed files!
+Check your system clock" 1>&2; exit 1; }
+fi
+rm -f conftest*
+echo "$ac_t""yes" 1>&6
+if test "$program_transform_name" = s,x,x,; then
+  program_transform_name=
+else
+  # Double any \ or $.  echo might interpret backslashes.
+  cat <<\EOF_SED > conftestsed
+s,\\,\\\\,g; s,\$,$$,g
+EOF_SED
+  program_transform_name="`echo $program_transform_name|sed -f conftestsed`"
+  rm -f conftestsed
+fi
+test "$program_prefix" != NONE &&
+  program_transform_name="s,^,${program_prefix},; $program_transform_name"
+# Use a double $ so make ignores it.
+test "$program_suffix" != NONE &&
+  program_transform_name="s,\$\$,${program_suffix},; $program_transform_name"
+
+# sed with no file args requires a program.
+test "$program_transform_name" = "" && program_transform_name="s,x,x,"
+
+test x"${MISSING+set}" = xset ||
+  MISSING="\${SHELL} `CDPATH=:; cd $ac_aux_dir && pwd`/missing"
+# Use eval to expand $SHELL
+if eval "$MISSING --run true"; then
+  am_missing_run="$MISSING --run "
+else
+  am_missing_run=
+  am_backtick='`'
+  echo "configure: warning: ${am_backtick}missing' script is too old or missing" 1>&2
+fi
+
+for ac_prog in mawk gawk nawk awk
+do
+# Extract the first word of "$ac_prog", so it can be a program name with args.
+set dummy $ac_prog; ac_word=$2
+echo $ac_n "checking for $ac_word""... $ac_c" 1>&6
+echo "configure:696: checking for $ac_word" >&5
+if eval "test \"`echo '$''{'ac_cv_prog_AWK'+set}'`\" = set"; then
+  echo $ac_n "(cached) $ac_c" 1>&6
+else
+  if test -n "$AWK"; then
+  ac_cv_prog_AWK="$AWK" # Let the user override the test.
+else
+  IFS="${IFS= 	}"; ac_save_ifs="$IFS"; IFS=":"
+  ac_dummy="$PATH"
+  for ac_dir in $ac_dummy; do
+    test -z "$ac_dir" && ac_dir=.
+    if test -f $ac_dir/$ac_word; then
+      ac_cv_prog_AWK="$ac_prog"
+      break
+    fi
+  done
+  IFS="$ac_save_ifs"
+fi
+fi
+AWK="$ac_cv_prog_AWK"
+if test -n "$AWK"; then
+  echo "$ac_t""$AWK" 1>&6
+else
+  echo "$ac_t""no" 1>&6
+fi
+
+test -n "$AWK" && break
+done
+
+echo $ac_n "checking whether ${MAKE-make} sets \${MAKE}""... $ac_c" 1>&6
+echo "configure:726: checking whether ${MAKE-make} sets \${MAKE}" >&5
+set dummy ${MAKE-make}; ac_make=`echo "$2" | sed 'y%./+-%__p_%'`
+if eval "test \"`echo '$''{'ac_cv_prog_make_${ac_make}_set'+set}'`\" = set"; then
+  echo $ac_n "(cached) $ac_c" 1>&6
+else
+  cat > conftestmake <<\EOF
+all:
+	@echo 'ac_maketemp="${MAKE}"'
+EOF
+# GNU make sometimes prints "make[1]: Entering...", which would confuse us.
+eval `${MAKE-make} -f conftestmake 2>/dev/null | grep temp=`
+if test -n "$ac_maketemp"; then
+  eval ac_cv_prog_make_${ac_make}_set=yes
+else
+  eval ac_cv_prog_make_${ac_make}_set=no
+fi
+rm -f conftestmake
+fi
+if eval "test \"`echo '$ac_cv_prog_make_'${ac_make}_set`\" = yes"; then
+  echo "$ac_t""yes" 1>&6
+  SET_MAKE=
+else
+  echo "$ac_t""no" 1>&6
+  SET_MAKE="MAKE=${MAKE-make}"
+fi
+
+# Extract the first word of "etags", so it can be a program name with args.
+set dummy etags; ac_word=$2
+echo $ac_n "checking for $ac_word""... $ac_c" 1>&6
+echo "configure:755: checking for $ac_word" >&5
+if eval "test \"`echo '$''{'ac_cv_prog_ETAGS'+set}'`\" = set"; then
+  echo $ac_n "(cached) $ac_c" 1>&6
+else
+  if test -n "$ETAGS"; then
+  ac_cv_prog_ETAGS="$ETAGS" # Let the user override the test.
+else
+  IFS="${IFS= 	}"; ac_save_ifs="$IFS"; IFS=":"
+  ac_dummy="$PATH"
+  for ac_dir in $ac_dummy; do
+    test -z "$ac_dir" && ac_dir=.
+    if test -f $ac_dir/$ac_word; then
+      ac_cv_prog_ETAGS="etags"
+      break
+    fi
+  done
+  IFS="$ac_save_ifs"
+fi
+fi
+ETAGS="$ac_cv_prog_ETAGS"
+if test -n "$ETAGS"; then
+  echo "$ac_t""$ETAGS" 1>&6
+else
+  echo "$ac_t""no" 1>&6
+fi
+
+if test -z "$ETAGS"; then
+  # Extract the first word of "ctags", so it can be a program name with args.
+set dummy ctags; ac_word=$2
+echo $ac_n "checking for $ac_word""... $ac_c" 1>&6
+echo "configure:785: checking for $ac_word" >&5
+if eval "test \"`echo '$''{'ac_cv_prog_ETAGS'+set}'`\" = set"; then
+  echo $ac_n "(cached) $ac_c" 1>&6
+else
+  if test -n "$ETAGS"; then
+  ac_cv_prog_ETAGS="$ETAGS" # Let the user override the test.
+else
+  IFS="${IFS= 	}"; ac_save_ifs="$IFS"; IFS=":"
+  ac_dummy="$PATH"
+  for ac_dir in $ac_dummy; do
+    test -z "$ac_dir" && ac_dir=.
+    if test -f $ac_dir/$ac_word; then
+      ac_cv_prog_ETAGS="ctags -e"
+      break
+    fi
+  done
+  IFS="$ac_save_ifs"
+fi
+fi
+ETAGS="$ac_cv_prog_ETAGS"
+if test -n "$ETAGS"; then
+  echo "$ac_t""$ETAGS" 1>&6
+else
+  echo "$ac_t""no" 1>&6
+fi
+
+fi
+if test -n "$ETAGS"; then
+	echo $ac_n "checking whether ${ETAGS-etags} works""... $ac_c" 1>&6
+echo "configure:814: checking whether ${ETAGS-etags} works" >&5
+if eval "test \"`echo '$''{'am_cv_prog_etags_works'+set}'`\" = set"; then
+  echo $ac_n "(cached) $ac_c" 1>&6
+else
+  cat >conftest.c <<EOF
+int globalvar;
+EOF
+if { ac_try='${ETAGS-etags} -f - conftest.c |egrep ^int\ globalvar\; >&2'; { (eval echo configure:821: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }; }; then
+	am_cv_prog_etags_works=yes
+else
+	am_cv_prog_etags_works=no
+fi
+rm -f conftest.c
+fi
+
+echo "$ac_t""$am_cv_prog_etags_works" 1>&6
+	if test "$am_cv_prog_etags_works" = yes ; then
+		if test "$am_cv_prog_etags_works" = yes ; then
+	echo $ac_n "checking for etags include option""... $ac_c" 1>&6
+echo "configure:833: checking for etags include option" >&5
+if eval "test \"`echo '$''{'am_cv_prog_etags_include_option'+set}'`\" = set"; then
+  echo $ac_n "(cached) $ac_c" 1>&6
+else
+  cat >conftest.c <<EOF
+int globalvar;
+EOF
+	if { ac_try='${ETAGS-etags} --etags-include=TAGS.inc -f - conftest.c |egrep ^TAGS.inc,include\$ >&2'; { (eval echo configure:840: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }; }; then
+		am_cv_prog_etags_include_option=--etags-include=
+	elif { ac_try='${ETAGS-etags} -i TAGS.inc -f - conftest.c |egrep ^TAGS.inc,include\$ >&2'; { (eval echo configure:842: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }; }; then
+		am_cv_prog_etags_include_option='"-i "'
+	else :
+		# AC_MSG_ERROR(unfamiliar etags implementation)
+	fi
+	rm -f conftest.c
+fi
+
+echo "$ac_t""$am_cv_prog_etags_include_option" 1>&6
+else
+	:
+fi
+ETAGS_INCLUDE_OPTION="$am_cv_prog_etags_include_option"
+
+	else
+		
+ETAGS=${ETAGS-"${am_missing_run}etags"}
+
+	fi
+else
+	
+ETAGS=${ETAGS-"${am_missing_run}etags"}
+
+fi
+# Check whether --enable-dependency-tracking or --disable-dependency-tracking was given.
+if test "${enable_dependency_tracking+set}" = set; then
+  enableval="$enable_dependency_tracking"
+  :
+fi
+
+if test "x$enable_dependency_tracking" != xno; then
+  am_depcomp="$ac_aux_dir/depcomp"
+  AMDEPBACKSLASH='\'
+fi
+
+
+if test "x$enable_dependency_tracking" != xno; then
+  AMDEP_TRUE=
+  AMDEP_FALSE='#'
+else
+  AMDEP_TRUE='#'
+  AMDEP_FALSE=
+fi
+
+
+
+
+if test -d .deps || mkdir .deps 2> /dev/null || test -d .deps; then
+  DEPDIR=.deps
+  # We redirect because .deps might already exist and be populated.
+  # In this situation we don't want to see an error.
+  rmdir .deps > /dev/null 2>&1
+else
+  DEPDIR=_deps
+fi
+
+
+# test to see if srcdir already configured
+if test "`CDPATH=:; cd $srcdir && pwd`" != "`pwd`" &&
+   test -f $srcdir/config.status; then
+  { echo "configure: error: source directory already configured; run \"make distclean\" there first" 1>&2; exit 1; }
+fi
+
+# Define the identity of the package.
+PACKAGE=cvs
+VERSION=1.11.1p1
+cat >> confdefs.h <<EOF
+#define PACKAGE "$PACKAGE"
+EOF
+
+cat >> confdefs.h <<EOF
+#define VERSION "$VERSION"
+EOF
+
+
+# Autoconf 2.50 wants to disallow AM_ names.  We explicitly allow
+# the ones we care about.
+
+# Some tools Automake needs.
+
+ACLOCAL=${ACLOCAL-"${am_missing_run}aclocal"}
+
+
+AUTOCONF=${AUTOCONF-"${am_missing_run}autoconf"}
+
+
+AUTOMAKE=${AUTOMAKE-"${am_missing_run}automake"}
+
+
+AUTOHEADER=${AUTOHEADER-"${am_missing_run}autoheader"}
+
+
+MAKEINFO=${MAKEINFO-"${am_missing_run}makeinfo"}
+
+
+AMTAR=${AMTAR-"${am_missing_run}tar"}
+
+
+if test -z "$install_sh"; then
+   for install_sh in "$ac_aux_dir/install-sh" \
+                     "$ac_aux_dir/install.sh" \
+                     "${am_missing_run}${ac_auxdir}/install-sh";
+   do
+     test -f "$install_sh" && break
+   done
+   # FIXME: an evil hack: we remove the SHELL invocation from
+   # install_sh because automake adds it back in.  Sigh.
+   install_sh=`echo $install_sh | sed -e 's/\${SHELL}//'`
+fi
+
+
+# We'd like to do this but we can't because it will unconditionally
+# require config.guess.  One way would be if autoconf had the capability
+# to let us compile in this code only when config.guess was already
+# a possibility.
+#if test "$cross_compiling" != no; then
+#  # since we are cross-compiling, we need to check for a suitable `strip'
+#  AM_PROG_STRIP
+#  if test -z "$STRIP"; then
+#    AC_MSG_WARN([strip missing, install-strip will not strip binaries])
+#  fi
+#fi
+
+# If $STRIP is defined (either by the user, or by AM_PROG_STRIP),
+# instruct install-strip to use install-sh and the given $STRIP program.
+# Otherwise, just use ${INSTALL}: the idea is to use the vendor install
+# as much as possible, because it's faster.
+if test -z "$STRIP"; then
+  # The top level make will set INSTALL_PROGRAM=$(INSTALL_STRIP_PROGRAM)
+  # and the double dolard below is there to make sure that ${INSTALL}
+  # is substitued in the sub-makes, not at the top-level; this is
+  # needed if ${INSTALL} is a relative path (ajusted in each subdirectory
+  # by config.status).
+  INSTALL_STRIP_PROGRAM='$${INSTALL} -s'
+  INSTALL_STRIP_PROGRAM_ENV=''
+else
+  _am_dirpart="`echo $install_sh | sed -e 's,//*[^/]*$,,'`"
+  INSTALL_STRIP_PROGRAM="\${SHELL} \`CDPATH=: && cd $_am_dirpart && pwd\`/install-sh -c -s"
+  INSTALL_STRIP_PROGRAM_ENV="STRIPPROG='\$(STRIP)'"
+fi
+
+
+
+# We need awk for the "check" target.  The system "awk" is bad on
+# some platforms.
+
 
 if test "x$prefix" = xNONE; then
 echo $ac_n "checking for prefix by $ac_c" 1>&6
 # Extract the first word of "cvs", so it can be a program name with args.
 set dummy cvs; ac_word=$2
 echo $ac_n "checking for $ac_word""... $ac_c" 1>&6
-echo "configure:544: checking for $ac_word" >&5
+echo "configure:994: checking for $ac_word" >&5
 if eval "test \"`echo '$''{'ac_cv_path_CVS'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
@@ -577,14 +1027,16 @@ fi
   fi
 fi
 
-AM_CONFIG_HEADER(config.h src/options.h)
+
+  
+
 
 for ac_prog in mawk gawk nawk awk
 do
 # Extract the first word of "$ac_prog", so it can be a program name with args.
 set dummy $ac_prog; ac_word=$2
 echo $ac_n "checking for $ac_word""... $ac_c" 1>&6
-echo "configure:588: checking for $ac_word" >&5
+echo "configure:1040: checking for $ac_word" >&5
 if eval "test \"`echo '$''{'ac_cv_prog_AWK'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
@@ -616,7 +1068,7 @@ done
 # Extract the first word of "gcc", so it can be a program name with args.
 set dummy gcc; ac_word=$2
 echo $ac_n "checking for $ac_word""... $ac_c" 1>&6
-echo "configure:620: checking for $ac_word" >&5
+echo "configure:1072: checking for $ac_word" >&5
 if eval "test \"`echo '$''{'ac_cv_prog_CC'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
@@ -646,7 +1098,7 @@ if test -z "$CC"; then
   # Extract the first word of "cc", so it can be a program name with args.
 set dummy cc; ac_word=$2
 echo $ac_n "checking for $ac_word""... $ac_c" 1>&6
-echo "configure:650: checking for $ac_word" >&5
+echo "configure:1102: checking for $ac_word" >&5
 if eval "test \"`echo '$''{'ac_cv_prog_CC'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
@@ -697,7 +1149,7 @@ fi
       # Extract the first word of "cl", so it can be a program name with args.
 set dummy cl; ac_word=$2
 echo $ac_n "checking for $ac_word""... $ac_c" 1>&6
-echo "configure:701: checking for $ac_word" >&5
+echo "configure:1153: checking for $ac_word" >&5
 if eval "test \"`echo '$''{'ac_cv_prog_CC'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
@@ -729,7 +1181,7 @@ fi
 fi
 
 echo $ac_n "checking whether the C compiler ($CC $CFLAGS $LDFLAGS) works""... $ac_c" 1>&6
-echo "configure:733: checking whether the C compiler ($CC $CFLAGS $LDFLAGS) works" >&5
+echo "configure:1185: checking whether the C compiler ($CC $CFLAGS $LDFLAGS) works" >&5
 
 ac_ext=c
 # CFLAGS is not in ac_cpp because -g, -O, etc. are not valid cpp options.
@@ -740,12 +1192,12 @@ cross_compiling=$ac_cv_prog_cc_cross
 
 cat > conftest.$ac_ext << EOF
 
-#line 744 "configure"
+#line 1196 "configure"
 #include "confdefs.h"
 
 main(){return(0);}
 EOF
-if { (eval echo configure:749: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
+if { (eval echo configure:1201: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
   ac_cv_prog_cc_works=yes
   # If we can't run a trivial program, we are probably using a cross compiler.
   if (./conftest; exit) 2>/dev/null; then
@@ -771,12 +1223,12 @@ if test $ac_cv_prog_cc_works = no; then
   { echo "configure: error: installation or configuration problem: C compiler cannot create executables." 1>&2; exit 1; }
 fi
 echo $ac_n "checking whether the C compiler ($CC $CFLAGS $LDFLAGS) is a cross-compiler""... $ac_c" 1>&6
-echo "configure:775: checking whether the C compiler ($CC $CFLAGS $LDFLAGS) is a cross-compiler" >&5
+echo "configure:1227: checking whether the C compiler ($CC $CFLAGS $LDFLAGS) is a cross-compiler" >&5
 echo "$ac_t""$ac_cv_prog_cc_cross" 1>&6
 cross_compiling=$ac_cv_prog_cc_cross
 
 echo $ac_n "checking whether we are using GNU C""... $ac_c" 1>&6
-echo "configure:780: checking whether we are using GNU C" >&5
+echo "configure:1232: checking whether we are using GNU C" >&5
 if eval "test \"`echo '$''{'ac_cv_prog_gcc'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
@@ -785,7 +1237,7 @@ else
   yes;
 #endif
 EOF
-if { ac_try='${CC-cc} -E conftest.c'; { (eval echo configure:789: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }; } | egrep yes >/dev/null 2>&1; then
+if { ac_try='${CC-cc} -E conftest.c'; { (eval echo configure:1241: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }; } | egrep yes >/dev/null 2>&1; then
   ac_cv_prog_gcc=yes
 else
   ac_cv_prog_gcc=no
@@ -804,7 +1256,7 @@ ac_test_CFLAGS="${CFLAGS+set}"
 ac_save_CFLAGS="$CFLAGS"
 CFLAGS=
 echo $ac_n "checking whether ${CC-cc} accepts -g""... $ac_c" 1>&6
-echo "configure:808: checking whether ${CC-cc} accepts -g" >&5
+echo "configure:1260: checking whether ${CC-cc} accepts -g" >&5
 if eval "test \"`echo '$''{'ac_cv_prog_cc_g'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
@@ -835,24 +1287,186 @@ else
   fi
 fi
 
-ac_aux_dir=
-for ac_dir in $srcdir $srcdir/.. $srcdir/../..; do
-  if test -f $ac_dir/install-sh; then
-    ac_aux_dir=$ac_dir
-    ac_install_sh="$ac_aux_dir/install-sh -c"
-    break
-  elif test -f $ac_dir/install.sh; then
-    ac_aux_dir=$ac_dir
-    ac_install_sh="$ac_aux_dir/install.sh -c"
-    break
-  fi
-done
-if test -z "$ac_aux_dir"; then
-  { echo "configure: error: can not find install-sh or install.sh in $srcdir $srcdir/.. $srcdir/../.." 1>&2; exit 1; }
+
+echo $ac_n "checking how to run the C preprocessor""... $ac_c" 1>&6
+echo "configure:1293: checking how to run the C preprocessor" >&5
+# On Suns, sometimes $CPP names a directory.
+if test -n "$CPP" && test -d "$CPP"; then
+  CPP=
 fi
-ac_config_guess=$ac_aux_dir/config.guess
-ac_config_sub=$ac_aux_dir/config.sub
-ac_configure=$ac_aux_dir/configure # This should be Cygnus configure.
+if test -z "$CPP"; then
+if eval "test \"`echo '$''{'ac_cv_prog_CPP'+set}'`\" = set"; then
+  echo $ac_n "(cached) $ac_c" 1>&6
+else
+    # This must be in double quotes, not single quotes, because CPP may get
+  # substituted into the Makefile and "${CC-cc}" will confuse make.
+  CPP="${CC-cc} -E"
+  # On the NeXT, cc -E runs the code through the compiler's parser,
+  # not just through cpp.
+  cat > conftest.$ac_ext <<EOF
+#line 1308 "configure"
+#include "confdefs.h"
+#include <assert.h>
+Syntax Error
+EOF
+ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out"
+{ (eval echo configure:1314: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }
+ac_err=`grep -v '^ *+' conftest.out | grep -v "^conftest.${ac_ext}\$"`
+if test -z "$ac_err"; then
+  :
+else
+  echo "$ac_err" >&5
+  echo "configure: failed program was:" >&5
+  cat conftest.$ac_ext >&5
+  rm -rf conftest*
+  CPP="${CC-cc} -E -traditional-cpp"
+  cat > conftest.$ac_ext <<EOF
+#line 1325 "configure"
+#include "confdefs.h"
+#include <assert.h>
+Syntax Error
+EOF
+ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out"
+{ (eval echo configure:1331: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }
+ac_err=`grep -v '^ *+' conftest.out | grep -v "^conftest.${ac_ext}\$"`
+if test -z "$ac_err"; then
+  :
+else
+  echo "$ac_err" >&5
+  echo "configure: failed program was:" >&5
+  cat conftest.$ac_ext >&5
+  rm -rf conftest*
+  CPP="${CC-cc} -nologo -E"
+  cat > conftest.$ac_ext <<EOF
+#line 1342 "configure"
+#include "confdefs.h"
+#include <assert.h>
+Syntax Error
+EOF
+ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out"
+{ (eval echo configure:1348: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }
+ac_err=`grep -v '^ *+' conftest.out | grep -v "^conftest.${ac_ext}\$"`
+if test -z "$ac_err"; then
+  :
+else
+  echo "$ac_err" >&5
+  echo "configure: failed program was:" >&5
+  cat conftest.$ac_ext >&5
+  rm -rf conftest*
+  CPP=/lib/cpp
+fi
+rm -f conftest*
+fi
+rm -f conftest*
+fi
+rm -f conftest*
+  ac_cv_prog_CPP="$CPP"
+fi
+  CPP="$ac_cv_prog_CPP"
+else
+  ac_cv_prog_CPP="$CPP"
+fi
+echo "$ac_t""$CPP" 1>&6
+
+am_make=${MAKE-make}
+cat > confinc << 'END'
+doit:
+	@echo done
+END
+# If we don't find an include directive, just comment out the code.
+echo $ac_n "checking for style of include used by $am_make""... $ac_c" 1>&6
+echo "configure:1379: checking for style of include used by $am_make" >&5
+_am_include='#'
+_am_quote=
+_am_result=none
+# First try GNU make style include.
+echo "include confinc" > confmf
+if test "`$am_make -s -f confmf 2> /dev/null`" = "done"; then
+   _am_include=include
+   _am_quote=
+   _am_result=GNU
+fi
+# Now try BSD make style include.
+if test "$_am_include" = "#"; then
+   echo '.include "confinc"' > confmf
+   if test "`$am_make -s -f confmf 2> /dev/null`" = "done"; then
+      _am_include=.include
+      _am_quote='"'
+      _am_result=BSD
+   fi
+fi
+
+
+echo "$ac_t""$_am_result" 1>&6
+rm -f confinc confmf
+
+
+depcc="$CC"
+depcpp="$CPP"
+
+
+
+echo $ac_n "checking dependency style of $depcc""... $ac_c" 1>&6
+echo "configure:1411: checking dependency style of $depcc" >&5
+if eval "test \"`echo '$''{'am_cv_CC_dependencies_compiler_type'+set}'`\" = set"; then
+  echo $ac_n "(cached) $ac_c" 1>&6
+else
+  if test -z "$AMDEP"; then
+  # We make a subdir and do the tests there.  Otherwise we can end up
+  # making bogus files that we don't know about and never remove.  For
+  # instance it was reported that on HP-UX the gcc test will end up
+  # making a dummy file named `D' -- because `-MD' means `put the output
+  # in D'.
+  mkdir confdir
+  # Copy depcomp to subdir because otherwise we won't find it if we're
+  # using a relative directory.
+  cp "$am_depcomp" confdir
+  cd confdir
+
+  am_cv_CC_dependencies_compiler_type=none
+  for depmode in `sed -n 's/^#*\([a-zA-Z0-9]*\))$/\1/p' < "./depcomp"`; do
+    # We need to recreate these files for each test, as the compiler may
+    # overwrite some of them when testing with obscure command lines.
+    # This happens at least with the AIX C compiler.
+    echo '#include "conftest.h"' > conftest.c
+    echo 'int i;' > conftest.h
+
+    case "$depmode" in
+    nosideeffect)
+      # after this tag, mechanisms are not by side-effect, so they'll
+      # only be used when explicitly requested
+      if test "x$enable_dependency_tracking" = xyes; then
+	continue
+      else
+	break
+      fi
+      ;;
+    none) break ;;
+    esac
+    # We check with `-c' and `-o' for the sake of the "dashmstdout"
+    # mode.  It turns out that the SunPro C++ compiler does not properly
+    # handle `-M -o', and we need to detect this.
+    if depmode="$depmode" \
+       source=conftest.c object=conftest.o \
+       depfile=conftest.Po tmpdepfile=conftest.TPo \
+       $SHELL ./depcomp $depcc -c conftest.c -o conftest.o >/dev/null 2>&1 &&
+       grep conftest.h conftest.Po > /dev/null 2>&1; then
+      am_cv_CC_dependencies_compiler_type="$depmode"
+      break
+    fi
+  done
+
+  cd ..
+  rm -rf confdir
+else
+  am_cv_CC_dependencies_compiler_type=none
+fi
+
+fi
+
+echo "$ac_t""$am_cv_CC_dependencies_compiler_type" 1>&6
+CCDEPMODE="depmode=$am_cv_CC_dependencies_compiler_type"
+
 
 # Find a good install program.  We prefer a C program (faster),
 # so one script is as good as another.  But avoid the broken or
@@ -866,7 +1480,7 @@ ac_configure=$ac_aux_dir/configure # This should be Cygnus configure.
 # SVR4 /usr/ucb/install, which tries to use the nonexistent group "staff"
 # ./install, which can be erroneously created by make from ./install.sh.
 echo $ac_n "checking for a BSD compatible install""... $ac_c" 1>&6
-echo "configure:870: checking for a BSD compatible install" >&5
+echo "configure:1484: checking for a BSD compatible install" >&5
 if test -z "$INSTALL"; then
 if eval "test \"`echo '$''{'ac_cv_path_install'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
@@ -919,7 +1533,7 @@ test -z "$INSTALL_SCRIPT" && INSTALL_SCRIPT='${INSTALL_PROGRAM}'
 test -z "$INSTALL_DATA" && INSTALL_DATA='${INSTALL} -m 644'
 
 echo $ac_n "checking whether ${MAKE-make} sets \${MAKE}""... $ac_c" 1>&6
-echo "configure:923: checking whether ${MAKE-make} sets \${MAKE}" >&5
+echo "configure:1537: checking whether ${MAKE-make} sets \${MAKE}" >&5
 set dummy ${MAKE-make}; ac_make=`echo "$2" | sed 'y%./+-%__p_%'`
 if eval "test \"`echo '$''{'ac_cv_prog_make_${ac_make}_set'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
@@ -949,7 +1563,7 @@ fi
 # Extract the first word of "ranlib", so it can be a program name with args.
 set dummy ranlib; ac_word=$2
 echo $ac_n "checking for $ac_word""... $ac_c" 1>&6
-echo "configure:953: checking for $ac_word" >&5
+echo "configure:1567: checking for $ac_word" >&5
 if eval "test \"`echo '$''{'ac_cv_prog_RANLIB'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
@@ -981,7 +1595,7 @@ do
 # Extract the first word of "$ac_prog", so it can be a program name with args.
 set dummy $ac_prog; ac_word=$2
 echo $ac_n "checking for $ac_word""... $ac_c" 1>&6
-echo "configure:985: checking for $ac_word" >&5
+echo "configure:1599: checking for $ac_word" >&5
 if eval "test \"`echo '$''{'ac_cv_prog_YACC'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
@@ -1012,7 +1626,7 @@ done
 test -n "$YACC" || YACC="yacc"
 
 echo $ac_n "checking whether ln -s works""... $ac_c" 1>&6
-echo "configure:1016: checking whether ln -s works" >&5
+echo "configure:1630: checking whether ln -s works" >&5
 if eval "test \"`echo '$''{'ac_cv_prog_LN_S'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
@@ -1036,7 +1650,7 @@ fi
 # Extract the first word of "perl", so it can be a program name with args.
 set dummy perl; ac_word=$2
 echo $ac_n "checking for $ac_word""... $ac_c" 1>&6
-echo "configure:1040: checking for $ac_word" >&5
+echo "configure:1654: checking for $ac_word" >&5
 if eval "test \"`echo '$''{'ac_cv_path_PERL'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
@@ -1072,7 +1686,7 @@ fi
 # Extract the first word of "csh", so it can be a program name with args.
 set dummy csh; ac_word=$2
 echo $ac_n "checking for $ac_word""... $ac_c" 1>&6
-echo "configure:1076: checking for $ac_word" >&5
+echo "configure:1690: checking for $ac_word" >&5
 if eval "test \"`echo '$''{'ac_cv_path_CSH'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
@@ -1108,7 +1722,7 @@ fi
 # Extract the first word of "pr", so it can be a program name with args.
 set dummy pr; ac_word=$2
 echo $ac_n "checking for $ac_word""... $ac_c" 1>&6
-echo "configure:1112: checking for $ac_word" >&5
+echo "configure:1726: checking for $ac_word" >&5
 if eval "test \"`echo '$''{'ac_cv_path_PR'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
@@ -1156,7 +1770,7 @@ do
 # Extract the first word of "$ac_prog", so it can be a program name with args.
 set dummy $ac_prog; ac_word=$2
 echo $ac_n "checking for $ac_word""... $ac_c" 1>&6
-echo "configure:1160: checking for $ac_word" >&5
+echo "configure:1774: checking for $ac_word" >&5
 if eval "test \"`echo '$''{'ac_cv_path_ROFF'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
@@ -1195,7 +1809,7 @@ test -n "$ROFF" || ROFF="$missing_dir/missing roff"
 # Extract the first word of "ps2pdf", so it can be a program name with args.
 set dummy ps2pdf; ac_word=$2
 echo $ac_n "checking for $ac_word""... $ac_c" 1>&6
-echo "configure:1199: checking for $ac_word" >&5
+echo "configure:1813: checking for $ac_word" >&5
 if eval "test \"`echo '$''{'ac_cv_path_PS2PDF'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
@@ -1231,7 +1845,7 @@ fi
 # Extract the first word of "texi2dvi", so it can be a program name with args.
 set dummy texi2dvi; ac_word=$2
 echo $ac_n "checking for $ac_word""... $ac_c" 1>&6
-echo "configure:1235: checking for $ac_word" >&5
+echo "configure:1849: checking for $ac_word" >&5
 if eval "test \"`echo '$''{'ac_cv_path_TEXI2DVI'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
@@ -1268,7 +1882,7 @@ fi
 # Pull the hash mark out of the macro call to avoid m4 problems.
 ac_msg="whether #! works in shell scripts"
 echo $ac_n "checking $ac_msg""... $ac_c" 1>&6
-echo "configure:1272: checking $ac_msg" >&5
+echo "configure:1886: checking $ac_msg" >&5
 if eval "test \"`echo '$''{'ac_cv_sys_interpreter'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
@@ -1296,12 +1910,12 @@ fi
 
 # BSD's logo is a devil for a reason, hey?
 echo $ac_n "checking for BSD VPATH bug in make""... $ac_c" 1>&6
-echo "configure:1300: checking for BSD VPATH bug in make" >&5
+echo "configure:1914: checking for BSD VPATH bug in make" >&5
 if eval "test \"`echo '$''{'ccvs_cv_bsd_make_vpath_bug'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
   if test ! -d ac_test_dir ; then
-	{ ac_try='mkdir ac_test_dir'; { (eval echo configure:1305: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }; }
+	{ ac_try='mkdir ac_test_dir'; { (eval echo configure:1919: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }; }
 fi
 cat >conftestmake <<EOF
 VPATH = ac_test_dir
@@ -1315,104 +1929,32 @@ touch ac_test_target
 # Don't know why, but the following test doesn't work under FreeBSD 4.2
 # without this sleep command
 sleep 1
-if { ac_try='make -f conftestmake 2>&1 >/dev/null |grep ^BSD\ VPATH\ bug\ present\$ >/dev/null'; { (eval echo configure:1319: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }; } ; then
+if { ac_try='make -f conftestmake 2>&1 >/dev/null |grep ^BSD\ VPATH\ bug\ present\$ >/dev/null'; { (eval echo configure:1933: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }; } ; then
 	ccvs_cv_bsd_make_vpath_bug=yes
 else
 	ccvs_cv_bsd_make_vpath_bug=no
 fi
-{ ac_try='rm -rf ac_test_dir ac_test_target conftestmake'; { (eval echo configure:1324: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }; }
+{ ac_try='rm -rf ac_test_dir ac_test_target conftestmake'; { (eval echo configure:1938: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }; }
 fi
 
 echo "$ac_t""$ccvs_cv_bsd_make_vpath_bug" 1>&6
 # We also don't need to worry about the bug when $srcdir = $builddir
-AM_CONDITIONAL(MAKE_TARGETS_IN_VPATH, \
-		test $ccvs_cv_bsd_make_vpath_bug = no \
-		|| test $srcdir = .)
 
-echo $ac_n "checking how to run the C preprocessor""... $ac_c" 1>&6
-echo "configure:1334: checking how to run the C preprocessor" >&5
-# On Suns, sometimes $CPP names a directory.
-if test -n "$CPP" && test -d "$CPP"; then
-  CPP=
-fi
-if test -z "$CPP"; then
-if eval "test \"`echo '$''{'ac_cv_prog_CPP'+set}'`\" = set"; then
-  echo $ac_n "(cached) $ac_c" 1>&6
-else
-    # This must be in double quotes, not single quotes, because CPP may get
-  # substituted into the Makefile and "${CC-cc}" will confuse make.
-  CPP="${CC-cc} -E"
-  # On the NeXT, cc -E runs the code through the compiler's parser,
-  # not just through cpp.
-  cat > conftest.$ac_ext <<EOF
-#line 1349 "configure"
-#include "confdefs.h"
-#include <assert.h>
-Syntax Error
-EOF
-ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out"
-{ (eval echo configure:1355: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }
-ac_err=`grep -v '^ *+' conftest.out | grep -v "^conftest.${ac_ext}\$"`
-if test -z "$ac_err"; then
-  :
-else
-  echo "$ac_err" >&5
-  echo "configure: failed program was:" >&5
-  cat conftest.$ac_ext >&5
-  rm -rf conftest*
-  CPP="${CC-cc} -E -traditional-cpp"
-  cat > conftest.$ac_ext <<EOF
-#line 1366 "configure"
-#include "confdefs.h"
-#include <assert.h>
-Syntax Error
-EOF
-ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out"
-{ (eval echo configure:1372: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }
-ac_err=`grep -v '^ *+' conftest.out | grep -v "^conftest.${ac_ext}\$"`
-if test -z "$ac_err"; then
-  :
-else
-  echo "$ac_err" >&5
-  echo "configure: failed program was:" >&5
-  cat conftest.$ac_ext >&5
-  rm -rf conftest*
-  CPP="${CC-cc} -nologo -E"
-  cat > conftest.$ac_ext <<EOF
-#line 1383 "configure"
-#include "confdefs.h"
-#include <assert.h>
-Syntax Error
-EOF
-ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out"
-{ (eval echo configure:1389: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }
-ac_err=`grep -v '^ *+' conftest.out | grep -v "^conftest.${ac_ext}\$"`
-if test -z "$ac_err"; then
-  :
-else
-  echo "$ac_err" >&5
-  echo "configure: failed program was:" >&5
-  cat conftest.$ac_ext >&5
-  rm -rf conftest*
-  CPP=/lib/cpp
-fi
-rm -f conftest*
-fi
-rm -f conftest*
-fi
-rm -f conftest*
-  ac_cv_prog_CPP="$CPP"
-fi
-  CPP="$ac_cv_prog_CPP"
+
+if \
+		test $ccvs_cv_bsd_make_vpath_bug = no \
+		|| test $srcdir = .; then
+  MAKE_TARGETS_IN_VPATH_TRUE=
+  MAKE_TARGETS_IN_VPATH_FALSE='#'
 else
-  ac_cv_prog_CPP="$CPP"
+  MAKE_TARGETS_IN_VPATH_TRUE='#'
+  MAKE_TARGETS_IN_VPATH_FALSE=
 fi
-echo "$ac_t""$CPP" 1>&6
 
 echo $ac_n "checking for AIX""... $ac_c" 1>&6
-echo "configure:1414: checking for AIX" >&5
+echo "configure:1956: checking for AIX" >&5
 cat > conftest.$ac_ext <<EOF
-#line 1416 "configure"
+#line 1958 "configure"
 #include "confdefs.h"
 #ifdef _AIX
   yes
@@ -1435,17 +1977,17 @@ rm -f conftest*
 
 ac_safe=`echo "minix/config.h" | sed 'y%./+-%__p_%'`
 echo $ac_n "checking for minix/config.h""... $ac_c" 1>&6
-echo "configure:1439: checking for minix/config.h" >&5
+echo "configure:1981: checking for minix/config.h" >&5
 if eval "test \"`echo '$''{'ac_cv_header_$ac_safe'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
   cat > conftest.$ac_ext <<EOF
-#line 1444 "configure"
+#line 1986 "configure"
 #include "confdefs.h"
 #include <minix/config.h>
 EOF
 ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out"
-{ (eval echo configure:1449: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }
+{ (eval echo configure:1991: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }
 ac_err=`grep -v '^ *+' conftest.out | grep -v "^conftest.${ac_ext}\$"`
 if test -z "$ac_err"; then
   rm -rf conftest*
@@ -1483,7 +2025,7 @@ EOF
 fi
 
 echo $ac_n "checking for POSIXized ISC""... $ac_c" 1>&6
-echo "configure:1487: checking for POSIXized ISC" >&5
+echo "configure:2029: checking for POSIXized ISC" >&5
 if test -d /etc/conf/kconfig.d &&
   grep _POSIX_VERSION /usr/include/sys/unistd.h >/dev/null 2>&1
 then
@@ -1513,12 +2055,12 @@ for ac_hdr in dirent.h sys/ndir.h sys/dir.h ndir.h
 do
 ac_safe=`echo "$ac_hdr" | sed 'y%./+-%__p_%'`
 echo $ac_n "checking for $ac_hdr that defines DIR""... $ac_c" 1>&6
-echo "configure:1517: checking for $ac_hdr that defines DIR" >&5
+echo "configure:2059: checking for $ac_hdr that defines DIR" >&5
 if eval "test \"`echo '$''{'ac_cv_header_dirent_$ac_safe'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
   cat > conftest.$ac_ext <<EOF
-#line 1522 "configure"
+#line 2064 "configure"
 #include "confdefs.h"
 #include <sys/types.h>
 #include <$ac_hdr>
@@ -1526,7 +2068,7 @@ int main() {
 DIR *dirp = 0;
 ; return 0; }
 EOF
-if { (eval echo configure:1530: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then
+if { (eval echo configure:2072: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then
   rm -rf conftest*
   eval "ac_cv_header_dirent_$ac_safe=yes"
 else
@@ -1551,7 +2093,7 @@ done
 # Two versions of opendir et al. are in -ldir and -lx on SCO Xenix.
 if test $ac_header_dirent = dirent.h; then
 echo $ac_n "checking for opendir in -ldir""... $ac_c" 1>&6
-echo "configure:1555: checking for opendir in -ldir" >&5
+echo "configure:2097: checking for opendir in -ldir" >&5
 ac_lib_var=`echo dir'_'opendir | sed 'y%./+-%__p_%'`
 if eval "test \"`echo '$''{'ac_cv_lib_$ac_lib_var'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
@@ -1559,7 +2101,7 @@ else
   ac_save_LIBS="$LIBS"
 LIBS="-ldir  $LIBS"
 cat > conftest.$ac_ext <<EOF
-#line 1563 "configure"
+#line 2105 "configure"
 #include "confdefs.h"
 /* Override any gcc2 internal prototype to avoid an error.  */
 /* We use char because int might match the return type of a gcc2
@@ -1570,7 +2112,7 @@ int main() {
 opendir()
 ; return 0; }
 EOF
-if { (eval echo configure:1574: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
+if { (eval echo configure:2116: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
   rm -rf conftest*
   eval "ac_cv_lib_$ac_lib_var=yes"
 else
@@ -1592,7 +2134,7 @@ fi
 
 else
 echo $ac_n "checking for opendir in -lx""... $ac_c" 1>&6
-echo "configure:1596: checking for opendir in -lx" >&5
+echo "configure:2138: checking for opendir in -lx" >&5
 ac_lib_var=`echo x'_'opendir | sed 'y%./+-%__p_%'`
 if eval "test \"`echo '$''{'ac_cv_lib_$ac_lib_var'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
@@ -1600,7 +2142,7 @@ else
   ac_save_LIBS="$LIBS"
 LIBS="-lx  $LIBS"
 cat > conftest.$ac_ext <<EOF
-#line 1604 "configure"
+#line 2146 "configure"
 #include "confdefs.h"
 /* Override any gcc2 internal prototype to avoid an error.  */
 /* We use char because int might match the return type of a gcc2
@@ -1611,7 +2153,7 @@ int main() {
 opendir()
 ; return 0; }
 EOF
-if { (eval echo configure:1615: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
+if { (eval echo configure:2157: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
   rm -rf conftest*
   eval "ac_cv_lib_$ac_lib_var=yes"
 else
@@ -1634,12 +2176,12 @@ fi
 fi
 
 echo $ac_n "checking for ANSI C header files""... $ac_c" 1>&6
-echo "configure:1638: checking for ANSI C header files" >&5
+echo "configure:2180: checking for ANSI C header files" >&5
 if eval "test \"`echo '$''{'ac_cv_header_stdc'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
   cat > conftest.$ac_ext <<EOF
-#line 1643 "configure"
+#line 2185 "configure"
 #include "confdefs.h"
 #include <stdlib.h>
 #include <stdarg.h>
@@ -1647,7 +2189,7 @@ else
 #include <float.h>
 EOF
 ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out"
-{ (eval echo configure:1651: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }
+{ (eval echo configure:2193: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }
 ac_err=`grep -v '^ *+' conftest.out | grep -v "^conftest.${ac_ext}\$"`
 if test -z "$ac_err"; then
   rm -rf conftest*
@@ -1664,7 +2206,7 @@ rm -f conftest*
 if test $ac_cv_header_stdc = yes; then
   # SunOS 4.x string.h does not declare mem*, contrary to ANSI.
 cat > conftest.$ac_ext <<EOF
-#line 1668 "configure"
+#line 2210 "configure"
 #include "confdefs.h"
 #include <string.h>
 EOF
@@ -1682,7 +2224,7 @@ fi
 if test $ac_cv_header_stdc = yes; then
   # ISC 2.0.2 stdlib.h does not declare free, contrary to ANSI.
 cat > conftest.$ac_ext <<EOF
-#line 1686 "configure"
+#line 2228 "configure"
 #include "confdefs.h"
 #include <stdlib.h>
 EOF
@@ -1703,7 +2245,7 @@ if test "$cross_compiling" = yes; then
   :
 else
   cat > conftest.$ac_ext <<EOF
-#line 1707 "configure"
+#line 2249 "configure"
 #include "confdefs.h"
 #include <ctype.h>
 #define ISLOWER(c) ('a' <= (c) && (c) <= 'z')
@@ -1714,7 +2256,7 @@ if (XOR (islower (i), ISLOWER (i)) || toupper (i) != TOUPPER (i)) exit(2);
 exit (0); }
 
 EOF
-if { (eval echo configure:1718: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext} && (./conftest; exit) 2>/dev/null
+if { (eval echo configure:2260: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext} && (./conftest; exit) 2>/dev/null
 then
   :
 else
@@ -1738,12 +2280,12 @@ EOF
 fi
 
 echo $ac_n "checking for sys/wait.h that is POSIX.1 compatible""... $ac_c" 1>&6
-echo "configure:1742: checking for sys/wait.h that is POSIX.1 compatible" >&5
+echo "configure:2284: checking for sys/wait.h that is POSIX.1 compatible" >&5
 if eval "test \"`echo '$''{'ac_cv_header_sys_wait_h'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
   cat > conftest.$ac_ext <<EOF
-#line 1747 "configure"
+#line 2289 "configure"
 #include "confdefs.h"
 #include <sys/types.h>
 #include <sys/wait.h>
@@ -1759,7 +2301,7 @@ wait (&s);
 s = WIFEXITED (s) ? WEXITSTATUS (s) : 1;
 ; return 0; }
 EOF
-if { (eval echo configure:1763: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then
+if { (eval echo configure:2305: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then
   rm -rf conftest*
   ac_cv_header_sys_wait_h=yes
 else
@@ -1786,17 +2328,17 @@ for ac_hdr in errno.h unistd.h string.h memory.h utime.h fcntl.h ndbm.h \
 do
 ac_safe=`echo "$ac_hdr" | sed 'y%./+-%__p_%'`
 echo $ac_n "checking for $ac_hdr""... $ac_c" 1>&6
-echo "configure:1790: checking for $ac_hdr" >&5
+echo "configure:2332: checking for $ac_hdr" >&5
 if eval "test \"`echo '$''{'ac_cv_header_$ac_safe'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
   cat > conftest.$ac_ext <<EOF
-#line 1795 "configure"
+#line 2337 "configure"
 #include "confdefs.h"
 #include <$ac_hdr>
 EOF
 ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out"
-{ (eval echo configure:1800: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }
+{ (eval echo configure:2342: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }
 ac_err=`grep -v '^ *+' conftest.out | grep -v "^conftest.${ac_ext}\$"`
 if test -z "$ac_err"; then
   rm -rf conftest*
@@ -1823,12 +2365,12 @@ fi
 done
 
 echo $ac_n "checking whether stat file-mode macros are broken""... $ac_c" 1>&6
-echo "configure:1827: checking whether stat file-mode macros are broken" >&5
+echo "configure:2369: checking whether stat file-mode macros are broken" >&5
 if eval "test \"`echo '$''{'ac_cv_header_stat_broken'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
   cat > conftest.$ac_ext <<EOF
-#line 1832 "configure"
+#line 2374 "configure"
 #include "confdefs.h"
 #include <sys/types.h>
 #include <sys/stat.h>
@@ -1879,12 +2421,12 @@ EOF
 fi
 
 echo $ac_n "checking whether time.h and sys/time.h may both be included""... $ac_c" 1>&6
-echo "configure:1883: checking whether time.h and sys/time.h may both be included" >&5
+echo "configure:2425: checking whether time.h and sys/time.h may both be included" >&5
 if eval "test \"`echo '$''{'ac_cv_header_time'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
   cat > conftest.$ac_ext <<EOF
-#line 1888 "configure"
+#line 2430 "configure"
 #include "confdefs.h"
 #include <sys/types.h>
 #include <sys/time.h>
@@ -1893,7 +2435,7 @@ int main() {
 struct tm *tp;
 ; return 0; }
 EOF
-if { (eval echo configure:1897: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then
+if { (eval echo configure:2439: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then
   rm -rf conftest*
   ac_cv_header_time=yes
 else
@@ -1915,12 +2457,12 @@ fi
 
 
 echo $ac_n "checking for working const""... $ac_c" 1>&6
-echo "configure:1919: checking for working const" >&5
+echo "configure:2461: checking for working const" >&5
 if eval "test \"`echo '$''{'ac_cv_c_const'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
   cat > conftest.$ac_ext <<EOF
-#line 1924 "configure"
+#line 2466 "configure"
 #include "confdefs.h"
 
 int main() {
@@ -1969,7 +2511,7 @@ ccp = (char const *const *) p;
 
 ; return 0; }
 EOF
-if { (eval echo configure:1973: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then
+if { (eval echo configure:2515: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then
   rm -rf conftest*
   ac_cv_c_const=yes
 else
@@ -1990,12 +2532,12 @@ EOF
 fi
 
 echo $ac_n "checking for uid_t in sys/types.h""... $ac_c" 1>&6
-echo "configure:1994: checking for uid_t in sys/types.h" >&5
+echo "configure:2536: checking for uid_t in sys/types.h" >&5
 if eval "test \"`echo '$''{'ac_cv_type_uid_t'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
   cat > conftest.$ac_ext <<EOF
-#line 1999 "configure"
+#line 2541 "configure"
 #include "confdefs.h"
 #include <sys/types.h>
 EOF
@@ -2024,12 +2566,12 @@ EOF
 fi
 
 echo $ac_n "checking for mode_t""... $ac_c" 1>&6
-echo "configure:2028: checking for mode_t" >&5
+echo "configure:2570: checking for mode_t" >&5
 if eval "test \"`echo '$''{'ac_cv_type_mode_t'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
   cat > conftest.$ac_ext <<EOF
-#line 2033 "configure"
+#line 2575 "configure"
 #include "confdefs.h"
 #include <sys/types.h>
 #if STDC_HEADERS
@@ -2057,12 +2599,12 @@ EOF
 fi
 
 echo $ac_n "checking for pid_t""... $ac_c" 1>&6
-echo "configure:2061: checking for pid_t" >&5
+echo "configure:2603: checking for pid_t" >&5
 if eval "test \"`echo '$''{'ac_cv_type_pid_t'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
   cat > conftest.$ac_ext <<EOF
-#line 2066 "configure"
+#line 2608 "configure"
 #include "confdefs.h"
 #include <sys/types.h>
 #if STDC_HEADERS
@@ -2090,12 +2632,12 @@ EOF
 fi
 
 echo $ac_n "checking for size_t""... $ac_c" 1>&6
-echo "configure:2094: checking for size_t" >&5
+echo "configure:2636: checking for size_t" >&5
 if eval "test \"`echo '$''{'ac_cv_type_size_t'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
   cat > conftest.$ac_ext <<EOF
-#line 2099 "configure"
+#line 2641 "configure"
 #include "confdefs.h"
 #include <sys/types.h>
 #if STDC_HEADERS
@@ -2123,12 +2665,12 @@ EOF
 fi
 
 echo $ac_n "checking return type of signal handlers""... $ac_c" 1>&6
-echo "configure:2127: checking return type of signal handlers" >&5
+echo "configure:2669: checking return type of signal handlers" >&5
 if eval "test \"`echo '$''{'ac_cv_type_signal'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
   cat > conftest.$ac_ext <<EOF
-#line 2132 "configure"
+#line 2674 "configure"
 #include "confdefs.h"
 #include <sys/types.h>
 #include <signal.h>
@@ -2145,7 +2687,7 @@ int main() {
 int i;
 ; return 0; }
 EOF
-if { (eval echo configure:2149: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then
+if { (eval echo configure:2691: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then
   rm -rf conftest*
   ac_cv_type_signal=void
 else
@@ -2165,12 +2707,12 @@ EOF
 
 
 echo $ac_n "checking for st_blksize in struct stat""... $ac_c" 1>&6
-echo "configure:2169: checking for st_blksize in struct stat" >&5
+echo "configure:2711: checking for st_blksize in struct stat" >&5
 if eval "test \"`echo '$''{'ac_cv_struct_st_blksize'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
   cat > conftest.$ac_ext <<EOF
-#line 2174 "configure"
+#line 2716 "configure"
 #include "confdefs.h"
 #include <sys/types.h>
 #include <sys/stat.h>
@@ -2178,7 +2720,7 @@ int main() {
 struct stat s; s.st_blksize;
 ; return 0; }
 EOF
-if { (eval echo configure:2182: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then
+if { (eval echo configure:2724: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then
   rm -rf conftest*
   ac_cv_struct_st_blksize=yes
 else
@@ -2199,12 +2741,12 @@ EOF
 fi
 
 echo $ac_n "checking for st_rdev in struct stat""... $ac_c" 1>&6
-echo "configure:2203: checking for st_rdev in struct stat" >&5
+echo "configure:2745: checking for st_rdev in struct stat" >&5
 if eval "test \"`echo '$''{'ac_cv_struct_st_rdev'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
   cat > conftest.$ac_ext <<EOF
-#line 2208 "configure"
+#line 2750 "configure"
 #include "confdefs.h"
 #include <sys/types.h>
 #include <sys/stat.h>
@@ -2212,7 +2754,7 @@ int main() {
 struct stat s; s.st_rdev;
 ; return 0; }
 EOF
-if { (eval echo configure:2216: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then
+if { (eval echo configure:2758: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then
   rm -rf conftest*
   ac_cv_struct_st_rdev=yes
 else
@@ -2235,12 +2777,12 @@ fi
 for ac_func in mkdir rename strstr dup2 strerror valloc waitpid memmove strtoul
 do
 echo $ac_n "checking for $ac_func""... $ac_c" 1>&6
-echo "configure:2239: checking for $ac_func" >&5
+echo "configure:2781: checking for $ac_func" >&5
 if eval "test \"`echo '$''{'ac_cv_func_$ac_func'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
   cat > conftest.$ac_ext <<EOF
-#line 2244 "configure"
+#line 2786 "configure"
 #include "confdefs.h"
 /* System header to define __stub macros and hopefully few prototypes,
     which can conflict with char $ac_func(); below.  */
@@ -2263,7 +2805,7 @@ $ac_func();
 
 ; return 0; }
 EOF
-if { (eval echo configure:2267: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
+if { (eval echo configure:2809: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
   rm -rf conftest*
   eval "ac_cv_func_$ac_func=yes"
 else
@@ -2318,12 +2860,12 @@ for ac_func in \
 
 do
 echo $ac_n "checking for $ac_func""... $ac_c" 1>&6
-echo "configure:2322: checking for $ac_func" >&5
+echo "configure:2864: checking for $ac_func" >&5
 if eval "test \"`echo '$''{'ac_cv_func_$ac_func'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
   cat > conftest.$ac_ext <<EOF
-#line 2327 "configure"
+#line 2869 "configure"
 #include "confdefs.h"
 /* System header to define __stub macros and hopefully few prototypes,
     which can conflict with char $ac_func(); below.  */
@@ -2346,7 +2888,7 @@ $ac_func();
 
 ; return 0; }
 EOF
-if { (eval echo configure:2350: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
+if { (eval echo configure:2892: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
   rm -rf conftest*
   eval "ac_cv_func_$ac_func=yes"
 else
@@ -2378,12 +2920,12 @@ for ac_func in \
 
 do
 echo $ac_n "checking for $ac_func""... $ac_c" 1>&6
-echo "configure:2382: checking for $ac_func" >&5
+echo "configure:2924: checking for $ac_func" >&5
 if eval "test \"`echo '$''{'ac_cv_func_$ac_func'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
   cat > conftest.$ac_ext <<EOF
-#line 2387 "configure"
+#line 2929 "configure"
 #include "confdefs.h"
 /* System header to define __stub macros and hopefully few prototypes,
     which can conflict with char $ac_func(); below.  */
@@ -2406,7 +2948,7 @@ $ac_func();
 
 ; return 0; }
 EOF
-if { (eval echo configure:2410: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
+if { (eval echo configure:2952: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
   rm -rf conftest*
   eval "ac_cv_func_$ac_func=yes"
 else
@@ -2450,17 +2992,17 @@ EOF
 
 ac_safe=`echo "vfork.h" | sed 'y%./+-%__p_%'`
 echo $ac_n "checking for vfork.h""... $ac_c" 1>&6
-echo "configure:2454: checking for vfork.h" >&5
+echo "configure:2996: checking for vfork.h" >&5
 if eval "test \"`echo '$''{'ac_cv_header_$ac_safe'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
   cat > conftest.$ac_ext <<EOF
-#line 2459 "configure"
+#line 3001 "configure"
 #include "confdefs.h"
 #include <vfork.h>
 EOF
 ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out"
-{ (eval echo configure:2464: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }
+{ (eval echo configure:3006: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }
 ac_err=`grep -v '^ *+' conftest.out | grep -v "^conftest.${ac_ext}\$"`
 if test -z "$ac_err"; then
   rm -rf conftest*
@@ -2485,18 +3027,18 @@ else
 fi
 
 echo $ac_n "checking for working vfork""... $ac_c" 1>&6
-echo "configure:2489: checking for working vfork" >&5
+echo "configure:3031: checking for working vfork" >&5
 if eval "test \"`echo '$''{'ac_cv_func_vfork_works'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
   if test "$cross_compiling" = yes; then
   echo $ac_n "checking for vfork""... $ac_c" 1>&6
-echo "configure:2495: checking for vfork" >&5
+echo "configure:3037: checking for vfork" >&5
 if eval "test \"`echo '$''{'ac_cv_func_vfork'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
   cat > conftest.$ac_ext <<EOF
-#line 2500 "configure"
+#line 3042 "configure"
 #include "confdefs.h"
 /* System header to define __stub macros and hopefully few prototypes,
     which can conflict with char vfork(); below.  */
@@ -2519,7 +3061,7 @@ vfork();
 
 ; return 0; }
 EOF
-if { (eval echo configure:2523: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
+if { (eval echo configure:3065: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
   rm -rf conftest*
   eval "ac_cv_func_vfork=yes"
 else
@@ -2541,7 +3083,7 @@ fi
 ac_cv_func_vfork_works=$ac_cv_func_vfork
 else
   cat > conftest.$ac_ext <<EOF
-#line 2545 "configure"
+#line 3087 "configure"
 #include "confdefs.h"
 /* Thanks to Paul Eggert for this test.  */
 #include <stdio.h>
@@ -2636,7 +3178,7 @@ main() {
   }
 }
 EOF
-if { (eval echo configure:2640: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext} && (./conftest; exit) 2>/dev/null
+if { (eval echo configure:3182: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext} && (./conftest; exit) 2>/dev/null
 then
   ac_cv_func_vfork_works=yes
 else
@@ -2659,7 +3201,7 @@ EOF
 fi
 
 echo $ac_n "checking whether closedir returns void""... $ac_c" 1>&6
-echo "configure:2663: checking whether closedir returns void" >&5
+echo "configure:3205: checking whether closedir returns void" >&5
 if eval "test \"`echo '$''{'ac_cv_func_closedir_void'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
@@ -2667,13 +3209,13 @@ else
   ac_cv_func_closedir_void=yes
 else
   cat > conftest.$ac_ext <<EOF
-#line 2671 "configure"
+#line 3213 "configure"
 #include "confdefs.h"
 #include <sys/types.h>
 #include <$ac_header_dirent>
 int closedir(); main() { exit(closedir(opendir(".")) != 0); }
 EOF
-if { (eval echo configure:2677: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext} && (./conftest; exit) 2>/dev/null
+if { (eval echo configure:3219: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext} && (./conftest; exit) 2>/dev/null
 then
   ac_cv_func_closedir_void=no
 else
@@ -2698,14 +3240,14 @@ fi
 
 
 echo $ac_n "checking for library containing getspnam""... $ac_c" 1>&6
-echo "configure:2702: checking for library containing getspnam" >&5
+echo "configure:3244: checking for library containing getspnam" >&5
 if eval "test \"`echo '$''{'ac_cv_search_getspnam'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
   ac_func_search_save_LIBS="$LIBS"
 ac_cv_search_getspnam="no"
 cat > conftest.$ac_ext <<EOF
-#line 2709 "configure"
+#line 3251 "configure"
 #include "confdefs.h"
 /* Override any gcc2 internal prototype to avoid an error.  */
 /* We use char because int might match the return type of a gcc2
@@ -2716,7 +3258,7 @@ int main() {
 getspnam()
 ; return 0; }
 EOF
-if { (eval echo configure:2720: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
+if { (eval echo configure:3262: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
   rm -rf conftest*
   ac_cv_search_getspnam="none required"
 else
@@ -2727,7 +3269,7 @@ rm -f conftest*
 test "$ac_cv_search_getspnam" = "no" && for i in sec gen; do
 LIBS="-l$i  $ac_func_search_save_LIBS"
 cat > conftest.$ac_ext <<EOF
-#line 2731 "configure"
+#line 3273 "configure"
 #include "confdefs.h"
 /* Override any gcc2 internal prototype to avoid an error.  */
 /* We use char because int might match the return type of a gcc2
@@ -2738,7 +3280,7 @@ int main() {
 getspnam()
 ; return 0; }
 EOF
-if { (eval echo configure:2742: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
+if { (eval echo configure:3284: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
   rm -rf conftest*
   ac_cv_search_getspnam="-l$i"
 break
@@ -2763,7 +3305,7 @@ else :
 fi
 
 echo $ac_n "checking for zlibVersion in -lz""... $ac_c" 1>&6
-echo "configure:2767: checking for zlibVersion in -lz" >&5
+echo "configure:3309: checking for zlibVersion in -lz" >&5
 ac_lib_var=`echo z'_'zlibVersion | sed 'y%./+-%__p_%'`
 if eval "test \"`echo '$''{'ac_cv_lib_$ac_lib_var'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
@@ -2771,7 +3313,7 @@ else
   ac_save_LIBS="$LIBS"
 LIBS="-lz  $LIBS"
 cat > conftest.$ac_ext <<EOF
-#line 2775 "configure"
+#line 3317 "configure"
 #include "confdefs.h"
 /* Override any gcc2 internal prototype to avoid an error.  */
 /* We use char because int might match the return type of a gcc2
@@ -2782,7 +3324,7 @@ int main() {
 zlibVersion()
 ; return 0; }
 EOF
-if { (eval echo configure:2786: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
+if { (eval echo configure:3328: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
   rm -rf conftest*
   eval "ac_cv_lib_$ac_lib_var=yes"
 else
@@ -2797,18 +3339,19 @@ LIBS="$ac_save_LIBS"
 fi
 if eval "test \"`echo '$ac_cv_lib_'$ac_lib_var`\" = yes"; then
   echo "$ac_t""yes" 1>&6
-  ZLIB=-lz 
+  ZLIB=-lz ZLIB_DEPEND=/usr/lib/libz.a
 else
   echo "$ac_t""no" 1>&6
-ZLIBSUBDIRS=zlib ZLIB=$srcdir/zlib/libz.a ZLIB_INCLUDES=-I$srcdir/zlib
+ZLIBSUBDIRS=zlib ZLIB=$srcdir/zlib/libz.a ZLIB_DEPEND=$srcdir/zlib/libz.a ZLIB_INCLUDES=-I$srcdir/zlib
 fi
 
 
 
 
 
+
 echo $ac_n "checking whether utime accepts a null argument""... $ac_c" 1>&6
-echo "configure:2812: checking whether utime accepts a null argument" >&5
+echo "configure:3355: checking whether utime accepts a null argument" >&5
 if eval "test \"`echo '$''{'ac_cv_func_utime_null'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
@@ -2818,7 +3361,7 @@ if test "$cross_compiling" = yes; then
   ac_cv_func_utime_null=no
 else
   cat > conftest.$ac_ext <<EOF
-#line 2822 "configure"
+#line 3365 "configure"
 #include "confdefs.h"
 #include <sys/types.h>
 #include <sys/stat.h>
@@ -2829,7 +3372,7 @@ exit(!(stat ("conftestdata", &s) == 0 && utime("conftestdata", (long *)0) == 0
 && t.st_mtime - s.st_mtime < 120));
 }
 EOF
-if { (eval echo configure:2833: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext} && (./conftest; exit) 2>/dev/null
+if { (eval echo configure:3376: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext} && (./conftest; exit) 2>/dev/null
 then
   ac_cv_func_utime_null=yes
 else
@@ -2853,7 +3396,7 @@ EOF
 fi
 
 echo $ac_n "checking for long file names""... $ac_c" 1>&6
-echo "configure:2857: checking for long file names" >&5
+echo "configure:3400: checking for long file names" >&5
 if eval "test \"`echo '$''{'ac_cv_sys_long_file_names'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
@@ -2898,7 +3441,7 @@ fi
 
 
 echo $ac_n "checking for working fnmatch""... $ac_c" 1>&6
-echo "configure:2902: checking for working fnmatch" >&5
+echo "configure:3445: checking for working fnmatch" >&5
 if eval "test \"`echo '$''{'ac_cv_func_fnmatch_works'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
@@ -2909,11 +3452,11 @@ if test "$cross_compiling" = yes; then
   ac_cv_func_fnmatch_works=no
 else
   cat > conftest.$ac_ext <<EOF
-#line 2913 "configure"
+#line 3456 "configure"
 #include "confdefs.h"
 main() { exit (fnmatch ("a*", "abc", 0) != 0); }
 EOF
-if { (eval echo configure:2917: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext} && (./conftest; exit) 2>/dev/null
+if { (eval echo configure:3460: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext} && (./conftest; exit) 2>/dev/null
 then
   ac_cv_func_fnmatch_works=yes
 else
@@ -2941,7 +3484,7 @@ fi
 
 # Try to find connect and gethostbyname.
 echo $ac_n "checking for main in -lnsl""... $ac_c" 1>&6
-echo "configure:2945: checking for main in -lnsl" >&5
+echo "configure:3488: checking for main in -lnsl" >&5
 ac_lib_var=`echo nsl'_'main | sed 'y%./+-%__p_%'`
 if eval "test \"`echo '$''{'ac_cv_lib_$ac_lib_var'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
@@ -2949,14 +3492,14 @@ else
   ac_save_LIBS="$LIBS"
 LIBS="-lnsl  $LIBS"
 cat > conftest.$ac_ext <<EOF
-#line 2953 "configure"
+#line 3496 "configure"
 #include "confdefs.h"
 
 int main() {
 main()
 ; return 0; }
 EOF
-if { (eval echo configure:2960: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
+if { (eval echo configure:3503: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
   rm -rf conftest*
   eval "ac_cv_lib_$ac_lib_var=yes"
 else
@@ -2973,14 +3516,14 @@ if eval "test \"`echo '$ac_cv_lib_'$ac_lib_var`\" = yes"; then
   echo "$ac_t""yes" 1>&6
   
 echo $ac_n "checking for library containing connect""... $ac_c" 1>&6
-echo "configure:2977: checking for library containing connect" >&5
+echo "configure:3520: checking for library containing connect" >&5
 if eval "test \"`echo '$''{'ac_cv_search_connect'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
   ac_func_search_save_LIBS="$LIBS"
 ac_cv_search_connect="no"
 cat > conftest.$ac_ext <<EOF
-#line 2984 "configure"
+#line 3527 "configure"
 #include "confdefs.h"
 /* Override any gcc2 internal prototype to avoid an error.  */
 /* We use char because int might match the return type of a gcc2
@@ -2991,7 +3534,7 @@ int main() {
 connect()
 ; return 0; }
 EOF
-if { (eval echo configure:2995: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
+if { (eval echo configure:3538: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
   rm -rf conftest*
   ac_cv_search_connect="none required"
 else
@@ -3002,7 +3545,7 @@ rm -f conftest*
 test "$ac_cv_search_connect" = "no" && for i in xnet socket inet; do
 LIBS="-l$i -lnsl $ac_func_search_save_LIBS"
 cat > conftest.$ac_ext <<EOF
-#line 3006 "configure"
+#line 3549 "configure"
 #include "confdefs.h"
 /* Override any gcc2 internal prototype to avoid an error.  */
 /* We use char because int might match the return type of a gcc2
@@ -3013,7 +3556,7 @@ int main() {
 connect()
 ; return 0; }
 EOF
-if { (eval echo configure:3017: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
+if { (eval echo configure:3560: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
   rm -rf conftest*
   ac_cv_search_connect="-l$i"
 break
@@ -3040,14 +3583,14 @@ else
   echo "$ac_t""no" 1>&6
 
 echo $ac_n "checking for library containing connect""... $ac_c" 1>&6
-echo "configure:3044: checking for library containing connect" >&5
+echo "configure:3587: checking for library containing connect" >&5
 if eval "test \"`echo '$''{'ac_cv_search_connect'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
   ac_func_search_save_LIBS="$LIBS"
 ac_cv_search_connect="no"
 cat > conftest.$ac_ext <<EOF
-#line 3051 "configure"
+#line 3594 "configure"
 #include "confdefs.h"
 /* Override any gcc2 internal prototype to avoid an error.  */
 /* We use char because int might match the return type of a gcc2
@@ -3058,7 +3601,7 @@ int main() {
 connect()
 ; return 0; }
 EOF
-if { (eval echo configure:3062: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
+if { (eval echo configure:3605: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
   rm -rf conftest*
   ac_cv_search_connect="none required"
 else
@@ -3069,7 +3612,7 @@ rm -f conftest*
 test "$ac_cv_search_connect" = "no" && for i in xnet socket inet; do
 LIBS="-l$i  $ac_func_search_save_LIBS"
 cat > conftest.$ac_ext <<EOF
-#line 3073 "configure"
+#line 3616 "configure"
 #include "confdefs.h"
 /* Override any gcc2 internal prototype to avoid an error.  */
 /* We use char because int might match the return type of a gcc2
@@ -3080,7 +3623,7 @@ int main() {
 connect()
 ; return 0; }
 EOF
-if { (eval echo configure:3084: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
+if { (eval echo configure:3627: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
   rm -rf conftest*
   ac_cv_search_connect="-l$i"
 break
@@ -3107,14 +3650,14 @@ fi
 
 
 echo $ac_n "checking for library containing gethostbyname""... $ac_c" 1>&6
-echo "configure:3111: checking for library containing gethostbyname" >&5
+echo "configure:3654: checking for library containing gethostbyname" >&5
 if eval "test \"`echo '$''{'ac_cv_search_gethostbyname'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
   ac_func_search_save_LIBS="$LIBS"
 ac_cv_search_gethostbyname="no"
 cat > conftest.$ac_ext <<EOF
-#line 3118 "configure"
+#line 3661 "configure"
 #include "confdefs.h"
 /* Override any gcc2 internal prototype to avoid an error.  */
 /* We use char because int might match the return type of a gcc2
@@ -3125,7 +3668,7 @@ int main() {
 gethostbyname()
 ; return 0; }
 EOF
-if { (eval echo configure:3129: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
+if { (eval echo configure:3672: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
   rm -rf conftest*
   ac_cv_search_gethostbyname="none required"
 else
@@ -3136,7 +3679,7 @@ rm -f conftest*
 test "$ac_cv_search_gethostbyname" = "no" && for i in netinet nsl; do
 LIBS="-l$i  $ac_func_search_save_LIBS"
 cat > conftest.$ac_ext <<EOF
-#line 3140 "configure"
+#line 3683 "configure"
 #include "confdefs.h"
 /* Override any gcc2 internal prototype to avoid an error.  */
 /* We use char because int might match the return type of a gcc2
@@ -3147,7 +3690,7 @@ int main() {
 gethostbyname()
 ; return 0; }
 EOF
-if { (eval echo configure:3151: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
+if { (eval echo configure:3694: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
   rm -rf conftest*
   ac_cv_search_gethostbyname="-l$i"
 break
@@ -3180,19 +3723,19 @@ echo "default place for krb4 is $KRB4"
 
 krb_h=
 echo $ac_n "checking for krb.h""... $ac_c" 1>&6
-echo "configure:3184: checking for krb.h" >&5
+echo "configure:3727: checking for krb.h" >&5
 if test "$cross_compiling" != yes && test -r $KRB4/include/krb.h; then
    hold_cflags=$CFLAGS
    CFLAGS="$CFLAGS -I$KRB4/include"
    cat > conftest.$ac_ext <<EOF
-#line 3189 "configure"
+#line 3732 "configure"
 #include "confdefs.h"
 #include <krb.h>
 int main() {
 int i;
 ; return 0; }
 EOF
-if { (eval echo configure:3196: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
+if { (eval echo configure:3739: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
   rm -rf conftest*
   krb_h=yes krb_incdir=$KRB4/include
 else
@@ -3201,14 +3744,14 @@ else
   rm -rf conftest*
   CFLAGS=$hold_cflags
            cat > conftest.$ac_ext <<EOF
-#line 3205 "configure"
+#line 3748 "configure"
 #include "confdefs.h"
 #include <krb.h>
 int main() {
 int i;
 ; return 0; }
 EOF
-if { (eval echo configure:3212: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
+if { (eval echo configure:3755: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
   rm -rf conftest*
   krb_h=yes krb_incdir=
 else
@@ -3221,14 +3764,14 @@ rm -f conftest*
    CFLAGS=$hold_cflags
 else
    cat > conftest.$ac_ext <<EOF
-#line 3225 "configure"
+#line 3768 "configure"
 #include "confdefs.h"
 #include <krb.h>
 int main() {
 int i;
 ; return 0; }
 EOF
-if { (eval echo configure:3232: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
+if { (eval echo configure:3775: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
   rm -rf conftest*
   krb_h=yes krb_incdir=
 else
@@ -3239,14 +3782,14 @@ rm -f conftest*
 fi
 if test -z "$krb_h"; then
   cat > conftest.$ac_ext <<EOF
-#line 3243 "configure"
+#line 3786 "configure"
 #include "confdefs.h"
 #include <krb.h>
 int main() {
 int i;
 ; return 0; }
 EOF
-if { (eval echo configure:3250: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
+if { (eval echo configure:3793: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
   rm -rf conftest*
   krb_h=yes krb_incdir=
 else
@@ -3257,14 +3800,14 @@ else
        hold_cflags=$CFLAGS
        CFLAGS="$CFLAGS -I$KRB4/include/kerberosIV"
        cat > conftest.$ac_ext <<EOF
-#line 3261 "configure"
+#line 3804 "configure"
 #include "confdefs.h"
 #include <krb.h>
 int main() {
 int i;
 ; return 0; }
 EOF
-if { (eval echo configure:3268: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
+if { (eval echo configure:3811: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
   rm -rf conftest*
   krb_h=yes krb_incdir=$KRB4/include/kerberosIV
 else
@@ -3287,7 +3830,7 @@ if test -n "$krb_h"; then
        hold_ldflags=$LDFLAGS
        LDFLAGS="-L${KRB4}/lib $LDFLAGS"
        echo $ac_n "checking for printf in -lkrb""... $ac_c" 1>&6
-echo "configure:3291: checking for printf in -lkrb" >&5
+echo "configure:3834: checking for printf in -lkrb" >&5
 ac_lib_var=`echo krb'_'printf | sed 'y%./+-%__p_%'`
 if eval "test \"`echo '$''{'ac_cv_lib_$ac_lib_var'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
@@ -3295,7 +3838,7 @@ else
   ac_save_LIBS="$LIBS"
 LIBS="-lkrb  $LIBS"
 cat > conftest.$ac_ext <<EOF
-#line 3299 "configure"
+#line 3842 "configure"
 #include "confdefs.h"
 /* Override any gcc2 internal prototype to avoid an error.  */
 /* We use char because int might match the return type of a gcc2
@@ -3306,7 +3849,7 @@ int main() {
 printf()
 ; return 0; }
 EOF
-if { (eval echo configure:3310: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
+if { (eval echo configure:3853: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
   rm -rf conftest*
   eval "ac_cv_lib_$ac_lib_var=yes"
 else
@@ -3328,7 +3871,7 @@ LDFLAGS=$hold_ldflags
             # Using open here instead of printf so we don't
             # get confused by the cached value for printf from above.
             echo $ac_n "checking for open in -lkrb""... $ac_c" 1>&6
-echo "configure:3332: checking for open in -lkrb" >&5
+echo "configure:3875: checking for open in -lkrb" >&5
 ac_lib_var=`echo krb'_'open | sed 'y%./+-%__p_%'`
 if eval "test \"`echo '$''{'ac_cv_lib_$ac_lib_var'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
@@ -3336,7 +3879,7 @@ else
   ac_save_LIBS="$LIBS"
 LIBS="-lkrb  $LIBS"
 cat > conftest.$ac_ext <<EOF
-#line 3340 "configure"
+#line 3883 "configure"
 #include "confdefs.h"
 /* Override any gcc2 internal prototype to avoid an error.  */
 /* We use char because int might match the return type of a gcc2
@@ -3347,7 +3890,7 @@ int main() {
 open()
 ; return 0; }
 EOF
-if { (eval echo configure:3351: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
+if { (eval echo configure:3894: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
   rm -rf conftest*
   eval "ac_cv_lib_$ac_lib_var=yes"
 else
@@ -3372,7 +3915,7 @@ fi
        LDFLAGS=$hold_ldflags
   else
        echo $ac_n "checking for printf in -lkrb""... $ac_c" 1>&6
-echo "configure:3376: checking for printf in -lkrb" >&5
+echo "configure:3919: checking for printf in -lkrb" >&5
 ac_lib_var=`echo krb'_'printf | sed 'y%./+-%__p_%'`
 if eval "test \"`echo '$''{'ac_cv_lib_$ac_lib_var'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
@@ -3380,7 +3923,7 @@ else
   ac_save_LIBS="$LIBS"
 LIBS="-lkrb  $LIBS"
 cat > conftest.$ac_ext <<EOF
-#line 3384 "configure"
+#line 3927 "configure"
 #include "confdefs.h"
 /* Override any gcc2 internal prototype to avoid an error.  */
 /* We use char because int might match the return type of a gcc2
@@ -3391,7 +3934,7 @@ int main() {
 printf()
 ; return 0; }
 EOF
-if { (eval echo configure:3395: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
+if { (eval echo configure:3938: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
   rm -rf conftest*
   eval "ac_cv_lib_$ac_lib_var=yes"
 else
@@ -3412,119 +3955,7 @@ else
 fi
 
   fi
-  if test -n "$krb_lib"; then
-    cat >> confdefs.h <<\EOF
-#define HAVE_KERBEROS 1
-EOF
-
-    test -n "${krb_libdir}" && LIBS="${LIBS} -L${krb_libdir}"
-    LIBS="${LIBS} -lkrb"
-    # Put -L${krb_libdir} in LDFLAGS temporarily so that it appears before
-    # -ldes in the command line.  Don't do it permanently so that we honor
-    # the user's setting for LDFLAGS
-    hold_ldflags=$LDFLAGS
-    test -n "${krb_libdir}" && LDFLAGS="$LDFLAGS -L${krb_libdir}"
-    echo $ac_n "checking for printf in -ldes""... $ac_c" 1>&6
-echo "configure:3429: checking for printf in -ldes" >&5
-ac_lib_var=`echo des'_'printf | sed 'y%./+-%__p_%'`
-if eval "test \"`echo '$''{'ac_cv_lib_$ac_lib_var'+set}'`\" = set"; then
-  echo $ac_n "(cached) $ac_c" 1>&6
-else
-  ac_save_LIBS="$LIBS"
-LIBS="-ldes  $LIBS"
-cat > conftest.$ac_ext <<EOF
-#line 3437 "configure"
-#include "confdefs.h"
-/* Override any gcc2 internal prototype to avoid an error.  */
-/* We use char because int might match the return type of a gcc2
-    builtin and then its argument prototype would still apply.  */
-char printf();
-
-int main() {
-printf()
-; return 0; }
-EOF
-if { (eval echo configure:3448: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
-  rm -rf conftest*
-  eval "ac_cv_lib_$ac_lib_var=yes"
-else
-  echo "configure: failed program was:" >&5
-  cat conftest.$ac_ext >&5
-  rm -rf conftest*
-  eval "ac_cv_lib_$ac_lib_var=no"
-fi
-rm -f conftest*
-LIBS="$ac_save_LIBS"
-
-fi
-if eval "test \"`echo '$ac_cv_lib_'$ac_lib_var`\" = yes"; then
-  echo "$ac_t""yes" 1>&6
-  LIBS="${LIBS} -ldes"
-else
-  echo "$ac_t""no" 1>&6
-fi
-
-    LDFLAGS=$hold_ldflags
-    if test -n "$krb_incdir"; then
-      includeopt="${includeopt} -I$krb_incdir"
-    fi
-  fi
 fi
-for ac_func in krb_get_err_text
-do
-echo $ac_n "checking for $ac_func""... $ac_c" 1>&6
-echo "configure:3477: checking for $ac_func" >&5
-if eval "test \"`echo '$''{'ac_cv_func_$ac_func'+set}'`\" = set"; then
-  echo $ac_n "(cached) $ac_c" 1>&6
-else
-  cat > conftest.$ac_ext <<EOF
-#line 3482 "configure"
-#include "confdefs.h"
-/* System header to define __stub macros and hopefully few prototypes,
-    which can conflict with char $ac_func(); below.  */
-#include <assert.h>
-/* Override any gcc2 internal prototype to avoid an error.  */
-/* We use char because int might match the return type of a gcc2
-    builtin and then its argument prototype would still apply.  */
-char $ac_func();
-
-int main() {
-
-/* The GNU C library defines this for functions which it implements
-    to always fail with ENOSYS.  Some functions are actually named
-    something starting with __ and the normal name is an alias.  */
-#if defined (__stub_$ac_func) || defined (__stub___$ac_func)
-choke me
-#else
-$ac_func();
-#endif
-
-; return 0; }
-EOF
-if { (eval echo configure:3505: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
-  rm -rf conftest*
-  eval "ac_cv_func_$ac_func=yes"
-else
-  echo "configure: failed program was:" >&5
-  cat conftest.$ac_ext >&5
-  rm -rf conftest*
-  eval "ac_cv_func_$ac_func=no"
-fi
-rm -f conftest*
-fi
-
-if eval "test \"`echo '$ac_cv_func_'$ac_func`\" = yes"; then
-  echo "$ac_t""yes" 1>&6
-    ac_tr_func=HAVE_`echo $ac_func | tr 'abcdefghijklmnopqrstuvwxyz' 'ABCDEFGHIJKLMNOPQRSTUVWXYZ'`
-  cat >> confdefs.h <<EOF
-#define $ac_tr_func 1
-EOF
- 
-else
-  echo "$ac_t""no" 1>&6
-fi
-done
-
 
 GSSAPI=/usr/cygnus/kerbnet
 
@@ -3542,17 +3973,17 @@ for ac_hdr in krb5.h gssapi.h gssapi/gssapi.h gssapi/gssapi_generic.h
 do
 ac_safe=`echo "$ac_hdr" | sed 'y%./+-%__p_%'`
 echo $ac_n "checking for $ac_hdr""... $ac_c" 1>&6
-echo "configure:3546: checking for $ac_hdr" >&5
+echo "configure:3977: checking for $ac_hdr" >&5
 if eval "test \"`echo '$''{'ac_cv_header_$ac_safe'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
   cat > conftest.$ac_ext <<EOF
-#line 3551 "configure"
+#line 3982 "configure"
 #include "confdefs.h"
 #include <$ac_hdr>
 EOF
 ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out"
-{ (eval echo configure:3556: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }
+{ (eval echo configure:3987: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }
 ac_err=`grep -v '^ *+' conftest.out | grep -v "^conftest.${ac_ext}\$"`
 if test -z "$ac_err"; then
   rm -rf conftest*
@@ -3590,7 +4021,7 @@ EOF
   includeopt="${includeopt} -I$GSSAPI/include/kerberosV"
   # FIXME: This is ugly, but these things don't seem to be standardized.
   if test "$ac_cv_header_gssapi_h" = "yes"; then
-    LIBS="$LIBS -L$GSSAPI/lib -lgssapi -lkrb lkrb5 -lasn1 -lcrypto -lcom_err -lkafs"
+    LIBS="$LIBS -L$GSSAPI/lib -lgssapi -lkrb -lkrb5 -lasn1 -lcrypto -lcom_err -lkafs"
   else
     LIBS="$LIBS -L$GSSAPI/lib -lgssapi_krb5 -lkrb -lkrb5 -lcrypto -lcom_err -lkafs"
   fi
@@ -3598,7 +4029,7 @@ EOF
   CPPFLAGS="-I$GSSAPI/include/kerberosV $CPPFLAGS"
   if test "$ac_cv_header_gssapi_h" = "yes"; then
     cat > conftest.$ac_ext <<EOF
-#line 3602 "configure"
+#line 4033 "configure"
 #include "confdefs.h"
 #include <gssapi.h>
 EOF
@@ -3614,7 +4045,7 @@ rm -f conftest*
 
   else
     cat > conftest.$ac_ext <<EOF
-#line 3618 "configure"
+#line 4049 "configure"
 #include "confdefs.h"
 #include <gssapi/gssapi.h>
 EOF
@@ -3633,7 +4064,7 @@ rm -f conftest*
   # This is necessary on Irix 5.3, in order to link against libkrb5 --
   # there, an_to_ln.o refers to things defined only in -lgen.
   echo $ac_n "checking for compile in -lgen""... $ac_c" 1>&6
-echo "configure:3637: checking for compile in -lgen" >&5
+echo "configure:4068: checking for compile in -lgen" >&5
 ac_lib_var=`echo gen'_'compile | sed 'y%./+-%__p_%'`
 if eval "test \"`echo '$''{'ac_cv_lib_$ac_lib_var'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
@@ -3641,7 +4072,7 @@ else
   ac_save_LIBS="$LIBS"
 LIBS="-lgen  $LIBS"
 cat > conftest.$ac_ext <<EOF
-#line 3645 "configure"
+#line 4076 "configure"
 #include "confdefs.h"
 /* Override any gcc2 internal prototype to avoid an error.  */
 /* We use char because int might match the return type of a gcc2
@@ -3652,7 +4083,7 @@ int main() {
 compile()
 ; return 0; }
 EOF
-if { (eval echo configure:3656: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
+if { (eval echo configure:4087: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
   rm -rf conftest*
   eval "ac_cv_lib_$ac_lib_var=yes"
 else
@@ -3681,6 +4112,121 @@ fi
 
 fi
 
+if test -n "$krb_h"; then
+  if test -n "$krb_lib"; then
+    cat >> confdefs.h <<\EOF
+#define HAVE_KERBEROS 1
+EOF
+
+    test -n "${krb_libdir}" && LIBS="${LIBS} -L${krb_libdir}"
+    LIBS="${LIBS} -lkrb"
+    # Put -L${krb_libdir} in LDFLAGS temporarily so that it appears before
+    # -ldes in the command line.  Don't do it permanently so that we honor
+    # the user's setting for LDFLAGS
+    hold_ldflags=$LDFLAGS
+    test -n "${krb_libdir}" && LDFLAGS="$LDFLAGS -L${krb_libdir}"
+    echo $ac_n "checking for printf in -ldes""... $ac_c" 1>&6
+echo "configure:4130: checking for printf in -ldes" >&5
+ac_lib_var=`echo des'_'printf | sed 'y%./+-%__p_%'`
+if eval "test \"`echo '$''{'ac_cv_lib_$ac_lib_var'+set}'`\" = set"; then
+  echo $ac_n "(cached) $ac_c" 1>&6
+else
+  ac_save_LIBS="$LIBS"
+LIBS="-ldes  $LIBS"
+cat > conftest.$ac_ext <<EOF
+#line 4138 "configure"
+#include "confdefs.h"
+/* Override any gcc2 internal prototype to avoid an error.  */
+/* We use char because int might match the return type of a gcc2
+    builtin and then its argument prototype would still apply.  */
+char printf();
+
+int main() {
+printf()
+; return 0; }
+EOF
+if { (eval echo configure:4149: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
+  rm -rf conftest*
+  eval "ac_cv_lib_$ac_lib_var=yes"
+else
+  echo "configure: failed program was:" >&5
+  cat conftest.$ac_ext >&5
+  rm -rf conftest*
+  eval "ac_cv_lib_$ac_lib_var=no"
+fi
+rm -f conftest*
+LIBS="$ac_save_LIBS"
+
+fi
+if eval "test \"`echo '$ac_cv_lib_'$ac_lib_var`\" = yes"; then
+  echo "$ac_t""yes" 1>&6
+  LIBS="${LIBS} -ldes"
+else
+  echo "$ac_t""no" 1>&6
+fi
+
+    LDFLAGS=$hold_ldflags
+    if test -n "$krb_incdir"; then
+      includeopt="${includeopt} -I$krb_incdir"
+    fi
+  fi
+fi
+for ac_func in krb_get_err_text
+do
+echo $ac_n "checking for $ac_func""... $ac_c" 1>&6
+echo "configure:4178: checking for $ac_func" >&5
+if eval "test \"`echo '$''{'ac_cv_func_$ac_func'+set}'`\" = set"; then
+  echo $ac_n "(cached) $ac_c" 1>&6
+else
+  cat > conftest.$ac_ext <<EOF
+#line 4183 "configure"
+#include "confdefs.h"
+/* System header to define __stub macros and hopefully few prototypes,
+    which can conflict with char $ac_func(); below.  */
+#include <assert.h>
+/* Override any gcc2 internal prototype to avoid an error.  */
+/* We use char because int might match the return type of a gcc2
+    builtin and then its argument prototype would still apply.  */
+char $ac_func();
+
+int main() {
+
+/* The GNU C library defines this for functions which it implements
+    to always fail with ENOSYS.  Some functions are actually named
+    something starting with __ and the normal name is an alias.  */
+#if defined (__stub_$ac_func) || defined (__stub___$ac_func)
+choke me
+#else
+$ac_func();
+#endif
+
+; return 0; }
+EOF
+if { (eval echo configure:4206: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
+  rm -rf conftest*
+  eval "ac_cv_func_$ac_func=yes"
+else
+  echo "configure: failed program was:" >&5
+  cat conftest.$ac_ext >&5
+  rm -rf conftest*
+  eval "ac_cv_func_$ac_func=no"
+fi
+rm -f conftest*
+fi
+
+if eval "test \"`echo '$ac_cv_func_'$ac_func`\" = yes"; then
+  echo "$ac_t""yes" 1>&6
+    ac_tr_func=HAVE_`echo $ac_func | tr 'abcdefghijklmnopqrstuvwxyz' 'ABCDEFGHIJKLMNOPQRSTUVWXYZ'`
+  cat >> confdefs.h <<EOF
+#define $ac_tr_func 1
+EOF
+ 
+else
+  echo "$ac_t""no" 1>&6
+fi
+done
+
+
 # Check whether --enable-encryption or --disable-encryption was given.
 if test "${enable_encryption+set}" = set; then
   enableval="$enable_encryption"
@@ -3701,12 +4247,12 @@ EOF
 fi
 
 echo $ac_n "checking for gethostname""... $ac_c" 1>&6
-echo "configure:3705: checking for gethostname" >&5
+echo "configure:4251: checking for gethostname" >&5
 if eval "test \"`echo '$''{'ac_cv_func_gethostname'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
   cat > conftest.$ac_ext <<EOF
-#line 3710 "configure"
+#line 4256 "configure"
 #include "confdefs.h"
 /* System header to define __stub macros and hopefully few prototypes,
     which can conflict with char gethostname(); below.  */
@@ -3729,7 +4275,7 @@ gethostname();
 
 ; return 0; }
 EOF
-if { (eval echo configure:3733: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
+if { (eval echo configure:4279: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
   rm -rf conftest*
   eval "ac_cv_func_gethostname=yes"
 else
@@ -3808,12 +4354,12 @@ if test "$enable_server" = yes; then
 for ac_func in crypt
 do
 echo $ac_n "checking for $ac_func""... $ac_c" 1>&6
-echo "configure:3812: checking for $ac_func" >&5
+echo "configure:4358: checking for $ac_func" >&5
 if eval "test \"`echo '$''{'ac_cv_func_$ac_func'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
   cat > conftest.$ac_ext <<EOF
-#line 3817 "configure"
+#line 4363 "configure"
 #include "confdefs.h"
 /* System header to define __stub macros and hopefully few prototypes,
     which can conflict with char $ac_func(); below.  */
@@ -3836,7 +4382,7 @@ $ac_func();
 
 ; return 0; }
 EOF
-if { (eval echo configure:3840: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
+if { (eval echo configure:4386: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
   rm -rf conftest*
   eval "ac_cv_func_$ac_func=yes"
 else
@@ -3862,7 +4408,7 @@ done
 
 if test "$ac_cv_func_crypt" = no; then
 echo $ac_n "checking for crypt in -lcrypt""... $ac_c" 1>&6
-echo "configure:3866: checking for crypt in -lcrypt" >&5
+echo "configure:4412: checking for crypt in -lcrypt" >&5
 ac_lib_var=`echo crypt'_'crypt | sed 'y%./+-%__p_%'`
 if eval "test \"`echo '$''{'ac_cv_lib_$ac_lib_var'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
@@ -3870,7 +4416,7 @@ else
   ac_save_LIBS="$LIBS"
 LIBS="-lcrypt  $LIBS"
 cat > conftest.$ac_ext <<EOF
-#line 3874 "configure"
+#line 4420 "configure"
 #include "confdefs.h"
 /* Override any gcc2 internal prototype to avoid an error.  */
 /* We use char because int might match the return type of a gcc2
@@ -3881,7 +4427,7 @@ int main() {
 crypt()
 ; return 0; }
 EOF
-if { (eval echo configure:3885: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
+if { (eval echo configure:4431: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
   rm -rf conftest*
   eval "ac_cv_lib_$ac_lib_var=yes"
 else
@@ -3911,12 +4457,12 @@ fi
 for ac_func in crypt
 do
 echo $ac_n "checking for $ac_func""... $ac_c" 1>&6
-echo "configure:3915: checking for $ac_func" >&5
+echo "configure:4461: checking for $ac_func" >&5
 if eval "test \"`echo '$''{'ac_cv_func_$ac_func'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
   cat > conftest.$ac_ext <<EOF
-#line 3920 "configure"
+#line 4466 "configure"
 #include "confdefs.h"
 /* System header to define __stub macros and hopefully few prototypes,
     which can conflict with char $ac_func(); below.  */
@@ -3939,7 +4485,7 @@ $ac_func();
 
 ; return 0; }
 EOF
-if { (eval echo configure:3943: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
+if { (eval echo configure:4489: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
   rm -rf conftest*
   eval "ac_cv_func_$ac_func=yes"
 else
@@ -3975,19 +4521,19 @@ fi # enable_server
 
 
 echo $ac_n "checking for cygwin32""... $ac_c" 1>&6
-echo "configure:3979: checking for cygwin32" >&5
+echo "configure:4525: checking for cygwin32" >&5
 if eval "test \"`echo '$''{'ccvs_cv_sys_cygwin32'+set}'`\" = set"; then
   echo $ac_n "(cached) $ac_c" 1>&6
 else
   cat > conftest.$ac_ext <<EOF
-#line 3984 "configure"
+#line 4530 "configure"
 #include "confdefs.h"
 
 int main() {
 return __CYGWIN32__;
 ; return 0; }
 EOF
-if { (eval echo configure:3991: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then
+if { (eval echo configure:4537: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then
   rm -rf conftest*
   ccvs_cv_sys_cygwin32=yes
 else
@@ -4089,19 +4635,7 @@ fi
 
 trap 'rm -f $CONFIG_STATUS conftest*; exit 1' 1 2 15
 
-# Transform confdefs.h into DEFS.
-# Protect against shell expansion while executing Makefile rules.
-# Protect against Makefile macro expansion.
-cat > conftest.defs <<\EOF
-s%#define \([A-Za-z_][A-Za-z0-9_]*\) *\(.*\)%-D\1=\2%g
-s%[ 	`~#$^&*(){}\\|;'"<>?]%\\&%g
-s%\[%\\&%g
-s%\]%\\&%g
-s%\$%$$%g
-EOF
-DEFS=`sed -f conftest.defs confdefs.h | tr '\012' ' '`
-rm -f conftest.defs
-
+DEFS=-DHAVE_CONFIG_H
 
 # Without the "./", some shells look in PATH for config.status.
 : ${CONFIG_STATUS=./config.status}
@@ -4162,7 +4696,7 @@ trap 'rm -fr `echo "Makefile \
 	  vms/Makefile \
 	  windows-NT/Makefile \
 	  windows-NT/SCC/Makefile \
-	  zlib/Makefile" | sed "s/:[^ ]*//g"` conftest*; exit 1' 1 2 15
+	  zlib/Makefile config.h src/options.h" | sed "s/:[^ ]*//g"` conftest*; exit 1' 1 2 15
 EOF
 cat >> $CONFIG_STATUS <<EOF
 
@@ -4194,13 +4728,35 @@ s%@includedir@%$includedir%g
 s%@oldincludedir@%$oldincludedir%g
 s%@infodir@%$infodir%g
 s%@mandir@%$mandir%g
-s%@CVS@%$CVS%g
-s%@AWK@%$AWK%g
-s%@CC@%$CC%g
 s%@INSTALL_PROGRAM@%$INSTALL_PROGRAM%g
 s%@INSTALL_SCRIPT@%$INSTALL_SCRIPT%g
 s%@INSTALL_DATA@%$INSTALL_DATA%g
+s%@PACKAGE@%$PACKAGE%g
+s%@VERSION@%$VERSION%g
+s%@ACLOCAL@%$ACLOCAL%g
+s%@AUTOCONF@%$AUTOCONF%g
+s%@AUTOMAKE@%$AUTOMAKE%g
+s%@AUTOHEADER@%$AUTOHEADER%g
+s%@MAKEINFO@%$MAKEINFO%g
+s%@AMTAR@%$AMTAR%g
+s%@install_sh@%$install_sh%g
+s%@STRIP@%$STRIP%g
+s%@INSTALL_STRIP_PROGRAM@%$INSTALL_STRIP_PROGRAM%g
+s%@INSTALL_STRIP_PROGRAM_ENV@%$INSTALL_STRIP_PROGRAM_ENV%g
+s%@AWK@%$AWK%g
 s%@SET_MAKE@%$SET_MAKE%g
+s%@ETAGS@%$ETAGS%g
+s%@ETAGS_INCLUDE_OPTION@%$ETAGS_INCLUDE_OPTION%g
+s%@AMDEP_TRUE@%$AMDEP_TRUE%g
+s%@AMDEP_FALSE@%$AMDEP_FALSE%g
+s%@AMDEPBACKSLASH@%$AMDEPBACKSLASH%g
+s%@DEPDIR@%$DEPDIR%g
+s%@CVS@%$CVS%g
+s%@CC@%$CC%g
+s%@CPP@%$CPP%g
+s%@_am_include@%$_am_include%g
+s%@_am_quote@%$_am_quote%g
+s%@CCDEPMODE@%$CCDEPMODE%g
 s%@RANLIB@%$RANLIB%g
 s%@YACC@%$YACC%g
 s%@LN_S@%$LN_S%g
@@ -4210,11 +4766,13 @@ s%@PR@%$PR%g
 s%@ROFF@%$ROFF%g
 s%@PS2PDF@%$PS2PDF%g
 s%@TEXI2DVI@%$TEXI2DVI%g
-s%@CPP@%$CPP%g
+s%@MAKE_TARGETS_IN_VPATH_TRUE@%$MAKE_TARGETS_IN_VPATH_TRUE%g
+s%@MAKE_TARGETS_IN_VPATH_FALSE@%$MAKE_TARGETS_IN_VPATH_FALSE%g
 s%@LIBOBJS@%$LIBOBJS%g
 s%@ZLIB@%$ZLIB%g
 s%@ZLIBSUBDIRS@%$ZLIBSUBDIRS%g
 s%@ZLIB_INCLUDES@%$ZLIB_INCLUDES%g
+s%@ZLIB_DEPEND@%$ZLIB_DEPEND%g
 s%@KRB4@%$KRB4%g
 s%@includeopt@%$includeopt%g
 s%@GSSAPI@%$GSSAPI%g
@@ -4341,11 +4899,179 @@ s%@INSTALL@%$INSTALL%g
 fi; done
 rm -f conftest.s*
 
+# These sed commands are passed to sed as "A NAME B NAME C VALUE D", where
+# NAME is the cpp macro being defined and VALUE is the value it is being given.
+#
+# ac_d sets the value in "#define NAME VALUE" lines.
+ac_dA='s%^\([ 	]*\)#\([ 	]*define[ 	][ 	]*\)'
+ac_dB='\([ 	][ 	]*\)[^ 	]*%\1#\2'
+ac_dC='\3'
+ac_dD='%g'
+# ac_u turns "#undef NAME" with trailing blanks into "#define NAME VALUE".
+ac_uA='s%^\([ 	]*\)#\([ 	]*\)undef\([ 	][ 	]*\)'
+ac_uB='\([ 	]\)%\1#\2define\3'
+ac_uC=' '
+ac_uD='\4%g'
+# ac_e turns "#undef NAME" without trailing blanks into "#define NAME VALUE".
+ac_eA='s%^\([ 	]*\)#\([ 	]*\)undef\([ 	][ 	]*\)'
+ac_eB='$%\1#\2define\3'
+ac_eC=' '
+ac_eD='%g'
+
+if test "${CONFIG_HEADERS+set}" != set; then
 EOF
 cat >> $CONFIG_STATUS <<EOF
+  CONFIG_HEADERS="config.h src/options.h"
+EOF
+cat >> $CONFIG_STATUS <<\EOF
+fi
+for ac_file in .. $CONFIG_HEADERS; do if test "x$ac_file" != x..; then
+  # Support "outfile[:infile[:infile...]]", defaulting infile="outfile.in".
+  case "$ac_file" in
+  *:*) ac_file_in=`echo "$ac_file"|sed 's%[^:]*:%%'`
+       ac_file=`echo "$ac_file"|sed 's%:.*%%'` ;;
+  *) ac_file_in="${ac_file}.in" ;;
+  esac
+
+  echo creating $ac_file
+
+  rm -f conftest.frag conftest.in conftest.out
+  ac_file_inputs=`echo $ac_file_in|sed -e "s%^%$ac_given_srcdir/%" -e "s%:% $ac_given_srcdir/%g"`
+  cat $ac_file_inputs > conftest.in
 
 EOF
+
+# Transform confdefs.h into a sed script conftest.vals that substitutes
+# the proper values into config.h.in to produce config.h.  And first:
+# Protect against being on the right side of a sed subst in config.status.
+# Protect against being in an unquoted here document in config.status.
+rm -f conftest.vals
+cat > conftest.hdr <<\EOF
+s/[\\&%]/\\&/g
+s%[\\$`]%\\&%g
+s%#define \([A-Za-z_][A-Za-z0-9_]*\) *\(.*\)%${ac_dA}\1${ac_dB}\1${ac_dC}\2${ac_dD}%gp
+s%ac_d%ac_u%gp
+s%ac_u%ac_e%gp
+EOF
+sed -n -f conftest.hdr confdefs.h > conftest.vals
+rm -f conftest.hdr
+
+# This sed command replaces #undef with comments.  This is necessary, for
+# example, in the case of _POSIX_SOURCE, which is predefined and required
+# on some systems where configure will not decide to define it.
+cat >> conftest.vals <<\EOF
+s%^[ 	]*#[ 	]*undef[ 	][ 	]*[a-zA-Z_][a-zA-Z_0-9]*%/* & */%
+EOF
+
+# Break up conftest.vals because some shells have a limit on
+# the size of here documents, and old seds have small limits too.
+
+rm -f conftest.tail
+while :
+do
+  ac_lines=`grep -c . conftest.vals`
+  # grep -c gives empty output for an empty file on some AIX systems.
+  if test -z "$ac_lines" || test "$ac_lines" -eq 0; then break; fi
+  # Write a limited-size here document to conftest.frag.
+  echo '  cat > conftest.frag <<CEOF' >> $CONFIG_STATUS
+  sed ${ac_max_here_lines}q conftest.vals >> $CONFIG_STATUS
+  echo 'CEOF
+  sed -f conftest.frag conftest.in > conftest.out
+  rm -f conftest.in
+  mv conftest.out conftest.in
+' >> $CONFIG_STATUS
+  sed 1,${ac_max_here_lines}d conftest.vals > conftest.tail
+  rm -f conftest.vals
+  mv conftest.tail conftest.vals
+done
+rm -f conftest.vals
+
 cat >> $CONFIG_STATUS <<\EOF
+  rm -f conftest.frag conftest.h
+  echo "/* $ac_file.  Generated automatically by configure.  */" > conftest.h
+  cat conftest.in >> conftest.h
+  rm -f conftest.in
+  if cmp -s $ac_file conftest.h 2>/dev/null; then
+    echo "$ac_file is unchanged"
+    rm -f conftest.h
+  else
+    # Remove last slash and all that follows it.  Not all systems have dirname.
+      ac_dir=`echo $ac_file|sed 's%/[^/][^/]*$%%'`
+      if test "$ac_dir" != "$ac_file" && test "$ac_dir" != .; then
+      # The file is in a subdirectory.
+      test ! -d "$ac_dir" && mkdir "$ac_dir"
+    fi
+    rm -f $ac_file
+    mv conftest.h $ac_file
+  fi
+fi; done
+
+EOF
+cat >> $CONFIG_STATUS <<EOF
+am_indx=1
+for am_file in config.h src/options.h; do
+  case " \$CONFIG_HEADERS " in
+  *" \$am_file "*)
+    am_dir=\`echo \$am_file |sed 's%:.*%%;s%[^/]*\$%%'\`
+    if test -n "\$am_dir"; then
+      am_tmpdir=\`echo \$am_dir |sed 's%^\(/*\).*\$%\1%'\`
+      for am_subdir in \`echo \$am_dir |sed 's%/% %'\`; do
+        am_tmpdir=\$am_tmpdir\$am_subdir/
+        if test ! -d \$am_tmpdir; then
+          mkdir \$am_tmpdir
+        fi
+      done
+    fi
+    echo timestamp > "\$am_dir"stamp-h\$am_indx
+    ;;
+  esac
+  am_indx=\`expr \$am_indx + 1\`
+done
+AMDEP="$AMDEP"
+ac_aux_dir="$ac_aux_dir"
+
+EOF
+cat >> $CONFIG_STATUS <<\EOF
+
+
+test x"$AMDEP" != x"" ||
+for mf in $CONFIG_FILES; do
+  case "$mf" in
+  Makefile) dirpart=.;;
+  */Makefile) dirpart=`echo "$mf" | sed -e 's|/[^/]*$||'`;;
+  *) continue;;
+  esac
+  grep '^DEP_FILES *= *[^ #]' < "$mf" > /dev/null || continue
+  # Extract the definition of DEP_FILES from the Makefile without
+  # running `make'.
+  DEPDIR=`sed -n -e '/^DEPDIR = / s///p' < "$mf"`
+  test -z "$DEPDIR" && continue
+  # When using ansi2knr, U may be empty or an underscore; expand it
+  U=`sed -n -e '/^U = / s///p' < "$mf"`
+  test -d "$dirpart/$DEPDIR" || mkdir "$dirpart/$DEPDIR"
+  # We invoke sed twice because it is the simplest approach to
+  # changing $(DEPDIR) to its actual value in the expansion.
+  for file in `sed -n -e '
+    /^DEP_FILES = .*\\\\$/ {
+      s/^DEP_FILES = //
+      :loop
+	s/\\\\$//
+	p
+	n
+	/\\\\$/ b loop
+      p
+    }
+    /^DEP_FILES = / s/^DEP_FILES = //p' < "$mf" | \
+       sed -e 's/\$(DEPDIR)/'"$DEPDIR"'/g' -e 's/\$U/'"$U"'/g'`; do
+    # Make sure the directory exists.
+    test -f "$dirpart/$file" && continue
+    fdir=`echo "$file" | sed -e 's|/[^/]*$||'`
+    $ac_aux_dir/mkinstalldirs "$dirpart/$fdir" > /dev/null 2>&1
+    # echo "creating $dirpart/$file"
+    echo '# dummy' > "$dirpart/$file"
+  done
+done
+
 chmod -f +x \
 	  contrib/clmerge \
 	  contrib/cln_hist \
diff --git a/gnu/usr.bin/cvs/configure.in b/gnu/usr.bin/cvs/configure.in
index 883136813a5..2e86f5b5e0c 100644
--- a/gnu/usr.bin/cvs/configure.in
+++ b/gnu/usr.bin/cvs/configure.in
@@ -169,10 +169,11 @@ AC_SEARCH_LIBS(getspnam, sec gen, AC_DEFINE(HAVE_GETSPNAM))
 dnl
 dnl Check for a system libz.
 dnl
-AC_CHECK_LIB(z, zlibVersion, ZLIB=-lz , ZLIBSUBDIRS=zlib ZLIB=$srcdir/zlib/libz.a ZLIB_INCLUDES=-I$srcdir/zlib)
+AC_CHECK_LIB(z, zlibVersion, ZLIB=-lz ZLIB_DEPEND=/usr/lib/libz.a, ZLIBSUBDIRS=zlib ZLIB=$srcdir/zlib/libz.a ZLIB_DEPEND=$srcdir/zlib/libz.a ZLIB_INCLUDES=-I$srcdir/zlib)
 AC_SUBST(ZLIB)
 AC_SUBST(ZLIBSUBDIRS)
 AC_SUBST(ZLIB_INCLUDES)
+AC_SUBST(ZLIB_DEPEND)
 
 dnl We always use CVS's regular expression matcher.
 dnl This is because:
@@ -267,23 +268,7 @@ if test -n "$krb_h"; then
   else
        AC_CHECK_LIB(krb,printf,[krb_lib=yes krb_libdir=])
   fi
-  if test -n "$krb_lib"; then
-    AC_DEFINE(HAVE_KERBEROS)
-    test -n "${krb_libdir}" && LIBS="${LIBS} -L${krb_libdir}"
-    LIBS="${LIBS} -lkrb"
-    # Put -L${krb_libdir} in LDFLAGS temporarily so that it appears before
-    # -ldes in the command line.  Don't do it permanently so that we honor
-    # the user's setting for LDFLAGS
-    hold_ldflags=$LDFLAGS
-    test -n "${krb_libdir}" && LDFLAGS="$LDFLAGS -L${krb_libdir}"
-    AC_CHECK_LIB(des,printf,[LIBS="${LIBS} -ldes"])
-    LDFLAGS=$hold_ldflags
-    if test -n "$krb_incdir"; then
-      includeopt="${includeopt} -I$krb_incdir"
-    fi
-  fi
 fi
-AC_CHECK_FUNCS(krb_get_err_text)
 
 dnl
 dnl Use --with-gssapi=DIR to enable GSSAPI support.
@@ -310,7 +295,7 @@ if test "$ac_cv_header_krb5_h" = "yes" &&
   includeopt="${includeopt} -I$GSSAPI/include/kerberosV"
   # FIXME: This is ugly, but these things don't seem to be standardized.
   if test "$ac_cv_header_gssapi_h" = "yes"; then
-    LIBS="$LIBS -L$GSSAPI/lib -lgssapi -lkrb lkrb5 -lasn1 -lcrypto -lcom_err -lkafs"
+    LIBS="$LIBS -L$GSSAPI/lib -lgssapi -lkrb -lkrb5 -lasn1 -lcrypto -lcom_err -lkafs"
   else
     LIBS="$LIBS -L$GSSAPI/lib -lgssapi_krb5 -lkrb -lkrb5 -lcrypto -lcom_err -lkafs"
   fi
@@ -327,6 +312,25 @@ if test "$ac_cv_header_krb5_h" = "yes" &&
   AC_CHECK_LIB(gen, compile)
 fi
 
+if test -n "$krb_h"; then
+  if test -n "$krb_lib"; then
+    AC_DEFINE(HAVE_KERBEROS)
+    test -n "${krb_libdir}" && LIBS="${LIBS} -L${krb_libdir}"
+    LIBS="${LIBS} -lkrb"
+    # Put -L${krb_libdir} in LDFLAGS temporarily so that it appears before
+    # -ldes in the command line.  Don't do it permanently so that we honor
+    # the user's setting for LDFLAGS
+    hold_ldflags=$LDFLAGS
+    test -n "${krb_libdir}" && LDFLAGS="$LDFLAGS -L${krb_libdir}"
+    AC_CHECK_LIB(des,printf,[LIBS="${LIBS} -ldes"])
+    LDFLAGS=$hold_ldflags
+    if test -n "$krb_incdir"; then
+      includeopt="${includeopt} -I$krb_incdir"
+    fi
+  fi
+fi
+AC_CHECK_FUNCS(krb_get_err_text)
+
 dnl
 dnl Use --with-encryption to turn on encryption support
 dnl
diff --git a/gnu/usr.bin/cvs/doc/cvs.info-3 b/gnu/usr.bin/cvs/doc/cvs.info-3
index 946feae29c8..ada6dd98f78 100644
--- a/gnu/usr.bin/cvs/doc/cvs.info-3
+++ b/gnu/usr.bin/cvs/doc/cvs.info-3
@@ -1,5 +1,8 @@
-This is Info file cvs.info, produced by Makeinfo-1.55 from the input
-file ./cvs.texinfo.
+This is cvs.info, produced by makeinfo version 4.0 from cvs.texinfo.
+
+START-INFO-DIR-ENTRY
+* CVS: (cvs).          Concurrent Versions System
+END-INFO-DIR-ENTRY
 
    Copyright (C) 1992, 1993 Signum Support AB Copyright (C) 1993, 1994
 Free Software Foundation, Inc.
@@ -10,1419 +13,1245 @@ preserved on all copies.
 
    Permission is granted to copy and distribute modified versions of
 this manual under the conditions for verbatim copying, provided also
-that the section entitled "GNU General Public License" is included
-exactly as in the original, and provided that the entire resulting
-derived work is distributed under the terms of a permission notice
-identical to this one.
+that the entire resulting derived work is distributed under the terms
+of a permission notice identical to this one.
 
    Permission is granted to copy and distribute translations of this
 manual into another language, under the above conditions for modified
-versions, except that the section entitled "GNU General Public License"
-and this permission notice may be included in translations approved by
-the Free Software Foundation instead of in the original English.
-
-
-File: cvs.info,  Node: add options,  Next: add examples,  Up: add
-
-add options
------------
-
-   There are only two options you can give to `add':
-
-`-k KFLAG'
-     This option specifies the default way that this file will be
-     checked out.  See rcs(1) and co(1).  The KFLAG argument (*note
-     Substitution modes::.) is stored in the RCS file and can be
-     changed with `admin -k' (*note admin options::.).  Specifying
-     `-ko' is useful for checking in binaries that should not have the
-     RCS id strings expanded.
-
-     *Warning:* this option is reported to be broken in version 1.3 and
-     1.3-s2 of CVS.  Use `admin -k' after the commit instead.  *Note
-     admin examples::.
-
-`-m DESCRIPTION'
-     Using this option, you can give a description for the file.  This
-     description appears in the history log (if it is enabled, *note
-     history file::.).  It will also be saved in the RCS history file
-     inside the repository when the file is committed.  The `log'
-     command displays this description.
-
-     The description can be changed using `admin -t'.  *Note admin::.
-
-     If you omit the `-m DESCRIPTION' flag, an empty string will be
-     used.  You will not be prompted for a description.
-
-
-File: cvs.info,  Node: add examples,  Prev: add options,  Up: add
-
-add examples
-------------
-
-   To add the file `backend.c' to the repository, with a description,
-the following can be used.
-
-     $ cvs add -m "Optimizer and code generation passes." backend.c
-     $ cvs commit -m "Early version. Not yet compilable." backend.c
-
-
-File: cvs.info,  Node: admin,  Next: checkout,  Prev: add,  Up: Invoking CVS
-
-admin--Administration front end for rcs
-=======================================
-
-   * Requires: repository, working directory.
-
-   * Changes: repository.
-
-   * Synonym: rcs
-
-   This is the CVS interface to assorted administrative RCS facilities,
-documented in rcs(1).  `admin' simply passes all its options and
-arguments to the `rcs' command; it does no filtering or other
-processing.  This command *does* work recursively, however, so extreme
-care should be used.
-
-* Menu:
-
-* admin options::               admin options
-* admin examples::              admin examples
+versions, except that this permission notice may be stated in a
+translation approved by the Free Software Foundation.
 
 
-File: cvs.info,  Node: admin options,  Next: admin examples,  Up: admin
-
-admin options
--------------
-
-   Not all valid `rcs' options are useful together with CVS.  Some even
-makes it impossible to use CVS until you undo the effect!
-
-   This description of the available options is based on the `rcs(1)'
-man page, but modified to suit readers that are more interrested in CVS
-than RCS.
-
-`-AOLDFILE'
-     Might not work together with CVS.  Append the access list of
-     OLDFILE to the access list of the RCS file.
-
-`-aLOGINS'
-     Might not work together with CVS.  Append the login names
-     appearing in the comma-separated list LOGINS to the access list of
-     the RCS file.
-
-`-b[REV]'
-     Breaks CVS.  When used with bare RCS, this option sets the default
-     branch to REV.  If REV is omitted, the default branch is reset to
-     the (dynamically) highest branch on the trunk.  Use sticky tags
-     instead, as in `cvs co -r'.  *Note Sticky tags::.
-
-`-cSTRING'
-     Useful with CVS.  Sets the comment leader to STRING.  The comment
-     leader is printed before every log message line generated by the
-     keyword `$Log: cvs.info-3,v $
-     keyword `Revision 1.1  1995/12/19 09:21:39  deraadt
-     keyword `Initial revision
-     keyword `' (*note Keyword substitution::.).  This is useful
-     for programming languages without multi-line comments.  RCS
-     initially guesses the value of the comment leader from the file
-     name extension when the file is first committed.
-
-`-e[LOGINS]'
-     Might not work together with CVS.  Erase the login names appearing
-     in the comma-separated list LOGINS from the access list of the RCS
-     file.  If LOGINS is omitted, erase the entire access list.
-
-`-I'
-     Run interactively, even if the standard input is not a terminal.
-
-`-i'
-     Useless with CVS.  When using bare RCS, this is used to create and
-     initialize a new RCS file, without depositing a revision.
-
-`-kSUBST'
-     Useful with CVS.  Set the default keyword substitution to SUBST.
-     *Note Keyword substitution::.  Giving an explicit `-k' option to
-     `cvs update' or `cvs checkout' overrides this default.  `cvs
-     export' always uses `-kv', regardless of which keyword
-     substitution is set with `cvs admin'.
-
-`-l[REV]'
-     Probably useless with CVS.  With bare RCS, this option can be used
-     to lock the revision with number REV.  If a branch is given, lock
-     the latest revision on that branch.  If REV is omitted, lock the
-     latest revision on the default branch.
-
-`-L'
-     Probably useless with CVS.  Used with bare RCS to set locking to
-     strict.  Strict locking means that the owner of an RCS file is not
-     exempt from locking for checkin.
-
-`-mREV:MSG'
-     Replace the log message of revision REV with MSG.
-
-`-NNAME[:[REV]]'
-     Act like `-n', except override any previous assignment of NAME.
-
-`-nNAME[:[REV]]'
-     Associate the symbolic name NAME with the branch or revision REV.
-     It is normally better to use `cvs tag' or `cvs rtag' instead.
-     Delete the symbolic name if both `:' and REV are omitted;
-     otherwise, print an error message if NAME is already associated
-     with another number.  If REV is symbolic, it is expanded before
-     association.  A REV consisting of a branch number followed by a
-     `.' stands for the current latest revision in the branch.  A `:'
-     with an empty REV stands for the current latest revision on the
-     default branch, normally the trunk.  For example, `rcs -nNAME:
-     RCS/*' associates NAME with the current latest revision of all the
-     named RCS files; this contrasts with `rcs -nNAME:$ RCS/*' which
-     associates NAME with the revision numbers extracted from keyword
-     strings in the corresponding working files.
-
-`-oRANGE'
-     Useful, but dangerous, with CVS (see below).  Deletes ("outdates")
-     the revisions given by RANGE.  A range consisting of a single
-     revision number means that revision.  A range consisting of a
-     branch number means the latest revision on that branch.  A range
-     of the form `REV1:REV2' means revisions REV1 to REV2 on the same
-     branch, `:REV' means from the beginning of the branch containing
-     REV up to and including REV, and `REV:' means from revision REV to
-     the end of the branch containing REV.  None of the outdated
-     revisions may have branches or locks.
-
-     Due to the way CVS handles branches REV cannot be specified
-     symbolically if it is a branch.  *Note Magic branch numbers::, for
-     an explanation.
-
-     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, you should never use
-     this option to take back a bogus commit unless you work alone.
-     Instead, you should fix the file and commit a new revision.
-
-`-q'
-     Run quietly; do not print diagnostics.
-
-`-sSTATE[:REV]'
-     Useful with CVS.  Set the state attribute of the revision REV to
-     STATE.  If REV is a branch number, assume the latest revision on
-     that branch.  If REV is omitted, assume the latest revision on the
-     default branch.  Any identifier is acceptable for STATE.  A useful
-     set of states is `Exp' (for experimental), `Stab' (for stable),
-     and `Rel' (for released).  By default, the state of a new revision
-     is set to `Exp' when it is created.  The state is visible in the
-     output from CVS LOG (*note log::.), and in the `$Log: cvs.info-3,v $
-     output from CVS LOG (*note log::.), and in the `Revision 1.1  1995/12/19 09:21:39  deraadt
-     output from CVS LOG (*note log::.), and in the `Initial revision
-     output from CVS LOG (*note log::.), and in the `' and
-     `$State: Exp $' keywords (*note Keyword substitution::.).
-
-`-t[FILE]'
-     Useful with CVS.  Write descriptive text from the contents of the
-     named FILE into the RCS file, deleting the existing text.  The
-     FILE pathname may not begin with `-'.  If FILE is omitted, obtain
-     the text from standard input, terminated by end-of-file or by a
-     line containing `.' by itself.  Prompt for the text if interaction
-     is possible; see `-I'.  The descriptive text can be seen in the
-     output from `cvs log' (*note log::.).
-
-`-t-STRING'
-     Similar to `-tFILE'. Write descriptive text from the STRING into
-     the RCS file, deleting the existing text.
-
-`-U'
-     Probably useless with CVS.  Used with bare RCS to set locking to
-     non-strict.  Non-strict locking means that the owner of a file
-     need not lock a revision for checkin.
-
-`-u[REV]'
-     Probably useless with CVS.  With bare RCS, unlock the revision
-     with number REV.  If a branch is given, unlock the latest revision
-     on that branch.  If REV 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 a mail message to be sent to the original locker.  The
-     message contains a commentary solicited from the breaker.  The
-     commentary is terminated by end-of-file or by a line containing
-     `.' by itself.
-
-`-VN'
-     Emulate RCS version N. Use -VN to make an RCS file acceptable to
-     RCS version N by discarding information that would confuse version
-     N.
-
-`-xSUFFIXES'
-     Useless with CVS. Use SUFFIXES to characterize RCS files.
+File: cvs.info,  Node: Tags,  Next: Tagging the working directory,  Prev: Assigning revisions,  Up: Revisions
+
+Tags-Symbolic revisions
+=======================
+
+   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 CVS the revision numbers might
+change several times between two releases.  As an example, some of the
+source files that make up RCS 5.6 have the following revision numbers:
+
+     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
+
+   You can use the `tag' command to give a symbolic name to a certain
+revision of a file.  You can use the `-v' flag to the `status' 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, `-', and `_'.
+The two tag names `BASE' and `HEAD' are reserved for use by CVS.  It is
+expected that future names which are special to CVS will be specially
+named, for example by starting with `.', rather than being named
+analogously to `BASE' and `HEAD', to avoid conflicts with actual tag
+names.
+
+   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 `.' changed to `-', so
+that CVS 1.9 would be tagged with the name `cvs1-9'.  If you choose a
+consistent convention, then you won't constantly be guessing whether a
+tag is `cvs-1-9' or `cvs1_9' or what.  You might even want to consider
+enforcing your convention in the taginfo file (*note user-defined
+logging::).
+
+   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 `backend.c' resides.
+
+     $ 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)
+
+   For a complete summary of the syntax of `cvs tag', including the
+various options, see *Note Invoking CVS::.
+
+   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.
+
+     $ cvs tag rel-1-0 .
+     cvs tag: Tagging .
+     T Makefile
+     T backend.c
+     T driver.c
+     T frontend.c
+     T parser.c
+
+   (When you give CVS 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.  *Note Recursive behavior::.)
+
+   The `checkout' command has a flag, `-r', 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 `tc' at any time in the
+future:
+
+     $ cvs checkout -r rel-1-0 tc
+
+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.
+
+   You can also check out a module as it was at any given date.  *Note
+checkout options::.  When specifying `-r' to any of these commands, you
+will need beware of sticky tags; see *Note Sticky tags::.
+
+   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:
+
+             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
+
+   At some time in the past, the `*' 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:
+
+             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
 
 
-File: cvs.info,  Node: admin examples,  Prev: admin options,  Up: admin
-
-admin examples
---------------
-
-Outdating is dangerous
-......................
-
-   First, an example of how *not* to use the `admin' command.  It is
-included to stress the fact that this command can be quite dangerous
-unless you know *exactly* what you are doing.
-
-   The `-o' option can be used to "outdate" old revisions from the
-history file.  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!
-
-   The next line is an example of a command that you would *not* like
-to execute.
-
-     $ cvs admin -o:R_1_02 .
-
-   The above command will delete all revisions up to, and including,
-the revision that corresponds to 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 *the same* 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!
-
-Handling binary files
-.....................
-
-   If you use CVS to store binary files, where keyword strings (*note
-Keyword substitution::.) might accidentally appear inside the file, you
-should use `cvs admin -ko' to make sure that they are not modified
-automatically.  Here is an example of how you can create a new file
-using the `-ko' flag:
-
-     $ echo '$Id: cvs.info-3,v 1.1 1995/12/19 09:21:39 deraadt Exp $' > kotest
-     $ cvs add -m"A test file" kotest
-     $ cvs ci -m"First checkin; contains a keyword" kotest
-     $ cvs admin -ko kotest
-     $ rm kotest
-     $ cvs update kotest
-
-   When you check in the file `kotest' the keywords are expanded.  (Try
-the above example, and do a `cat kotest' after every command!)  The `cvs
-admin -ko' command sets the default keyword substitution method for
-this file, but it does not alter the working copy of the file that you
-have.  The easiest way to get the unexpanded version of `kotest' is to
-remove it and check it out again.
-
-Comment leaders
-...............
-
-   If you use the `$Log: cvs.info-3,v $
-   If you use the `Revision 1.1  1995/12/19 09:21:39  deraadt
-   If you use the `Initial revision
-   If you use the `' keyword and you do not agree with the guess
-for comment leader that CVS has done, you can enforce your will with
-`cvs admin -c'.  This might be suitable for `nroff' source:
-
-     $ cvs admin -c'.\" ' *.man
-     $ rm *.man
-     $ cvs update
-
-   The two last steps are to make sure that you get the versions with
-correct comment leaders in your working files.
+File: cvs.info,  Node: Tagging the working directory,  Next: Tagging by date/tag,  Prev: Tags,  Up: Revisions
+
+Specifying what to tag from the working directory
+=================================================
+
+   The example in the previous section demonstrates one of the most
+common ways to choose which revisions to tag.  Namely, running the `cvs
+tag' command without arguments causes CVS to select the revisions which
+are checked out in the current working directory.  For example, if the
+copy of `backend.c' in working directory was checked out from revision
+1.4, then CVS 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 `cvs commit' to transfer that
+modification to the repository.
+
+   One potentially surprising aspect of the fact that `cvs tag'
+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
+`-c' option to `cvs tag'.  If there are any locally modified files, CVS
+will abort with an error before it tags any files:
+
+     $ cvs tag -c rel-0-4
+     cvs tag: backend.c is locally modified
+     cvs [tag aborted]: correct the above errors first!
 
 
-File: cvs.info,  Node: checkout,  Next: commit,  Prev: admin,  Up: Invoking CVS
-
-checkout--Check out sources for editing
-=======================================
-
-   * Synopsis: checkout [options] modules...
-
-   * Requires: repository.
-
-   * Changes: working directory.
+File: cvs.info,  Node: Tagging by date/tag,  Next: Modifying tags,  Prev: Tagging the working directory,  Up: Revisions
 
-   * Synonyms: co, get
-
-   Make a working directory containing copies of the source files
-specified by MODULES.  You must execute `checkout' before using most of
-the other CVS commands, since most of them operate on your working
-directory.
-
-   The MODULES part of the command 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
-`modules' file.  *Note modules::.
-
-   Depending on the modules you specify, `checkout' 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.
-
-   Note that `checkout' is used to create directories.  The top-level
-directory created is always added to the directory where `checkout' 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
-`checkout' will show the relative path leading to each file as it is
-extracted into your private work area (unless you specify the `-Q'
-global option).
-
-   Running `checkout' on a directory that was already built by a prior
-`checkout' is also permitted, and has the same effect as specifying the
-`-d' option to the `update' command, that is, any new directories that
-have been created in the repository will appear in your work area.
-*Note update::.
-
-* Menu:
-
-* checkout options::            checkout options
-* checkout examples::           checkout examples
-
-
-File: cvs.info,  Node: checkout options,  Next: checkout examples,  Up: checkout
+Specifying what to tag by date or revision
+==========================================
 
-checkout options
-----------------
+   The `cvs rtag' command tags the repository as of a certain date or
+time (or can be used to tag the latest revision).  `rtag' works
+directly on the repository contents (it requires no prior checkout and
+does not look for a working directory).
 
-   These standard options are supported by `checkout' (*note Common
-options::., for a complete description of them):
+   The following options specify which date or revision to tag.  See
+*Note Common options::, for a complete description of them.
 
 `-D DATE'
-     Use the most recent revision no later than DATE.  This option is
-     sticky, and implies `-P'.
+     Tag the most recent revision no later than DATE.
 
 `-f'
      Only useful with the `-D DATE' or `-r TAG' flags.  If no matching
-     revision is found, retrieve the most recent revision (instead of
+     revision is found, use the most recent revision (instead of
      ignoring the file).
 
-`-k KFLAG'
-     Process RCS keywords according to KFLAG.  See co(1).  This option
-     is sticky; future updates of this file in this working directory
-     will use the same KFLAG.  The `status' command can be viewed to
-     see the sticky options.  *Note status::.
-
-`-l'
-     Local; run only in current working directory.
-
-`-n'
-     Do not run any checkout program (as specified with the `-o' option
-     in the modules file; *note modules::.).
-
-`-P'
-     Prune empty directories.
-
-`-p'
-     Pipe files to the standard output.
-
 `-r TAG'
-     Use revision TAG.  This option is sticky, and implies `-P'.
-
-   In addition to those, you can use these special command options with
-`checkout':
-
-`-A'
-     Reset any sticky tags, dates, or `-k' options.  (If you get a
-     working file using one of the `-r', `-D', or `-k' options, CVS
-     remembers the corresponding tag, date, or KFLAG and continues using
-     it for future updates; use the `-A' option to make CVS forget
-     these specifications, and retrieve the `head' revision of the
-     file).
-
-`-c'
-     Copy the module file, sorted, to the standard output, instead of
-     creating or modifying any files or directories in your working
-     directory.
-
-`-d DIR'
-     Create a directory called DIR for the working files, instead of
-     using the module name.  Unless you also use `-N', the paths
-     created under DIR will be as short as possible.
-
-`-j TAG'
-     Merge the changes made between the resulting revision and the
-     revision that it is based on (e.g., if TAG refers to a branch, CVS
-     will merge all changes made on that branch into your working file).
-
-     With two `-j TAG' options, CVS will merge in the changes between
-     the two respective revisions.  This can be used to undo changes
-     made between two revisions (*note Merging two revisions::.) in
-     your working copy, or to move changes between different branches.
-
-     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.  An example might be
-     what `import' tells you to do when you have just imported sources
-     that have conflicts with local changes:
-
-          $ cvs checkout -jTAG:yesterday -jTAG module
-
-`-N'
-     Only useful together with `-d DIR'.  With this option, CVS will
-     not shorten module paths in your working directory.  (Normally,
-     CVS shortens paths as much as possible when you specify an
-     explicit target directory).
-
-`-s'
-     Like `-c', but include the status of all modules, and sort it by
-     the status string.  *Note modules::, for info about the `-s'
-     option that is used inside the modules file to set the module
-     status.
+     Only tag those files that contain existing tag TAG.
 
-
-File: cvs.info,  Node: checkout examples,  Prev: checkout options,  Up: checkout
+   The `cvs tag' command also allows one to specify files by revision
+or date, using the same `-r', `-D', and `-f' options.  However, this
+feature is probably not what you want.  The reason is that `cvs tag'
+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 `cvs rtag'.  The
+exceptions might be cases like:
 
-checkout examples
------------------
-
-   Get a copy of the module `tc':
-
-     $ cvs checkout tc
-
-   Get a copy of the module `tc' as it looked one day ago:
-
-     $ cvs checkout -D yesterday tc
+     cvs tag -r 1.4 backend.c
 
 
-File: cvs.info,  Node: commit,  Next: diff,  Prev: checkout,  Up: Invoking CVS
-
-commit--Check files into the repository
-=======================================
+File: cvs.info,  Node: Modifying tags,  Next: Tagging add/remove,  Prev: Tagging by date/tag,  Up: Revisions
 
-   * Version 1.3 Synopsis: commit [-lnR] [-m 'log_message' | -f file]
-     [-r revision] [files...]
+Deleting, moving, and renaming tags
+===================================
 
-   * Version 1.3.1 Synopsis: commit [-lnRf] [-m 'log_message' | -F
-     file] [-r revision] [files...]
+   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.
 
-   * Requires: working directory, repository.
+   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.  Warning: the commands in this section are
+dangerous; they permanently discard historical information and it can
+difficult or impossible to recover from errors.  If you are a CVS
+administrator, you may consider restricting these commands with taginfo
+(*note user-defined logging::).
 
-   * Changes: repository.
+   To delete a tag, specify the `-d' option to either `cvs tag' or `cvs
+rtag'.  For example:
 
-   * Synonym: ci
+     cvs rtag -d rel-0-4 tc
 
-   *Warning:* The `-f FILE' option will probably be renamed to `-F
-FILE', and `-f' will be given a new behavior in future releases of CVS.
+   deletes the tag `rel-0-4' from the module `tc'.
 
-   Use `commit' when you want to incorporate changes from your working
-source files into the source repository.
+   When we say "move" a tag, we mean to make the same name point to
+different revisions.  For example, the `stable' tag may currently point
+to revision 1.4 of `backend.c' and perhaps we want to make it point to
+revision 1.6.  To move a tag, specify the `-F' option to either `cvs
+tag' or `cvs rtag'.  For example, the task just mentioned might be
+accomplished as:
 
-   If you don't specify particular files to commit, all of the files in
-your working current directory are examined.  `commit' is careful to
-change in the repository only those files that you have really changed.
-By default (or if you explicitly specify the `-R' option), files in
-subdirectories are also examined and committed if they have changed;
-you can use the `-l' option to limit `commit' to the current directory
-only.
+     cvs tag -r 1.6 -F stable backend.c
 
-   `commit' 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 `update' (*note update::.).  `commit' does not call
-the `update' command for you, but rather leaves that for you to do when
-the time is right.
+   When we say "rename" 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 `-r' option to `cvs rtag', and then delete the old name.
+This leaves the new tag on exactly the same files as the old tag.  For
+example:
 
-   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 (*note
-modules::., and *note loginfo::.) and placed in the RCS history file
-inside the repository.  This log message can be retrieved with the
-`log' command; *Note log::.  You can specify the log message on the
-command line with the `-m MESSAGE' option, and thus avoid the editor
-invocation, or use the `-f FILE' option to specify that the argument
-file contains the log message.
-
-* Menu:
-
-* commit options::              commit options
-* commit examples::             commit examples
+     cvs rtag -r old-name-0-4 rel-0-4 tc
+     cvs rtag -d old-name-0-4 tc
 
 
-File: cvs.info,  Node: commit options,  Next: commit examples,  Up: commit
-
-commit options
---------------
-
-   These standard options are supported by `commit' (*note Common
-options::., for a complete description of them):
-
-`-l'
-     Local; run only in current working directory.
-
-`-n'
-     Do not run any module program.
-
-`-R'
-     Commit directories recursively.  This is on by default.
-
-`-r REVISION'
-     Commit to REVISION.  REVISION must be either a branch, or a
-     revision on the main trunk that is higher than any existing
-     revision number.  You cannot commit to a specific revision on a
-     branch.
-
-   `commit' also supports these options:
-
-`-F FILE'
-     This option is present in CVS releases 1.3-s3 and later.  Read the
-     log message from FILE, instead of invoking an editor.
-
-`-f'
-     This option is present in CVS 1.3-s3 and later releases of CVS.
-     Note that this is not the standard behavior of the `-f' option as
-     defined in *Note Common options::.
-
-     Force CVS to commit a new revision even if you haven't made any
-     changes to the file.  If the current revision of FILE is 1.7, then
-     the following two commands are equivalent:
-
-          $ cvs commit -f FILE
-          $ cvs commit -r 1.8 FILE
-
-`-f FILE'
-     This option is present in CVS releases 1.3, 1.3-s1 and 1.3-s2.
-     Note that this is not the standard behavior of the `-f' option as
-     defined in *Note Common options::.
-
-     Read the log message from FILE, instead of invoking an editor.
-
-`-m MESSAGE'
-     Use MESSAGE as the log message, instead of invoking an editor.
+File: cvs.info,  Node: Tagging add/remove,  Next: Sticky tags,  Prev: Modifying tags,  Up: Revisions
+
+Tagging and adding and removing files
+=====================================
+
+   The subject of exactly how tagging interacts with adding and
+removing files is somewhat obscure; for the most part CVS 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 CVS knows to
+treat the absence of a tag as meaning that the file didn't exist as of
+that tag.
+
+   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 `-r' option to `cvs rtag', then CVS tags the files
+which have been removed, and thereby avoids this problem.  For example,
+one might specify `-r HEAD' to tag the head.
+
+   On the subject of adding and removing files, the `cvs rtag' command
+has a `-a' 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 `-F' when moving a tag.  If one moved a tag
+without `-a', 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 `-r' is specified, as
+noted above.
 
 
-File: cvs.info,  Node: commit examples,  Prev: commit options,  Up: commit
-
-commit examples
----------------
-
-New major release number
-........................
-
-   When you make a major release of your product, you might want the
-revision numbers to track your major release number.  You should
-normally not care about the revision numbers, but this is a thing that
-many people want to do, and it can be done without doing any harm.
-
-   To bring all your files up to the RCS revision 3.0 (including those
-that haven't changed), you might do:
-
-     $ cvs commit -r 3.0
-
-   Note that it is generally a bad idea to try to make the RCS revision
-number equal to the current release number of your product.  You should
-think of the revision number as an internal number that the CVS package
-maintains, and that you generally never need to care much about.  Using
-the `tag' and `rtag' commands you can give symbolic names to the
-releases instead.  *Note tag:: and *Note rtag::.
-
-   Note that the number you specify with `-r' must be larger than any
-existing revision number.  That is, if revision 3.0 exists, you cannot
-`cvs commit -r 1.3'.
-
-Committing to a branch
-......................
-
-   You can commit to a branch revision (one that has an even number of
-dots) with the `-r' option.  To create a branch revision, use the `-b'
-option of the `rtag' or `tag' commands (*note tag::.  or *note
-rtag::.).  Then, either `checkout' or `update' can be used to base your
-sources on the newly created branch.  From that point on, all `commit'
-changes made within these working sources will be automatically added
-to a branch revision, thereby not disturbing main-line development in
-any way.  For example, if you had to create a patch to the 1.2 version
-of the product, even though the 2.0 version is already under
-development, you might do:
-
-     $ cvs rtag -b -r FCS1_2 FCS1_2_Patch product_module
-     $ cvs checkout -r FCS1_2_Patch product_module
-     $ cd product_module
-     [[ hack away ]]
-     $ cvs commit
-
-This works automatically since the `-r' option is sticky.
-
-Creating the branch after editing
-.................................
-
-   Say you have been working on some extremely experimental software,
-based on whatever revision you happened to checkout last week.  If
-others in your group would like to work on this software with you, but
-without disturbing main-line development, you could commit your change
-to a new branch.  Others can then checkout your experimental stuff and
-utilize the full benefit of CVS conflict resolution.  The scenario might
-look like:
-
-     [[ hacked sources are present ]]
-     $ cvs tag -b EXPR1
-     $ cvs update -r EXPR1
-     $ cvs commit
-
-   The `update' command will make the `-r EXPR1' option sticky on all
-files.  Note that your changes to the files will never be removed by the
-`update' command.  The `commit' will automatically commit to the
-correct branch, because the `-r' is sticky.  You could also do like
-this:
-
-     [[ hacked sources are present ]]
-     $ cvs tag -b EXPR1
-     $ cvs commit -r EXPR1
-
-but then, only those files that were changed by you will have the `-r
-EXPR1' sticky flag.  If you hack away, and commit without specifying
-the `-r EXPR1' flag, some files may accidentally end up on the main
-trunk.
-
-   To work with you on the experimental change, others would simply do
-
-     $ cvs checkout -r EXPR1 whatever_module
+File: cvs.info,  Node: Sticky tags,  Prev: Tagging add/remove,  Up: Revisions
+
+Sticky tags
+===========
+
+   Sometimes a working copy's revision has extra data associated with
+it, for example it might be on a branch (*note Branching and
+merging::), or restricted to versions prior to a certain date by
+`checkout -D' or `update -D'.  Because this data persists - that is, it
+applies to subsequent commands in the working copy - we refer to it as
+"sticky".
+
+   Most of the time, stickiness is an obscure aspect of CVS that you
+don't need to think about.  However, even if you don't want to use the
+feature, you may need to know _something_ about sticky tags (for
+example, how to avoid them!).
+
+   You can use the `status' command to see if any sticky tags or dates
+are set:
+
+     $ 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)
+
+   The sticky tags will remain on your working files until you delete
+them with `cvs update -A'.  The `-A' option retrieves the version of
+the file from the head of the trunk, and forgets any sticky tags,
+dates, or options.
+
+   The most common use of sticky tags is to identify which branch one
+is working on, as described in *Note 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 `cvs update'.  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 `cvs update' commands will not retrieve the latest
+revision until you reset the tag with `cvs update -A'.  Likewise, use
+of the `-D' option to `update' or `checkout' sets a "sticky date",
+which, similarly, causes that date to be used for future retrievals.
+
+   People often want to retrieve an old version of a file without
+setting a sticky tag.  This can be done with the `-p' option to
+`checkout' or `update', which sends the contents of the file to
+standard output.  For example:
+     $ cvs update -p -r 1.1 file1 >file1
+     ===================================================================
+     Checking out file1
+     RCS:  /tmp/cvs-sanity/cvsroot/first-dir/Attic/file1,v
+     VERS: 1.1
+     ***************
+     $
+
+   However, this isn't the easiest way, if you are asking how to undo a
+previous checkin (in this example, put `file1' back to the way it was
+as of revision 1.1).  In that case you are better off using the `-j'
+option to `update'; for further discussion see *Note Merging two
+revisions::.
 
 
-File: cvs.info,  Node: diff,  Next: export,  Prev: commit,  Up: Invoking CVS
-
-diff--Run diffs between revisions
-=================================
-
-   * Synopsis: diff [-l] [rcsdiff_options] [[-r rev1 | -D date1] [-r
-     rev2 |  -D date2]] [files...]
+File: cvs.info,  Node: Branching and merging,  Next: Recursive behavior,  Prev: Revisions,  Up: Top
 
-   * Requires: working directory, repository.
+Branching and merging
+*********************
 
-   * Changes: nothing.
+   CVS allows you to isolate changes onto a separate line of
+development, known as a "branch".  When you change files on a branch,
+those changes do not appear on the main trunk or other branches.
 
-   The `diff' command is used to compare different revisions of files.
-The default action is to compare your working files with the revisions
-they were based on, and report any differences that are found.
-
-   If any file names are given, only those files are compared.  If any
-directories are given, all files under them will be compared.
-
-   The exit status will be 0 if no differences were found, 1 if some
-differences were found, and 2 if any error occurred.
+   Later you can move changes from one branch to another branch (or the
+main trunk) by "merging".  Merging involves first running `cvs update
+-j', to merge the changes into the working directory.  You can then
+commit that revision, and thus effectively copy the changes onto
+another branch.
 
 * Menu:
 
-* diff options::                diff options
-* diff examples::               diff examples
+* Branches motivation::         What branches are good for
+* Creating a branch::           Creating a branch
+* Accessing branches::          Checking out and updating branches
+* Branches and revisions::      Branches are reflected in revision numbers
+* Magic branch numbers::        Magic branch numbers
+* Merging a branch::            Merging an entire branch
+* Merging more than once::      Merging from a branch several times
+* Merging two revisions::       Merging differences between two revisions
+* Merging adds and removals::   What if files are added or removed?
+* Merging and keywords::        Avoiding conflicts due to keyword substitution
 
 
-File: cvs.info,  Node: diff options,  Next: diff examples,  Up: diff
-
-diff options
-------------
-
-   These standard options are supported by `diff' (*note Common
-options::., for a complete description of them):
-
-`-D DATE'
-     Use the most recent revision no later than DATE.  See `-r' for how
-     this affects the comparison.
-
-     CVS can be configured to pass the `-D' option through to `rcsdiff'
-     (which in turn passes it on to `diff'.  GNU diff uses `-D' as a
-     way to put `cpp'-style `#define' statements around the output
-     differences.  There is no way short of testing to figure out how
-     CVS was configured.  In the default configuration CVS will use the
-     `-D DATE' option.
-
-`-k KFLAG'
-     Process RCS keywords according to KFLAG.  See co(1).
-
-`-l'
-     Local; run only in current working directory.
-
-`-R'
-     Examine directories recursively.  This option is on by default.
-
-`-r TAG'
-     Compare with revision TAG.  Zero, one or two `-r' options can be
-     present.  With no `-r' option, the working file will be compared
-     with the revision it was based on.  With one `-r', that revision
-     will be compared to your current working file.  With two `-r'
-     options those two revisions will be compared (and your working
-     file will not affect the outcome in any way).
-
-     One or both `-r' options can be replaced by a `-D DATE' option,
-     described above.
-
-   Any other options that are found are passed through to `rcsdiff',
-which in turn passes them to `diff'.  The exact meaning of the options
-depends on which `diff' you are using.  The long options introduced in
-GNU diff 2.0 are not yet supported in CVS.  See the documentation for
-your `diff' to see which options are supported.
+File: cvs.info,  Node: Branches motivation,  Next: Creating a branch,  Up: Branching and merging
+
+What branches are good for
+==========================
+
+   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 (*note Tags::) 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.
+
+   The thing to do in a situation like this is to create a "branch" 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.
 
 
-File: cvs.info,  Node: diff examples,  Prev: diff options,  Up: diff
-
-diff examples
--------------
+File: cvs.info,  Node: Creating a branch,  Next: Accessing branches,  Prev: Branches motivation,  Up: Branching and merging
 
-   The following line produces a Unidiff (`-u' flag) between revision
-1.14 and 1.19 of `backend.c'.  Due to the `-kk' flag no keywords are
-substituted, so differences that only depend on keyword substitution
-are ignored.
+Creating a branch
+=================
 
-     $ cvs diff -kk -u -r 1.14 -r 1.19 backend.c
+   You can create a branch with `tag -b'; for example, assuming you're
+in a working copy:
 
-   Suppose the experimental branch EXPR1 was based on a set of files
-tagged RELEASE_1_0.  To see what has happened on that branch, the
-following can be used:
+     $ cvs tag -b rel-1-0-patches
 
-     $ cvs diff -r RELEASE_1_0 -r EXPR1
+   This splits off a branch based on the current revisions in the
+working copy, assigning that branch the name `rel-1-0-patches'.
 
-   A command like this can be used to produce a context diff between
-two releases:
+   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 _not_ automatically
+switch the working copy to be on the new branch.  For information on how
+to do that, see *Note Accessing branches::.
 
-     $ cvs diff -c -r RELEASE_1_0 -r RELEASE_1_1 > diffs
+   You can also create a branch without reference to any working copy,
+by using `rtag':
 
-   If you are maintaining ChangeLogs, a command like the following just
-before you commit your changes may help you write the ChangeLog entry.
-All local modifications that have not yet been committed will be
-printed.
-
-     $ cvs diff -u | less
-
-
-File: cvs.info,  Node: export,  Next: history,  Prev: diff,  Up: Invoking CVS
+     $ cvs rtag -b -r rel-1-0 rel-1-0-patches tc
 
-export--Export sources from CVS, similar to checkout
-====================================================
+   `-r rel-1-0' says that this branch should be rooted at the revision
+that corresponds to the tag `rel-1-0'.  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).
 
-   * Synopsis: export [-flNnQq] -r rev|-D date [-d dir] module...
+   As with `tag', the `-b' flag tells `rtag' to create a branch (rather
+than just a symbolic revision name).  Note that the numeric revision
+number that matches `rel-1-0' will probably be different from file to
+file.
 
-   * Requires: repository.
-
-   * Changes: current directory.
-
-   This command is a variant of `checkout'; use it when you want a copy
-of the source for module without the CVS administrative directories.
-For example, you might use `export' to prepare source for shipment
-off-site.  This command requires that you specify a date or tag (with
-`-D' or `-r'), so that you can count on reproducing the source you ship
-to others.
-
-   The keyword substitution option `-kv' is always set when export is
-used.  This causes any RCS keywords to be expanded such that an import
-done at some other site will not lose the keyword revision information.
-There is no way to override this.  Note that this breaks the `ident'
-command (which is part of the RCS suite--see ident(1)) which looks for
-RCS keyword strings.  If you want to be able to use `ident' you must
-use `checkout' instead.
-
-* Menu:
+   So, the full effect of the command is to create a new branch - named
+`rel-1-0-patches' - in module `tc', rooted in the revision tree at the
+point tagged by `rel-1-0'.
 
-* export options::              export options
+
+File: cvs.info,  Node: Accessing branches,  Next: Branches and revisions,  Prev: Creating a branch,  Up: Branching and merging
+
+Accessing branches
+==================
+
+   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.
+
+   To check out a branch from the repository, invoke `checkout' with
+the `-r' flag, followed by the tag name of the branch (*note Creating a
+branch::):
+
+     $ cvs checkout -r rel-1-0-patches tc
+
+   Or, if you already have a working copy, you can switch it to a given
+branch with `update -r':
+
+     $ cvs update -r rel-1-0-patches tc
+
+   or equivalently:
+
+     $ cd tc
+     $ cvs update -r rel-1-0-patches
+
+   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 `update' command, `update -r'
+merges any changes you have made, notifying you of conflicts where they
+occur.
+
+   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.
+
+   To find out what branch a working copy is on, you can use the
+`status' command.  In its output, look for the field named `Sticky tag'
+(*note Sticky tags::) - that's CVS's way of telling you the branch, if
+any, of the current working files:
+
+     $ 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)
+
+   Don't be confused by the fact that the branch numbers for each file
+are different (`1.7.2' and `1.4.2' respectively).  The branch tag is the
+same, `rel-1-0-patches', 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
+`driver.c' had been through more changes than `backend.c' before this
+branch was created.
+
+   See *Note Branches and revisions:: for details about how branch
+numbers are constructed.
 
 
-File: cvs.info,  Node: export options,  Up: export
+File: cvs.info,  Node: Branches and revisions,  Next: Magic branch numbers,  Prev: Accessing branches,  Up: Branching and merging
+
+Branches and revisions
+======================
+
+   Ordinarily, a file's revision history is a linear series of
+increments (*note Revision numbers::):
+
+            +-----+    +-----+    +-----+    +-----+    +-----+
+            ! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 !
+            +-----+    +-----+    +-----+    +-----+    +-----+
+
+   However, CVS is not limited to linear development.  The "revision
+tree" can be split into "branches", where each branch is a
+self-maintained line of development.  Changes made on one branch can
+easily be moved back to the main trunk.
+
+   Each branch has a "branch number", 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.
+
+   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.
+
+                                                           +-------------+
+                                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 !
+                         +---------+    +---------+    +---------+
+
+   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 CVS 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 CVS (*note Magic branch
+numbers::).  The branch 1.1.1 has a special meaning.  *Note Tracking
+sources::.
 
-export options
---------------
+
+File: cvs.info,  Node: Magic branch numbers,  Next: Merging a branch,  Prev: Branches and revisions,  Up: Branching and merging
 
-   These standard options are supported by `export' (*note Common
-options::., for a complete description of them):
+Magic branch numbers
+====================
 
-`-D DATE'
-     Use the most recent revision no later than DATE.
+   This section describes a CVS feature called "magic branches".  For
+most purposes, you need not worry about magic branches; CVS 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.
 
-`-f'
-     If no matching revision is found, retrieve the most recent
-     revision (instead of ignoring the file).
+   Externally, branch numbers consist of an odd number of dot-separated
+decimal integers.  *Note Revision numbers::.  That is not the whole
+truth, however.  For efficiency reasons CVS 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).
 
-`-l'
-     Local; run only in current working directory.
+   CVS does a pretty good job at hiding these so called magic branches,
+but in a few places the hiding is incomplete:
 
-`-n'
-     Do not run any checkout program.
+   * The magic branch number appears in the output from `cvs log'.
 
-`-R'
-     Export directories recursively.  This is on by default.
+   * You cannot specify a symbolic branch name to `cvs admin'.
 
-`-r TAG'
-     Use revision TAG.
 
-   In addition, these options (that are common to `checkout' and
-`export') are also supported:
+   You can use the `admin' command to reassign a symbolic name to a
+branch the way RCS expects it to be.  If `R4patches' is assigned to the
+branch 1.4.2 (magic branch number 1.4.0.2) in file `numbers.c' you can
+do this:
 
-`-d DIR'
-     Create a directory called DIR for the working files, instead of
-     using the module name.  Unless you also use `-N', the paths
-     created under DIR will be as short as possible.
+     $ cvs admin -NR4patches:1.4.2 numbers.c
 
-`-N'
-     Only useful together with `-d DIR'.  With this option, CVS will
-     not shorten module paths in your working directory.  (Normally,
-     CVS shortens paths as much as possible when you specify an
-     explicit target directory.)
+   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).
 
 
-File: cvs.info,  Node: history,  Next: import,  Prev: export,  Up: Invoking CVS
+File: cvs.info,  Node: Merging a branch,  Next: Merging more than once,  Prev: Magic branch numbers,  Up: Branching and merging
 
-history--Show status of files and users
-=======================================
+Merging an entire branch
+========================
 
-   * Synopsis:     history [-report] [-flags] [-options args] [files...]
+   You can merge changes made on a branch into your working copy by
+giving the `-j BRANCHNAME' flag to the `update' subcommand.  With one
+`-j BRANCHNAME' option it merges the changes made between the point
+where the branch forked and newest revision on that branch (into your
+working copy).
 
-   * Requires: the file `$CVSROOT/CVSROOT/history'
+   The `-j' stands for "join".
 
-   * Changes: nothing.
+   Consider this revision tree:
 
-   CVS can keep a history file that tracks each use of the `checkout',
-`commit', `rtag', `update', and `release' commands.  You can use
-`history' to display this information in various formats.
+     +-----+    +-----+    +-----+    +-----+
+     ! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !      <- The main trunk
+     +-----+    +-----+    +-----+    +-----+
+                     !
+                     !
+                     !   +---------+    +---------+
+     Branch R1fix -> +---! 1.2.2.1 !----! 1.2.2.2 !
+                         +---------+    +---------+
 
-   Logging must be enabled by creating the file
-`$CVSROOT/CVSROOT/history'.
+The branch 1.2.2 has been given the tag (symbolic name) `R1fix'.  The
+following example assumes that the module `mod' contains only one file,
+`m.c'.
 
-   *Warning:* `history' uses `-f', `-l', `-n', and `-p' in ways that
-conflict with the normal use inside CVS (*note Common options::.).
-
-* Menu:
-
-* history options::             history options
-
-
-File: cvs.info,  Node: history options,  Up: history
+     $ cvs checkout mod               # Retrieve the latest revision, 1.4
+     
+     $ cvs update -j R1fix m.c        # Merge all changes made on the branch,
+                                      # i.e. the changes between revision 1.2
+                                      # and 1.2.2.2, into your working copy
+                                      # of the file.
+     
+     $ cvs commit -m "Included R1fix" # Create revision 1.5.
 
-history options
----------------
+   A conflict can result from a merge operation.  If that happens, you
+should resolve it before committing the new revision.  *Note Conflicts
+example::.
 
-   Several options (shown above as `-report')  control  what kind of
-report is generated:
+   If your source files contain keywords (*note Keyword substitution::),
+you might be getting more conflicts than strictly necessary.  See *Note
+Merging and keywords::, for information on how to avoid this.
 
-`-c'
-     Report on each time commit was used (i.e., each time the
-     repository was modified).
+   The `checkout' command also supports the `-j BRANCHNAME' flag.  The
+same effect as above could be achieved with this:
 
-`-e'
-     Everything (all record types); equivalent to specifying
-     `-xMACFROGWUT'.
+     $ cvs checkout -j R1fix mod
+     $ cvs commit -m "Included R1fix"
 
-`-m MODULE'
-     Report on a particular module.  (You can meaningfully use `-m'
-     more than once on the command line.)
+   It should be noted that `update -j TAGNAME' will also work but may
+not produce the desired result.  *Note Merging adds and removals::, for
+more.
 
-`-o'
-     Report on checked-out modules.
-
-`-T'
-     Report on all tags.
-
-`-x TYPE'
-     Extract a particular set of record types TYPE from the CVS
-     history.  The types are indicated by single letters, which you may
-     specify in combination.
-
-     Certain commands have a single record type:
-
-    `F'
-          release
-
-    `O'
-          checkout
+
+File: cvs.info,  Node: Merging more than once,  Next: Merging two revisions,  Prev: Merging a branch,  Up: Branching and merging
 
-    `T'
-          rtag
+Merging from a branch several times
+===================================
 
-     One of four record types may result from an update:
+   Continuing our example, the revision tree now looks like this:
 
-    `C'
-          A merge was necessary but collisions were detected (requiring
-          manual merging).
+     +-----+    +-----+    +-----+    +-----+    +-----+
+     ! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 !   <- The main trunk
+     +-----+    +-----+    +-----+    +-----+    +-----+
+                     !                           *
+                     !                          *
+                     !   +---------+    +---------+
+     Branch R1fix -> +---! 1.2.2.1 !----! 1.2.2.2 !
+                         +---------+    +---------+
 
-    `G'
-          A merge was necessary and it succeeded.
+   where the starred line represents the merge from the `R1fix' branch
+to the main trunk, as just discussed.
 
-    `U'
-          A working file was copied from the repository.
+   Now suppose that development continues on the `R1fix' branch:
 
-    `W'
-          The working copy of a file was deleted during update (because
-          it was gone from the repository).
+     +-----+    +-----+    +-----+    +-----+    +-----+
+     ! 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 !
+                         +---------+    +---------+    +---------+
 
-     One of three record types results from commit:
+   and then you want to merge those new changes onto the main trunk.
+If you just use the `cvs update -j R1fix m.c' command again, CVS will
+attempt to merge again the changes which you have already merged, which
+can have undesirable side effects.
 
-    `A'
-          A file was added for the first time.
+   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 `-j' options, and CVS merges the changes from
+the first revision to the second revision.  For example, in this case
+the simplest way would be
 
-    `M'
-          A file was modified.
+     cvs update -j 1.2.2.2 -j R1fix m.c    # Merge changes from 1.2.2.2 to the
+                                           # head of the R1fix branch
 
-    `R'
-          A file was removed.
+   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:
 
-   The options shown as `-flags' constrain or expand the report without
-requiring option arguments:
+     cvs update -j R1fix:yesterday -j R1fix m.c
 
-`-a'
-     Show data for all users (the default is to show data only for the
-     user executing `history').
+   Better yet, tag the R1fix branch after every merge into the trunk,
+and then use that tag for subsequent merges:
 
-`-l'
-     Show last modification only.
+     cvs update -j merged_from_R1fix_to_trunk -j R1fix m.c
 
-`-w'
-     Show only the records for modifications done from the same working
-     directory where `history' is executing.
+
+File: cvs.info,  Node: Merging two revisions,  Next: Merging adds and removals,  Prev: Merging more than once,  Up: Branching and merging
 
-   The options shown as `-options ARGS' constrain the report based on
-an argument:
+Merging differences between any two revisions
+=============================================
 
-`-b STR'
-     Show data back to a record containing  the  string STR  in  either
-     the module name, the file name, or the repository path.
+   With two `-j REVISION' flags, the `update' (and `checkout') command
+can merge the differences between any two revisions into your working
+file.
 
-`-D DATE'
-     Show data since DATE.  This is slightly different from the normal
-     use of `-D DATE', which selects the newest revision older than
-     DATE.
+     $ cvs update -j 1.5 -j 1.3 backend.c
 
-`-p REPOSITORY'
-     Show data for a particular source repository  (you can specify
-     several `-p' options on the same command line).
+will undo all changes made between revision 1.3 and 1.5.  Note the
+order of the revisions!
 
-`-r REV'
-     Show records referring to revisions since the revision or tag
-     named REV appears in individual RCS files.  Each RCS file is
-     searched for the revision or tag.
+   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.
 
-`-t TAG'
-     Show records since tag TAG was last added to the the history file.
-     This differs from the `-r' flag above in that it reads only the
-     history file, not the RCS files, and is much faster.
+   Specifying two `-j' options can also undo file removals or
+additions.  For example, suppose you have a file named `file1' 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:
 
-`-u NAME'
-     Show records for user NAME.
+     $ 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
+     $
 
 
-File: cvs.info,  Node: import,  Next: log,  Prev: history,  Up: Invoking CVS
-
-import--Import sources into CVS, using vendor branches
-======================================================
-
-   * Synopsis: import [-options] repository vendortag releasetag...
-
-   * Requires: Repository, source distribution directory.
-
-   * Changes: repository.
-
-   Use `import' to incorporate an entire source distribution from an
-outside source (e.g., a source vendor) into your source repository
-directory.  You can use this command both for initial creation of a
-repository, and for wholesale updates to the module from the outside
-source.  *Note Tracking sources::, for a discussion on this subject.
-
-   The REPOSITORY argument gives a directory name (or a path to a
-directory) under the CVS root directory for repositories; if the
-directory did not exist, import creates it.
-
-   When you use import for updates to source that has been modified in
-your source repository (since a prior import), it will notify you of
-any files that conflict in the two branches of development; use
-`checkout -j' to reconcile the differences, as import instructs you to
-do.
-
-   By default, certain file names are ignored during `import': names
-associated with CVS administration, or with other common source control
-systems; common names for patch files, object files, archive files, and
-editor backup files; and other names that are usually artifacts of
-assorted utilities.  Currently, the default list of ignored files
-includes files matching these names:
-
-             RCSLOG  RCS     SCCS
-             CVS*    cvslog.*
-             tags    TAGS
-             .make.state     .nse_depinfo
-             *~      #*      .#*     ,*
-             *.old   *.bak   *.BAK   *.orig  *.rej   .del-*
-             *.a     *.o     *.so    *.Z     *.elc   *.ln
-             core
-
-   If the file `$CVSROOT/CVSROOT/cvsignore' exists, any files whose
-names match the specifications in that file will also be ignored.
-
-   If the file `$CVSROOT/CVSROOT/cvswrappers' exists, any file whose
-names match the specifications in that file will be treated as packages
-and the appropriate filtering will be performed on the file/directory
-before being imported, *Note Wrappers::.
-
-   The outside source is saved in a first-level RCS branch, by default
-1.1.1.  Updates are leaves of this branch; for example, files from the
-first imported collection of source will be revision 1.1.1.1, then
-files from the first imported update will be revision 1.1.1.2, and so
-on.
-
-   At least three arguments are required.  REPOSITORY is needed to
-identify the collection of source.  VENDORTAG is a tag for the entire
-branch (e.g., for 1.1.1).  You must also specify at least one
-RELEASETAG to identify the files at the leaves created each time you
-execute `import'.
-
-* Menu:
-
-* import options::              import options
-* import examples::             import examples
+File: cvs.info,  Node: Merging adds and removals,  Next: Merging and keywords,  Prev: Merging two revisions,  Up: Branching and merging
+
+Merging can add or remove files
+===============================
+
+   If the changes which you are merging involve removing or adding some
+files, `update -j' will reflect such additions or removals.
+
+   For example:
+     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
+
+   After these commands are executed and a `cvs commit' is done, file
+`a' will be removed and file `d' added in the main branch.
+
+   Note that using a single static tag (`-j TAGNAME') rather than a
+dynamic tag (`-j BRANCHNAME') to merge changes from a branch will
+usually not remove files which were removed on the branch since CVS
+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 propogated in the merge.
 
 
-File: cvs.info,  Node: import options,  Next: import examples,  Up: import
-
-import options
---------------
-
-   This standard option is supported by `import' (*note Common
-options::., for a complete description):
-
-`-m MESSAGE'
-     Use MESSAGE as log information, instead of invoking an editor.
-
-   There are three additional special options.
-
-`-b BRANCH'
-     Specify a first-level branch other than 1.1.1.  Unless the `-b
-     BRANCH' flag is given, revisions will *always* be made to the
-     branch 1.1.1--even if a VENDORTAG that matches another branch is
-     given!  What happens in that case, is that the tag will be reset
-     to 1.1.1.  Warning: This behavior might change in the future.
-
-`-k SUBST'
-     Indicate the RCS 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 co(1) for a
-     complete list of valid `-k' settings.
-
-     If you are checking in sources that contain RCS keywords, and you
-     wish those keywords to remain intact, use the `-ko' flag when
-     importing the files.  This setting indicates that no keyword
-     expansion is to be performed by RCS when checking files out.  It
-     is also useful for checking in binaries.
-
-`-I NAME'
-     Specify file names that should be ignored during import.  You can
-     use this option repeatedly.  To avoid ignoring any files at all
-     (even those ignored by default), specify `-I !'.
-
-     NAME can be a file name pattern of the same type that you can
-     specify in the `.cvsignore' file.  *Note cvsignore::.
-
-`-W SPEC'
-     Specify file names that should be filtered during import.  You can
-     use this option repeatedly.
-
-     SPEC can be a file name pattern of the same type that you can
-     specify in the `.cvswrappers' file. *Note Wrappers::.
+File: cvs.info,  Node: Merging and keywords,  Prev: Merging adds and removals,  Up: Branching and merging
+
+Merging and keywords
+====================
+
+   If you merge files containing keywords (*note Keyword
+substitution::), you will normally get numerous conflicts during the
+merge, because the keywords are expanded differently in the revisions
+which you are merging.
+
+   Therefore, you will often want to specify the `-kk' (*note
+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.
+
+   For example, suppose you have a file like this:
+
+            +---------+
+           _! 1.1.2.1 !   <-  br1
+          / +---------+
+         /
+        /
+     +-----+    +-----+
+     ! 1.1 !----! 1.2 !
+     +-----+    +-----+
+
+   and your working directory is currently on the trunk (revision 1.2).
+Then you might get the following results from a merge:
+
+     $ cat file1
+     key $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 $Revision: 1.2 $
+     =======
+     key $Revision: 1.2 $
+     >>>>>>> 1.1.2.1
+     . . .
+
+   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 `Revision: 1.1' to `Revision: 1.1.2.1', CVS tried
+to merge that change into your working directory, which conflicted with
+the fact that your working directory had contained `Revision: 1.2'.
+
+   Here is what happens if you had used `-kk':
+
+     $ cat file1
+     key $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 $Revision: 1.2 $
+     . . .
+
+   What is going on here is that revision 1.1 and 1.1.2.1 both expand
+as plain `Revision', and therefore merging the changes between them
+into the working directory need not change anything.  Therefore, there
+is no conflict.
+
+   There is, however, one major caveat with using `-kk' on merges.
+Namely, it overrides whatever keyword expansion mode CVS would normally
+have used.  In particular, this is a problem if the mode had been `-kb'
+for a binary file.  Therefore, if your repository contains binary
+files, you will need to deal with the conflicts rather than using `-kk'.
 
 
-File: cvs.info,  Node: import examples,  Prev: import options,  Up: import
-
-import examples
----------------
-
-   *Note Tracking sources::, and *Note From files::.
+File: cvs.info,  Node: Recursive behavior,  Next: Adding and removing,  Prev: Branching and merging,  Up: Top
+
+Recursive behavior
+******************
+
+   Almost all of the subcommands of CVS work recursively when you
+specify a directory as an argument.  For instance, consider this
+directory structure:
+
+           `$HOME'
+             |
+             +--tc
+             |   |
+                 +--CVS
+                 |      (internal CVS files)
+                 +--Makefile
+                 +--backend.c
+                 +--driver.c
+                 +--frontend.c
+                 +--parser.c
+                 +--man
+                 |    |
+                 |    +--CVS
+                 |    |  (internal CVS files)
+                 |    +--tc.1
+                 |
+                 +--testing
+                      |
+                      +--CVS
+                      |  (internal CVS files)
+                      +--testpgm.t
+                      +--test2.t
+
+If `tc' is the current working directory, the following is true:
+
+   * `cvs update testing' is equivalent to
+
+          cvs update testing/testpgm.t testing/test2.t
+
+   * `cvs update testing man' updates all files in the subdirectories
+
+   * `cvs update .' or just `cvs update' updates all files in the `tc'
+     directory
+
+   If no arguments are given to `update' it will update all files in
+the current working directory and all its subdirectories.  In other
+words, `.' is a default argument to `update'.  This is also true for
+most of the CVS subcommands, not only the `update' command.
+
+   The recursive behavior of the CVS subcommands can be turned off with
+the `-l' option.  Conversely, the `-R' option can be used to force
+recursion if `-l' is specified in `~/.cvsrc' (*note ~/.cvsrc::).
+
+     $ cvs update -l         # Don't update files in subdirectories
 
 
-File: cvs.info,  Node: log,  Next: rdiff,  Prev: import,  Up: Invoking CVS
-
-log--Print out 'rlog' information for files
-===========================================
-
-   * Synopsis: log [-l] rlog-options [files...]
+File: cvs.info,  Node: Adding and removing,  Next: History browsing,  Prev: Recursive behavior,  Up: Top
 
-   * Requires: repository, working directory.
+Adding, removing, and renaming files and directories
+****************************************************
 
-   * Changes: nothing.
-
-   * Synonym: rlog
-
-   Display log information for files.  `log' calls the RCS utility
-`rlog', which prints all available information about the RCS history
-file.  This includes the location of the RCS file, the "head" revision
-(the latest revision on the trunk), all symbolic names (tags) and some
-other things.  For each revision, the revision number, the 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 CVS print times in the local timezone).
+   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 CVS to record the fact that a change has
+taken place, just as with modifying an existing file.  The exact
+mechanisms to do this in CVS vary depending on the situation.
 
 * Menu:
 
-* log options::                 log options
-* log examples::                log examples
+* Adding files::                Adding files
+* Removing files::              Removing files
+* Removing directories::        Removing directories
+* Moving files::                Moving and renaming files
+* Moving directories::          Moving and renaming directories
 
 
-File: cvs.info,  Node: log options,  Next: log examples,  Up: log
-
-log options
------------
-
-   Only one option is interpreted by CVS and not passed on to `rlog':
-
-`-l'
-     Local; run only in current working directory.  (Default is to run
-     recursively).
+File: cvs.info,  Node: Adding files,  Next: Removing files,  Up: Adding and removing
 
-   By default, `rlog' prints all information that is available.  All
-other options (including those that normally behave differently) are
-passed through to `rlog' and restrict the output.  See rlog(1) for a
-complete description of options.  This incomplete list (which is a
-slightly edited extract from rlog(1)) lists all options that are useful
-in conjunction with CVS.
+Adding files to a directory
+===========================
 
-   *Please note:*  There can be no space between the option and its
-argument, since `rlog' parses its options in a different way than CVS.
+   To add a new file to a directory, follow these steps.
 
-`-b'
-     Print information about the revisions on the default branch,
-     normally the highest branch on the trunk.
+   * You must have a working copy of the directory.  *Note Getting the
+     source::.
 
-`-dDATES'
-     Print information about revisions with a checkin date/time in the
-     range given by the semicolon-separated list of dates.  The
-     following table explains the available range formats:
+   * Create the new file inside your working copy of the directory.
 
-    `D1<D2'
-    `D2>D1'
-          Select the revisions that were deposited between D1 and D2
-          inclusive.
+   * Use `cvs add FILENAME' to tell CVS that you want to version
+     control the file.  If the file contains binary data, specify `-kb'
+     (*note Binary files::).
 
-    `<D'
-    `D>'
-          Select all revisions dated D or earlier.
+   * Use `cvs commit FILENAME' to actually check in the file into the
+     repository.  Other developers cannot see the file until you
+     perform this step.
 
-    `D<'
-    `>D'
-          Select all revisions dated D or later.
+   You can also use the `add' command to add a new directory.
 
-    `D'
-          Select the single, latest revision dated D or earlier.
+   Unlike most other commands, the `add' command is not recursive.  You
+cannot even type `cvs add foo/bar'!  Instead, you have to
 
-     The date/time strings D, D1, and D2 are in the free format
-     explained in co(1).  Quoting is normally necessary, especially for
-     < and >.  Note that the separator is a semicolon (;).
+     $ cd foo
+     $ cvs add bar
 
-`-h'
-     Print only the RCS pathname, working pathname, head, default
-     branch, access list, locks, symbolic names, and suffix.
+ - Command: cvs add [`-k' kflag] [`-m' message] files ...
+     Schedule FILES to be added to the repository.  The files or
+     directories specified with `add' 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 `import' command instead.  *Note import::.
 
-`-N'
-     Do not print the list of tags for this file.  This option can be
-     very useful when your site uses a lot of tags, so rather than
-     "more"'ing over 3 pages of tag information, the log information is
-     presented without tags at all.
+     The added files are not placed in the source repository until you
+     use `commit' to make the change permanent.  Doing an `add' on a
+     file that was removed with the `remove' command will undo the
+     effect of the `remove', unless a `commit' command intervened.
+     *Note Removing files::, for an example.
 
-`-R'
-     Print only the name of the RCS history file.
+     The `-k' option specifies the default way that this file will be
+     checked out; for more information see *Note Substitution modes::.
 
-`-rREVISIONS'
-     Print information about revisions given in the comma-separated
-     list REVISIONS of revisions and ranges.  The following table
-     explains the available range formats:
-
-    `REV1:REV2'
-          Revisions REV1 to REV2 (which must be on the same branch).
-
-    `:REV'
-          Revisions from the beginning of the branch up to and
-          including REV.
-
-    `REV:'
-          Revisions starting with REV to the end of the branch
-          containing REV.
-
-    `BRANCH'
-          An argument that is a branch means all revisions on that
-          branch.  You can unfortunately not specify a symbolic branch
-          here.  You must specify the numeric branch number.  *Note
-          Magic branch numbers::, for an explanation.
-
-    `BRANCH1:BRANCH2'
-          A range of branches means all revisions on the branches in
-          that range.
-
-    `BRANCH.'
-          The latest revision in BRANCH.
-
-     A bare `-r' with no revisions means the latest revision on the
-     default branch, normally the trunk.
-
-`-sSTATES'
-     Print information about revisions whose state attributes match one
-     of the states given in the comma-separated list STATES.
+     The `-m' option specifies a description for the file.  This
+     description appears in the history log (if it is enabled, *note
+     history file::).  It will also be saved in the version history
+     inside the repository when the file is committed.  The `log'
+     command displays this description.  The description can be changed
+     using `admin -t'.  *Note admin::.  If you omit the `-m
+     DESCRIPTION' flag, an empty string will be used.  You will not be
+     prompted for a description.
 
-`-t'
-     Print the same as `-h', plus the descriptive text.
+   For example, the following commands add the file `backend.c' to the
+repository:
 
-`-wLOGINS'
-     Print information about revisions checked in by users with login
-     names appearing in the comma-separated list LOGINS.  If LOGINS is
-     omitted, the user's login is assumed.
+     $ cvs add backend.c
+     $ cvs commit -m "Early version. Not yet compilable." backend.c
 
-   `rlog' prints the intersection of the revisions selected with the
-options `-d', `-l', `-s', and `-w', intersected with the union of the
-revisions selected by `-b' and `-r'.
+   When you add a file it is added only on the branch which you are
+working on (*note Branching and merging::).  You can later merge the
+additions to another branch if you want (*note Merging adds and
+removals::).
 
 
-File: cvs.info,  Node: log examples,  Prev: log options,  Up: log
-
-log examples
-------------
-
-   Contributed examples are gratefully accepted.
+File: cvs.info,  Node: Removing files,  Next: Removing directories,  Prev: Adding files,  Up: Adding and removing
+
+Removing files
+==============
+
+   Directories change.  New files are added, and old files disappear.
+Still, you want to be able to retrieve an exact copy of old releases.
+
+   Here is what you can do to remove a file, but remain able to
+retrieve old revisions:
+
+   * Make sure that you have not made any uncommitted modifications to
+     the file.  *Note Viewing differences::, for one way to do that.
+     You can also use the `status' or `update' 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.
+
+   * Remove the file from your working copy of the directory.  You can
+     for instance use `rm'.
+
+   * Use `cvs remove FILENAME' to tell CVS that you really want to
+     delete the file.
+
+   * Use `cvs commit FILENAME' to actually perform the removal of the
+     file from the repository.
+
+   When you commit the removal of the file, CVS 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.  CVS will correctly create or not create the file, based on
+the `-r' and `-D' options specified to `checkout' or `update'.
+
+ - Command: cvs remove [options] files ...
+     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 *Note Invoking CVS::.
+
+   Here is an example of removing several files:
+
+     $ 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 .
+
+   As a convenience you can remove the file and `cvs remove' it in one
+step, by specifying the `-f' option.  For example, the above example
+could also be done like this:
+
+     $ 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 .
+
+   If you execute `remove' for a file, and then change your mind before
+you commit, you can undo the `remove' with an `add' command.
+
+     $ 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
+
+   If you realize your mistake before you run the `remove' command you
+can use `update' to resurrect the file:
+
+     $ rm oj.c
+     $ cvs update oj.c
+     cvs update: warning: oj.c was lost
+     U oj.c
+
+   When you remove a file it is removed only on the branch which you
+are working on (*note Branching and merging::).  You can later merge
+the removals to another branch if you want (*note Merging adds and
+removals::).
 
 
-File: cvs.info,  Node: rdiff,  Next: release,  Prev: log,  Up: Invoking CVS
-
-rdiff--'patch' format diffs between releases
-============================================
-
-   * rdiff [-flags] [-V vn] [-r t|-D d [-r t2|-D d2]] modules...
+File: cvs.info,  Node: Removing directories,  Next: Moving files,  Prev: Removing files,  Up: Adding and removing
+
+Removing directories
+====================
+
+   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.
+
+   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 `-P' option to `cvs update' or `cvs checkout',
+which will cause CVS to remove empty directories from working
+directories.  (Note that `cvs export' always removes empty directories.)
+Probably the best way to do this is to always specify `-P'; if you want
+an empty directory then put a dummy file (for example `.keepme') in it
+to prevent `-P' from removing it.
+
+   Note that `-P' is implied by the `-r' or `-D' options of `checkout'.
+This way CVS 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.
 
-   * Requires: repository.
-
-   * Changes: nothing.
-
-   * Synonym: patch
+
+File: cvs.info,  Node: Moving files,  Next: Moving directories,  Prev: Removing directories,  Up: Adding and removing
 
-   Builds a Larry Wall format patch(1) file between two releases, that
-can be fed directly into the patch program to bring an old release
-up-to-date with the new release.  (This is one of the few CVS commands
-that operates directly from the repository, and doesn't require a prior
-checkout.) The diff output is sent to the standard output device.
+Moving and renaming files
+=========================
 
-   You can specify (using the standard `-r' and `-D' options) any
-combination of one or two revisions or dates.  If only one revision or
-date is specified, the patch file reflects differences between that
-revision or date and the current head revisions in the RCS file.
+   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.  *Note Moving
+directories::.).
 
-   Note that if the software release affected is contained in more than
-one directory, then it may be necessary to specify the `-p' option to
-the patch command when patching the old sources, so that patch is able
-to find the files that are located in other directories.
+   The examples below assume that the file OLD is renamed to NEW.
 
 * Menu:
 
-* rdiff options::               rdiff options
-* rdiff examples::              rdiff examples
+* Outside::                     The normal way to Rename
+* Inside::                      A tricky, alternative way
+* Rename by copying::           Another tricky, alternative way
 
 
-File: cvs.info,  Node: rdiff options,  Next: rdiff examples,  Up: rdiff
-
-rdiff options
--------------
-
-   These standard options are supported by `rdiff' (*note Common
-options::., for a complete description of them):
+File: cvs.info,  Node: Outside,  Next: Inside,  Up: Moving files
 
-`-D DATE'
-     Use the most recent revision no later than DATE.
+The Normal way to Rename
+------------------------
 
-`-f'
-     If no matching revision is found, retrieve the most recent
-     revision (instead of ignoring the file).
+   The normal way to move a file is to copy OLD to NEW, and then issue
+the normal CVS commands to remove OLD from the repository, and add NEW
+to it.
 
-`-l'
-     Local; don't descend subdirectories.
+     $ mv OLD NEW
+     $ cvs remove OLD
+     $ cvs add NEW
+     $ cvs commit -m "Renamed OLD to NEW" OLD NEW
 
-`-r TAG'
-     Use revision TAG.
+   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, `cvs
+log OLD' will give the log up until the time of the rename.
 
-   In addition to the above, these options are available:
+   When NEW is committed its revision numbers will start again, usually
+at 1.1, so if that bothers you, use the `-r rev' option to commit.  For
+more information see *Note Assigning revisions::.
 
-`-c'
-     Use the context diff format.  This is the default format.
+
+File: cvs.info,  Node: Inside,  Next: Rename by copying,  Prev: Outside,  Up: Moving files
 
-`-s'
-     Create a summary change report instead of a patch.  The summary
-     includes information about files that were changed or added
-     between the releases.  It is sent to the standard output device.
-     This is useful for finding out, for example, which files have
-     changed between two dates or revisions.
+Moving the history file
+-----------------------
 
-`-t'
-     A diff of the top two revisions is sent to the standard output
-     device.  This is most useful for seeing what the last change to a
-     file was.
+   This method is more dangerous, since it involves moving files inside
+the repository.  Read this entire section before trying it out!
 
-`-u'
-     Use the unidiff format for the context diffs.  This option is not
-     available if your diff does not support the unidiff format.
-     Remember that old versions of the `patch' program can't handle the
-     unidiff format, so if you plan to post this patch to the net you
-     should probably not use `-u'.
+     $ cd $CVSROOT/DIR
+     $ mv OLD,v NEW,v
 
-`-V VN'
-     Expand RCS keywords according to the rules current in RCS version
-     VN (the expansion format changed with RCS version 5).
+Advantages:
 
-
-File: cvs.info,  Node: rdiff examples,  Prev: rdiff options,  Up: rdiff
+   * The log of changes is maintained intact.
 
-rdiff examples
---------------
+   * The revision numbers are not affected.
 
-   Suppose you receive mail from foo@bar.com asking for an update from
-release 1.2 to 1.4 of the tc compiler.  You have no such patches on
-hand, but with CVS that can easily be fixed with a command such as this:
+Disadvantages:
 
-     $ cvs rdiff -c -r FOO1_2 -r FOO1_4 tc | \
-     $$ Mail -s 'The patches you asked for' foo@bar.com
+   * Old releases cannot easily be fetched from the repository.  (The
+     file will show up as NEW even in revisions from the time before it
+     was renamed).
 
-   Suppose you have made release 1.3, and forked a branch called
-`R_1_3fix' for bugfixes.  `R_1_3_1' corresponds to release 1.3.1, which
-was made some time ago.  Now, you want to see how much development has
-been done on the branch.  This command can be used:
+   * There is no log information of when the file was renamed.
 
-     $ 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
+   * Nasty things might happen if someone accesses the history file
+     while you are moving it.  Make sure no one else runs any of the CVS
+     commands while you move it.
 
 
-File: cvs.info,  Node: release,  Next: remove,  Prev: rdiff,  Up: Invoking CVS
+File: cvs.info,  Node: Rename by copying,  Prev: Inside,  Up: Moving files
 
-release--Indicate that a Module is no longer in use
-===================================================
+Copying the history file
+------------------------
 
-   * release [-dQq] modules...
+   This way also involves direct modifications to the repository.  It
+is safe, but not without drawbacks.
 
-   * Requires: Working directory.
+     # Copy the RCS file inside the repository
+     $ cd $CVSROOT/DIR
+     $ cp OLD,v NEW,v
+     # Remove the old file
+     $ cd ~/DIR
+     $ rm OLD
+     $ cvs remove OLD
+     $ cvs commit OLD
+     # Remove all tags from NEW
+     $ cvs update NEW
+     $ cvs log NEW             # Remember the non-branch tag names
+     $ cvs tag -d TAG1 NEW
+     $ cvs tag -d TAG2 NEW
+     ...
 
-   * Changes: Working directory, history log.
+   By removing the tags you will be able to check out old revisions.
 
-   This command is meant to safely cancel the effect of `cvs checkout'.
-Since CVS doesn't lock files, it isn't strictly necessary to use this
-command.  You can always simply delete your working directory, if you
-like; but you risk losing changes you may have forgotten, and you leave
-no trace in the CVS history file (*note history file::.) that you've
-abandoned your checkout.
+Advantages:
 
-   Use `cvs release' to avoid these problems.  This command checks that
-no uncommitted changes are present; that you are executing it from
-immediately above a CVS working directory; and that the repository
-recorded for your files is the same as the repository defined in the
-module database.
+   * Checking out old revisions works correctly, as long as you use
+     `-rTAG' and not `-DDATE' to retrieve the revisions.
 
-   If all these conditions are true, `cvs release' leaves a record of
-its execution (attesting to your intentionally abandoning your
-checkout) in the CVS history log.
-
-* Menu:
-
-* release options::             release options
-* release output::              release options
-* release examples::            release examples
-
-
-File: cvs.info,  Node: release options,  Next: release output,  Up: release
+   * The log of changes is maintained intact.
 
-release options
----------------
+   * The revision numbers are not affected.
 
-   The `release' command supports one command option:
+Disadvantages:
 
-`-d'
-     Delete your working copy of the file if the release succeeds.  If
-     this flag is not given your files will remain in your working
-     directory.
+   * You cannot easily see the history of the file across the rename.
 
-     *Warning:*  The `release' command uses `rm -r `module'' to delete
-     your file.  This has the very serious side-effect that any
-     directory that you have created inside your checked-out sources,
-     and not added to the repository (using the `add' command; *note
-     add::.) will be silently deleted--even if it is non-empty!
 
diff --git a/gnu/usr.bin/cvs/doc/cvs.info-4 b/gnu/usr.bin/cvs/doc/cvs.info-4
index dc97df8e6c8..76a4437d117 100644
--- a/gnu/usr.bin/cvs/doc/cvs.info-4
+++ b/gnu/usr.bin/cvs/doc/cvs.info-4
@@ -1,5 +1,8 @@
-This is Info file cvs.info, produced by Makeinfo-1.55 from the input
-file ./cvs.texinfo.
+This is cvs.info, produced by makeinfo version 4.0 from cvs.texinfo.
+
+START-INFO-DIR-ENTRY
+* CVS: (cvs).          Concurrent Versions System
+END-INFO-DIR-ENTRY
 
    Copyright (C) 1992, 1993 Signum Support AB Copyright (C) 1993, 1994
 Free Software Foundation, Inc.
@@ -10,1264 +13,1277 @@ preserved on all copies.
 
    Permission is granted to copy and distribute modified versions of
 this manual under the conditions for verbatim copying, provided also
-that the section entitled "GNU General Public License" is included
-exactly as in the original, and provided that the entire resulting
-derived work is distributed under the terms of a permission notice
-identical to this one.
+that the entire resulting derived work is distributed under the terms
+of a permission notice identical to this one.
 
    Permission is granted to copy and distribute translations of this
 manual into another language, under the above conditions for modified
-versions, except that the section entitled "GNU General Public License"
-and this permission notice may be included in translations approved by
-the Free Software Foundation instead of in the original English.
+versions, except that this permission notice may be stated in a
+translation approved by the Free Software Foundation.
 
 
-File: cvs.info,  Node: release output,  Next: release examples,  Prev: release options,  Up: release
-
-release output
---------------
+File: cvs.info,  Node: Moving directories,  Prev: Moving files,  Up: Adding and removing
 
-   Before `release' releases your sources it will print a one-line
-message for any file that is not up-to-date.
-
-   *Warning:*  Any new directories that you have created, but not added
-to the CVS directory hierarchy with the `add' command (*note add::.)
-will be silently ignored (and deleted, if `-d' is specified), even if
-they contain files.
+Moving and renaming directories
+===============================
 
-`U FILE'
-     There exists a newer revision of this file in the repository, and
-     you have not modified your local copy of the file.
+   The normal way to rename or move a directory is to rename or move
+each file within it as described in *Note Outside::.  Then check out
+with the `-P' option, as described in *Note Removing directories::.
 
-`A FILE'
-     The file has been added to your private copy of the sources, but
-     has not yet been committed to the repository.  If you delete your
-     copy of the sources this file will be lost.
+   If you really want to hack the repository to rename or delete a
+directory in the repository, you can do it like this:
 
-`R FILE'
-     The file has been removed from your private copy of the sources,
-     but has not yet been removed from the repository, since you have
-     not yet committed the removal.  *Note commit::.
+  1. 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.
 
-`M FILE'
-     The file is modified in your working directory.  There might also
-     be a newer revision inside the repository.
+  2. Rename the directory inside the repository.
 
-`? FILE'
-     FILE is in your working directory, but does not correspond to
-     anything in the source repository, and is not in the list of files
-     for CVS to ignore (see the description of the `-I' option, and
-     *note cvsignore::.).  If you remove your working sources, this
-     file will be lost.
+          $ cd $CVSROOT/PARENT-DIR
+          $ mv OLD-DIR NEW-DIR
 
-     Note that no warning message like this is printed for spurious
-     directories that CVS encounters.  The directory, and all its
-     contents, are silently ignored.
+  3. Fix the CVS administrative files, if necessary (for instance if
+     you renamed an entire module).
 
-
-File: cvs.info,  Node: release examples,  Prev: release output,  Up: release
+  4. Tell everyone that they can check out again and continue working.
 
-release examples
-----------------
 
-   Release the module, and delete your local working copy of the files.
+   If someone had a working copy the CVS commands will cease to work
+for him, until he removes the directory that disappeared inside the
+repository.
 
-     $ cd ..         # You must stand immediately above the
-                     # sources when you issue `cvs release'.
-     $ cvs release -d tc
-     You have [0] altered files in this repository.
-     Are you sure you want to release (and delete) module `tc': y
-     $
+   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.
 
 
-File: cvs.info,  Node: remove,  Next: rtag,  Prev: release,  Up: Invoking CVS
-
-remove--Remove an entry from the repository
-===========================================
-
-   * remove [-lR] [files...]
-
-   * Requires: Working directory.
+File: cvs.info,  Node: History browsing,  Next: Binary files,  Prev: Adding and removing,  Up: Top
 
-   * Changes: Working directory.
+History browsing
+****************
 
-   * Synonyms: rm, delete
-
-   Use this command to declare that you wish to remove files from the
-source repository.  Like most CVS commands, `cvs remove' works on files
-in your working directory, not directly on the repository.  As a
-safeguard, it also requires that you first erase the specified files
-from your working directory.
-
-   The files are not actually removed until you apply your changes to
-the repository with `commit'; at that point, the corresponding RCS
-files in the source repository are moved into the `Attic' directory
-(also within the source repository).
-
-   This command is recursive by default, scheduling all physically
-removed files that it finds for removal by the next commit.  Use the
-`-l' option to avoid this recursion, or just specify the actual files
-that you wish removed.
+   Once you have used CVS 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.
 
 * Menu:
 
-* remove options::              remove options
-* remove examples::             remove examples
+* log messages::                Log messages
+* history database::            The history database
+* user-defined logging::        User-defined logging
+* annotate::                    What revision modified each line of a file?
 
 
-File: cvs.info,  Node: remove options,  Next: remove examples,  Up: remove
-
-remove options
---------------
+File: cvs.info,  Node: log messages,  Next: history database,  Up: History browsing
 
-   Two of the standard options are the only options supported by
-`remove'.
+Log messages
+============
 
-`-l'
-     Local; run only in current working directory.
+   Whenever you commit a file you specify a log message.
 
-`-R'
-     Commit directories recursively.  This is on by default.
+   To look through the log messages which have been specified for every
+revision which has been committed, use the `cvs log' command (*note
+log::).
 
 
-File: cvs.info,  Node: remove examples,  Prev: remove options,  Up: remove
-
-remove examples
----------------
-
-Remove a couple of files.
-.........................
-
-     $ 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 .
-
-Resurrecting removed files
-..........................
-
-   If you change your mind you can easily resurrect the file before you
-commit it, using the `add' command.
-
-     $ 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
-
-   If you realize your mistake before you run the `remove' command you
-can use `update' to resurrect the file:
-
-     $ rm oj.c
-     $ cvs update oj.c
-     cvs update: warning: oj.c was lost
-     U oj.c
-
-
-File: cvs.info,  Node: rtag,  Next: status,  Prev: remove,  Up: Invoking CVS
-
-rtag--Add a tag to the RCS file
-===============================
+File: cvs.info,  Node: history database,  Next: user-defined logging,  Prev: log messages,  Up: History browsing
 
-   * rtag [-falnRQq] [-b] [-d] [-r tag | -Ddate] symbolic_tag modules...
-
-   * Requires: repository.
-
-   * Changes: repository.
-
-   * Synonym: rfreeze
-
-   You can use this command to assign symbolic tags to particular,
-explicitly specified source revisions in the repository.  `rtag' works
-directly on the repository contents (and requires no prior checkout).
-Use `tag' instead (*note tag::.), to base the selection of revisions on
-the contents of your working directory.
-
-   If you attempt to use a tag name that already exists, CVS will
-complain and not overwrite that tag.  Use the `-F' option to force the
-new tag value.
+The history database
+====================
 
-* Menu:
+   You can use the history file (*note history file::) to log various
+CVS actions.  To retrieve the information from the history file, use
+the `cvs history' command (*note history::).
 
-* rtag options::                rtag options
+   Note: you can control what is logged to this file by using the
+`LogHistory' keyword in the `CVSROOT/config' file (*note config::).
 
 
-File: cvs.info,  Node: rtag options,  Up: rtag
-
-rtag options
-------------
+File: cvs.info,  Node: user-defined logging,  Next: annotate,  Prev: history database,  Up: History browsing
 
-   These standard options are supported by `rtag' (*note Common
-options::., for a complete description of them):
-
-`-D DATE'
-     Tag the most recent revision no later than DATE.
-
-`-f'
-     Only useful with the `-D DATE' or `-r TAG' flags.  If no matching
-     revision is found, use the most recent revision (instead of
-     ignoring the file).
-
-`-F'
-     Overwrite an existing tag of the same name on a different
-     revision.  This option is new in CVS 1.4.  The old behavior is
-     matched by `cvs tag -F'.
+User-defined logging
+====================
 
-`-l'
-     Local; run only in current working directory.
+   You can customize CVS 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 `loginfo' file (*note loginfo::).  To log
+commits, checkouts, exports, and tags, respectively, you can also use
+the `-i', `-o', `-e', and `-t' 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 `cvs
+watch add' command (*note Getting Notified::); this command is useful
+even if you are not using `cvs watch on'.
+
+   The `taginfo' file defines programs to execute when someone executes
+a `tag' or `rtag' command.  The `taginfo' file has the standard form
+for administrative files (*note 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 TAGNAME, OPERATION
+(`add' for `tag', `mov' for `tag -F', and `del' for `tag -d'),
+REPOSITORY, and any remaining are pairs of FILENAME REVISION.  A
+non-zero exit of the filter program will cause the tag to be aborted.
+
+   Here is an example of using taginfo to log tag and rtag commands.
+In the taginfo file put:
+
+     ALL /usr/local/cvsroot/CVSROOT/loggit
+
+   Where `/usr/local/cvsroot/CVSROOT/loggit' contains the following
+script:
 
-`-n'
-     Do not run any tag program that was specified with the `-t' flag
-     inside the `modules' file.  (*note modules::.).
+     #!/bin/sh
+     echo "$@" >>/home/kingdon/cvsroot/CVSROOT/taglog
 
-`-R'
-     Commit directories recursively.  This is on by default.
+
+File: cvs.info,  Node: annotate,  Prev: user-defined logging,  Up: History browsing
 
-`-r TAG'
-     Only tag those files that contain TAG.  This can be used to rename
-     a tag: tag only the files identified by the old tag, then delete
-     the old tag, leaving the new tag on exactly the same files as the
-     old tag.
+Annotate command
+================
 
-   In addition to the above common options, these options are available:
+ - Command: cvs annotate [`-flR'] [`-r rev'|`-D date'] files ...
+     For each file in FILES, print the head revision of the trunk,
+     together with information on the last modification for each line.
+     For example:
 
-`-a'
-     Use the `-a' option to have `rtag' look in the `Attic' (*note
-     Removing files::.) for removed files that contain the specified
-     tag.  The tag is removed from these files, which makes it
-     convenient to re-use a symbolic tag as development continues (and
-     files get removed from the up-coming distribution).
+          $ cvs annotate ssfile
+          Annotations for ssfile
+          ***************
+          1.1          (mary     27-Mar-96): ssfile line 1
+          1.2          (joe      28-Mar-96): ssfile line 2
 
-`-b'
-     Make the tag a branch tag.  *Note Branches::.
+     The file `ssfile' currently contains two lines.  The `ssfile line
+     1' line was checked in by `mary' on March 27.  Then, on March 28,
+     `joe' added a line `ssfile line 2', without modifying the `ssfile
+     line 1' line.  This report doesn't tell you anything about lines
+     which have been deleted or replaced; you need to use `cvs diff'
+     for that (*note diff::).
 
-`-d'
-     Delete the tag instead of creating it.
 
-     In general, tags (often the symbolic names of software
-     distributions) should not be removed, but the `-d' option is
-     available as a means to remove completely obsolete symbolic names
-     if necessary (as might be the case for an Alpha release, or if you
-     mistagged a module).
+   The options to `cvs annotate' are listed in *Note Invoking CVS::,
+and can be used to select the files and revisions to annotate.  The
+options are described in more detail in *Note Common options::.
 
 
-File: cvs.info,  Node: status,  Next: tag,  Prev: rtag,  Up: Invoking CVS
-
-status--Status info on the revisions
-====================================
+File: cvs.info,  Node: Binary files,  Next: Multiple developers,  Prev: History browsing,  Up: Top
 
-   * status [-lR] [-v] [files...]
+Handling binary files
+*********************
 
-   * Requires: working directory, repository.
-
-   * Changes: nothing.
-
-   Display a brief report on the current status of files with respect
-to the source repository, including any sticky tags, dates, or `-k'
-options.
-
-   You can also use this command to determine the potential impact of a
-`cvs update' on your working source directory--but remember that things
-might change in the repository before you run `update'.
+   The most common use for CVS is to store text files.  With text
+files, CVS 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, CVS
+can store binary files.  For example, one might store a web site in CVS
+including both text files and binary images.
 
 * Menu:
 
-* status options::              status options
+* Binary why::     More details on issues with binary files
+* Binary howto::   How to store them
 
 
-File: cvs.info,  Node: status options,  Up: status
-
-status options
---------------
+File: cvs.info,  Node: Binary why,  Next: Binary howto,  Up: Binary files
 
-   These standard options are supported by `status' (*note Common
-options::., for a complete description of them):
-
-`-l'
-     Local; run only in current working directory.
-
-`-R'
-     Commit directories recursively.  This is on by default.
-
-   There is one additional option:
+The issues with binary files
+============================
 
-`-v'
-     Verbose.  In addition to the information normally displayed, print
-     all symbolic tags, together with the numerical value of the
-     revision or branch they refer to.
+   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.
+
+   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, CVS provides
+this functionality via the `cvs diff' command.  For binary files, it
+may be possible to extract the two revisions and then compare them with
+a tool external to CVS (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.
+
+   Another ability of a version control system is the ability to merge
+two revisions.  For CVS this happens in two contexts.  The first is
+when users make changes in separate working directories (*note Multiple
+developers::).  The second is when one merges explicitly with the
+`update -j' command (*note Branching and merging::).
+
+   In the case of text files, CVS can merge changes made independently,
+and signal a conflict if the changes conflict.  With binary files, the
+best that CVS 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.
+
+   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 *Note Multiple developers::.  To avoid the merges resulting
+from branches, restrict use of branches.
 
 
-File: cvs.info,  Node: tag,  Next: update,  Prev: status,  Up: Invoking CVS
+File: cvs.info,  Node: Binary howto,  Prev: Binary why,  Up: Binary files
 
-tag--Add a symbolic tag to checked out version of RCS file
-==========================================================
-
-   * tag [-lQqR] [-b] [-d] symbolic_tag [files...]
-
-   * Requires: working directory, repository.
-
-   * Changes: repository.
-
-   * Synonym: freeze
-
-   Use this command to assign symbolic tags to the nearest repository
-versions to your working sources.  The tags are applied immediately to
-the repository, as with `rtag', but the versions are supplied
-implicitly by the CVS records of your working files' history rather than
-applied explicitly.
-
-   One use for tags is to record a snapshot of the current sources when
-the software freeze date of a project arrives.  As bugs are fixed after
-the freeze date, only those changed sources that are to be part of the
-release need be re-tagged.
-
-   The symbolic tags are meant to permanently record which revisions of
-which files were used in creating a software distribution.  The
-`checkout' and `update' commands allow you to extract an exact copy of
-a tagged release at any time in the future, regardless of whether files
-have been changed, added, or removed since the release was tagged.
+How to store binary files
+=========================
 
-   This command can also be used to delete a symbolic tag, or to create
-a branch.  See the options section below.
+   There are two issues with using CVS to store binary files.  The
+first is that CVS 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).
+
+   The second is that a binary file might happen to contain data which
+looks like a keyword (*note Keyword substitution::), so keyword
+expansion must be turned off.
+
+   The `-kb' option available with some CVS commands insures that
+neither line ending conversion nor keyword expansion will be done.
+
+   Here is an example of how you can create a new file using the `-kb'
+flag:
+
+     $ echo '$Id: cvs.info-4,v 1.2 2001/09/29 00:00:39 tholo Exp $' > kotest
+     $ cvs add -kb -m"A test file" kotest
+     $ cvs ci -m"First checkin; contains a keyword" kotest
+
+   If a file accidentally gets added without `-kb', one can use the
+`cvs admin' command to recover.  For example:
+
+     $ echo '$Id: cvs.info-4,v 1.2 2001/09/29 00:00:39 tholo Exp $' > 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
+     # For non-unix systems:
+     # Copy in a good copy of the file from outside CVS
+     $ cvs commit -m "make it binary" kotest
+
+   When you check in the file `kotest' the file is not preserved as a
+binary file, because you did not check it in as a binary file.  The `cvs
+admin -kb' 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
+CVS on a non-unix system), then you need to check in a new copy of the
+file, as shown by the `cvs commit' command above.  On unix, the `cvs
+update -A' command suffices.
+
+   However, in using `cvs admin -k' 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, CVS 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.
+
+   You can also set a default for whether `cvs add' and `cvs import'
+treat a file as binary based on its name; for example you could say
+that files who names end in `.exe' are binary.  *Note Wrappers::.
+There is currently no way to have CVS 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.
 
-   If you attempt to use a tag name that already exists, CVS will
-complain and not overwrite that tag.  Use the `-F' option to force the
-new tag value.
+
+File: cvs.info,  Node: Multiple developers,  Next: Revision management,  Prev: Binary files,  Up: Top
+
+Multiple developers
+*******************
+
+   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 "file locking" or "reserved
+checkouts", is to allow only one person to edit each file at a time.
+This is the only solution with some version control systems, including
+RCS and SCCS.  Currently the usual way to get reserved checkouts with
+CVS is the `cvs admin -l' command (*note admin options::).  This is not
+as nicely integrated into CVS 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.
+
+   The default model with CVS is known as "unreserved checkouts".  In
+this model, developers can edit their own "working copy" 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 CVS commands to bring their working copy up to date with the
+repository revision.  This process is almost automatic.
+
+   CVS also supports mechanisms which facilitate various kinds of
+communication, without actually enforcing rules like reserved checkouts
+do.
+
+   The rest of this chapter describes how these various models work,
+and some of the issues involved in choosing between them.
 
 * Menu:
 
-* tag options::                 tag options
+* File status::                 A file can be in several states
+* Updating a file::             Bringing a file up-to-date
+* Conflicts example::           An informative example
+* Informing others::            To cooperate you must inform
+* Concurrency::                 Simultaneous repository access
+* Watches::                     Mechanisms to track who is editing files
+* Choosing a model::            Reserved or unreserved checkouts?
 
 
-File: cvs.info,  Node: tag options,  Up: tag
-
-tag options
------------
-
-   These standard options are supported by `tag' (*note Common
-options::., for a complete description of them):
-
-`-F'
-     Overwrite an existing tag of the same name on a different
-     revision.  This option is new in CVS 1.4.  The old behavior is
-     matched by `cvs tag -F'.
-
-`-l'
-     Local; run only in current working directory.
-
-`-R'
-     Commit directories recursively.  This is on by default.
-
-   Two special options are available:
-
-`-b'
-     The -b option makes the tag a branch tag (*note Branches::.),
-     allowing concurrent, isolated development.  This is most useful
-     for creating a patch to a previously released software
-     distribution.
+File: cvs.info,  Node: File status,  Next: Updating a file,  Up: Multiple developers
+
+File status
+===========
+
+   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 `status' command, are:
+
+Up-to-date
+     The file is identical with the latest revision in the repository
+     for the branch in use.
+
+Locally Modified
+     You have edited the file, and not yet committed your changes.
+
+Locally Added
+     You have added the file with `add', and not yet committed your
+     changes.
+
+Locally Removed
+     You have removed the file with `remove', and not yet committed
+     your changes.
+
+Needs Checkout
+     Someone else has committed a newer revision to the repository.
+     The name is slightly misleading; you will ordinarily use `update'
+     rather than `checkout' to get that newer revision.
+
+Needs Patch
+     Like Needs Checkout, but the CVS server will send a patch rather
+     than the entire file.  Sending a patch or sending an entire file
+     accomplishes the same thing.
+
+Needs Merge
+     Someone else has committed a newer revision to the repository, and
+     you have also made modifications to the file.
+
+File had conflicts on merge
+     This is like Locally Modified, except that a previous `update'
+     command gave a conflict.  If you have not already done so, you
+     need to resolve the conflict as described in *Note Conflicts
+     example::.
+
+Unknown
+     CVS doesn't know anything about this file.  For example, you have
+     created a new file and have not run `add'.
+
+   To help clarify the file status, `status' also reports the `Working
+revision' which is the revision that the file in the working directory
+derives from, and the `Repository revision' which is the latest
+revision in the repository for the branch in use.
+
+   The options to `status' are listed in *Note Invoking CVS::.  For
+information on its `Sticky tag' and `Sticky date' output, see *Note
+Sticky tags::.  For information on its `Sticky options' output, see the
+`-k' option in *Note update options::.
+
+   You can think of the `status' and `update' commands as somewhat
+complementary.  You use `update' to bring your files up to date, and you
+can use `status' to give you some idea of what an `update' would do (of
+course, the state of the repository might change before you actually run
+`update').  In fact, if you want a command to display file status in a
+more brief format than is displayed by the `status' command, you can
+invoke
 
-`-d'
-     Delete a tag.
+     $ cvs -n -q update
 
-     If you use `cvs tag -d symbolic_tag', the symbolic tag you specify
-     is deleted instead of being added.  Warning: Be very certain of
-     your ground before you delete a tag; doing this permanently
-     discards some historical information, which may later turn out to
-     be valuable.
+   The `-n' option means to not actually do the update, but merely to
+display statuses; the `-q' option avoids printing the name of each
+directory.  For more information on the `update' command, and these
+options, see *Note Invoking CVS::.
 
 
-File: cvs.info,  Node: update,  Prev: tag,  Up: Invoking CVS
-
-update--Bring work tree in sync with repository
-===============================================
+File: cvs.info,  Node: Updating a file,  Next: Conflicts example,  Prev: File status,  Up: Multiple developers
 
-   * update [-AdflPpQqR] [-d] [-r tag|-D date] files...
+Bringing a file up to date
+==========================
 
-   * Requires: repository, working directory.
+   When you want to update or merge a file, use the `update' command.
+For files that are not up to date this is roughly equivalent to a
+`checkout' command: the newest revision of the file is extracted from
+the repository and put in your working directory.
 
-   * Changes: working directory.
+   Your modifications to a file are never lost when you use `update'.
+If no newer revision exists, running `update' has no effect.  If you
+have edited the file, and a newer revision is available, CVS will merge
+all changes into your working copy.
 
-   After you've run checkout to create your private copy of source from
-the common repository, other developers will continue changing the
-central source.  From time to time, when it is convenient in your
-development process, you can use the `update' command from within your
-working directory to reconcile your work with any revisions applied to
-the source repository since your last checkout or update.
-
-* Menu:
+   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 `update' on the file now,
+CVS will incorporate all changes between revision 1.4 and 1.6 into your
+file.
 
-* update options::              update options
-* update output::               update output
-* update examples::             update examples
+   If any of the changes between 1.4 and 1.6 were made too close to any
+of the changes you have made, an "overlap" occurs.  In such cases a
+warning is printed, and the resulting file includes both versions of
+the lines that overlap, delimited by special markers.  *Note update::,
+for a complete description of the `update' command.
 
 
-File: cvs.info,  Node: update options,  Next: update output,  Up: update
-
-update options
---------------
-
-   These standard options are available with `update' (*note Common
-options::., for a complete description of them):
-
-`-D date'
-     Use the most recent revision no later than DATE.  This option is
-     sticky, and implies `-P'.
-
-`-f'
-     Only useful with the `-D DATE' or `-r TAG' flags.  If no matching
-     revision is found, retrieve the most recent revision (instead of
-     ignoring the file).
-
-`-k KFLAG'
-     Process RCS keywords according to KFLAG.  See co(1).  This option
-     is sticky; future updates of this file in this working directory
-     will use the same KFLAG.  The `status' command can be viewed to
-     see the sticky options.  *Note status::.
-
-`-l'
-     Local; run only in current working directory.
-
-`-P'
-     Prune empty directories.
-
-`-p'
-     Pipe files to the standard output.
-
-`-R'
-     Commit directories recursively.  This is on by default.
-
-`-r tag'
-     Retrieve revision TAG.  This option is sticky, and implies `-P'.
-
-   These special options are also available with `update'.
-
-`-A'
-     Reset any sticky tags, dates, or `-k' options.  (If you get a
-     working copy of a file by using one of the `-r', `-D', or `-k'
-     options, CVS remembers the corresponding tag, date, or KFLAG and
-     continues using it on future updates; use the `-A' option to make
-     CVS forget these specifications, and retrieve the head revision of
-     the file).
-
-`-d'
-     Create any directories that exist in the repository if they're
-     missing from the working directory.  Normally, `update' acts only
-     on directories and files that were already enrolled in your
-     working directory.
-
-     This is useful for updating directories that were created in the
-     repository since the initial checkout; but it has an unfortunate
-     side effect.  If you deliberately avoided certain directories in
-     the repository when you created your working directory (either
-     through use of a module name or by listing explicitly the files
-     and directories you wanted on the command line), then updating
-     with `-d' will create those directories, which may not be what you
-     want.
-
-`-I NAME'
-     Ignore files whose names match NAME (in your working directory)
-     during the update.  You can specify `-I' more than once on the
-     command line to specify several files to ignore.  By default,
-     `update' ignores files whose names match any of the following:
-
-                  RCSLOG  RCS     SCCS
-                  CVS*    cvslog.*
-                  tags    TAGS
-                  .make.state     .nse_depinfo
-                  *~      #*      .#*     ,*
-                  *.old   *.bak   *.BAK   *.orig  *.rej   .del-*
-                  *.a     *.o     *.so    *.Z     *.elc   *.ln
-                  core
-
-     Use `-I !' to avoid ignoring any files at all.  *Note cvsignore::,
-     for other ways to make CVS ignore some files.
-
-`-WSPEC'
-     Specify file names that should be filtered during update.  You can
-     use this option repeatedly.
-
-     SPEC can be a file name pattern of the same type that you can
-     specify in the `.cvswrappers' file. *Note Wrappers::.
-
-`-jBRANCH'
-     Merge the changes made between the resulting revision and the
-     revision that it is based on (e.g., if the tag refers to a branch,
-     CVS will merge all changes made in that branch into your working
-     file).
-
-     With two `-j' options, CVS will merge in the changes between the
-     two respective revisions.  This can be used to remove a certain
-     delta from your working file;  if the file `foo.c' is based on
-     revision 1.6 and you want to remove the changes made between 1.3
-     and 1.5, you might do:
-
-          $ cvs update -j1.5 -j1.3 foo.c   # note the order...
-
-     In addition, each -j option can contain an optional date
-     specification which, when used with branches, can limit the chosen
-     revision to one within a specific date.  An optional date is
-     specified by adding a colon (:) to the tag:
-     `-jSYMBOLIC_TAG:DATE_SPECIFIER'.
+File: cvs.info,  Node: Conflicts example,  Next: Informing others,  Prev: Updating a file,  Up: Multiple developers
 
-
-File: cvs.info,  Node: update output,  Next: update examples,  Prev: update options,  Up: update
-
-update output
--------------
-
-   `update' keeps you informed of its progress by printing a line for
-each file, preceded by one character indicating the status of the file:
-
-`U FILE'
-     The file 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.
-
-`A FILE'
-     The file has been added to your private copy of the sources, and
-     will be added to the source repository when you run `commit' on
-     the file.  This is a reminder to you that the file needs to be
-     committed.
-
-`R FILE'
-     The file has been removed from your private copy of the sources,
-     and will be removed from the source repository when you run
-     `commit' on the file.  This is a reminder to you that the file
-     needs to be committed.
-
-`M FILE'
-     The file is modified in  your  working  directory.
-
-     `M' can indicate one of two states for a file you're working on:
-     either there were no modifications to the same file in the
-     repository, so that your file remains as you last saw it; or there
-     were modifications in the repository as well as in your copy, but
-     they were merged successfully, without conflict, in your working
-     directory.
-
-     CVS will print some messages if it merges your work, and a backup
-     copy of your working file (as it looked before you ran `update')
-     will be made.  The exact name of that file is printed while
-     `update' runs.
-
-`C FILE'
-     A conflict was detected while trying to merge your changes to FILE
-     with changes from the source repository.  FILE (the copy in your
-     working directory) is now the output of the rcsmerge(1) command on
-     the two revisions; an unmodified copy of your file is also in your
-     working directory, with the name `.#FILE.REVISION' where REVISION
-     is the RCS revision that your modified file started from.  (Note
-     that some systems automatically purge files that begin with `.#'
-     if they have not been accessed for a few days.  If you intend to
-     keep a copy of your original file, it is a very good idea to rename
-     it.)
-
-`? FILE'
-     FILE is in your working directory, but does not correspond to
-     anything in the source repository, and is not in the list of files
-     for CVS to ignore (see the description of the `-I' option, and
-     *note cvsignore::.).
-
-     Note that no warning message like this is printed for spurious
-     directories that CVS encounters.  The directory, and all its
-     contents, are silently ignored.
+Conflicts example
+=================
 
-
-File: cvs.info,  Node: update examples,  Prev: update output,  Up: update
+   Suppose revision 1.4 of `driver.c' contains this:
 
-update examples
----------------
+     #include <stdio.h>
+     
+     void main()
+     {
+         parse();
+         if (nerr == 0)
+             gencode();
+         else
+             fprintf(stderr, "No code generated.\n");
+         exit(nerr == 0 ? 0 : 1);
+     }
+
+Revision 1.6 of `driver.c' contains this:
+
+     #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);
+     }
+
+Your working copy of `driver.c', based on revision 1.4, contains this
+before you run `cvs update':
+
+     #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);
+     }
+
+You run `cvs update':
+
+     $ 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
+
+CVS tells you that there were some conflicts.  Your original working
+file is saved unmodified in `.#driver.c.1.4'.  The new version of
+`driver.c' contains this:
+
+     #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
+     }
+
+Note how all non-overlapping modifications are incorporated in your
+working copy, and that the overlapping section is clearly marked with
+`<<<<<<<', `=======' and `>>>>>>>'.
+
+   You resolve the conflict by editing the file, removing the markers
+and the erroneous line.  Suppose you end up with this file:
+     #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);
+     }
+
+You can now go ahead and commit this as revision 1.7.
+
+     $ 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
 
-   The following line will display all files which are not up-to-date
-without actually change anything in your working directory.  It can be
-used to check what has been going on with the project.
+   For your protection, CVS 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 CVS, you also needed to insure that the file
+contains no conflict markers.  Because your file may legitimately
+contain conflict markers (that is, occurrences of `>>>>>>> ' at the
+start of a line that don't mark a conflict), the current version of CVS
+will print a warning and proceed to check in the file.
 
-     $ cvs -n -q update
+   If you use release 1.04 or later of pcl-cvs (a GNU Emacs front-end
+for CVS) you can use an Emacs package called emerge to help you resolve
+conflicts.  See the documentation for pcl-cvs.
 
 
-File: cvs.info,  Node: Administrative files,  Next: Environment variables,  Prev: Invoking CVS,  Up: Top
-
-Reference manual for the Administrative files
-*********************************************
-
-   Inside the repository, in the directory `$CVSROOT/CVSROOT', there
-are a number of supportive files for CVS.  You can use CVS in a limited
-fashion without any of them, but if they are set up properly they can
-help make life easier.
+File: cvs.info,  Node: Informing others,  Next: Concurrency,  Prev: Conflicts example,  Up: Multiple developers
 
-   The most important of these files is the `modules' file, which
-defines the modules inside the repository.
+Informing others about commits
+==============================
 
-* Menu:
-
-* modules::                     Defining modules
-* Wrappers::                    Treat directories as files
-* commit files::                The commit support files
-* commitinfo::                  Pre-commit checking
-* editinfo::                    Specifying how log messages are created
-* loginfo::                     Where should log messages be sent?
-* rcsinfo::                     Templates for the log messages
-* cvsignore::                   Ignoring files via cvsignore
-* history file::                History information
-* Setting up::                  Setting up the repository
+   It is often useful to inform others when you commit a new revision
+of a file.  The `-i' option of the `modules' file, or the `loginfo'
+file, can be used to automate this process.  *Note modules::.  *Note
+loginfo::.  You can use these features of CVS to, for instance,
+instruct CVS to mail a message to all developers, or post a message to
+a local newsgroup.
 
 
-File: cvs.info,  Node: modules,  Next: Wrappers,  Up: Administrative files
+File: cvs.info,  Node: Concurrency,  Next: Watches,  Prev: Informing others,  Up: Multiple developers
 
-The modules file
-================
+Several developers simultaneously attempting to run CVS
+=======================================================
 
-   The `modules' file records your definitions of names for collections
-of source code.  CVS will use these definitions if you create a file
-with the right format in `$CVSROOT/CVSROOT/modules,v'.  The
-mkmodules(1) command should be run whenever the modules file changes,
-so that the appropriate files can be generated (depending on how you
-have configured CVS operation).
-
-   To allow convenient editing of the `modules' file itself, the file
-should include an entry like the following (where LOCALBIN represents
-the directory where your site installs programs like mkmodules(1)):
-
-     modules    -i /LOCALBIN/mkmodules CVSROOT modules
-
-This defines the name `modules' as the module name for the file itself,
-so that you can use
-
-     $ cvs checkout modules
-
-to get a copy of the file that you can edit.  You should define similar
-module entries for the other configuration files described in this
-appendix, except `history').
-
-   The `modules' file may contain blank lines and comments (lines
-beginning with `#') as well as module definitions.  Long lines can be
-continued on the next line by specifying a backslash (`\') as the last
-character on the line.
-
-   A module definition is a single line of the `modules' file, in
-either of two formats.  In both cases, MNAME represents the symbolic
-module name, and the remainder of the line is its definition.
-
-`MNAME -a ALIASES...'
-     This represents the simplest way of defining a module MNAME.  The
-     `-a' flags the definition as a simple alias: CVS will treat any
-     use of MNAME (as a command argument) as if the list of names
-     ALIASES had been specified instead.  ALIASES may contain either
-     other module names or paths.  When you use paths in aliases,
-     `checkout' creates all intermediate directories in the working
-     directory, just as if the path had been specified explicitly in
-     the CVS arguments.
-
-`MNAME [ options ] DIR [ FILES... ] [ &MODULE... ]'
-     In the simplest case, this form of module definition reduces to
-     `MNAME DIR'.  This defines all the files in directory DIR as
-     module mname.  DIR is a relative path (from `$CVSROOT') to a
-     directory of source in the source repository.  In this case, on
-     checkout, a single directory called MNAME is created as a working
-     directory; no intermediate directory levels are used by default,
-     even if DIR was a path involving several directory levels.
-
-     By explicitly specifying files in the module definition after DIR,
-     you can select particular files from directory DIR.  The sample
-     definition for `modules' is an example of a module defined with a
-     single file from a particular directory.  Here is another example:
-
-          m4test  unsupported/gnu/m4 foreach.m4 forloop.m4
-
-     With this definition, executing `cvs checkout m4test' will create
-     a single working directory `m4test' containing the two files
-     listed, which both come from a common directory several levels deep
-     in the CVS source repository.
-
-     A module definition can refer to other modules by including
-     `&MODULE' in its definition.  `checkout' creates a subdirectory
-     for each such module, in your working directory.
-
-    `-d NAME'
-          Name the working directory something other than the module
-          name.
-
-    `-i PROG'
-          Specify a program PROG to run whenever files in a module are
-          committed.  PROG runs with a single argument, the full
-          pathname of the affected directory in a source repository.
-          The `commitinfo', `loginfo', and `editinfo' files provide
-          other ways to call a program on commit.
-
-    `-o PROG'
-          Specify a program PROG to run whenever files in a module are
-          checked out.  PROG runs with a single argument, the module
-          name.
-
-    `-s STATUS'
-          Assign a status to the module.  When the module file is
-          printed with `cvs checkout -s' the modules are sorted
-          according to primarily module status, and secondarily
-          according to the module name.  This option has no other
-          meaning.  You can use this option for several things besides
-          status: for instance, list the person that is responsible for
-          this module.
-
-    `-t PROG'
-          Specify a program PROG to run whenever files in a module are
-          tagged with `rtag'.  PROG runs with two arguments: the module
-          name and the symbolic tag specified to `rtag'.  There is no
-          way to specify a program to run when `tag' is executed.
-
-    `-u PROG'
-          Specify a program PROG to run whenever `cvs update' is
-          executed from the top-level directory of the checked-out
-          module.  PROG runs with a single argument, the full path to
-          the source repository for this module.
+   If several developers try to run CVS at the same time, one may get
+the following message:
 
-
-File: cvs.info,  Node: Wrappers,  Next: commit files,  Prev: modules,  Up: Administrative files
+     [11:43:23] waiting for bach's lock in /usr/local/cvsroot/foo
 
-The cvswrappers file
-====================
+   CVS 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 `#cvs.rfl', `#cvs.wfl', or `#cvs.lock'.
 
-   Wrappers are essentially directories that are to be treated as
-"files."  This package allows such wrappers to be "processed" on the
-way in and out of CVS.  The intended use is to wrap up a wrapper into a
-single tar, such that that tar can be treated as a single binary file
-in CVS.  Apparently this is particularly useful on NEXTSTEP.  To solve
-the problem effectively, it was also necessary to be able to prevent
-rcsmerge application at appropriate times.
+   Note that these locks are to protect CVS's internal data structures
+and have no relationship to the word "lock" in the sense used by
+RCS--which refers to reserved checkouts (*note Multiple developers::).
 
-   The file `cvswrappers' defines the script that will be run on a file
-when its name matches a regular expresion. There are two scripts that
-can be run on a file or directory.  A script to filter the
-directory/file before it gets checked in and another that is run when
-the file/directory gets checked out.
+   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.
 
-   The `cvswrappers' also specifies the merge methodology that should
-be used when the file is updated, that is should a MERGE or a straight
-COPY of the diferences be used when checking into the repository.
+   One might hope for the following property
 
-   The basic format of the file `cvswrappers' is given as such:
+     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.
 
-     wildcard     [option value][option value]...
-     
-     where option is one of
-     -f           from cvs filter         value: path tofilter
-     -t           to cvs filter           value: path to filter
-     -m           update methodology      value: MERGE or COPY
-     
-     and value is a single-quote delimited value.
+   but CVS does _not_ have this property.  For example, given the files
 
-     *.nib    -f 'uncom %s' -t 'comb %s %s' -m 'COPY'
-     *.rtfd   -f 'uncom %s' -t 'comb %s %s' -m 'COPY'
+     a/one.c
+     a/two.c
+     b/three.c
+     b/four.c
 
-The above example of a `cvswrappers' file states that all
-files/directories that end with a `.nib' should be filtered with the
-`comb' program before checking the file into the repository. The file
-should be filtered though the `uncom' program when the file is checked
-out of the repository. The `cvswrappers' file also states that a `COPY'
-methodology should be used when updating the files in the repository
-(that is no merging should be performed).
+   if someone runs
 
-The `comb' filter is called with two arguments, the first is the name
-of the file/directory to filter and the second is the pathname to where
-the resulting filtered file should be placed.
+     cvs ci a/two.c b/three.c
 
-The `uncom' filter is called with one argument, which is the name of
-the file to filter from. The end result of the `uncom' filter will be a
-file/directory in the users current working directory, that represents
-the source before being filtered.
+   and someone else runs `cvs update' at the same time, the person
+running `update' might get only the change to `b/three.c' and not the
+change to `a/two.c'.
 
 
-File: cvs.info,  Node: commit files,  Next: commitinfo,  Prev: Wrappers,  Up: Administrative files
-
-The commit support files
-========================
-
-   The `-i' flag in the `modules' file can be used to run a certain
-program whenever files are committed (*note modules::.).  The files
-described in this section provide other, more flexible, ways to run
-programs whenever something is committed.
-
-   There are three 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.
-
-`commitinfo'
-     The program is responsible for checking that the commit is
-     allowed.  If it exits with a non-zero exit status the commit will
-     be aborted.
-
-`editinfo'
-     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 `rcsinfo' file, which can hold
-     a log message template (*note rcsinfo::.).
-
-`loginfo'
-     The specified program is called when the commit is complete.  It
-     receives the log message and some additional information and can
-     store the log message in a file, or mail it to appropriate
-     persons, or maybe post it to a local newsgroup, or...  Your
-     imagination is the limit!
+File: cvs.info,  Node: Watches,  Next: Choosing a model,  Prev: Concurrency,  Up: Multiple developers
+
+Mechanisms to track who is editing files
+========================================
+
+   For many groups, use of CVS 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.
+
+   For maximum benefit developers should use `cvs edit' (not `chmod')
+to make files read-write to edit them, and `cvs release' (not `rm') to
+discard a working directory which is no longer in use, but CVS is not
+able to enforce this behavior.
 
 * Menu:
 
-* syntax::                      The common syntax
+* Setting a watch::             Telling CVS to watch certain files
+* Getting Notified::            Telling CVS to notify you
+* Editing files::               How to edit a file which is being watched
+* Watch information::           Information about who is watching and editing
+* Watches Compatibility::       Watches interact poorly with CVS 1.6 or earlier
 
 
-File: cvs.info,  Node: syntax,  Up: commit files
-
-The common syntax
------------------
+File: cvs.info,  Node: Setting a watch,  Next: Getting Notified,  Up: Watches
 
-   The four files `commitinfo', `loginfo', `rcsinfo' and `editinfo' all
-have a common format.  The purpose of the files are described later on.
-The common syntax is described here.
+Telling CVS to watch certain files
+----------------------------------
 
-   Each line contains the following:
-   * A regular expression
+   To enable the watch features, you first specify that certain files
+are to be watched.
 
-   * A whitespace separator--one or more spaces and/or tabs.
+ - Command: cvs watch on [`-lR'] files ...
+     Specify that developers should run `cvs edit' before editing
+     FILES.  CVS will create working copies of FILES read-only, to
+     remind developers to run the `cvs edit' command before working on
+     them.
 
-   * A file name or command-line template.
+     If FILES includes the name of a directory, CVS 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
+     `-l' option is given.  The `-R' option can be used to force
+     recursion if the `-l' option is set in `~/.cvsrc' (*note
+     ~/.cvsrc::).
 
-Blank lines are ignored.  Lines that start with the character `#' are
-treated as comments.  Long lines unfortunately can *not* be broken in
-two parts in any way.
+     If FILES is omitted, it defaults to the current directory.
 
-   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.
 
-
-File: cvs.info,  Node: commitinfo,  Next: editinfo,  Prev: commit files,  Up: Administrative files
-
-Commitinfo
-==========
-
-   The `commitinfo' file defines programs to execute whenever `cvs
-commit' is about to execute.  These programs are used for pre-commit
-checking to verify that the modified, added and removed files are really
-ready to be committed.  This could be used, for instance, to verify
-that the changed files conform to to your site's standards for coding
-practice.
-
-   As mentioned earlier, each line in the `commitinfo' 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).
+ - Command: cvs watch off [`-lR'] files ...
+     Do not create FILES read-only on checkout; thus, developers will
+     not be reminded to use `cvs edit' and `cvs unedit'.
 
-   The first line with a regular expression matching the relative path
-to the module will be used.  If the command returns a non-zero exit
-status the commit will be aborted.
+     The FILES and options are processed as for `cvs watch on'.
 
-   If the repository name does not match any of the regular expressions
-in this file, the `DEFAULT' line is used, if it is specified.
-
-   All occurances of the name `ALL' appearing as a regular expression
-are used in addition to the first matching regular expression or the
-name `DEFAULT'.
-
-   Note: when CVS is accessing a remote repository, `commitinfo' will
-be run on the *remote* (i.e., server) side, not the client side (*note
-Remote repositories::.).
 
 
-File: cvs.info,  Node: editinfo,  Next: loginfo,  Prev: commitinfo,  Up: Administrative files
-
-Editinfo
-========
-
-   If you want to make sure that all log messages look the same way,
-you can use the `editinfo' 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.
+File: cvs.info,  Node: Getting Notified,  Next: Editing files,  Prev: Setting a watch,  Up: Watches
 
-   If no matching line is found in the `editinfo' file, the editor
-specified in the environment variable `$CVSEDITOR' is used instead.  If
-that variable is not set, then the environment variable `$EDITOR' is
-used instead.  If that variable is not set a precompiled default,
-normally `vi', will be used.
+Telling CVS to notify you
+-------------------------
 
-   The `editinfo' file is often most useful together with the `rcsinfo'
-file, which can be used to specify a log message template.
+   You can tell CVS that you want to receive notifications about
+various actions taken on a file.  You can do this without using `cvs
+watch on' for the file, but generally you will want to use `cvs watch
+on', so that developers use the `cvs edit' command.
 
-   Each line in the `editinfo' 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.
+ - Command: cvs watch add [`-a' action] [`-lR'] files ...
+     Add the current user to the list of people to receive notification
+     of work done on FILES.
 
-   One thing that should be noted is that the `ALL' keyword is not
-supported.  If more than one matching line is found, the first one is
-used.  This can be useful for specifying a default edit script in a
-module, and then overriding it in a subdirectory.
+     The `-a' option specifies what kinds of events CVS should notify
+     the user about.  ACTION is one of the following:
 
-   If the repository name does not match any of the regular expressions
-in this file, the `DEFAULT' line is used, if it is specified.
+    `edit'
+          Another user has applied the `cvs edit' command (described
+          below) to a file.
 
-   If the edit script exits with a non-zero exit status, the commit is
-aborted.
+    `unedit'
+          Another user has applied the `cvs unedit' command (described
+          below) or the `cvs release' command to a file, or has deleted
+          the file and allowed `cvs update' to recreate it.
 
-   Note: when CVS is accessing a remote repository, `editinfo' will be
-run on the *remote* (i.e., server) side, not the client side (*note
-Remote repositories::.).
+    `commit'
+          Another user has committed changes to a file.
 
-* Menu:
+    `all'
+          All of the above.
 
-* editinfo example::            Editinfo example
+    `none'
+          None of the above.  (This is useful with `cvs edit',
+          described below.)
 
-
-File: cvs.info,  Node: editinfo example,  Up: editinfo
+     The `-a' option may appear more than once, or not at all.  If
+     omitted, the action defaults to `all'.
 
-Editinfo example
-----------------
+     The FILES and options are processed as for the `cvs watch'
+     commands.
 
-   The following is a little silly example of a `editinfo' file,
-together with the corresponding `rcsinfo' 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 `/usr/cvssupport/tc.template'.
 
-     BugId:
+ - Command: cvs watch remove [`-a' action] [`-lR'] files ...
+     Remove a notification request established using `cvs watch add';
+     the arguments are the same.  If the `-a' option is present, only
+     watches for the specified actions are removed.
 
-   The script `/usr/cvssupport/bugid.edit' is used to edit the log
-message.
 
-     #!/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
+   When the conditions exist for notification, CVS calls the `notify'
+administrative file.  Edit `notify' as one edits the other
+administrative files (*note Intro administrative files::).  This file
+follows the usual conventions for administrative files (*note
+syntax::), where each line is a regular expression followed by a
+command to execute.  The command should contain a single occurrence of
+`%s' 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 `notify' file is
+the single line:
 
-   The `editinfo' file contains this line:
+     ALL mail %s -s "CVS notification"
 
-     ^tc     /usr/cvssupport/bugid.edit
+   This causes users to be notified by electronic mail.
 
-   The `rcsinfo' file contains this line:
+   Note that if you set this up in the straightforward way, users
+receive notifications on the server machine.  One could of course write
+a `notify' script which directed notifications elsewhere, but to make
+this easy, CVS allows you to associate a notification address for each
+user.  To do so create a file `users' in `CVSROOT' with a line for each
+user in the format USER:VALUE.  Then instead of passing the name of the
+user to be notified to `notify', CVS will pass the VALUE (normally an
+email address on some other machine).
 
-     ^tc     /usr/cvssupport/tc.template
+   CVS 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.
 
 
-File: cvs.info,  Node: loginfo,  Next: rcsinfo,  Prev: editinfo,  Up: Administrative files
+File: cvs.info,  Node: Editing files,  Next: Watch information,  Prev: Getting Notified,  Up: Watches
+
+How to edit a file which is being watched
+-----------------------------------------
+
+   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 `cvs edit' command.  Some systems
+call this a "checkout", but CVS uses that term for obtaining a copy of
+the sources (*note Getting the source::), an operation which those
+systems call a "get" or a "fetch".
+
+ - Command: cvs edit [options] files ...
+     Prepare to edit the working files FILES.  CVS makes the FILES
+     read-write, and notifies users who have requested `edit'
+     notification for any of FILES.
+
+     The `cvs edit' command accepts the same OPTIONS as the `cvs watch
+     add' command, and establishes a temporary watch for the user on
+     FILES; CVS will remove the watch when FILES are `unedit'ed or
+     `commit'ted.  If the user does not wish to receive notifications,
+     she should specify `-a none'.
+
+     The FILES and options are processed as for the `cvs watch'
+     commands.
+
+
+   Normally when you are done with a set of changes, you use the `cvs
+commit' 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 `cvs
+unedit' command.
+
+ - Command: cvs unedit [`-lR'] files ...
+     Abandon work on the working files FILES, and revert them to the
+     repository versions on which they are based.  CVS makes those
+     FILES read-only for which users have requested notification using
+     `cvs watch on'.  CVS notifies users who have requested `unedit'
+     notification for any of FILES.
+
+     The FILES and options are processed as for the `cvs watch'
+     commands.
+
+     If watches are not in use, the `unedit' command probably does not
+     work, and the way to revert to the repository version is to remove
+     the file and then use `cvs update' to get a new copy.  The meaning
+     is not precisely the same; removing and updating may also bring in
+     some changes which have been made in the repository since the last
+     time you updated.
+
+   When using client/server CVS, you can use the `cvs edit' and `cvs
+unedit' commands even if CVS is unable to successfully communicate with
+the server; the notifications will be sent upon the next successful CVS
+command.
 
-Loginfo
-=======
-
-   The `loginfo' file is used to control where `cvs commit' 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 `$CVSROOT'.  If a match is found, then the remainder of
-the line is a filter program that should expect log information on its
-standard input.
-
-   The filter program may use one and only one % modifier (a la
-printf).  If `%s' is specified in the filter program, a brief title is
-included (enclosed in single quotes) showing the modified file names.
+
+File: cvs.info,  Node: Watch information,  Next: Watches Compatibility,  Prev: Editing files,  Up: Watches
 
-   If the repository name does not match any of the regular expressions
-in this file, the `DEFAULT' line is used, if it is specified.
+Information about who is watching and editing
+---------------------------------------------
 
-   All occurances of the name `ALL' appearing as a regular expression
-are used in addition to the first matching regular expression or
-`DEFAULT'.
+ - Command: cvs watchers [`-lR'] files ...
+     List the users currently watching changes to FILES.  The report
+     includes the files being watched, and the mail address of each
+     watcher.
 
-   The first matching regular expression is used.
+     The FILES and options are processed as for the `cvs watch'
+     commands.
 
-   *Note commit files::, for a description of the syntax of the
-`loginfo' file.
 
-   Note: when CVS is accessing a remote repository, `loginfo' will be
-run on the *remote* (i.e., server) side, not the client side (*note
-Remote repositories::.).
+ - Command: cvs editors [`-lR'] files ...
+     List the users currently working on FILES.  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.
 
-* Menu:
+     The FILES and options are processed as for the `cvs watch'
+     commands.
 
-* loginfo example::             Loginfo example
 
 
-File: cvs.info,  Node: loginfo example,  Up: loginfo
+File: cvs.info,  Node: Watches Compatibility,  Prev: Watch information,  Up: Watches
 
-Loginfo example
----------------
+Using watches with old versions of CVS
+--------------------------------------
 
-   The following `loginfo' file, together with the tiny shell-script
-below, appends all log messages to the file
-`$CVSROOT/CVSROOT/commitlog', and any commits to the administrative
-files (inside the `CVSROOT' directory) are also logged in
-`/usr/adm/cvsroot-log' and mailed to ceder.
+   If you use the watch features on a repository, it creates `CVS'
+directories in the repository and stores the information about watches
+in that directory.  If you attempt to use CVS 1.6 or earlier with the
+repository, you get an error message such as the following (all on one
+line):
 
-     ALL             /usr/local/bin/cvs-log $CVSROOT/CVSROOT/commitlog
-     ^CVSROOT        Mail -s %s ceder
-     ^CVSROOT        /usr/local/bin/cvs-log /usr/adm/cvsroot-log
+     cvs update: cannot open CVS/Entries for reading:
+     No such file or directory
 
-   The shell-script `/usr/local/bin/cvs-log' looks like this:
-
-     #!/bin/sh
-     (echo "-----------------------------------------------------------------";
-      echo -n $USER"  ";
-      date;
-      echo;
-      sed '1s+'${CVSROOT}'++') >> $1
+   and your operation will likely be aborted.  To use the watch
+features, you must upgrade all copies of CVS which use that repository
+in local or server mode.  If you cannot upgrade, use the `watch off' and
+`watch remove' commands to remove all watches, and that will restore
+the repository to a state which CVS 1.6 can cope with.
 
 
-File: cvs.info,  Node: rcsinfo,  Next: cvsignore,  Prev: loginfo,  Up: Administrative files
+File: cvs.info,  Node: Choosing a model,  Prev: Watches,  Up: Multiple developers
+
+Choosing between reserved or unreserved checkouts
+=================================================
+
+   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.  CVS does not try to enforce a certain organization.  It is
+a tool that can be used in several ways.
+
+   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.
+
+   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.
+
+   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 _any_ source management regimen, developers must
+agree on the general design of the system; given this agreement,
+overlapping changes are usually straightforward to merge.
+
+   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.
+
+   The watches features described above in *Note Watches:: 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.
 
-Rcsinfo
-=======
-
-   The `rcsinfo' file can be used to specify a form to edit when
-filling out the commit log.  The `rcsinfo' file has a syntax similar to
-the `editinfo', `commitinfo' and `loginfo' files.  *Note syntax::.
-Unlike the other files the second part is *not* a command-line
-template.  Instead, the part after the regular expression should be a
-full pathname to a file containing the log message template.
+
+File: cvs.info,  Node: Revision management,  Next: Keyword substitution,  Prev: Multiple developers,  Up: Top
 
-   If the repository name does not match any of the regular expressions
-in this file, the `DEFAULT' line is used, if it is specified.
+Revision management
+*******************
 
-   All occurances of the name `ALL' appearing as a regular expression
-are used in addition to the first matching regular expression or
-`DEFAULT'.
+   If you have read this far, you probably have a pretty good grasp on
+what CVS can do for you.  This chapter talks a little about things that
+you still have to decide.
 
-   The log message template will be used as a default log message.  If
-you specify a log message with `cvs commit -m MESSAGE' or `cvs commit -f
-FILE' that log message will override the template.
+   If you are doing development on your own using CVS 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.
 
-   *Note editinfo example::, for an example `rcsinfo' file.
+* Menu:
 
-   Note: when CVS is accessing a remote repository, `rcsinfo' will be
-run on the *remote* (i.e., server) side, not the client side (*note
-Remote repositories::.).
+* When to commit::              Some discussion on the subject
 
 
-File: cvs.info,  Node: cvsignore,  Next: history file,  Prev: rcsinfo,  Up: Administrative files
-
-Ignoring files via cvsignore
-============================
-
-   There are certain file names that frequently occur inside your
-working copy, but that you don't want to put under CVS control.
-Examples are all the object files that you get while you compile your
-sources.  Normally, when you run `cvs update', it prints a line for
-each file it encounters that it doesn't know about (*note update
-output::.).
+File: cvs.info,  Node: When to commit,  Up: Revision management
+
+When to commit?
+===============
+
+   Your group should decide which policy to use regarding commits.
+Several policies are possible, and as your experience with CVS grows
+you will probably find out what works for you.
+
+   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.
+
+   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 (*note
+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.
 
-   CVS has a list of files (or sh(1) file name patterns) that it should
-ignore while running `update', `import' and `release'.  This list is
-constructed in the following way.
-
-   * The list is initialized to the following file name patterns:
-
-              RCSLOG  RCS     SCCS
-              CVS*    cvslog.*
-              tags    TAGS
-              .make.state     .nse_depinfo
-              *~      #*      .#*     ,*
-              *.old   *.bak   *.BAK   *.orig  *.rej   .del-*
-              *.a     *.o     *.so    *.Z     *.elc   *.ln
-              core
-
-   * The per-repository list in `$CVSROOT/CVSROOT/cvsignore' is
-     appended to the list, if that file exists.
+
+File: cvs.info,  Node: Keyword substitution,  Next: Tracking sources,  Prev: Revision management,  Up: Top
 
-   * The per-user list in `.cvsignore' in your home directory is
-     appended to the list, if it exists.
+Keyword substitution
+********************
 
-   * Any entries in the environment variable `$CVSIGNORE' is appended
-     to the list.
+   As long as you edit source files inside a working directory you can
+always find out the state of your files via `cvs status' and `cvs log'.
+But as soon as you export the files from your development environment
+it becomes harder to identify which revisions they are.
 
-   * Any `-I' options given to CVS is appended.
+   CVS can use a mechanism known as "keyword substitution" (or "keyword
+expansion") to help identifying the files.  Embedded strings of the form
+`$KEYWORD$' and `$KEYWORD:...$' in a file are replaced with strings of
+the form `$KEYWORD:VALUE$' whenever you obtain a new revision of the
+file.
 
-   * As CVS traverses through your directories, the contents of any
-     `.cvsignore' will be appended to the list.  The patterns found in
-     `.cvsignore' are only valid for the directory that contains them,
-     not for any sub-directories.
+* Menu:
 
-   In any of the 5 places listed above, a single exclamation mark (`!')
-clears the ignore list.  This can be used if you want to store any file
-which normally is ignored by CVS.
+* Keyword list::                Keywords
+* Using keywords::              Using keywords
+* Avoiding substitution::       Avoiding substitution
+* Substitution modes::          Substitution modes
+* Log keyword::                 Problems with the $Log: cvs.info-4,v $
+* Log keyword::                 Problems with the Revision 1.2  2001/09/29 00:00:39  tholo
+* Log keyword::                 Problems with the Merge remaining local changes, correct build issues
+* Log keyword::                 Problems with the keyword.
 
 
-File: cvs.info,  Node: history file,  Next: Setting up,  Prev: cvsignore,  Up: Administrative files
-
-The history file
-================
-
-   The file `$CVSROOT/CVSROOT/history' is used to log information for
-the `history' command (*note history::.).  This file must be created to
-turn on logging.  This is done automatically if the `cvsinit' script is
-used to set up the repository.
-
-   The file format of the `history' file is unfortunately not yet
-documented anywhere, but it is fairly easy to understand most of it.
+File: cvs.info,  Node: Keyword list,  Next: Using keywords,  Up: Keyword substitution
+
+Keyword List
+============
+
+   This is a list of the keywords:
+
+`$Author: tholo $'
+     The login name of the user who checked in the revision.
+
+`$Date: 2001/09/29 00:00:39 $'
+     The date and time (UTC) the revision was checked in.
+
+`$Header: /cvs/OpenBSD/src/gnu/usr.bin/cvs/doc/cvs.info-4,v 1.2 2001/09/29 00:00:39 tholo Exp $'
+     A standard header containing the full pathname of the RCS 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 CVS.
+
+`$Id: cvs.info-4,v 1.2 2001/09/29 00:00:39 tholo Exp $'
+     Same as `$Header: /cvs/OpenBSD/src/gnu/usr.bin/cvs/doc/cvs.info-4,v 1.2 2001/09/29 00:00:39 tholo Exp $', except that the RCS filename is without a path.
+
+`$Name:  $'
+     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 `cvs co -r first', the keyword expands to
+     `Name: first'.
+
+`$Locker:  $'
+     The login name of the user who locked the revision (empty if not
+     locked, which is the normal case unless `cvs admin -l' is in use).
+
+`$Log: cvs.info-4,v $
+`Revision 1.2  2001/09/29 00:00:39  tholo
+`Merge remaining local changes, correct build issues
+`'
+     The log message supplied during commit, preceded by a header
+     containing the RCS filename, the revision number, the author, and
+     the date (UTC).  Existing log messages are _not_ replaced.
+     Instead, the new log message is inserted after `$Log: cvs.info-4,v $
+     Instead, the new log message is inserted after `Revision 1.2  2001/09/29 00:00:39  tholo
+     Instead, the new log message is inserted after `Merge remaining local changes, correct build issues
+     Instead, the new log message is inserted after `'.  Each
+     new line is prefixed with the same string which precedes the
+     `$Log' keyword.  For example, if the file contains
+
+            /* Here is what people have been up to:
+             *
+             * $Log: cvs.info-4,v $
+             * Revision 1.2  2001/09/29 00:00:39  tholo
+             * Merge remaining local changes, correct build issues
+             *
+             * Revision 1.1  1997/01/03 14:23:51  joe
+             * Add the superfrobnicate option
+             *
+             */
+
+     then additional lines which are added when expanding the `$Log'
+     keyword will be preceded by `   * '.  Unlike previous versions of
+     CVS and RCS, the "comment leader" from the RCS file is not used.
+     The `$Log' keyword is useful for accumulating a complete change
+     log in a source file, but for several reasons it can be
+     problematic.  *Note Log keyword::.
+
+`$RCSfile: cvs.info-4,v $'
+     The name of the RCS file without a path.
+
+`$Revision: 1.2 $'
+     The revision number assigned to the revision.
+
+`$Source: /cvs/OpenBSD/src/gnu/usr.bin/cvs/doc/cvs.info-4,v $'
+     The full pathname of the RCS file.
+
+`$State: Exp $'
+     The state assigned to the revision.  States can be assigned with
+     `cvs admin -s'--see *Note admin options::.
 
 
-File: cvs.info,  Node: Setting up,  Prev: history file,  Up: Administrative files
-
-Setting up the repository
-=========================
-
-   When you install CVS for the first time, you should follow the
-instructions in the `INSTALL' file to set up the repository.
-
-   If you want to set up another repository, the easiest way to get a
-reasonable set of working administrative files is to run the `cvsinit'
-shell script.  It will set up an empty repository in the directory
-defined by the environment variable `$CVSROOT'.  (`cvsinit' is careful
-to never overwrite any existing files in the repository, so no harm is
-done if you run `cvsinit' on an already set-up repository.  In fact,
-running it on an already set-up repository is the best way to update
-the various scripts from the `contrib' directory.)
+File: cvs.info,  Node: Using keywords,  Next: Avoiding substitution,  Prev: Keyword list,  Up: Keyword substitution
+
+Using keywords
+==============
+
+   To include a keyword string you simply include the relevant text
+string, such as `$Id: cvs.info-4,v 1.2 2001/09/29 00:00:39 tholo Exp $', inside the file, and commit the file.  CVS will
+automatically expand the string as part of the commit operation.
+
+   It is common to embed the `$Id: cvs.info-4,v 1.2 2001/09/29 00:00:39 tholo Exp $' 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 `#pragma ident' directive.  Or a document management system
+might provide a way to pass a string through to generated files.
+
+   The `ident' command (which is part of the RCS 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.
+
+     $ ident samp.c
+     samp.c:
+          $Id: cvs.info-4,v 1.2 2001/09/29 00:00:39 tholo Exp $
+     $ gcc samp.c
+     $ ident a.out
+     a.out:
+          $Id: cvs.info-4,v 1.2 2001/09/29 00:00:39 tholo Exp $
+
+   SCCS is another popular revision control system.  It has a command,
+`what', which is very similar to `ident' and used for the same purpose.
+Many sites without RCS have SCCS.  Since `what' looks for the
+character sequence `@(#)' it is easy to include keywords that are
+detected by either command.  Simply prefix the keyword with the magic
+SCCS phrase, like this:
+
+     static char *id="@(#) $Id: cvs.info-4,v 1.2 2001/09/29 00:00:39 tholo Exp $";
 
 
-File: cvs.info,  Node: Environment variables,  Next: Troubleshooting,  Prev: Administrative files,  Up: Top
-
-All environment variables which affect CVS
-******************************************
-
-   This is a complete list of all environment variables that affect CVS.
-
-`$CVSIGNORE'
-     A whitespace-separated list of file name patterns that CVS should
-     ignore. *Note cvsignore::.
-
-`$CVSWRAPPERS'
-     A whitespace-separated list of file name patterns that CVS should
-     treat as wrappers. *Note Wrappers::.
-
-`$CVSREAD'
-     If this is set, `checkout' and `update' will try hard to make the
-     files in your working directory read-only.  When this is not set,
-     the default behavior is to permit modification of your working
-     files.
-
-`$CVSROOT'
-     Should contain the full pathname to the root of the CVS source
-     repository (where the RCS history files are kept).  This
-     information must be available to CVS for most commands to execute;
-     if `$CVSROOT' is not set, or if you wish to override it for one
-     invocation, you can supply it on the command line: `cvs -d cvsroot
-     cvs_command...' You may not need to set `$CVSROOT' if your CVS
-     binary has the right path compiled in.
-
-`$EDITOR'
-`$CVSEDITOR'
-     Specifies the program to use for recording log messages during
-     commit.  If not set, the default is `/usr/ucb/vi'.  `$CVSEDITOR'
-     overrides `$EDITOR'.  `$CVSEDITOR' does not exist in CVS 1.3, but
-     the next release will probably include it.
-
-`$PATH'
-     If `$RCSBIN' is not set, and no path is compiled into CVS, it will
-     use `$PATH' to try to find all programs it uses.
-
-`$RCSBIN'
-     Specifies the full pathname of the location of RCS programs, such
-     as co(1) and ci(1).  If not set, a compiled-in value is used, or
-     your `$PATH' is searched.
-
-   CVS is a front-end to RCS.  The following environment variables
-affect RCS:
-
-`$LOGNAME'
-`$USER'
-     If set, they affect who RCS thinks you are.  If you have trouble
-     checking in files it might be because your login name differs from
-     the setting of e.g.  `$LOGNAME'.
-
-`$RCSINIT'
-     Options prepended to the argument list, separated by spaces.  A
-     backslash escapes spaces within an option.  The `$RCSINIT' options
-     are prepended to the argument lists of most RCS commands.
-
-`$TMPDIR'
-`$TMP'
-`$TEMP'
-     Name of the temporary directory.  The environment variables are
-     inspected in the order they appear above and the first value found
-     is taken; if none of them are set, a host-dependent default is
-     used, typically `/tmp'.
+File: cvs.info,  Node: Avoiding substitution,  Next: Substitution modes,  Prev: Using keywords,  Up: Keyword substitution
 
-
-File: cvs.info,  Node: Troubleshooting,  Next: Copying,  Prev: Environment variables,  Up: Top
+Avoiding substitution
+=====================
 
-Troubleshooting
-***************
+   Keyword substitution has its disadvantages.  Sometimes you might
+want the literal text string `$Author: tholo $' to appear inside a file without
+CVS interpreting it as a keyword and expanding it into something like
+`$Author: tholo $'.
 
-* Menu:
+   There is unfortunately no way to selectively turn off keyword
+substitution.  You can use `-ko' (*note Substitution modes::) to turn
+off keyword substitution entirely.
 
-* Magic branch numbers::        Magic branch numbers
+   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 `$@asis{}Author$' whenever the text `$Author: tholo $'
+should appear.  In `nroff' and `troff' you can embed the null-character
+`\&' inside the keyword for a similar effect.
 
 
-File: cvs.info,  Node: Magic branch numbers,  Up: Troubleshooting
+File: cvs.info,  Node: Substitution modes,  Next: Log keyword,  Prev: Avoiding substitution,  Up: Keyword substitution
+
+Substitution modes
+==================
+
+   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 `-k' option to `cvs add' and `cvs admin'; the latter is set
+by the `-k' or `-A' options to `cvs checkout' or `cvs update'.  `cvs
+diff' also has a `-k' option.  For some examples, see *Note Binary
+files::, and *Note Merging and keywords::.
+
+   The modes available are:
+
+`-kkv'
+     Generate keyword strings using the default form, e.g.  `$Revision:
+     5.7 $' for the `Revision' keyword.
+
+`-kkvl'
+     Like `-kkv', except that a locker's name is always inserted if the
+     given revision is currently locked.  The locker's name is only
+     relevant if `cvs admin -l' is in use.
+
+`-kk'
+     Generate only keyword names in keyword strings; omit their values.
+     For example, for the `Revision' keyword, generate the string
+     `$Revision: 1.2 $' instead of `$Revision: 1.2 $'.  This option is useful
+     to ignore differences due to keyword substitution when comparing
+     different revisions of a file (*note Merging and keywords::).
+
+`-ko'
+     Generate the old keyword string, present in the working file just
+     before it was checked in.  For example, for the `Revision'
+     keyword, generate the string `$Revision: 1.2 $' instead of
+     `$Revision: 1.2 $' if that is how the string appeared when the
+     file was checked in.
+
+`-kb'
+     Like `-ko', 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 the same as `-ko'.  For more
+     information on binary files, see *Note Binary files::.
+
+`-kv'
+     Generate only keyword values for keyword strings.  For example,
+     for the `Revision' keyword, generate the string `5.7' instead of
+     `$Revision: 1.2 $'.  This can help generate files in programming
+     languages where it is hard to strip keyword delimiters like
+     `$Revision: 1.2 $' from a string.  However, further keyword
+     substitution cannot be performed once the keyword names are
+     removed, so this option should be used with care.
+
+     One often would like to use `-kv' with `cvs export'--*note
+     export::.  But be aware that doesn't handle an export containing
+     binary files correctly.
 
-Magic branch numbers
-====================
-
-   Externally, branch numbers consist of an odd number of dot-separated
-decimal integers.  *Note Revision numbers::.  That is not the whole
-truth, however.  For efficiency reasons CVS sometimes inserts an extra 0
-in the second rightmost position (1.2.3 becomes 1.2.0.3, 8.9.10.11.12
-becomes 8.9.10.11.0.12 and so on).
-
-   CVS does a pretty good job at hiding these so called magic branches,
-but in at least four places the hiding is incomplete.
-
-   * The magic branch can appear in the output from `cvs status' in
-     vanilla CVS 1.3.  This is fixed in CVS 1.3-s2.
+
+File: cvs.info,  Node: Log keyword,  Prev: Substitution modes,  Up: Keyword substitution
+
+Problems with the $Log: cvs.info-4,v $
+Problems with the Revision 1.2  2001/09/29 00:00:39  tholo
+Problems with the Merge remaining local changes, correct build issues
+Problems with the keyword.
+================================
+
+   The `$Log: cvs.info-4,v $
+   The `Revision 1.2  2001/09/29 00:00:39  tholo
+   The `Merge remaining local changes, correct build issues
+   The `' 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 `$Log: cvs.info-4,v $
+even if you do not use the `Revision 1.2  2001/09/29 00:00:39  tholo
+even if you do not use the `Merge remaining local changes, correct build issues
+even if you do not use the `' keyword--just do a `cvs log'.  Once
+you export the file the history information might be useless anyhow.
+
+   A more serious concern is that CVS is not good at handling `$Log: cvs.info-4,v $
+   A more serious concern is that CVS is not good at handling `Revision 1.2  2001/09/29 00:00:39  tholo
+   A more serious concern is that CVS is not good at handling `Merge remaining local changes, correct build issues
+   A more serious concern is that CVS is not good at handling `'
+entries when a branch is merged onto the main trunk.  Conflicts often
+result from the merging operation.
+
+   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 `cvs log' will not be consistent with the information
+inside the file.  This may or may not be a problem in real life.
+
+   It has been suggested that the `$Log: cvs.info-4,v $
+   It has been suggested that the `Revision 1.2  2001/09/29 00:00:39  tholo
+   It has been suggested that the `Merge remaining local changes, correct build issues
+   It has been suggested that the `' keyword should be inserted
+_last_ 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.
 
-   * The magic branch number appears in the output from `cvs log'.
-     This is much harder to fix, since `cvs log' runs `rlog' (which is
-     part of the RCS distribution), and modifying `rlog' to know about
-     magic branches would probably break someone's habits (if they use
-     branch 0 for their own purposes).
+
+File: cvs.info,  Node: Tracking sources,  Next: Builds,  Prev: Keyword substitution,  Up: Top
 
-   * You cannot specify a symbolic branch name to `cvs log'.
+Tracking third-party sources
+****************************
 
-   * You cannot specify a symbolic branch name to `cvs admin'.
+   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.  CVS can help you with this task.
 
-   You can use the `admin' command to reassign a symbolic name to a
-branch the way RCS expects it to be.  If `R4patches' is assigned to the
-branch 1.4.2 (magic branch number 1.4.0.2) in file `numbers.c' you can
-do this:
+   In the terminology used in CVS, the supplier of the program is
+called a "vendor".  The unmodified distribution from the vendor is
+checked in on its own branch, the "vendor branch".  CVS reserves branch
+1.1.1 for this use.
 
-     $ cvs admin -NR4patches:1.4.2 numbers.c
+   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.
 
-   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).
+   Use the `import' 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.
 
-
-File: cvs.info,  Node: Copying,  Next: Index,  Prev: Troubleshooting,  Up: Top
+* Menu:
 
-GNU GENERAL PUBLIC LICENSE
-**************************
+* First import::                Importing for the first time
+* Update imports::              Updating with the import command
+* Reverting local changes::     Reverting to the latest vendor release
+* Binary files in imports::     Binary files require special handling
+* Keywords in imports::         Keyword substitution might be undesirable
+* Multiple vendor branches::    What if you get sources from several places?
 
diff --git a/gnu/usr.bin/cvs/doc/cvs.info-5 b/gnu/usr.bin/cvs/doc/cvs.info-5
index f07f839f52b..371dd4ce8e8 100644
--- a/gnu/usr.bin/cvs/doc/cvs.info-5
+++ b/gnu/usr.bin/cvs/doc/cvs.info-5
@@ -1,5 +1,8 @@
-This is Info file cvs.info, produced by Makeinfo-1.55 from the input
-file ./cvs.texinfo.
+This is cvs.info, produced by makeinfo version 4.0 from cvs.texinfo.
+
+START-INFO-DIR-ENTRY
+* CVS: (cvs).          Concurrent Versions System
+END-INFO-DIR-ENTRY
 
    Copyright (C) 1992, 1993 Signum Support AB Copyright (C) 1993, 1994
 Free Software Foundation, Inc.
@@ -10,375 +13,1180 @@ preserved on all copies.
 
    Permission is granted to copy and distribute modified versions of
 this manual under the conditions for verbatim copying, provided also
-that the section entitled "GNU General Public License" is included
-exactly as in the original, and provided that the entire resulting
-derived work is distributed under the terms of a permission notice
-identical to this one.
+that the entire resulting derived work is distributed under the terms
+of a permission notice identical to this one.
 
    Permission is granted to copy and distribute translations of this
 manual into another language, under the above conditions for modified
-versions, except that the section entitled "GNU General Public License"
-and this permission notice may be included in translations approved by
-the Free Software Foundation instead of in the original English.
+versions, except that this permission notice may be stated in a
+translation approved by the Free Software Foundation.
+
+
+File: cvs.info,  Node: First import,  Next: Update imports,  Up: Tracking sources
+
+Importing for the first time
+============================
+
+   Use the `import' command to check in the sources for the first time.
+When you use the `import' command to track third-party sources, the
+"vendor tag" and "release tags" are useful.  The "vendor tag" is a
+symbolic name for the branch (which is always 1.1.1, unless you use the
+`-b BRANCH' flag--see *Note Multiple vendor branches::.).  The "release
+tags" are symbolic names for a particular release, such as `FSF_0_04'.
+
+   Note that `import' does _not_ change the directory in which you
+invoke it.  In particular, it does not set up that directory as a CVS
+working directory; if you want to work with the sources import them
+first and then check them out into a different directory (*note Getting
+the source::).
+
+   Suppose you have the sources to a program called `wdiff' in a
+directory `wdiff-0.04', 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:
+
+     $ cd wdiff-0.04
+     $ cvs import -m "Import of FSF v. 0.04" fsf/wdiff FSF_DIST WDIFF_0_04
+
+   The vendor tag is named `FSF_DIST' in the above example, and the
+only release tag assigned is `WDIFF_0_04'.
+
+
+File: cvs.info,  Node: Update imports,  Next: Reverting local changes,  Prev: First import,  Up: Tracking sources
+
+Updating with the import command
+================================
+
+   When a new release of the source arrives, you import it into the
+repository with the same `import' 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.
+
+     $ 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
+
+   For files that have not been modified locally, the newly created
+revision becomes the head revision.  If you have made local changes,
+`import' will warn you that you must merge the changes into the main
+trunk, and tell you to use `checkout -j' to do so.
+
+     $ cvs checkout -jFSF_DIST:yesterday -jFSF_DIST wdiff
+
+The above command will check out the latest revision of `wdiff',
+merging the changes made on the vendor branch `FSF_DIST' since
+yesterday into the working copy.  If any conflicts arise during the
+merge they should be resolved in the normal way (*note Conflicts
+example::).  Then, the modified files may be committed.
+
+   Using a date, as suggested above, assumes that you do not import
+more than one release of a product per day. If you do, you can always
+use something like this instead:
+
+     $ cvs checkout -jWDIFF_0_04 -jWDIFF_0_05 wdiff
+
+In this case, the two above commands are equivalent.
+
+
+File: cvs.info,  Node: Reverting local changes,  Next: Binary files in imports,  Prev: Update imports,  Up: Tracking sources
+
+Reverting to the latest vendor release
+======================================
+
+   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 `~/work.d/wdiff', and you want to revert to the
+vendor's version for all the files in that directory, you would type:
+
+     $ cd ~/work.d/wdiff
+     $ cvs admin -bWDIFF .
+
+You must specify the `-bWDIFF' without any space after the `-b'.  *Note
+admin options::.
+
+
+File: cvs.info,  Node: Binary files in imports,  Next: Keywords in imports,  Prev: Reverting local changes,  Up: Tracking sources
+
+How to handle binary files with cvs import
+==========================================
+
+   Use the `-k' wrapper option to tell import which files are binary.
+*Note Wrappers::.
+
+
+File: cvs.info,  Node: Keywords in imports,  Next: Multiple vendor branches,  Prev: Binary files in imports,  Up: Tracking sources
+
+How to handle keyword substitution with cvs import
+==================================================
+
+   The sources which you are importing may contain keywords (*note
+Keyword substitution::).  For example, the vendor may use CVS 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 CVS.  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.
+
+   To maintain the keyword expansions supplied by the vendor, supply
+the `-ko' option to `cvs import' 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 `-k' option to `cvs update' or `cvs admin' as appropriate.
+
+
+File: cvs.info,  Node: Multiple vendor branches,  Prev: Keywords in imports,  Up: Tracking sources
+
+Multiple vendor branches
+========================
+
+   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
+CVS so that you at least have them in one place.
+
+   For handling situations in which there may be more than one vendor,
+you may specify the `-b' option to `cvs import'.  It takes as an
+argument the vendor branch to import to.  The default is `-b 1.1.1'.
+
+   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:
+
+     $ cvs import dir RED RED_1-0
+     $ cvs import -b 1.1.3 dir BLUE BLUE_1-5
+
+   Note that if your vendor tag does not match your `-b' option, CVS
+will not detect this case!  For example,
+
+     $ cvs import -b 1.1.3 dir RED RED_1-0
+
+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.  CVS is likely to make this
+an error in some future release.
+
+
+File: cvs.info,  Node: Builds,  Next: Special Files,  Prev: Tracking sources,  Up: Top
+
+How your build system interacts with CVS
+****************************************
+
+   As mentioned in the introduction, CVS does not contain software for
+building your software from source code.  This section describes how
+various aspects of your build system might interact with CVS.
+
+   One common question, especially from people who are accustomed to
+RCS, is how to make their build get an up to date copy of the sources.
+The answer to this with CVS is two-fold.  First of all, since CVS
+itself can recurse through directories, there is no need to modify your
+`Makefile' (or whatever configuration file your build tool uses) to
+make sure each file is up to date.  Instead, just use two commands,
+first `cvs -q update' and then `make' or whatever the command is to
+invoke your build tool.  Secondly, you do not necessarily _want_ 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.
+
+   One common need is to record which versions of which source files
+went into a particular build.  This kind of functionality is sometimes
+called "bill of materials" or something similar.  The best way to do
+this with CVS is to use the `tag' command to record which versions went
+into a given build (*note Tags::).
+
+   Using CVS 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 are they are actively working on.
+
+   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 `VPATH' feature found in many
+versions of `make'.  One build tool which is designed to help with this
+kind of thing is Odin (see
+`ftp://ftp.cs.colorado.edu/pub/distribs/odin').
 
 
-File: cvs.info,  Node: Index,  Prev: Copying,  Up: Top
+File: cvs.info,  Node: Special Files,  Next: CVS commands,  Prev: Builds,  Up: Top
+
+Special Files
+*************
 
-Index
-*****
+   In normal circumstances, CVS 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.  CVS 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, CVS will refuse to handle it.  Files also lose their ownerships
+and permissions during repository transactions.
+
+
+File: cvs.info,  Node: CVS commands,  Next: Invoking CVS,  Prev: Special Files,  Up: Top
 
-   If you cannot find what you are looking for here write to
-<ceder@signum.se> so that an entry can be added to the next release of
-this manual.
+Guide to CVS commands
+*********************
+
+   This appendix describes the overall structure of CVS commands, and
+describes some commands in detail (others are described elsewhere; for
+a quick reference to CVS commands, *note Invoking CVS::).
 
 * Menu:
 
-* -j (merging branches):                Merging a branch.
-* -k (RCS kflags):                      Substitution modes.
-* .bashrc:                              Repository.
-* .cshrc:                               Repository.
-* .cvsrc file:                          ~/.cvsrc.
-* .profile:                             Repository.
-* .tcshrc:                              Repository.
-* /usr/local/cvsroot:                   Repository.
-* <<<<<<<:                              Conflicts example.
-* =======:                              Conflicts example.
-* >>>>>>>:                              Conflicts example.
-* A sample session:                     A sample session.
-* About this manual:                    Preface.
-* Add (subcommand):                     add.
-* Add options:                          add options.
-* Adding a tag:                         Tags.
-* Adding files:                         Adding files.
-* Admin (subcommand):                   admin.
-* Administrative files (intro):         Intro administrative files.
-* Administrative files (reference):     Administrative files.
-* Administrative files, editing them:   Intro administrative files.
-* ALL in commitinfo:                    commitinfo.
-* Author keyword:                       Keyword list.
-* Automatically ignored files:          cvsignore.
-* Avoiding editor invocation:           Common options.
-* Binary files (inhibit keyword expansion): admin examples.
-* Branch merge example:                 Merging a branch.
-* Branch number:                        Revision numbers.
-* Branch numbers:                       Creating a branch.
-* Branch, creating a:                   Creating a branch.
-* Branch, vendor-:                      Tracking sources.
-* Branches:                             Branches.
-* Branches motivation:                  Branches motivation.
-* Branches, copying changes between:    Merging.
-* Branches, sticky:                     Sticky tags.
-* Bringing a file up to date:           Updating a file.
-* Bugs, known in this manual:           BUGS.
-* Bugs, reporting (manual):             BUGS.
-* Changes, copying between branches:    Merging.
-* Changing a log message:               admin options.
-* Checkin program:                      modules.
-* Checking commits:                     commitinfo.
-* Checking out source:                  Getting the source.
-* Checkout (subcommand):                checkout.
-* Checkout program:                     modules.
-* Checkout, example:                    Getting the source.
-* Cleaning up:                          Cleaning up.
-* Client/Server Operation:              Remote repositories.
-* Co (subcommand):                      checkout.
-* Command reference:                    Invoking CVS.
-* Command structure:                    Structure.
-* Comment leader:                       admin examples.
-* Commit (subcommand):                  commit.
-* Commit files:                         commit files.
-* Commit, when to:                      When to commit.
-* Commitinfo:                           commitinfo.
-* Committing changes:                   Committing your changes.
-* Common options:                       Common options.
-* Common syntax of info files:          syntax.
-* Conflict markers:                     Conflicts example.
-* Conflict resolution:                  Conflicts example.
-* Conflicts (merge example):            Conflicts example.
-* Contributors (CVS program):           What is CVS?.
-* Contributors (manual):                Credits.
-* Copying changes:                      Merging.
-* Correcting a log message:             admin options.
-* Creating a branch:                    Creating a branch.
-* Creating a project:                   Starting a new project.
-* Creating a repository:                Setting up.
-* Credits (CVS program):                What is CVS?.
-* Credits (manual):                     Credits.
-* CVS command structure:                Structure.
-* CVS FAQ:                              What is CVS?.
-* CVS FTP site:                         What is CVS?.
-* CVS, history of:                      What is CVS?.
-* CVS, introduction to:                 What is CVS?.
-* CVSEDITOR:                            Environment variables.
-* CVSEDITOR, environment variable:      Committing your changes.
-* CVSIGNORE:                            Environment variables.
-* Cvsignore, global:                    cvsignore.
-* CVSREAD:                              Environment variables.
-* CVSREAD, overriding:                  Global options.
-* CVSROOT:                              Environment variables.
-* cvsroot:                              Repository.
-* CVSROOT (file):                       Administrative files.
-* CVSROOT, environment variable:        Repository.
-* CVSROOT, module name:                 Intro administrative files.
-* CVSROOT, multiple repositories:       Multiple repositories.
-* CVSROOT, overriding:                  Global options.
-* cvswrappers (admin file):             Wrappers.
-* CVSWRAPPERS, environment variable:    Wrappers.
-* Date keyword:                         Keyword list.
-* Dates:                                Common options.
-* Decimal revision number:              Revision numbers.
-* DEFAULT in commitinfo:                commitinfo.
-* DEFAULT in editinfo:                  editinfo.
-* Defining a module:                    Defining the module.
-* Defining modules (intro):             Intro administrative files.
-* Defining modules (reference manual):  modules.
-* Deleting files:                       Removing files.
-* Deleting revisions:                   admin options.
-* Deleting sticky tags:                 Sticky tags.
-* Descending directories:               Recursive behavior.
-* Diff:                                 Viewing differences.
-* Diff (subcommand):                    diff.
-* Differences, merging:                 Merging two revisions.
-* Directories, moving:                  Moving directories.
-* Directory, descending:                Recursive behavior.
-* Disjoint repositories:                Multiple repositories.
-* Distributing log messages:            loginfo.
-* driver.c (merge example):             Conflicts example.
-* Editinfo:                             editinfo.
-* Editing administrative files:         Intro administrative files.
-* Editing the modules file:             Defining the module.
-* EDITOR:                               Environment variables.
-* Editor, avoiding invocation of:       Common options.
-* EDITOR, environment variable:         Committing your changes.
-* EDITOR, overriding:                   Global options.
-* Editor, specifying per module:        editinfo.
-* emerge:                               Conflicts example.
-* Environment variables:                Environment variables.
-* Errors, reporting (manual):           BUGS.
-* Example of a work-session:            A sample session.
-* Example of merge:                     Conflicts example.
-* Example, branch merge:                Merging a branch.
-* Export (subcommand):                  export.
-* FAQ:                                  What is CVS?.
-* Fetching source:                      Getting the source.
-* File locking:                         Multiple developers.
-* File permissions:                     File permissions.
-* File status:                          File status.
-* Files, moving:                        Moving files.
-* Files, reference manual:              Administrative files.
-* Fixes to CVS:                         What is CVS?.
-* Fixing a log message:                 admin options.
-* Forcing a tag match:                  Common options.
-* Form for log message:                 rcsinfo.
-* Format of CVS commands:               Structure.
-* Four states of a file:                File status.
-* FTP site:                             What is CVS?.
-* Getting started:                      A sample session.
-* Getting the source:                   Getting the source.
-* Global cvsignore:                     cvsignore.
-* Global options:                       Global options.
-* Group:                                File permissions.
-* Header keyword:                       Keyword list.
-* History (subcommand):                 history.
-* History file:                         history file.
-* History files:                        User modules.
-* History of CVS:                       What is CVS?.
-* Id keyword:                           Keyword list.
-* Ident (shell command):                Using keywords.
-* Identifying files:                    Keyword substitution.
-* Ignored files:                        cvsignore.
-* Ignoring files:                       cvsignore.
-* Import (subcommand):                  import.
-* Importing files:                      From files.
-* Importing modules:                    First import.
-* Index:                                Index.
-* Info files (syntax):                  syntax.
-* Informing others:                     Informing others.
-* Inhibiting keyword expansion:         admin examples.
-* Introduction to CVS:                  What is CVS?.
-* Invoking CVS:                         Invoking CVS.
-* Join:                                 Merging a branch.
-* Keyword expansion:                    Keyword substitution.
-* Keyword expansion, inhibiting:        admin examples.
-* Keyword substitution:                 Keyword substitution.
-* Kflag:                                Substitution modes.
-* Known bugs in this manual:            BUGS.
-* Layout of repository:                 Repository.
-* Left-hand options:                    Global options.
-* Linear development:                   Revision numbers.
-* List, mailing list:                   What is CVS?.
-* Locally modified:                     File status.
-* Locker keyword:                       Keyword list.
-* Locking files:                        Multiple developers.
-* Log (subcommand):                     log.
-* Log information, saving:              history file.
-* Log keyword:                          Keyword list.
-* Log keyword, selecting comment leader: admin examples.
-* Log message entry:                    Committing your changes.
-* Log message template:                 rcsinfo.
-* Log message, correcting:              admin options.
-* Log messages:                         loginfo.
-* Log messages, editing:                editinfo.
-* Loginfo:                              loginfo.
-* LOGNAME:                              Environment variables.
-* Mail, automatic mail on commit:       Informing others.
-* Mailing list:                         What is CVS?.
-* Mailing log messages:                 loginfo.
-* Main trunk (intro):                   Revision numbers.
-* Main trunk and branches:              Branches.
-* Many repositories:                    Multiple repositories.
-* Markers, conflict:                    Conflicts example.
-* Merge, an example:                    Conflicts example.
-* Merge, branch example:                Merging a branch.
-* Merging:                              Merging.
-* Merging a branch:                     Merging a branch.
-* Merging a file:                       Updating a file.
-* Merging two revisions:                Merging two revisions.
-* mkmodules:                            Intro administrative files.
-* Modifications, copying between branches: Merging.
-* Module status:                        modules.
-* Module, defining:                     Defining the module.
-* Modules (admin file):                 modules.
-* Modules (intro):                      Basic concepts.
-* Modules file:                         Intro administrative files.
-* Modules file, changing:               Defining the module.
-* Motivation for branches:              Branches motivation.
-* Moving directories:                   Moving directories.
-* Moving files:                         Moving files.
-* Multiple developers:                  Multiple developers.
-* Multiple repositories:                Multiple repositories.
-* Name, symbolic (tag):                 Tags.
-* Needing merge:                        File status.
-* Needing update:                       File status.
-* Nroff (selecting comment leader):     admin examples.
-* Number, branch:                       Revision numbers.
-* Number, revision-:                    Revision numbers.
-* option defaults:                      ~/.cvsrc.
-* Options, global:                      Global options.
-* Outdating revisions:                  admin options.
-* Overlap:                              Updating a file.
-* Overriding CVSREAD:                   Global options.
-* Overriding CVSROOT:                   Global options.
-* Overriding EDITOR:                    Global options.
-* Overriding RCSBIN:                    Global options.
-* Parallel repositories:                Multiple repositories.
-* Patches to CVS:                       What is CVS?.
-* PATH:                                 Environment variables.
-* Per-module editor:                    editinfo.
-* Policy:                               When to commit.
-* Precommit checking:                   commitinfo.
-* Preface:                              Preface.
-* RCS history files:                    User modules.
-* RCS keywords:                         Keyword list.
-* RCS revision numbers:                 Tags.
-* RCS, CVS uses RCS:                    User modules.
-* RCSBIN:                               Environment variables.
-* RCSBIN, overriding:                   Global options.
-* RCSfile keyword:                      Keyword list.
-* Rcsinfo:                              rcsinfo.
-* RCSINIT:                              Environment variables.
-* Rdiff (subcommand):                   rdiff.
-* Read-only files:                      Global options.
-* Read-only mode:                       Global options.
-* Recursive (directory descending):     Recursive behavior.
-* Reference manual (files):             Administrative files.
-* Reference manual for variables:       Environment variables.
-* Reference, commands:                  Invoking CVS.
-* Release (subcommand):                 release.
-* Releases, revisions and versions:     Versions revisions releases.
-* Releasing your working copy:          Cleaning up.
-* Remote repositories:                  Remote repositories.
-* Remove (subcommand):                  remove.
-* Removing a change:                    Merging two revisions.
-* Removing files:                       Removing files.
-* Removing your working copy:           Cleaning up.
-* Renaming directories:                 Moving directories.
-* Renaming files:                       Moving files.
-* Replacing a log message:              admin options.
-* Reporting bugs (manual):              BUGS.
-* Repositories, multiple:               Multiple repositories.
-* Repositories, remote:                 Remote repositories.
-* Repository (intro):                   Basic concepts.
-* Repository, example:                  Repository.
-* Repository, setting up:               Setting up.
-* Repository, user parts:               User modules.
-* Resetting sticky tags:                Sticky tags.
-* Resolving a conflict:                 Conflicts example.
-* Retrieving an old revision using tags: Tags.
-* Revision keyword:                     Keyword list.
-* Revision management:                  Revision management.
-* Revision numbers:                     Revision numbers.
-* Revision tree:                        Revision numbers.
-* Revision tree, making branches:       Branches.
-* Revisions, merging differences between: Merging two revisions.
-* Revisions, versions and releases:     Versions revisions releases.
-* Right-hand options:                   Common options.
-* Rtag (subcommand):                    rtag.
-* rtag, creating a branch using:        Creating a branch.
-* Saving space:                         admin options.
-* Security:                             File permissions.
-* setgid:                               File permissions.
-* Setting up a repository:              Setting up.
-* setuid:                               File permissions.
-* Signum Support:                       Preface.
-* Source keyword:                       Keyword list.
-* Source, getting CVS source:           What is CVS?.
-* Source, getting from CVS:             Getting the source.
-* Specifying dates:                     Common options.
-* Spreading information:                Informing others.
-* Starting a project with CVS:          Starting a new project.
-* State keyword:                        Keyword list.
-* Status (subcommand):                  status.
-* Status of a file:                     File status.
-* Status of a module:                   modules.
-* Sticky tags:                          Sticky tags.
-* Sticky tags, resetting:               Sticky tags.
-* Storing log messages:                 loginfo.
-* Structure:                            Structure.
-* Subdirectories:                       Recursive behavior.
-* Support, getting CVS support:         Preface.
-* Symbolic name (tag):                  Tags.
-* Syntax of info files:                 syntax.
-* Tag (subcommand):                     tag.
-* Tag program:                          modules.
-* tag, command, introduction:           Tags.
-* tag, example:                         Tags.
-* Tag, retrieving old revisions:        Tags.
-* Tag, symbolic name:                   Tags.
-* Tags:                                 Tags.
-* Tags, sticky:                         Sticky tags.
-* tc, Trivial Compiler (example):       A sample session.
-* Team of developers:                   Multiple developers.
-* TEMP:                                 Environment variables.
-* Template for log message:             rcsinfo.
-* Third-party sources:                  Tracking sources.
-* Time:                                 Common options.
-* TMP:                                  Environment variables.
-* TMPDIR:                               Environment variables.
-* Trace:                                Global options.
-* Tracking sources:                     Tracking sources.
-* Trivial Compiler (example):           A sample session.
-* Typical repository:                   Repository.
-* Undoing a change:                     Merging two revisions.
-* Up-to-date:                           File status.
-* Update (subcommand):                  update.
-* Update program:                       modules.
-* update, introduction:                 Updating a file.
-* Updating a file:                      Updating a file.
-* USER:                                 Environment variables.
-* User modules:                         User modules.
-* Vendor:                               Tracking sources.
-* Vendor branch:                        Tracking sources.
-* Versions, revisions and releases:     Versions revisions releases.
-* Viewing differences:                  Viewing differences.
-* Wdiff (import example):               First import.
-* What (shell command):                 Using keywords.
-* What branches are good for:           Branches motivation.
-* What is CVS?:                         What is CVS?.
-* When to commit:                       When to commit.
-* Work-session, example of:             A sample session.
-* Working copy:                         Multiple developers.
-* Working copy, removing:               Cleaning up.
-* Wrappers:                             Wrappers.
+* Structure::                   Overall structure of CVS commands
+* Exit status::                 Indicating CVS's success or failure
+* ~/.cvsrc::                    Default options with the ~/.csvrc file
+* Global options::              Options you give to the left of cvs_command
+* Common options::              Options you give to the right of cvs_command
+* admin::                       Administration
+* checkout::                    Checkout sources for editing
+* commit::                      Check files into the repository
+* diff::                        Show differences between revisions
+* export::                      Export sources from CVS, similar to checkout
+* history::                     Show status of files and users
+* import::                      Import sources into CVS, using vendor branches
+* log::                         Show log messages for files
+* rdiff::                       'patch' format diffs between releases
+* release::                     Indicate that a directory is no longer in use
+* update::                      Bring work tree in sync with repository
+
+
+File: cvs.info,  Node: Structure,  Next: Exit status,  Up: CVS commands
+
+Overall structure of CVS commands
+=================================
+
+   The overall format of all CVS commands is:
+
+     cvs [ cvs_options ] cvs_command [ command_options ] [ command_args ]
+
+`cvs'
+     The name of the CVS program.
+
+`cvs_options'
+     Some options that affect all sub-commands of CVS.  These are
+     described below.
+
+`cvs_command'
+     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 `cvs_command': `cvs -H' elicits a list of
+     available commands, and `cvs -v' displays version information on
+     CVS itself.
+
+`command_options'
+     Options that are specific for the command.
+
+`command_args'
+     Arguments to the commands.
+
+   There is unfortunately some confusion between `cvs_options' and
+`command_options'.  `-l', when given as a `cvs_option', only affects
+some of the commands.  When it is given as a `command_option' 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.
+
+
+File: cvs.info,  Node: Exit status,  Next: ~/.cvsrc,  Prev: Structure,  Up: CVS commands
+
+CVS's exit status
+=================
+
+   CVS can indicate to the calling environment whether it succeeded or
+failed by setting its "exit status".  The exact way of testing the exit
+status will vary from one operating system to another.  For example in
+a unix shell script the `$?' variable will be 0 if the last command
+returned a successful exit status, or greater than 0 if the exit status
+indicated failure.
+
+   If CVS 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 `cvs diff' 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
+`cvs diff' will be changed to behave like the other CVS commands.
+
+
+File: cvs.info,  Node: ~/.cvsrc,  Next: Global options,  Prev: Exit status,  Up: CVS commands
+
+Default options and the ~/.cvsrc file
+=====================================
+
+   There are some `command_options' 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 `.cvsrc' support, actually) is that many people
+find the default output of the `diff' command to be very hard to read,
+and that either context diffs or unidiffs are much easier to understand.
+
+   The `~/.cvsrc' file is a way that you can add default options to
+`cvs_commands' within cvs, instead of relying on aliases or other shell
+scripts.
+
+   The format of the `~/.cvsrc' file is simple.  The file is searched
+for a line that begins with the same name as the `cvs_command' 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 _before_ any options from the command line.
+
+   If a command has two names (e.g., `checkout' and `co'), 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
+`~/.cvsrc' file:
+
+     log -N
+     diff -u
+     update -P
+     checkout -P
+
+the command `cvs checkout foo' would have the `-P' option added to the
+arguments, as well as `cvs co foo'.
+
+   With the example file above, the output from `cvs diff foobar' will
+be in unidiff format.  `cvs diff -c foobar' will provide context diffs,
+as usual.  Getting "old" format diffs would be slightly more
+complicated, because `diff' doesn't have an option to specify use of
+the "old" format, so you would need `cvs -f diff foobar'.
+
+   In place of the command name you can use `cvs' to specify global
+options (*note Global options::).  For example the following line in
+`.cvsrc'
+
+     cvs -z6
+
+   causes CVS to use compression level 6.
+
+
+File: cvs.info,  Node: Global options,  Next: Common options,  Prev: ~/.cvsrc,  Up: CVS commands
+
+Global options
+==============
+
+   The available `cvs_options' (that are given to the left of
+`cvs_command') are:
+
+`--allow-root=ROOTDIR'
+     Specify legal CVSROOT directory.  See *Note Password
+     authentication server::.
+
+`-a'
+     Authenticate all communication between the client and the server.
+     Only has an effect on the CVS client.  As of this writing, this is
+     only implemented when using a GSSAPI connection (*note GSSAPI
+     authenticated::).  Authentication prevents certain sorts of attacks
+     involving hijacking the active TCP connection.  Enabling
+     authentication does not enable encryption.
+
+`-b BINDIR'
+     In CVS 1.9.18 and older, this specified that RCS programs are in
+     the BINDIR directory.  Current versions of CVS do not run RCS
+     programs; for compatibility this option is accepted, but it does
+     nothing.
+
+`-T TEMPDIR'
+     Use TEMPDIR as the directory where temporary files are located.
+     Overrides the setting of the `$TMPDIR' environment variable and
+     any precompiled directory.  This parameter should be specified as
+     an absolute pathname.
+
+`-d CVS_ROOT_DIRECTORY'
+     Use CVS_ROOT_DIRECTORY as the root directory pathname of the
+     repository.  Overrides the setting of the `$CVSROOT' environment
+     variable.  *Note Repository::.
+
+`-e EDITOR'
+     Use EDITOR to enter revision log information.  Overrides the
+     setting of the `$CVSEDITOR' and `$EDITOR' environment variables.
+     For more information, see *Note Committing your changes::.
+
+`-f'
+     Do not read the `~/.cvsrc' file.  This option is most often used
+     because of the non-orthogonality of the CVS option set.  For
+     example, the `cvs log' option `-N' (turn off display of tag names)
+     does not have a corresponding option to turn the display on.  So
+     if you have `-N' in the `~/.cvsrc' entry for `log', you may need
+     to use `-f' to show the tag names.
+
+`-H'
+`--help'
+     Display usage information about the specified `cvs_command' (but
+     do not actually execute the command).  If you don't specify a
+     command name, `cvs -H' displays overall help for CVS, including a
+     list of other help options.
+
+`-l'
+     Do not log the `cvs_command' in the command history (but execute it
+     anyway).  *Note history::, for information on command history.
+
+`-n'
+     Do not change any files.  Attempt to execute the `cvs_command',
+     but only to issue reports; do not remove, update, or merge any
+     existing files, or create any new files.
+
+     Note that CVS will not necessarily produce exactly the same output
+     as without `-n'.  In some cases the output will be the same, but
+     in other cases CVS will skip some of the processing that would
+     have been required to produce the exact same output.
+
+`-Q'
+     Cause the command to be really quiet; the command will only
+     generate output for serious problems.
+
+`-q'
+     Cause the command to be somewhat quiet; informational messages,
+     such as reports of recursion through subdirectories, are
+     suppressed.
+
+`-r'
+     Make new working files read-only.  Same effect as if the
+     `$CVSREAD' environment variable is set (*note Environment
+     variables::).  The default is to make working files writable,
+     unless watches are on (*note Watches::).
+
+`-s VARIABLE=VALUE'
+     Set a user variable (*note Variables::).
+
+`-t'
+     Trace program execution; display messages showing the steps of CVS
+     activity.  Particularly useful with `-n' to explore the potential
+     impact of an unfamiliar command.
+
+`-v'
+
+`--version'
+     Display version and copyright information for CVS.
+
+`-w'
+     Make new working files read-write.  Overrides the setting of the
+     `$CVSREAD' environment variable.  Files are created read-write by
+     default, unless `$CVSREAD' is set or `-r' is given.
+
+`-x'
+     Encrypt all communication between the client and the server.  Only
+     has an effect on the CVS client.  As of this writing, this is only
+     implemented when using a GSSAPI connection (*note GSSAPI
+     authenticated::) or a Kerberos connection (*note Kerberos
+     authenticated::).  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, `--enable-encryption', when you build CVS.
+
+`-z GZIP-LEVEL'
+     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 CVS client.
+
+
+File: cvs.info,  Node: Common options,  Next: admin,  Prev: Global options,  Up: CVS commands
+
+Common command options
+======================
+
+   This section describes the `command_options' that are available
+across several CVS commands.  These options are always given to the
+right of `cvs_command'. 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 CVS command to the other).
+
+   *Warning:* the `history' command is an exception; it supports many
+options that conflict even with these standard options.
+
+`-D DATE_SPEC'
+     Use the most recent revision no later than DATE_SPEC.  DATE_SPEC
+     is a single argument, a date description specifying a date in the
+     past.
+
+     The specification is "sticky" when you use it to make a private
+     copy of a source file; that is, when you get a working file using
+     `-D', CVS 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, *note Sticky tags::).
+
+     `-D' is available with the `checkout', `diff', `export', `history',
+     `rdiff', `rtag', and `update' commands.  (The `history' command
+     uses this option in a slightly different way; *note history
+     options::).
+
+     A wide variety of date formats are supported by CVS.  The most
+     standard ones are ISO8601 (from the International Standards
+     Organization) and the Internet e-mail standard (specified in
+     RFC822 as amended by RFC1123).
+
+     ISO8601 dates have many variants but a few examples are:
+
+          1972-09-24
+          1972-09-24 20:05
+
+     There are a lot more ISO8601 date formats, and CVS accepts many of
+     them, but you probably don't want to hear the _whole_ long story
+     :-).
+
+     In addition to the dates allowed in Internet e-mail itself, CVS
+     also allows some of the fields to be omitted.  For example:
+
+          24 Sep 1972 20:05
+          24 Sep
+
+     The date is interpreted as being in the local timezone, unless a
+     specific timezone is specified.
+
+     These two date formats are preferred.  However, CVS currently
+     accepts a wide variety of other date formats.  They are
+     intentionally not documented here in any detail, and future
+     versions of CVS might not accept all of them.
+
+     One such format is `MONTH/DAY/YEAR'.  This may confuse people who
+     are accustomed to having the month and day in the other order;
+     `1/4/96' is January 4, not April 1.
+
+     Remember to quote the argument to the `-D' flag so that your shell
+     doesn't interpret spaces as argument separators.  A command using
+     the `-D' flag can look like this:
+
+          $ cvs diff -D "1 hour ago" cvs.texinfo
+
+`-f'
+     When you specify a particular date or tag to CVS commands, they
+     normally ignore files that do not contain the tag (or did not
+     exist prior to the date) that you specified.  Use the `-f' 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).
+
+     Note that even with `-f', a tag that you specify must exist (that
+     is, in some file, not necessary in every file).  This is so that
+     CVS will continue to give an error if you mistype a tag name.
+
+     `-f' is available with these commands: `annotate', `checkout',
+     `export', `rdiff', `rtag', and `update'.
+
+     *Warning:*  The `commit' and `remove' commands also have a `-f'
+     option, but it has a different behavior for those commands.  See
+     *Note commit options::, and *Note Removing files::.
+
+`-k KFLAG'
+     Alter the default processing of keywords.  *Note Keyword
+     substitution::, for the meaning of KFLAG.  Your KFLAG
+     specification is "sticky" when you use it to create a private copy
+     of a source file; that is, when you use this option with the
+     `checkout' or `update' commands, CVS associates your selected
+     KFLAG with the file, and continues to use it with future update
+     commands on the same file until you specify otherwise.
+
+     The `-k' option is available with the `add', `checkout', `diff',
+     `import' and `update' commands.
+
+`-l'
+     Local; run only in current working directory, rather than
+     recursing through subdirectories.
+
+     *Warning:* this is not the same as the overall `cvs -l' option,
+     which you can specify to the left of a cvs command!
+
+     Available with the following commands: `annotate', `checkout',
+     `commit', `diff', `edit', `editors', `export', `log', `rdiff',
+     `remove', `rtag', `status', `tag', `unedit', `update', `watch',
+     and `watchers'.
+
+`-m MESSAGE'
+     Use MESSAGE as log information, instead of invoking an editor.
+
+     Available with the following commands: `add', `commit' and
+     `import'.
+
+`-n'
+     Do not run any checkout/commit/tag program.  (A program can be
+     specified to run on each of these activities, in the modules
+     database (*note modules::); this option bypasses it).
+
+     *Warning:* this is not the same as the overall `cvs -n' option,
+     which you can specify to the left of a cvs command!
+
+     Available with the `checkout', `commit', `export', and `rtag'
+     commands.
+
+`-P'
+     Prune empty directories.  See *Note Removing directories::.
+
+`-p'
+     Pipe the files retrieved from the repository to standard output,
+     rather than writing them in the current directory.  Available with
+     the `checkout' and `update' commands.
+
+`-R'
+     Process directories recursively.  This is on by default.
+
+     Available with the following commands: `annotate', `checkout',
+     `commit', `diff', `edit', `editors', `export', `rdiff', `remove',
+     `rtag', `status', `tag', `unedit', `update', `watch', and
+     `watchers'.
+
+`-r TAG'
+     Use the revision specified by the TAG argument instead of the
+     default "head" revision.  As well as arbitrary tags defined with
+     the `tag' or `rtag' command, two special tags are always
+     available: `HEAD' refers to the most recent version available in
+     the repository, and `BASE' refers to the revision you last checked
+     out into the current working directory.
+
+     The tag specification is sticky when you use this with `checkout'
+     or `update' to make your own copy of a file: CVS remembers the tag
+     and continues to use it on future update commands, until you
+     specify otherwise (for more information on sticky tags/dates,
+     *note Sticky tags::).
+
+     The tag can be either a symbolic or numeric tag, as described in
+     *Note Tags::, or the name of a branch, as described in *Note
+     Branching and merging::.
+
+     Specifying the `-q' global option along with the `-r' command
+     option is often useful, to suppress the warning messages when the
+     RCS file does not contain the specified tag.
+
+     *Warning:* this is not the same as the overall `cvs -r' option,
+     which you can specify to the left of a CVS command!
+
+     `-r' is available with the `checkout', `commit', `diff',
+     `history', `export', `rdiff', `rtag', and `update' commands.
+
+`-W'
+     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 `.cvswrappers' file.
+     Available with the following commands: `import', and `update'.
+
+
+File: cvs.info,  Node: admin,  Next: checkout,  Prev: Common options,  Up: CVS commands
+
+admin--Administration
+=====================
+
+   * Requires: repository, working directory.
+
+   * Changes: repository.
+
+   * Synonym: rcs
+
+   This is the CVS interface to assorted administrative facilities.
+Some of them have questionable usefulness for CVS but exist for
+historical purposes.  Some of the questionable options are likely to
+disappear in the future.  This command _does_ work recursively, so
+extreme care should be used.
+
+   On unix, if there is a group named `cvsadmin', only members of that
+group can run `cvs admin' (except for the `cvs admin -k' command, which
+can be run by anybody).  This group should exist on the server, or any
+system running the non-client/server CVS.  To disallow `cvs admin' for
+all users, create a group with no users in it.  On NT, the `cvsadmin'
+feature does not exist and all users can run `cvs admin'.
+
+* Menu:
+
+* admin options::               admin options
+
+
+File: cvs.info,  Node: admin options,  Up: admin
+
+admin options
+-------------
+
+   Some of these options have questionable usefulness for CVS but exist
+for historical purposes.  Some even make it impossible to use CVS until
+you undo the effect!
+
+`-AOLDFILE'
+     Might not work together with CVS.  Append the access list of
+     OLDFILE to the access list of the RCS file.
+
+`-aLOGINS'
+     Might not work together with CVS.  Append the login names
+     appearing in the comma-separated list LOGINS to the access list of
+     the RCS file.
+
+`-b[REV]'
+     Set the default branch to REV.  In CVS, you normally do not
+     manipulate default branches; sticky tags (*note Sticky tags::) are
+     a better way to decide which branch you want to work on.  There is
+     one reason to run `cvs admin -b': to revert to the vendor's
+     version when using vendor branches (*note Reverting local
+     changes::).  There can be no space between `-b' and its argument.
+
+`-cSTRING'
+     Sets the comment leader to STRING.  The comment leader is not used
+     by current versions of CVS or RCS 5.7.  Therefore, you can almost
+     surely not worry about it.  *Note Keyword substitution::.
+
+`-e[LOGINS]'
+     Might not work together with CVS.  Erase the login names appearing
+     in the comma-separated list LOGINS from the access list of the RCS
+     file.  If LOGINS is omitted, erase the entire access list.  There
+     can be no space between `-e' and its argument.
+
+`-I'
+     Run interactively, even if the standard input is not a terminal.
+     This option does not work with the client/server CVS and is likely
+     to disappear in a future release of CVS.
+
+`-i'
+     Useless with CVS.  This creates and initializes a new RCS file,
+     without depositing a revision.  With CVS, add files with the `cvs
+     add' command (*note Adding files::).
+
+`-kSUBST'
+     Set the default keyword substitution to SUBST.  *Note Keyword
+     substitution::.  Giving an explicit `-k' option to `cvs update',
+     `cvs export', or `cvs checkout' overrides this default.
+
+`-l[REV]'
+     Lock the revision with number REV.  If a branch is given, lock the
+     latest revision on that branch.  If REV is omitted, lock the
+     latest revision on the default branch.  There can be no space
+     between `-l' and its argument.
+
+     This can be used in conjunction with the `rcslock.pl' script in
+     the `contrib' directory of the CVS 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 `README' 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).
+
+`-L'
+     Set locking to strict.  Strict locking means that the owner of an
+     RCS file is not exempt from locking for checkin.  For use with
+     CVS, strict locking must be set; see the discussion under the `-l'
+     option above.
+
+`-mREV:MSG'
+     Replace the log message of revision REV with MSG.
+
+`-NNAME[:[REV]]'
+     Act like `-n', except override any previous assignment of NAME.
+     For use with magic branches, see *Note Magic branch numbers::.
+
+`-nNAME[:[REV]]'
+     Associate the symbolic name NAME with the branch or revision REV.
+     It is normally better to use `cvs tag' or `cvs rtag' instead.
+     Delete the symbolic name if both `:' and REV are omitted;
+     otherwise, print an error message if NAME is already associated
+     with another number.  If REV is symbolic, it is expanded before
+     association.  A REV consisting of a branch number followed by a
+     `.' stands for the current latest revision in the branch.  A `:'
+     with an empty REV stands for the current latest revision on the
+     default branch, normally the trunk.  For example, `cvs admin
+     -nNAME:' associates NAME with the current latest revision of all
+     the RCS files; this contrasts with `cvs admin -nNAME:$' which
+     associates NAME with the revision numbers extracted from keyword
+     strings in the corresponding working files.
+
+`-oRANGE'
+     Deletes ("outdates") the revisions given by RANGE.
+
+     Note that this command can be quite dangerous unless you know
+     _exactly_ what you are doing (for example see the warnings below
+     about how the REV1:REV2 syntax is confusing).
+
+     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 CVS 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.
+
+     Specify RANGE in one of the following ways:
+
+    `REV1::REV2'
+          Collapse all revisions between rev1 and rev2, so that CVS
+          only stores the differences associated with going from rev1
+          to rev2, not intermediate steps.  For example, after `-o
+          1.3::1.5' 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: `-o
+          1.3::1.4' and `-o 1.3::1.3' have no effect, because there are
+          no intermediate revisions to remove.
+
+    `::REV'
+          Collapse revisions between the beginning of the branch
+          containing REV and REV itself.  The branchpoint and REV are
+          left intact.  For example, `-o ::1.3.2.6' 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.
+
+    `REV::'
+          Collapse revisions between REV and the end of the branch
+          containing REV.  Revision REV is left intact but the head
+          revision is deleted.
+
+    `REV'
+          Delete the revision REV.  For example, `-o 1.3' is equivalent
+          to `-o 1.2::1.4'.
+
+    `REV1:REV2'
+          Delete the revisions from REV1 to REV2, inclusive, on the
+          same branch.  One will not be able to retrieve REV1 or REV2
+          or any of the revisions in between.  For example, the command
+          `cvs admin -oR_1_01:R_1_02 .' 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 _the same_ 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 REV1::REV2 instead.
+
+    `:REV'
+          Delete revisions from the beginning of the branch containing
+          REV up to and including REV.
+
+    `REV:'
+          Delete revisions from revision REV, including REV itself, to
+          the end of the branch containing REV.
+
+     None of the revisions to be deleted may have branches or locks.
+
+     If any of the revisions to be deleted have symbolic names, and one
+     specifies one of the `::' syntaxes, then CVS 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 `cvs tag -d', then run `cvs admin -o'.  If one
+     specifies the non-`::' syntaxes, then CVS will delete the
+     revisions but leave the symbolic names pointing to nonexistent
+     revisions.  This behavior is preserved for compatibility with
+     previous versions of CVS, but because it isn't very useful, in the
+     future it may change to be like the `::' case.
+
+     Due to the way CVS handles branches REV cannot be specified
+     symbolically if it is a branch.  *Note Magic branch numbers::, for
+     an explanation.
+
+     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 (*note Merging two revisions::).
+
+`-q'
+     Run quietly; do not print diagnostics.
+
+`-sSTATE[:REV]'
+     Useful with CVS.  Set the state attribute of the revision REV to
+     STATE.  If REV is a branch number, assume the latest revision on
+     that branch.  If REV is omitted, assume the latest revision on the
+     default branch.  Any identifier is acceptable for STATE.  A useful
+     set of states is `Exp' (for experimental), `Stab' (for stable),
+     and `Rel' (for released).  By default, the state of a new revision
+     is set to `Exp' when it is created.  The state is visible in the
+     output from CVS LOG (*note log::), and in the `$Log: cvs.info-5,v $
+     output from CVS LOG (*note log::), and in the `Revision 1.2  2001/09/29 00:00:39  tholo
+     output from CVS LOG (*note log::), and in the `Merge remaining local changes, correct build issues
+     output from CVS LOG (*note log::), and in the `' and
+     `$State: Exp $' keywords (*note Keyword substitution::).  Note that CVS
+     uses the `dead' state for its own purposes; to take a file to or
+     from the `dead' state use commands like `cvs remove' and `cvs
+     add', not `cvs admin -s'.
+
+`-t[FILE]'
+     Useful with CVS.  Write descriptive text from the contents of the
+     named FILE into the RCS file, deleting the existing text.  The
+     FILE pathname may not begin with `-'.  The descriptive text can be
+     seen in the output from `cvs log' (*note log::).  There can be no
+     space between `-t' and its argument.
+
+     If FILE is omitted, obtain the text from standard input,
+     terminated by end-of-file or by a line containing `.' by itself.
+     Prompt for the text if interaction is possible; see `-I'.
+
+`-t-STRING'
+     Similar to `-tFILE'. Write descriptive text from the STRING into
+     the RCS file, deleting the existing text.  There can be no space
+     between `-t' and its argument.
+
+`-U'
+     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 CVS, strict locking must be set; see the discussion under the
+     `-l' option above.
+
+`-u[REV]'
+     See the option `-l' above, for a discussion of using this option
+     with CVS.  Unlock the revision with number REV.  If a branch is
+     given, unlock the latest revision on that branch.  If REV 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 `commit' notification (*note Getting
+     Notified::).  There can be no space between `-u' and its argument.
+
+`-VN'
+     In previous versions of CVS, this option meant to write an RCS
+     file which would be acceptable to RCS version N, but it is now
+     obsolete and specifying it will produce an error.
+
+`-xSUFFIXES'
+     In previous versions of CVS, this was documented as a way of
+     specifying the names of the RCS files.  However, CVS has always
+     required that the RCS files used by CVS end in `,v', so this
+     option has never done anything useful.
+
+
+File: cvs.info,  Node: checkout,  Next: commit,  Prev: admin,  Up: CVS commands
+
+checkout--Check out sources for editing
+=======================================
+
+   * Synopsis: checkout [options] modules...
+
+   * Requires: repository.
+
+   * Changes: working directory.
+
+   * Synonyms: co, get
+
+   Create or update a working directory containing copies of the source
+files specified by MODULES.  You must execute `checkout' before using
+most of the other CVS commands, since most of them operate on your
+working directory.
+
+   The MODULES 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 `modules' file.
+*Note modules::.
+
+   Depending on the modules you specify, `checkout' 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.
+
+   Note that `checkout' is used to create directories.  The top-level
+directory created is always added to the directory where `checkout' 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
+`checkout' will show the relative path leading to each file as it is
+extracted into your private work area (unless you specify the `-Q'
+global option).
+
+   The files created by `checkout' are created read-write, unless the
+`-r' option to CVS (*note Global options::) is specified, the `CVSREAD'
+environment variable is specified (*note Environment variables::), or a
+watch is in effect for that file (*note Watches::).
+
+   Note that running `checkout' on a directory that was already built
+by a prior `checkout' is also permitted.  This is similar to specifying
+the `-d' option to the `update' command in the sense that new
+directories that have been created in the repository will appear in
+your work area.  However, `checkout' takes a module name whereas
+`update' takes a directory name.  Also to use `checkout' this way it
+must be run from the top level directory (where you originally ran
+`checkout' from), so before you run `checkout' to update an existing
+directory, don't forget to change your directory to the top level
+directory.
+
+   For the output produced by the `checkout' command see *Note update
+output::.
+
+* Menu:
+
+* checkout options::            checkout options
+* checkout examples::           checkout examples
+
+
+File: cvs.info,  Node: checkout options,  Next: checkout examples,  Up: checkout
+
+checkout options
+----------------
+
+   These standard options are supported by `checkout' (*note Common
+options::, for a complete description of them):
+
+`-D DATE'
+     Use the most recent revision no later than DATE.  This option is
+     sticky, and implies `-P'.  See *Note Sticky tags::, for more
+     information on sticky tags/dates.
+
+`-f'
+     Only useful with the `-D DATE' or `-r TAG' flags.  If no matching
+     revision is found, retrieve the most recent revision (instead of
+     ignoring the file).
+
+`-k KFLAG'
+     Process keywords according to KFLAG.  See *Note Keyword
+     substitution::.  This option is sticky; future updates of this
+     file in this working directory will use the same KFLAG.  The
+     `status' command can be viewed to see the sticky options.  See
+     *Note Invoking CVS::, for more information on the `status' command.
+
+`-l'
+     Local; run only in current working directory.
+
+`-n'
+     Do not run any checkout program (as specified with the `-o' option
+     in the modules file; *note modules::).
+
+`-P'
+     Prune empty directories.  See *Note Moving directories::.
+
+`-p'
+     Pipe files to the standard output.
+
+`-R'
+     Checkout directories recursively.  This option is on by default.
+
+`-r TAG'
+     Use revision TAG.  This option is sticky, and implies `-P'.  See
+     *Note Sticky tags::, for more information on sticky tags/dates.
+
+   In addition to those, you can use these special command options with
+`checkout':
+
+`-A'
+     Reset any sticky tags, dates, or `-k' options.  See *Note Sticky
+     tags::, for more information on sticky tags/dates.
+
+`-c'
+     Copy the module file, sorted, to the standard output, instead of
+     creating or modifying any files or directories in your working
+     directory.
+
+`-d DIR'
+     Create a directory called DIR for the working files, instead of
+     using the module name.  In general, using this flag is equivalent
+     to using `mkdir DIR; cd DIR' followed by the checkout command
+     without the `-d' flag.
+
+     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 _only_, CVS tries to "shorten" pathnames to avoid those
+     empty directories.
+
+     For example, given a module `foo' that contains the file `bar.c',
+     the command `cvs co -d dir foo' will create directory `dir' and
+     place `bar.c' inside.  Similarly, given a module `bar' which has
+     subdirectory `baz' wherein there is a file `quux.c', the command
+     `cvs -d dir co bar/baz' will create directory `dir' and place
+     `quux.c' inside.
+
+     Using the `-N' flag will defeat this behavior.  Given the same
+     module definitions above, `cvs co -N -d dir foo' will create
+     directories `dir/foo' and place `bar.c' inside, while `cvs co -N -d
+     dir bar/baz' will create directories `dir/bar/baz' and place
+     `quux.c' inside.
+
+`-j TAG'
+     With two `-j' options, merge changes from the revision specified
+     with the first `-j' option to the revision specified with the
+     second `j' option, into the working directory.
+
+     With one `-j' option, merge changes from the ancestor revision to
+     the revision specified with the `-j' option, into the working
+     directory.  The ancestor revision is the common ancestor of the
+     revision which the working directory is based on, and the revision
+     specified in the `-j' option.
+
+     In addition, each -j option can contain an optional date
+     specification which, when used with branches, can limit the chosen
+     revision to one within a specific date.  An optional date is
+     specified by adding a colon (:) to the tag:
+     `-jSYMBOLIC_TAG:DATE_SPECIFIER'.
+
+     *Note Branching and merging::.
+
+`-N'
+     Only useful together with `-d DIR'.  With this option, CVS will
+     not "shorten" module paths in your working directory when you
+     check out a single module.  See the `-d' flag for examples and a
+     discussion.
+
+`-s'
+     Like `-c', but include the status of all modules, and sort it by
+     the status string.  *Note modules::, for info about the `-s'
+     option that is used inside the modules file to set the module
+     status.
+
+
+File: cvs.info,  Node: checkout examples,  Prev: checkout options,  Up: checkout
+
+checkout examples
+-----------------
+
+   Get a copy of the module `tc':
+
+     $ cvs checkout tc
+
+   Get a copy of the module `tc' as it looked one day ago:
+
+     $ cvs checkout -D yesterday tc
+
+
+File: cvs.info,  Node: commit,  Next: diff,  Prev: checkout,  Up: CVS commands
+
+commit--Check files into the repository
+=======================================
+
+   * Synopsis: commit [-lnRf] [-m 'log_message' | -F file] [-r
+     revision] [files...]
+
+   * Requires: working directory, repository.
+
+   * Changes: repository.
+
+   * Synonym: ci
+
+   Use `commit' when you want to incorporate changes from your working
+source files into the source repository.
+
+   If you don't specify particular files to commit, all of the files in
+your working current directory are examined.  `commit' is careful to
+change in the repository only those files that you have really changed.
+By default (or if you explicitly specify the `-R' option), files in
+subdirectories are also examined and committed if they have changed;
+you can use the `-l' option to limit `commit' to the current directory
+only.
+
+   `commit' 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 `update' (*note update::).  `commit' does not call
+the `update' command for you, but rather leaves that for you to do when
+the time is right.
+
+   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 (*note
+modules::, and *note loginfo::) and placed in the RCS file inside the
+repository.  This log message can be retrieved with the `log' command;
+see *Note log::.  You can specify the log message on the command line
+with the `-m MESSAGE' option, and thus avoid the editor invocation, or
+use the `-F FILE' option to specify that the argument file contains the
+log message.
+
+* Menu:
 
+* commit options::              commit options
+* commit examples::             commit examples
 
diff --git a/gnu/usr.bin/cvs/doc/cvs.info-7 b/gnu/usr.bin/cvs/doc/cvs.info-7
index d3ea494bcf8..9f375050b04 100644
--- a/gnu/usr.bin/cvs/doc/cvs.info-7
+++ b/gnu/usr.bin/cvs/doc/cvs.info-7
@@ -1,5 +1,8 @@
-This is Info file cvs.info, produced by Makeinfo-1.64 from the input
-file ../../work/ccvs/doc/cvs.texinfo.
+This is cvs.info, produced by makeinfo version 4.0 from cvs.texinfo.
+
+START-INFO-DIR-ENTRY
+* CVS: (cvs).          Concurrent Versions System
+END-INFO-DIR-ENTRY
 
    Copyright (C) 1992, 1993 Signum Support AB Copyright (C) 1993, 1994
 Free Software Foundation, Inc.
@@ -10,826 +13,1493 @@ preserved on all copies.
 
    Permission is granted to copy and distribute modified versions of
 this manual under the conditions for verbatim copying, provided also
-that the section entitled "GNU General Public License" is included
-exactly as in the original, and provided that the entire resulting
-derived work is distributed under the terms of a permission notice
-identical to this one.
+that the entire resulting derived work is distributed under the terms
+of a permission notice identical to this one.
 
    Permission is granted to copy and distribute translations of this
 manual into another language, under the above conditions for modified
-versions, except that the section entitled "GNU General Public License"
-and this permission notice may be included in translations approved by
-the Free Software Foundation instead of in the original English.
+versions, except that this permission notice may be stated in a
+translation approved by the Free Software Foundation.
 
 
-File: cvs.info,  Node: Copying,  Next: Index,  Prev: Troubleshooting,  Up: Top
+File: cvs.info,  Node: Invoking CVS,  Next: Administrative files,  Prev: CVS commands,  Up: Top
 
-GNU GENERAL PUBLIC LICENSE
-**************************
+Quick reference to CVS commands
+*******************************
 
-                         Version 2, June 1991
+   This appendix describes how to invoke CVS, with references to where
+each command or feature is described in detail.  For other references
+run the `cvs --help' command, or see *Note Index::.
 
-     Copyright (C) 1989, 1991 Free Software Foundation, Inc.
-     59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
-     
-     Everyone is permitted to copy and distribute verbatim copies
-     of this license document, but changing it is not allowed.
+   A CVS command looks like:
 
-Preamble
-========
+     cvs [ GLOBAL_OPTIONS ] COMMAND [ COMMAND_OPTIONS ] [ COMMAND_ARGS ]
 
-   The licenses for most software are designed to take away your
-freedom to share and change it.  By contrast, the GNU General Public
-License is intended to guarantee your freedom to share and change free
-software--to make sure the software is free for all its users.  This
-General Public License applies to most of the Free Software
-Foundation's software and to any other program whose authors commit to
-using it.  (Some other Free Software Foundation software is covered by
-the GNU Library General Public License instead.)  You can apply it to
-your programs, too.
-
-   When we speak of free software, we are referring to freedom, not
-price.  Our General Public Licenses are designed to make sure that you
-have the freedom to distribute copies of free software (and charge for
-this service if you wish), that you receive source code or can get it
-if you want it, that you can change the software or use pieces of it in
-new free programs; and that you know you can do these things.
-
-   To protect your rights, we need to make restrictions that forbid
-anyone to deny you these rights or to ask you to surrender the rights.
-These restrictions translate to certain responsibilities for you if you
-distribute copies of the software, or if you modify it.
-
-   For example, if you distribute copies of such a program, whether
-gratis or for a fee, you must give the recipients all the rights that
-you have.  You must make sure that they, too, receive or can get the
-source code.  And you must show them these terms so they know their
-rights.
-
-   We protect your rights with two steps: (1) copyright the software,
-and (2) offer you this license which gives you legal permission to copy,
-distribute and/or modify the software.
-
-   Also, for each author's protection and ours, we want to make certain
-that everyone understands that there is no warranty for this free
-software.  If the software is modified by someone else and passed on, we
-want its recipients to know that what they have is not the original, so
-that any problems introduced by others will not reflect on the original
-authors' reputations.
-
-   Finally, any free program is threatened constantly by software
-patents.  We wish to avoid the danger that redistributors of a free
-program will individually obtain patent licenses, in effect making the
-program proprietary.  To prevent this, we have made it clear that any
-patent must be licensed for everyone's free use or not licensed at all.
-
-   The precise terms and conditions for copying, distribution and
-modification follow.
-
-    TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
-
-  0. This License applies to any program or other work which contains a
-     notice placed by the copyright holder saying it may be distributed
-     under the terms of this General Public License.  The "Program",
-     below, refers to any such program or work, and a "work based on
-     the Program" means either the Program or any derivative work under
-     copyright law: that is to say, a work containing the Program or a
-     portion of it, either verbatim or with modifications and/or
-     translated into another language.  (Hereinafter, translation is
-     included without limitation in the term "modification".)  Each
-     licensee is addressed as "you".
-
-     Activities other than copying, distribution and modification are
-     not covered by this License; they are outside its scope.  The act
-     of running the Program is not restricted, and the output from the
-     Program is covered only if its contents constitute a work based on
-     the Program (independent of having been made by running the
-     Program).  Whether that is true depends on what the Program does.
-
-  1. You may copy and distribute verbatim copies of the Program's
-     source code as you receive it, in any medium, provided that you
-     conspicuously and appropriately publish on each copy an appropriate
-     copyright notice and disclaimer of warranty; keep intact all the
-     notices that refer to this License and to the absence of any
-     warranty; and give any other recipients of the Program a copy of
-     this License along with the Program.
-
-     You may charge a fee for the physical act of transferring a copy,
-     and you may at your option offer warranty protection in exchange
-     for a fee.
-
-  2. You may modify your copy or copies of the Program or any portion
-     of it, thus forming a work based on the Program, and copy and
-     distribute such modifications or work under the terms of Section 1
-     above, provided that you also meet all of these conditions:
-
-       a. You must cause the modified files to carry prominent notices
-          stating that you changed the files and the date of any change.
-
-       b. You must cause any work that you distribute or publish, that
-          in whole or in part contains or is derived from the Program
-          or any part thereof, to be licensed as a whole at no charge
-          to all third parties under the terms of this License.
-
-       c. If the modified program normally reads commands interactively
-          when run, you must cause it, when started running for such
-          interactive use in the most ordinary way, to print or display
-          an announcement including an appropriate copyright notice and
-          a notice that there is no warranty (or else, saying that you
-          provide a warranty) and that users may redistribute the
-          program under these conditions, and telling the user how to
-          view a copy of this License.  (Exception: if the Program
-          itself is interactive but does not normally print such an
-          announcement, your work based on the Program is not required
-          to print an announcement.)
-
-     These requirements apply to the modified work as a whole.  If
-     identifiable sections of that work are not derived from the
-     Program, and can be reasonably considered independent and separate
-     works in themselves, then this License, and its terms, do not
-     apply to those sections when you distribute them as separate
-     works.  But when you distribute the same sections as part of a
-     whole which is a work based on the Program, the distribution of
-     the whole must be on the terms of this License, whose permissions
-     for other licensees extend to the entire whole, and thus to each
-     and every part regardless of who wrote it.
-
-     Thus, it is not the intent of this section to claim rights or
-     contest your rights to work written entirely by you; rather, the
-     intent is to exercise the right to control the distribution of
-     derivative or collective works based on the Program.
-
-     In addition, mere aggregation of another work not based on the
-     Program with the Program (or with a work based on the Program) on
-     a volume of a storage or distribution medium does not bring the
-     other work under the scope of this License.
-
-  3. You may copy and distribute the Program (or a work based on it,
-     under Section 2) in object code or executable form under the terms
-     of Sections 1 and 2 above provided that you also do one of the
-     following:
-
-       a. Accompany it with the complete corresponding machine-readable
-          source code, which must be distributed under the terms of
-          Sections 1 and 2 above on a medium customarily used for
-          software interchange; or,
-
-       b. Accompany it with a written offer, valid for at least three
-          years, to give any third party, for a charge no more than your
-          cost of physically performing source distribution, a complete
-          machine-readable copy of the corresponding source code, to be
-          distributed under the terms of Sections 1 and 2 above on a
-          medium customarily used for software interchange; or,
-
-       c. Accompany it with the information you received as to the offer
-          to distribute corresponding source code.  (This alternative is
-          allowed only for noncommercial distribution and only if you
-          received the program in object code or executable form with
-          such an offer, in accord with Subsection b above.)
-
-     The source code for a work means the preferred form of the work for
-     making modifications to it.  For an executable work, complete
-     source code means all the source code for all modules it contains,
-     plus any associated interface definition files, plus the scripts
-     used to control compilation and installation of the executable.
-     However, as a special exception, the source code distributed need
-     not include anything that is normally distributed (in either
-     source or binary form) with the major components (compiler,
-     kernel, and so on) of the operating system on which the executable
-     runs, unless that component itself accompanies the executable.
-
-     If distribution of executable or object code is made by offering
-     access to copy from a designated place, then offering equivalent
-     access to copy the source code from the same place counts as
-     distribution of the source code, even though third parties are not
-     compelled to copy the source along with the object code.
-
-  4. You may not copy, modify, sublicense, or distribute the Program
-     except as expressly provided under this License.  Any attempt
-     otherwise to copy, modify, sublicense or distribute the Program is
-     void, and will automatically terminate your rights under this
-     License.  However, parties who have received copies, or rights,
-     from you under this License will not have their licenses
-     terminated so long as such parties remain in full compliance.
-
-  5. You are not required to accept this License, since you have not
-     signed it.  However, nothing else grants you permission to modify
-     or distribute the Program or its derivative works.  These actions
-     are prohibited by law if you do not accept this License.
-     Therefore, by modifying or distributing the Program (or any work
-     based on the Program), you indicate your acceptance of this
-     License to do so, and all its terms and conditions for copying,
-     distributing or modifying the Program or works based on it.
-
-  6. Each time you redistribute the Program (or any work based on the
-     Program), the recipient automatically receives a license from the
-     original licensor to copy, distribute or modify the Program
-     subject to these terms and conditions.  You may not impose any
-     further restrictions on the recipients' exercise of the rights
-     granted herein.  You are not responsible for enforcing compliance
-     by third parties to this License.
-
-  7. If, as a consequence of a court judgment or allegation of patent
-     infringement or for any other reason (not limited to patent
-     issues), conditions are imposed on you (whether by court order,
-     agreement or otherwise) that contradict the conditions of this
-     License, they do not excuse you from the conditions of this
-     License.  If you cannot distribute so as to satisfy simultaneously
-     your obligations under this License and any other pertinent
-     obligations, then as a consequence you may not distribute the
-     Program at all.  For example, if a patent license would not permit
-     royalty-free redistribution of the Program by all those who
-     receive copies directly or indirectly through you, then the only
-     way you could satisfy both it and this License would be to refrain
-     entirely from distribution of the Program.
-
-     If any portion of this section is held invalid or unenforceable
-     under any particular circumstance, the balance of the section is
-     intended to apply and the section as a whole is intended to apply
-     in other circumstances.
-
-     It is not the purpose of this section to induce you to infringe any
-     patents or other property right claims or to contest validity of
-     any such claims; this section has the sole purpose of protecting
-     the integrity of the free software distribution system, which is
-     implemented by public license practices.  Many people have made
-     generous contributions to the wide range of software distributed
-     through that system in reliance on consistent application of that
-     system; it is up to the author/donor to decide if he or she is
-     willing to distribute software through any other system and a
-     licensee cannot impose that choice.
-
-     This section is intended to make thoroughly clear what is believed
-     to be a consequence of the rest of this License.
-
-  8. If the distribution and/or use of the Program is restricted in
-     certain countries either by patents or by copyrighted interfaces,
-     the original copyright holder who places the Program under this
-     License may add an explicit geographical distribution limitation
-     excluding those countries, so that distribution is permitted only
-     in or among countries not thus excluded.  In such case, this
-     License incorporates the limitation as if written in the body of
-     this License.
-
-  9. The Free Software Foundation may publish revised and/or new
-     versions of the General Public License from time to time.  Such
-     new versions will be similar in spirit to the present version, but
-     may differ in detail to address new problems or concerns.
-
-     Each version is given a distinguishing version number.  If the
-     Program specifies a version number of this License which applies
-     to it and "any later version", you have the option of following
-     the terms and conditions either of that version or of any later
-     version published by the Free Software Foundation.  If the Program
-     does not specify a version number of this License, you may choose
-     any version ever published by the Free Software Foundation.
-
- 10. If you wish to incorporate parts of the Program into other free
-     programs whose distribution conditions are different, write to the
-     author to ask for permission.  For software which is copyrighted
-     by the Free Software Foundation, write to the Free Software
-     Foundation; we sometimes make exceptions for this.  Our decision
-     will be guided by the two goals of preserving the free status of
-     all derivatives of our free software and of promoting the sharing
-     and reuse of software generally.
-
-                                NO WARRANTY
-
- 11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO
-     WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE
-     LAW.  EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT
-     HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT
-     WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT
-     NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
-     FITNESS FOR A PARTICULAR PURPOSE.  THE ENTIRE RISK AS TO THE
-     QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU.  SHOULD THE
-     PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY
-     SERVICING, REPAIR OR CORRECTION.
-
- 12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN
-     WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY
-     MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE
-     LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL,
-     INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR
-     INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF
-     DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU
-     OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY
-     OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN
-     ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
-
-                      END OF TERMS AND CONDITIONS
-
-How to Apply These Terms to Your New Programs
-=============================================
-
-   If you develop a new program, and you want it to be of the greatest
-possible use to the public, the best way to achieve this is to make it
-free software which everyone can redistribute and change under these
-terms.
-
-   To do so, attach the following notices to the program.  It is safest
-to attach them to the start of each source file to most effectively
-convey the exclusion of warranty; and each file should have at least
-the "copyright" line and a pointer to where the full notice is found.
-
-     ONE LINE TO GIVE THE PROGRAM'S NAME AND A BRIEF IDEA OF WHAT IT DOES.
-     Copyright (C) 19YY  NAME OF AUTHOR
-     
-     This program is free software; you can redistribute it and/or modify
-     it under the terms of the GNU General Public License as published by
-     the Free Software Foundation; either version 2 of the License, or
-     (at your option) any later version.
-     
-     This program is distributed in the hope that it will be useful,
-     but WITHOUT ANY WARRANTY; without even the implied warranty of
-     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-     GNU General Public License for more details.
+   Global options:
+
+`--allow-root=ROOTDIR'
+     Specify legal CVSROOT directory (server only) (not in CVS 1.9 and
+     older).  See *Note Password authentication server::.
+
+`-a'
+     Authenticate all communication (client only) (not in CVS 1.9 and
+     older).  See *Note Global options::.
+
+`-b'
+     Specify RCS location (CVS 1.9 and older).  See *Note Global
+     options::.
+
+`-d ROOT'
+     Specify the CVSROOT.  See *Note Repository::.
+
+`-e EDITOR'
+     Edit messages with EDITOR.  See *Note Committing your changes::.
+
+`-f'
+     Do not read the `~/.cvsrc' file.  See *Note Global options::.
+
+`-H'
+`--help'
+     Print a help message.  See *Note Global options::.
+
+`-l'
+     Do not log in `$CVSROOT/CVSROOT/history' file.  See *Note Global
+     options::.
+
+`-n'
+     Do not change any files.  See *Note Global options::.
+
+`-Q'
+     Be really quiet.  See *Note Global options::.
+
+`-q'
+     Be somewhat quiet.  See *Note Global options::.
+
+`-r'
+     Make new working files read-only.  See *Note Global options::.
+
+`-s VARIABLE=VALUE'
+     Set a user variable.  See *Note Variables::.
+
+`-T TEMPDIR'
+     Put temporary files in TEMPDIR.  See *Note Global options::.
+
+`-t'
+     Trace CVS execution.  See *Note Global options::.
+
+`-v'
+
+`--version'
+     Display version and copyright information for CVS.
+
+`-w'
+     Make new working files read-write.  See *Note Global options::.
+
+`-x'
+     Encrypt all communication (client only).  See *Note Global
+     options::.
+
+`-z GZIP-LEVEL'
+     Set the compression level (client only).  See *Note Global
+     options::.
+
+   Keyword expansion modes (*note Substitution modes::):
+
+     -kkv  $Id: cvs.info-7,v 1.2 2001/09/29 00:00:39 tholo Exp $
+     -kkvl $Id: cvs.info-7,v 1.2 2001/09/29 00:00:39 tholo Exp $
+     -kk   $Id: cvs.info-7,v 1.2 2001/09/29 00:00:39 tholo Exp $
+     -kv   file1,v 1.1 1993/12/09 03:21:13 joe Exp
+     -ko   no expansion
+     -kb   no expansion, file is binary
+
+   Keywords (*note Keyword list::):
+
+     $Author: tholo $
+     $Date: 2001/09/29 00:00:39 $
+     $Header: /cvs/OpenBSD/src/gnu/usr.bin/cvs/doc/cvs.info-7,v 1.2 2001/09/29 00:00:39 tholo Exp $
+     $Id: cvs.info-7,v 1.2 2001/09/29 00:00:39 tholo Exp $
+     $Locker:  $
+     $Name:  $
+     $RCSfile: cvs.info-7,v $
+     $Revision: 1.2 $
+     $Source: /cvs/OpenBSD/src/gnu/usr.bin/cvs/doc/cvs.info-7,v $
+     $State: Exp $
+     $Log: cvs.info-7,v $
+     Revision 1.2  2001/09/29 00:00:39  tholo
+     Merge remaining local changes, correct build issues
+
+     Revision 1.1  1993/12/09 03:30:17  joe
+     Initial revision
+
+   Commands, command options, and command arguments:
+
+`add [OPTIONS] [FILES...]'
+     Add a new file/directory.  See *Note Adding files::.
+
+    `-k KFLAG'
+          Set keyword expansion.
+
+    `-m MSG'
+          Set file description.
+
+`admin [OPTIONS] [FILES...]'
+     Administration of history files in the repository.  See *Note
+     admin::.
+
+    `-b[REV]'
+          Set default branch.  See *Note Reverting local changes::.
+
+    `-cSTRING'
+          Set comment leader.
+
+    `-kSUBST'
+          Set keyword substitution.  See *Note Keyword substitution::.
+
+    `-l[REV]'
+          Lock revision REV, or latest revision.
+
+    `-mREV:MSG'
+          Replace the log message of revision REV with MSG.
+
+    `-oRANGE'
+          Delete revisions from the repository.  See *Note admin
+          options::.
+
+    `-q'
+          Run quietly; do not print diagnostics.
+
+    `-sSTATE[:REV]'
+          Set the state.
+
+    `-t'
+          Set file description from standard input.
+
+    `-tFILE'
+          Set file description from FILE.
+
+    `-t-STRING'
+          Set file description to STRING.
+
+    `-u[REV]'
+          Unlock revision REV, or latest revision.
+
+`annotate [OPTIONS] [FILES...]'
+     Show last revision where each line was modified.  See *Note
+     annotate::.
+
+    `-D DATE'
+          Annotate the most recent revision no later than DATE.  See
+          *Note Common options::.
+
+    `-f'
+          Use head revision if tag/date not found.  See *Note Common
+          options::.
+
+    `-l'
+          Local; run only in current working directory.  *Note
+          Recursive behavior::.
+
+    `-R'
+          Operate recursively (default).  *Note Recursive behavior::.
+
+    `-r TAG'
+          Annotate revision TAG.  See *Note Common options::.
+
+`checkout [OPTIONS] MODULES...'
+     Get a copy of the sources.  See *Note checkout::.
+
+    `-A'
+          Reset any sticky tags/date/options.  See *Note Sticky tags::
+          and *Note Keyword substitution::.
+
+    `-c'
+          Output the module database.  See *Note checkout options::.
+
+    `-D DATE'
+          Check out revisions as of DATE (is sticky).  See *Note Common
+          options::.
+
+    `-d DIR'
+          Check out into DIR.  See *Note checkout options::.
+
+    `-f'
+          Use head revision if tag/date not found.  See *Note Common
+          options::.
+
+    `-j REV'
+          Merge in changes.  See *Note checkout options::.
+
+    `-k KFLAG'
+          Use KFLAG keyword expansion.  See *Note Substitution modes::.
+
+    `-l'
+          Local; run only in current working directory.  *Note
+          Recursive behavior::.
+
+    `-N'
+          Don't "shorten" module paths if -d specified.  See *Note
+          checkout options::.
+
+    `-n'
+          Do not run module program (if any).  See *Note checkout
+          options::.
+
+    `-P'
+          Prune empty directories.  See *Note Moving directories::.
+
+    `-p'
+          Check out files to standard output (avoids stickiness).  See
+          *Note checkout options::.
+
+    `-R'
+          Operate recursively (default).  *Note Recursive behavior::.
+
+    `-r TAG'
+          Checkout revision TAG (is sticky).  See *Note Common
+          options::.
+
+    `-s'
+          Like -c, but include module status.  See *Note checkout
+          options::.
+
+`commit [OPTIONS] [FILES...]'
+     Check changes into the repository.  See *Note commit::.
+
+    `-F FILE'
+          Read log message from FILE.  See *Note commit options::.
+
+    `-f'
+          Force the file to be committed; disables recursion.  See
+          *Note commit options::.
+
+    `-l'
+          Local; run only in current working directory.  See *Note
+          Recursive behavior::.
+
+    `-m MSG'
+          Use MSG as log message.  See *Note commit options::.
+
+    `-n'
+          Do not run module program (if any).  See *Note commit
+          options::.
+
+    `-R'
+          Operate recursively (default).  *Note Recursive behavior::.
+
+    `-r REV'
+          Commit to REV.  See *Note commit options::.
+
+`diff [OPTIONS] [FILES...]'
+     Show differences between revisions.  See *Note diff::.  In
+     addition to the options shown below, accepts a wide variety of
+     options to control output style, for example `-c' for context
+     diffs.
+
+    `-D DATE1'
+          Diff revision for date against working file.  See *Note diff
+          options::.
+
+    `-D DATE2'
+          Diff REV1/DATE1 against DATE2.  See *Note diff options::.
+
+    `-l'
+          Local; run only in current working directory.  See *Note
+          Recursive behavior::.
+
+    `-N'
+          Include diffs for added and removed files.  See *Note diff
+          options::.
+
+    `-R'
+          Operate recursively (default).  *Note Recursive behavior::.
+
+    `-r REV1'
+          Diff revision for REV1 against working file.  See *Note diff
+          options::.
+
+    `-r REV2'
+          Diff REV1/DATE1 against REV2.  See *Note diff options::.
+
+`edit [OPTIONS] [FILES...]'
+     Get ready to edit a watched file.  See *Note Editing files::.
+
+    `-a ACTIONS'
+          Specify actions for temporary watch, where ACTIONS is `edit',
+          `unedit', `commit', `all', or `none'.  See *Note Editing
+          files::.
+
+    `-l'
+          Local; run only in current working directory.  See *Note
+          Recursive behavior::.
+
+    `-R'
+          Operate recursively (default).  *Note Recursive behavior::.
+
+`editors [OPTIONS] [FILES...]'
+     See who is editing a watched file.  See *Note Watch information::.
+
+    `-l'
+          Local; run only in current working directory.  See *Note
+          Recursive behavior::.
+
+    `-R'
+          Operate recursively (default).  *Note Recursive behavior::.
+
+`export [OPTIONS] MODULES...'
+     Export files from CVS.  See *Note export::.
+
+    `-D DATE'
+          Check out revisions as of DATE.  See *Note Common options::.
+
+    `-d DIR'
+          Check out into DIR.  See *Note export options::.
+
+    `-f'
+          Use head revision if tag/date not found.  See *Note Common
+          options::.
+
+    `-k KFLAG'
+          Use KFLAG keyword expansion.  See *Note Substitution modes::.
+
+    `-l'
+          Local; run only in current working directory.  *Note
+          Recursive behavior::.
+
+    `-N'
+          Don't "shorten" module paths if -d specified.  See *Note
+          export options::.
+
+    `-n'
+          Do not run module program (if any).  See *Note export
+          options::.
+
+    `-P'
+          Prune empty directories.  See *Note Moving directories::.
+
+    `-R'
+          Operate recursively (default).  *Note Recursive behavior::.
+
+    `-r TAG'
+          Checkout revision TAG.  See *Note Common options::.
+
+`history [OPTIONS] [FILES...]'
+     Show repository access history.  See *Note history::.
+
+    `-a'
+          All users (default is self).  See *Note history options::.
+
+    `-b STR'
+          Back to record with STR in module/file/repos field.  See
+          *Note history options::.
+
+    `-c'
+          Report on committed (modified) files.  See *Note history
+          options::.
+
+    `-D DATE'
+          Since DATE.  See *Note history options::.
+
+    `-e'
+          Report on all record types.  See *Note history options::.
+
+    `-l'
+          Last modified (committed or modified report).  See *Note
+          history options::.
+
+    `-m MODULE'
+          Report on MODULE (repeatable).  See *Note history options::.
+
+    `-n MODULE'
+          In MODULE.  See *Note history options::.
+
+    `-o'
+          Report on checked out modules.  See *Note history options::.
+
+    `-r REV'
+          Since revision REV.  See *Note history options::.
+
+    `-T'
+          Produce report on all TAGs.  See *Note history options::.
+
+    `-t TAG'
+          Since tag record placed in history file (by anyone).  See
+          *Note history options::.
+
+    `-u USER'
+          For user USER (repeatable).  See *Note history options::.
+
+    `-w'
+          Working directory must match.  See *Note history options::.
+
+    `-x TYPES'
+          Report on TYPES, one or more of `TOEFWUCGMAR'.  See *Note
+          history options::.
+
+    `-z ZONE'
+          Output for time zone ZONE.  See *Note history options::.
+
+`import [OPTIONS] REPOSITORY VENDOR-TAG RELEASE-TAGS...'
+     Import files into CVS, using vendor branches.  See *Note import::.
+
+    `-b BRA'
+          Import to vendor branch BRA.  See *Note Multiple vendor
+          branches::.
+
+    `-d'
+          Use the file's modification time as the time of import.  See
+          *Note import options::.
+
+    `-k KFLAG'
+          Set default keyword substitution mode.  See *Note import
+          options::.
+
+    `-m MSG'
+          Use MSG for log message.  See *Note import options::.
+
+    `-I IGN'
+          More files to ignore (! to reset).  See *Note import
+          options::.
+
+    `-W SPEC'
+          More wrappers.  See *Note import options::.
+
+`init'
+     Create a CVS repository if it doesn't exist.  See *Note Creating a
+     repository::.
+
+`log [OPTIONS] [FILES...]'
+     Print out history information for files.  See *Note log::.
+
+    `-b'
+          Only list revisions on the default branch.  See *Note log
+          options::.
+
+    `-d DATES'
+          Specify dates (D1<D2 for range, D for latest before).  See
+          *Note log options::.
+
+    `-h'
+          Only print header.  See *Note log options::.
+
+    `-l'
+          Local; run only in current working directory.  See *Note
+          Recursive behavior::.
+
+    `-N'
+          Do not list tags.  See *Note log options::.
+
+    `-R'
+          Only print name of RCS file.  See *Note log options::.
+
+    `-rREVS'
+          Only list revisions REVS.  See *Note log options::.
+
+    `-s STATES'
+          Only list revisions with specified states.  See *Note log
+          options::.
+
+    `-t'
+          Only print header and descriptive text.  See *Note log
+          options::.
+
+    `-wLOGINS'
+          Only list revisions checked in by specified logins.  See
+          *Note log options::.
+
+`login'
+     Prompt for password for authenticating server.  See *Note Password
+     authentication client::.
+
+`logout'
+     Remove stored password for authenticating server.  See *Note
+     Password authentication client::.
+
+`rdiff [OPTIONS] MODULES...'
+     Show differences between releases.  See *Note rdiff::.
+
+    `-c'
+          Context diff output format (default).  See *Note rdiff
+          options::.
+
+    `-D DATE'
+          Select revisions based on DATE.  See *Note Common options::.
+
+    `-f'
+          Use head revision if tag/date not found.  See *Note Common
+          options::.
+
+    `-l'
+          Local; run only in current working directory.  See *Note
+          Recursive behavior::.
+
+    `-R'
+          Operate recursively (default).  *Note Recursive behavior::.
+
+    `-r REV'
+          Select revisions based on REV.  See *Note Common options::.
+
+    `-s'
+          Short patch - one liner per file.  See *Note rdiff options::.
+
+    `-t'
+          Top two diffs - last change made to the file.  See *Note diff
+          options::.
+
+    `-u'
+          Unidiff output format.  See *Note rdiff options::.
+
+    `-V VERS'
+          Use RCS Version VERS for keyword expansion (obsolete).  See
+          *Note rdiff options::.
+
+`release [OPTIONS] DIRECTORY'
+     Indicate that a directory is no longer in use.  See *Note
+     release::.
+
+    `-d'
+          Delete the given directory.  See *Note release options::.
+
+`remove [OPTIONS] [FILES...]'
+     Remove an entry from the repository.  See *Note Removing files::.
+
+    `-f'
+          Delete the file before removing it.  See *Note Removing
+          files::.
+
+    `-l'
+          Local; run only in current working directory.  See *Note
+          Recursive behavior::.
+
+    `-R'
+          Operate recursively (default).  *Note Recursive behavior::.
+
+`rtag [OPTIONS] TAG MODULES...'
+     Add a symbolic tag to a module.  See *Note Revisions:: and *Note
+     Branching and merging::.
+
+    `-a'
+          Clear tag from removed files that would not otherwise be
+          tagged.  See *Note Tagging add/remove::.
+
+    `-b'
+          Create a branch named TAG.  See *Note Branching and merging::.
+
+    `-D DATE'
+          Tag revisions as of DATE.  See *Note Tagging by date/tag::.
+
+    `-d'
+          Delete TAG.  See *Note Modifying tags::.
+
+    `-F'
+          Move TAG if it already exists.  See *Note Modifying tags::.
+
+    `-f'
+          Force a head revision match if tag/date not found.  See *Note
+          Tagging by date/tag::.
+
+    `-l'
+          Local; run only in current working directory.  See *Note
+          Recursive behavior::.
+
+    `-n'
+          No execution of tag program.  See *Note Common options::.
+
+    `-R'
+          Operate recursively (default).  *Note Recursive behavior::.
+
+    `-r REV'
+          Tag existing tag REV.  See *Note Tagging by date/tag::.
+
+`status [OPTIONS] FILES...'
+     Display status information in a working directory.  See *Note File
+     status::.
+
+    `-l'
+          Local; run only in current working directory.  See *Note
+          Recursive behavior::.
+
+    `-R'
+          Operate recursively (default).  *Note Recursive behavior::.
+
+    `-v'
+          Include tag information for file.  See *Note Tags::.
+
+`tag [OPTIONS] TAG [FILES...]'
+     Add a symbolic tag to checked out version of files.  See *Note
+     Revisions:: and *Note Branching and merging::.
+
+    `-b'
+          Create a branch named TAG.  See *Note Branching and merging::.
+
+    `-c'
+          Check that working files are unmodified.  See *Note Tagging
+          the working directory::.
+
+    `-D DATE'
+          Tag revisions as of DATE.  See *Note Tagging by date/tag::.
+
+    `-d'
+          Delete TAG.  See *Note Modifying tags::.
+
+    `-F'
+          Move TAG if it already exists.  See *Note Modifying tags::.
+
+    `-f'
+          Force a head revision match if tag/date not found.  See *Note
+          Tagging by date/tag::.
+
+    `-l'
+          Local; run only in current working directory.  See *Note
+          Recursive behavior::.
+
+    `-R'
+          Operate recursively (default).  *Note Recursive behavior::.
+
+    `-r REV'
+          Tag existing tag REV.  See *Note Tagging by date/tag::.
+
+`unedit [OPTIONS] [FILES...]'
+     Undo an edit command.  See *Note Editing files::.
+
+    `-a ACTIONS'
+          Specify actions for temporary watch, where ACTIONS is `edit',
+          `unedit', `commit', `all', or `none'.  See *Note Editing
+          files::.
+
+    `-l'
+          Local; run only in current working directory.  See *Note
+          Recursive behavior::.
+
+    `-R'
+          Operate recursively (default).  *Note Recursive behavior::.
+
+`update [OPTIONS] [FILES...]'
+     Bring work tree in sync with repository.  See *Note update::.
+
+    `-A'
+          Reset any sticky tags/date/options.  See *Note Sticky tags::
+          and *Note Keyword substitution::.
+
+    `-C'
+          Overwrite locally modified files with clean copies from the
+          repository (the modified file is saved in `.#FILE.REVISION',
+          however).
+
+    `-D DATE'
+          Check out revisions as of DATE (is sticky).  See *Note Common
+          options::.
+
+    `-d'
+          Create directories.  See *Note update options::.
+
+    `-f'
+          Use head revision if tag/date not found.  See *Note Common
+          options::.
+
+    `-I IGN'
+          More files to ignore (! to reset).  See *Note import
+          options::.
+
+    `-j REV'
+          Merge in changes.  See *Note update options::.
+
+    `-k KFLAG'
+          Use KFLAG keyword expansion.  See *Note Substitution modes::.
+
+    `-l'
+          Local; run only in current working directory.  *Note
+          Recursive behavior::.
+
+    `-P'
+          Prune empty directories.  See *Note Moving directories::.
+
+    `-p'
+          Check out files to standard output (avoids stickiness).  See
+          *Note update options::.
+
+    `-R'
+          Operate recursively (default).  *Note Recursive behavior::.
+
+    `-r TAG'
+          Checkout revision TAG (is sticky).  See *Note Common
+          options::.
+
+    `-W SPEC'
+          More wrappers.  See *Note import options::.
+
+`version'
+     Display the version of CVS being used.  If the repository is
+     remote, display both the client and server versions.
+
+`watch [on|off|add|remove] [OPTIONS] [FILES...]'
+     on/off: turn on/off read-only checkouts of files.  See *Note
+     Setting a watch::.
+
+     add/remove: add or remove notification on actions.  See *Note
+     Getting Notified::.
+
+    `-a ACTIONS'
+          Specify actions for temporary watch, where ACTIONS is `edit',
+          `unedit', `commit', `all', or `none'.  See *Note Editing
+          files::.
+
+    `-l'
+          Local; run only in current working directory.  See *Note
+          Recursive behavior::.
+
+    `-R'
+          Operate recursively (default).  *Note Recursive behavior::.
+
+`watchers [OPTIONS] [FILES...]'
+     See who is watching a file.  See *Note Watch information::.
+
+    `-l'
+          Local; run only in current working directory.  See *Note
+          Recursive behavior::.
+
+    `-R'
+          Operate recursively (default).  *Note Recursive behavior::.
+
+
+File: cvs.info,  Node: Administrative files,  Next: Environment variables,  Prev: Invoking CVS,  Up: Top
+
+Reference manual for Administrative files
+*****************************************
+
+   Inside the repository, in the directory `$CVSROOT/CVSROOT', there
+are a number of supportive files for CVS.  You can use CVS in a limited
+fashion without any of them, but if they are set up properly they can
+help make life easier.  For a discussion of how to edit them, see *Note
+Intro administrative files::.
+
+   The most important of these files is the `modules' file, which
+defines the modules inside the repository.
+
+* Menu:
+
+* modules::                     Defining modules
+* Wrappers::                    Specify binary-ness based on file name
+* commit files::                The commit support files
+* commitinfo::                  Pre-commit checking
+* verifymsg::                   How are log messages evaluated?
+* editinfo::                    Specifying how log messages are created
+                                (obsolete)
+* loginfo::                     Where should log messages be sent?
+* rcsinfo::                     Templates for the log messages
+* cvsignore::                   Ignoring files via cvsignore
+* checkoutlist::                Adding your own administrative files
+* history file::                History information
+* Variables::                   Various variables are expanded
+* config::                      Miscellaneous CVS configuration
+
+
+File: cvs.info,  Node: modules,  Next: Wrappers,  Up: Administrative files
+
+The modules file
+================
+
+   The `modules' file records your definitions of names for collections
+of source code.  CVS will use these definitions if you use CVS to
+update the modules file (use normal commands like `add', `commit', etc).
+
+   The `modules' file may contain blank lines and comments (lines
+beginning with `#') as well as module definitions.  Long lines can be
+continued on the next line by specifying a backslash (`\') as the last
+character on the line.
+
+   There are three basic types of modules: alias modules, regular
+modules, and ampersand modules.  The difference between them is the way
+that they map files in the repository to files in the working
+directory.  In all of the following examples, the top-level repository
+contains a directory called `first-dir', which contains two files,
+`file1' and `file2', and a directory `sdir'.  `first-dir/sdir' contains
+a file `sfile'.
+
+* Menu:
+
+* Alias modules::             The simplest kind of module
+* Regular modules::
+* Ampersand modules::
+* Excluding directories::     Excluding directories from a module
+* Module options::            Regular and ampersand modules can take options
+* Module program options::    How the modules ``program options'' programs
+                              are run.
+
+
+File: cvs.info,  Node: Alias modules,  Next: Regular modules,  Up: modules
+
+Alias modules
+-------------
+
+   Alias modules are the simplest kind of module:
+
+`MNAME -a ALIASES...'
+     This represents the simplest way of defining a module MNAME.  The
+     `-a' flags the definition as a simple alias: CVS will treat any
+     use of MNAME (as a command argument) as if the list of names
+     ALIASES had been specified instead.  ALIASES may contain either
+     other module names or paths.  When you use paths in aliases,
+     `checkout' creates all intermediate directories in the working
+     directory, just as if the path had been specified explicitly in
+     the CVS arguments.
+
+   For example, if the modules file contains:
+
+     amodule -a first-dir
+
+then the following two commands are equivalent:
+
+     $ cvs co amodule
+     $ cvs co first-dir
+
+and they each would provide output such as:
+
+     cvs checkout: Updating first-dir
+     U first-dir/file1
+     U first-dir/file2
+     cvs checkout: Updating first-dir/sdir
+     U first-dir/sdir/sfile
+
+
+File: cvs.info,  Node: Regular modules,  Next: Ampersand modules,  Prev: Alias modules,  Up: modules
+
+Regular modules
+---------------
+
+`MNAME [ options ] DIR [ FILES... ]'
+     In the simplest case, this form of module definition reduces to
+     `MNAME DIR'.  This defines all the files in directory DIR as
+     module mname.  DIR is a relative path (from `$CVSROOT') to a
+     directory of source in the source repository.  In this case, on
+     checkout, a single directory called MNAME is created as a working
+     directory; no intermediate directory levels are used by default,
+     even if DIR was a path involving several directory levels.
+
+   For example, if a module is defined by:
+
+     regmodule first-dir
+
+then regmodule will contain the files from first-dir:
+
+     $ cvs co regmodule
+     cvs checkout: Updating regmodule
+     U regmodule/file1
+     U regmodule/file2
+     cvs checkout: Updating regmodule/sdir
+     U regmodule/sdir/sfile
+     $
+
+   By explicitly specifying files in the module definition after DIR,
+you can select particular files from directory DIR.  Here is an example:
+
+     regfiles first-dir/sdir sfile
+
+With this definition, getting the regfiles module will create a single
+working directory `regfiles' containing the file listed, which comes
+from a directory deeper in the CVS source repository:
+
+     $ cvs co regfiles
+     U regfiles/sfile
+     $
+
+
+File: cvs.info,  Node: Ampersand modules,  Next: Excluding directories,  Prev: Regular modules,  Up: modules
+
+Ampersand modules
+-----------------
+
+   A module definition can refer to other modules by including
+`&MODULE' in its definition.
+     MNAME [ options ] &MODULE...
+
+   Then getting the module creates a subdirectory for each such module,
+in the directory containing the module.  For example, if modules
+contains
+
+     ampermod &first-dir
+
+   then a checkout will create an `ampermod' directory which contains a
+directory called `first-dir', which in turns contains all the
+directories and files which live there.  For example, the command
+
+     $ cvs co ampermod
+
+will create the following files:
+
+     ampermod/first-dir/file1
+     ampermod/first-dir/file2
+     ampermod/first-dir/sdir/sfile
+
+   There is one quirk/bug: the messages that CVS prints omit the
+`ampermod', and thus do not correctly display the location to which it
+is checking out the files:
+
+     $ cvs co ampermod
+     cvs checkout: Updating first-dir
+     U first-dir/file1
+     U first-dir/file2
+     cvs checkout: Updating first-dir/sdir
+     U first-dir/sdir/sfile
+     $
+
+   Do not rely on this buggy behavior; it may get fixed in a future
+release of CVS.
+
+
+File: cvs.info,  Node: Excluding directories,  Next: Module options,  Prev: Ampersand modules,  Up: modules
+
+Excluding directories
+---------------------
+
+   An alias module may exclude particular directories from other
+modules by using an exclamation mark (`!') before the name of each
+directory to be excluded.
+
+   For example, if the modules file contains:
+
+     exmodule -a !first-dir/sdir first-dir
+
+   then checking out the module `exmodule' will check out everything in
+`first-dir' except any files in the subdirectory `first-dir/sdir'.
+
+
+File: cvs.info,  Node: Module options,  Next: Module program options,  Prev: Excluding directories,  Up: modules
+
+Module options
+--------------
+
+   Either regular modules or ampersand modules can contain options,
+which supply additional information concerning the module.
+
+`-d NAME'
+     Name the working directory something other than the module name.
+
+`-e PROG'
+     Specify a program PROG to run whenever files in a module are
+     exported.  PROG runs with a single argument, the module name.
+
+`-i PROG'
+     Specify a program PROG to run whenever files in a module are
+     committed.  PROG runs with a single argument, the full pathname of
+     the affected directory in a source repository.  The `commitinfo',
+     `loginfo', and `verifymsg' files provide other ways to call a
+     program on commit.
+
+`-o PROG'
+     Specify a program PROG to run whenever files in a module are
+     checked out.  PROG runs with a single argument, the module name.
+
+`-s STATUS'
+     Assign a status to the module.  When the module file is printed
+     with `cvs checkout -s' the modules are sorted according to
+     primarily module status, and secondarily according to the module
+     name.  This option has no other meaning.  You can use this option
+     for several things besides status: for instance, list the person
+     that is responsible for this module.
+
+`-t PROG'
+     Specify a program PROG to run whenever files in a module are
+     tagged with `rtag'.  PROG runs with two arguments: the module name
+     and the symbolic tag specified to `rtag'.  It is not run when
+     `tag' is executed.  Generally you will find that taginfo is a
+     better solution (*note user-defined logging::).
+
+`-u PROG'
+     Specify a program PROG to run whenever `cvs update' is executed
+     from the top-level directory of the checked-out module.  PROG runs
+     with a single argument, the full path to the source repository for
+     this module.
+
+   You should also see *note Module program options:: about how the
+"program options" programs are run.
+
+
+File: cvs.info,  Node: Module program options,  Prev: Module options,  Up: modules
+
+How the modules file "program options" programs are run
+-------------------------------------------------------
+
+For checkout, rtag, and export, the program is server-based, and as
+such the following applies:-
+
+   If using remote access methods (pserver, ext, etc.), CVS will
+execute this program on the server from a temporary directory. The path
+is searched for this program.
+
+   If using "local access" (on a local or remote NFS filesystem, i.e.
+repository set just to a path), the program will be executed from the
+newly checked-out tree, if found there, or alternatively searched for
+in the path if not.
+
+The commit and update programs are locally-based, and are run as
+follows:-
+
+   The program is always run locally. One must re-checkout the tree one
+is using if these options are updated in the modules administrative
+file. The file CVS/Checkin.prog contains the value of the option `-i'
+set in the modules file, and similarly for the file CVS/Update.prog and
+`-u'. The program is always executed from the top level of the
+checked-out copy on the client. Again, the program is first searched
+for in the checked-out copy and then using the path.
+
+   The programs are all run after the operation has effectively
+completed.
+
+
+File: cvs.info,  Node: Wrappers,  Next: commit files,  Prev: modules,  Up: Administrative files
+
+The cvswrappers file
+====================
+
+   Wrappers refers to a CVS feature which lets you control certain
+settings based on the name of the file which is being operated on.  The
+settings are `-k' for binary files, and `-m' for nonmergeable text
+files.
+
+   The `-m' option specifies the merge methodology that should be used
+when a non-binary file is updated.  `MERGE' means the usual CVS
+behavior: try to merge the files.  `COPY' means that `cvs update' will
+refuse to merge files, as it also does for files specified as binary
+with `-kb' (but if the file is specified as binary, there is no need to
+specify `-m 'COPY'').  CVS will provide the user with the two versions
+of the files, and require the user using mechanisms outside CVS, to
+insert any necessary changes.  *WARNING*: do not use `COPY' with CVS
+1.9 or earlier-such versions of CVS will copy one version of your file
+over the other, wiping out the previous contents.  The `-m' wrapper
+option only affects behavior when merging is done on update; it does
+not affect how files are stored.  See *Note Binary files::, for more on
+binary files.
+
+   The basic format of the file `cvswrappers' is:
+
+     wildcard     [option value][option value]...
      
-     You should have received a copy of the GNU General Public License
-     along with this program; if not, write to the Free Software
-     Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
-
-   Also add information on how to contact you by electronic and paper
-mail.
-
-   If the program is interactive, make it output a short notice like
-this when it starts in an interactive mode:
-
-     Gnomovision version 69, Copyright (C) 19YY NAME OF AUTHOR
-     Gnomovision comes with ABSOLUTELY NO WARRANTY; for details
-     type `show w'.
-     This is free software, and you are welcome to redistribute it
-     under certain conditions; type `show c' for details.
-
-   The hypothetical commands `show w' and `show c' should show the
-appropriate parts of the General Public License.  Of course, the
-commands you use may be called something other than `show w' and `show
-c'; they could even be mouse-clicks or menu items--whatever suits your
-program.
-
-   You should also get your employer (if you work as a programmer) or
-your school, if any, to sign a "copyright disclaimer" for the program,
-if necessary.  Here is a sample; alter the names:
-
-     Yoyodyne, Inc., hereby disclaims all copyright interest in the program
-     `Gnomovision' (which makes passes at compilers) written by James Hacker.
+     where option is one of
+     -m           update methodology      value: MERGE or COPY
+     -k           keyword expansion       value: expansion mode
      
-     SIGNATURE OF TY COON, 1 April 1989
-     Ty Coon, President of Vice
+     and value is a single-quote delimited value.
+
+   For example, the following command imports a directory, treating
+files whose name ends in `.exe' as binary:
+
+     cvs import -I ! -W "*.exe -k 'b'" first-dir vendortag reltag
 
-   This General Public License does not permit incorporating your
-program into proprietary programs.  If your program is a subroutine
-library, you may consider it more useful to permit linking proprietary
-applications with the library.  If this is what you want to do, use the
-GNU Library General Public License instead of this License.
+
+File: cvs.info,  Node: commit files,  Next: commitinfo,  Prev: Wrappers,  Up: Administrative files
+
+The commit support files
+========================
+
+   The `-i' flag in the `modules' file can be used to run a certain
+program whenever files are committed (*note modules::).  The files
+described in this section provide other, more flexible, ways to run
+programs whenever something is committed.
+
+   There are three 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.
+
+`commitinfo'
+     The program is responsible for checking that the commit is
+     allowed.  If it exits with a non-zero exit status the commit will
+     be aborted.
+
+`verifymsg'
+     The specified program is used to evaluate the log message, and
+     possibly verify that it contains all required fields.  This is
+     most useful in combination with the `rcsinfo' file, which can hold
+     a log message template (*note rcsinfo::).
+
+`editinfo'
+     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 `rcsinfo' file, which can hold
+     a log message template (*note rcsinfo::).  (obsolete)
+
+`loginfo'
+     The specified program is called when the commit is complete.  It
+     receives the log message and some additional information and can
+     store the log message in a file, or mail it to appropriate
+     persons, or maybe post it to a local newsgroup, or...  Your
+     imagination is the limit!
+
+* Menu:
+
+* syntax::                      The common syntax
+
+
+File: cvs.info,  Node: syntax,  Up: commit files
+
+The common syntax
+-----------------
+
+   The administrative files such as `commitinfo', `loginfo', `rcsinfo',
+`verifymsg', etc., all have a common format.  The purpose of the files
+are described later on.  The common syntax is described here.
+
+   Each line contains the following:
+   * A regular expression.  This is a basic regular expression in the
+     syntax used by GNU emacs.
+
+   * A whitespace separator--one or more spaces and/or tabs.
+
+   * A file name or command-line template.
+
+Blank lines are ignored.  Lines that start with the character `#' are
+treated as comments.  Long lines unfortunately can _not_ be broken in
+two parts in any way.
+
+   The first regular expression that matches the current directory name
+in the repository is used.  The rest of the line is used as a file name
+or command-line as appropriate.
+
+
+File: cvs.info,  Node: commitinfo,  Next: verifymsg,  Prev: commit files,  Up: Administrative files
+
+Commitinfo
+==========
+
+   The `commitinfo' file defines programs to execute whenever `cvs
+commit' is about to execute.  These programs are used for pre-commit
+checking to verify that the modified, added and removed files are really
+ready to be committed.  This could be used, for instance, to verify
+that the changed files conform to to your site's standards for coding
+practice.
+
+   As mentioned earlier, each line in the `commitinfo' 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).
+
+   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.
+
+   If the repository name does not match any of the regular expressions
+in this file, the `DEFAULT' line is used, if it is specified.
+
+   All occurrences of the name `ALL' appearing as a regular expression
+are used in addition to the first matching regular expression or the
+name `DEFAULT'.
+
+   Note: when CVS is accessing a remote repository, `commitinfo' will
+be run on the _remote_ (i.e., server) side, not the client side (*note
+Remote repositories::).
+
+
+File: cvs.info,  Node: verifymsg,  Next: editinfo,  Prev: commitinfo,  Up: Administrative files
+
+Verifying log messages
+======================
+
+   Once you have entered a log message, you can evaluate that message
+to check for specific content, such as a bug ID.  Use the `verifymsg'
+file to specify a program that is used to verify the log message.  This
+program could be a simple script that checks that the entered message
+contains the required fields.
+
+   The `verifymsg' file is often most useful together with the
+`rcsinfo' file, which can be used to specify a log message template.
+
+   Each line in the `verifymsg' 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.
+
+   One thing that should be noted is that the `ALL' keyword is not
+supported.  If more than one matching line is found, the first one is
+used.  This can be useful for specifying a default verification script
+in a directory, and then overriding it in a subdirectory.
+
+   If the repository name does not match any of the regular expressions
+in this file, the `DEFAULT' line is used, if it is specified.
+
+   If the verification script exits with a non-zero exit status, the
+commit is aborted.
+
+   Note that the verification script cannot change the log message; it
+can merely accept it or reject it.
+
+   The following is a little silly example of a `verifymsg' file,
+together with the corresponding `rcsinfo' 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 `/usr/cvssupport/tc.template'.
+
+     BugId:
+
+   The script `/usr/cvssupport/bugid.verify' is used to evaluate the
+log message.
+
+     #!/bin/sh
+     #
+     #       bugid.verify filename
+     #
+     #  Verify that the log message contains a valid bugid
+     #  on the first line.
+     #
+     if head -1 < $1 | grep '^BugId:[ ]*[0-9][0-9]*$' > /dev/null; then
+         exit 0
+     else
+         echo "No BugId found."
+         exit 1
+     fi
+
+   The `verifymsg' file contains this line:
+
+     ^tc     /usr/cvssupport/bugid.verify
+
+   The `rcsinfo' file contains this line:
+
+     ^tc     /usr/cvssupport/tc.template
 
 
-File: cvs.info,  Node: Index,  Prev: Copying,  Up: Top
+File: cvs.info,  Node: editinfo,  Next: loginfo,  Prev: verifymsg,  Up: Administrative files
+
+Editinfo
+========
+
+   _NOTE:_ The `editinfo' feature has been rendered obsolete.  To set a
+default editor for log messages use the `EDITOR' environment variable
+(*note Environment variables::) or the `-e' global option (*note Global
+options::).  See *Note verifymsg::, for information on the use of the
+`verifymsg' feature for evaluating log messages.
+
+   If you want to make sure that all log messages look the same way,
+you can use the `editinfo' 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.
+
+   If no matching line is found in the `editinfo' file, the editor
+specified in the environment variable `$CVSEDITOR' is used instead.  If
+that variable is not set, then the environment variable `$EDITOR' is
+used instead.  If that variable is not set a default will be used.  See
+*Note Committing your changes::.
+
+   The `editinfo' file is often most useful together with the `rcsinfo'
+file, which can be used to specify a log message template.
+
+   Each line in the `editinfo' 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.
+
+   One thing that should be noted is that the `ALL' keyword is not
+supported.  If more than one matching line is found, the first one is
+used.  This can be useful for specifying a default edit script in a
+module, and then overriding it in a subdirectory.
 
-Index
-*****
+   If the repository name does not match any of the regular expressions
+in this file, the `DEFAULT' line is used, if it is specified.
+
+   If the edit script exits with a non-zero exit status, the commit is
+aborted.
+
+   Note: when CVS is accessing a remote repository, or when the `-m' or
+`-F' options to `cvs commit' are used, `editinfo' will not be consulted.
+There is no good workaround for this; use `verifymsg' instead.
 
 * Menu:
 
-* -j (merging branches):                Merging a branch.
-* -k (RCS kflags):                      Substitution modes.
-* .# files:                             update output.
-* .bashrc, setting CVSROOT in:          Specifying a repository.
-* .cshrc, setting CVSROOT in:           Specifying a repository.
-* .cvsrc file:                          ~/.cvsrc.
-* .profile, setting CVSROOT in:         Specifying a repository.
-* .tcshrc, setting CVSROOT in:          Specifying a repository.
-* /usr/local/cvsroot, as example repository: Repository.
-* :ext::                                Connecting via rsh.
-* :kserver::                            Kerberos authenticated.
-* :local::                              Repository.
-* :pserver::                            Password authentication client.
-* :server::                             Connecting via rsh.
-* <<<<<<<:                              Conflicts example.
-* =======:                              Conflicts example.
-* >>>>>>>:                              Conflicts example.
-* __ files (VMS):                       update output.
-* A sample session:                     A sample session.
-* abandoning work:                      Editing files.
-* About this manual:                    Preface.
-* add (subcommand):                     Adding files.
-* Adding a tag:                         Tags.
-* Adding files:                         Adding files.
-* Admin (subcommand):                   admin.
-* Administrative files (intro):         Intro administrative files.
-* Administrative files (reference):     Administrative files.
-* Administrative files, editing them:   Intro administrative files.
-* ALL in commitinfo:                    commitinfo.
-* annotate (subcommand):                annotate.
-* Atomic transactions, lack of:         Concurrency.
-* authenticated client, using:          Password authentication client.
-* authenticating server, setting up:    Password authentication server.
-* Author keyword:                       Keyword list.
-* Automatically ignored files:          cvsignore.
-* Avoiding editor invocation:           Common options.
-* bill of materials:                    Builds.
-* Binary files:                         Binary files.
-* Branch merge example:                 Merging a branch.
-* Branch number:                        Revision numbers.
-* Branch numbers:                       Creating a branch.
-* Branch, creating a:                   Creating a branch.
-* Branch, vendor-:                      Tracking sources.
-* Branches:                             Branches.
-* Branches motivation:                  Branches motivation.
-* Branches, copying changes between:    Merging.
-* Branches, sticky:                     Sticky tags.
-* Bringing a file up to date:           Updating a file.
-* Bugs, known in this manual:           BUGS.
-* Bugs, reporting (CVS):                What is CVS?.
-* Bugs, reporting (manual):             BUGS.
-* builds:                               Builds.
-* Changes, copying between branches:    Merging.
-* Changing a log message:               admin options.
-* checked out copy, keeping:            Keeping a checked out copy.
-* Checkin program:                      modules.
-* Checking commits:                     commitinfo.
-* Checking out source:                  Getting the source.
-* Checkout (subcommand):                checkout.
-* Checkout program:                     modules.
-* checkout, as term for getting ready to edit: Editing files.
-* Checkout, example:                    Getting the source.
-* choosing, reserved or unreserved checkouts: Choosing a model.
-* Cleaning up:                          Cleaning up.
-* Client/Server Operation:              Remote repositories.
-* Co (subcommand):                      checkout.
-* Command reference:                    Invoking CVS.
-* Command structure:                    Structure.
-* Comment leader:                       admin examples.
-* Commit (subcommand):                  commit.
-* Commit files:                         commit files.
-* Commit, when to:                      When to commit.
-* Commitinfo:                           commitinfo.
-* Committing changes:                   Committing your changes.
-* Common options:                       Common options.
-* Common syntax of info files:          syntax.
-* compatibility, between CVS versions:  Compatibility.
-* COMSPEC:                              Environment variables.
-* Conflict markers:                     Conflicts example.
-* Conflict resolution:                  Conflicts example.
-* Conflicts (merge example):            Conflicts example.
-* Contributors (CVS program):           What is CVS?.
-* Contributors (manual):                Credits.
-* Copying changes:                      Merging.
-* Correcting a log message:             admin options.
-* Creating a branch:                    Creating a branch.
-* Creating a project:                   Starting a new project.
-* Creating a repository:                Creating a repository.
-* Credits (CVS program):                What is CVS?.
-* Credits (manual):                     Credits.
-* CVS 1.6, and watches:                 Watches Compatibility.
-* CVS command structure:                Structure.
-* CVS passwd file:                      Password authentication server.
-* CVS, history of:                      What is CVS?.
-* CVS, introduction to:                 What is CVS?.
-* CVS, versions of:                     Compatibility.
-* CVS_CLIENT_LOG:                       Environment variables.
-* CVS_CLIENT_PORT:                      Kerberos authenticated.
-* CVS_IGNORE_REMOTE_ROOT:               Environment variables.
-* CVS_PASSFILE, environment variable:   Password authentication client.
-* CVS_RCMD_PORT:                        Environment variables.
-* CVS_RSH:                              Environment variables.
-* CVS_SERVER:                           Connecting via rsh.
-* CVS_SERVER_SLEEP:                     Environment variables.
-* CVSEDITOR:                            Environment variables.
-* CVSEDITOR, environment variable:      Committing your changes.
-* CVSIGNORE:                            Environment variables.
-* cvsignore (admin file), global:       cvsignore.
-* CVSREAD:                              Environment variables.
-* CVSREAD, overriding:                  Global options.
-* CVSROOT:                              Environment variables.
-* cvsroot:                              Repository.
-* CVSROOT (file):                       Administrative files.
-* CVSROOT, environment variable:        Specifying a repository.
-* CVSROOT, module name:                 Intro administrative files.
-* CVSROOT, multiple repositories:       Multiple repositories.
-* CVSROOT, overriding:                  Global options.
-* CVSUMASK:                             File permissions.
-* CVSWRAPPERS:                          Environment variables.
-* cvswrappers (admin file):             Wrappers.
-* CVSWRAPPERS, environment variable:    Wrappers.
-* Date keyword:                         Keyword list.
-* Dates:                                Common options.
-* Decimal revision number:              Revision numbers.
-* DEFAULT in commitinfo:                commitinfo.
-* DEFAULT in editinfo:                  editinfo.
-* DEFAULT in verifymsg:                 verifymsg.
-* Defining a module:                    Defining the module.
-* Defining modules (intro):             Intro administrative files.
-* Defining modules (reference manual):  modules.
-* Deleting files:                       Removing files.
-* Deleting revisions:                   admin options.
-* Deleting sticky tags:                 Sticky tags.
-* Descending directories:               Recursive behavior.
-* Diff:                                 Viewing differences.
-* Diff (subcommand):                    diff.
-* Differences, merging:                 Merging two revisions.
-* Directories, moving:                  Moving directories.
-* directories, removing:                Removing directories.
-* Directory, descending:                Recursive behavior.
-* Disjoint repositories:                Multiple repositories.
-* Distributing log messages:            loginfo.
-* driver.c (merge example):             Conflicts example.
-* edit (subcommand):                    Editing files.
-* editinfo (admin file):                editinfo.
-* Editing administrative files:         Intro administrative files.
-* Editing the modules file:             Defining the module.
-* EDITOR:                               Environment variables.
-* Editor, avoiding invocation of:       Common options.
-* EDITOR, environment variable:         Committing your changes.
-* EDITOR, overriding:                   Global options.
-* Editor, specifying per module:        editinfo.
-* editors (subcommand):                 Watch information.
-* emerge:                               Conflicts example.
-* Environment variables:                Environment variables.
-* Errors, reporting (CVS):              What is CVS?.
-* Errors, reporting (manual):           BUGS.
-* Example of a work-session:            A sample session.
-* Example of merge:                     Conflicts example.
-* Example, branch merge:                Merging a branch.
-* Export (subcommand):                  export.
-* Export program:                       modules.
-* Fetching source:                      Getting the source.
-* File locking:                         Multiple developers.
-* File permissions:                     File permissions.
-* File status:                          File status.
-* Files, moving:                        Moving files.
-* Files, reference manual:              Administrative files.
-* Fixing a log message:                 admin options.
-* Forcing a tag match:                  Common options.
-* Form for log message:                 rcsinfo.
-* Format of CVS commands:               Structure.
-* Getting started:                      A sample session.
-* Getting the source:                   Getting the source.
-* Global cvsignore:                     cvsignore.
-* Global options:                       Global options.
-* Group:                                File permissions.
-* Header keyword:                       Keyword list.
-* History (subcommand):                 history.
-* History browsing:                     History browsing.
-* History file:                         history file.
-* History files:                        Repository files.
-* History of CVS:                       What is CVS?.
-* HOME:                                 Environment variables.
-* HOMEPATH:                             Environment variables.
-* Id keyword:                           Keyword list.
-* Ident (shell command):                Using keywords.
-* Identifying files:                    Keyword substitution.
-* Ignored files:                        cvsignore.
-* Ignoring files:                       cvsignore.
-* Import (subcommand):                  import.
-* Importing files:                      From files.
-* Importing files, from other version control systesm: From other version control systems.
-* Importing modules:                    First import.
-* Index:                                Index.
-* Info files (syntax):                  syntax.
-* Informing others:                     Informing others.
-* init (subcommand):                    Creating a repository.
-* Introduction to CVS:                  What is CVS?.
-* Invoking CVS:                         Invoking CVS.
-* Isolation:                            History browsing.
-* Join:                                 Merging a branch.
-* keeping a checked out copy:           Keeping a checked out copy.
-* kerberos:                             Kerberos authenticated.
-* Keyword expansion:                    Keyword substitution.
-* Keyword substitution:                 Keyword substitution.
-* Kflag:                                Substitution modes.
-* kinit:                                Kerberos authenticated.
-* Known bugs in this manual:            BUGS.
-* Layout of repository:                 Repository.
-* Left-hand options:                    Global options.
-* Linear development:                   Revision numbers.
-* List, mailing list:                   What is CVS?.
-* Locally Added:                        File status.
-* Locally Modified:                     File status.
-* Locally Removed:                      File status.
-* Locker keyword:                       Keyword list.
-* Locking files:                        Multiple developers.
-* locks, cvs:                           Concurrency.
-* Log (subcommand):                     log.
-* Log information, saving:              history file.
-* Log keyword:                          Keyword list.
-* Log keyword, selecting comment leader: admin examples.
-* Log message entry:                    Committing your changes.
-* Log message template:                 rcsinfo.
-* Log message, correcting:              admin options.
-* log message, verifying:               verifymsg.
-* Log messages:                         loginfo.
-* Log messages, editing:                editinfo.
-* Login (subcommand):                   Password authentication client.
-* loginfo (admin file):                 loginfo.
-* LOGNAME:                              Environment variables.
-* Mail, automatic mail on commit:       Informing others.
-* Mailing list:                         What is CVS?.
-* Mailing log messages:                 loginfo.
-* Main trunk (intro):                   Revision numbers.
-* Main trunk and branches:              Branches.
-* make:                                 Builds.
-* Many repositories:                    Multiple repositories.
-* Markers, conflict:                    Conflicts example.
-* Merge, an example:                    Conflicts example.
-* Merge, branch example:                Merging a branch.
-* Merging:                              Merging.
-* Merging a branch:                     Merging a branch.
-* Merging a file:                       Updating a file.
-* Merging two revisions:                Merging two revisions.
-* Modifications, copying between branches: Merging.
-* Module status:                        modules.
-* Module, defining:                     Defining the module.
-* Modules (admin file):                 modules.
-* Modules (intro):                      Basic concepts.
-* Modules file:                         Intro administrative files.
-* Modules file, changing:               Defining the module.
-* Motivation for branches:              Branches motivation.
-* Moving directories:                   Moving directories.
-* Moving files:                         Moving files.
-* Multiple developers:                  Multiple developers.
-* Multiple repositories:                Multiple repositories.
-* Name keyword:                         Keyword list.
-* Name, symbolic (tag):                 Tags.
-* Needs Checkout:                       File status.
-* Needs Merge:                          File status.
-* Needs Patch:                          File status.
-* Newsgroups:                           What is CVS?.
-* notify (admin file):                  Getting Notified.
-* Nroff (selecting comment leader):     admin examples.
-* Number, branch:                       Revision numbers.
-* Number, revision-:                    Revision numbers.
-* option defaults:                      ~/.cvsrc.
-* Options, global:                      Global options.
-* Outdating revisions:                  admin options.
-* Overlap:                              Updating a file.
-* Overriding CVSREAD:                   Global options.
-* Overriding CVSROOT:                   Global options.
-* Overriding EDITOR:                    Global options.
-* Overriding RCSBIN:                    Global options.
-* Overriding TMPDIR:                    Global options.
-* Parallel repositories:                Multiple repositories.
-* passwd (admin file):                  Password authentication server.
-* password client, using:               Password authentication client.
-* password server, setting up:          Password authentication server.
-* PATH:                                 Environment variables.
-* Per-module editor:                    editinfo.
-* Policy:                               When to commit.
-* Precommit checking:                   commitinfo.
-* Preface:                              Preface.
-* Pserver (subcommand):                 Password authentication server.
-* RCS history files:                    Repository files.
-* RCS keywords:                         Keyword list.
-* RCS revision numbers:                 Tags.
-* RCS, importing files from:            From other version control systems.
-* RCS-style locking:                    Multiple developers.
-* RCSBIN:                               Environment variables.
-* RCSBIN, overriding:                   Global options.
-* RCSfile keyword:                      Keyword list.
-* rcsinfo (admin file):                 rcsinfo.
-* RCSINIT:                              Environment variables.
-* Rdiff (subcommand):                   rdiff.
-* read-only files, and -r:              Global options.
-* read-only files, and CVSREAD:         Environment variables.
-* read-only files, and watches:         Setting a watch.
-* read-only files, in repository:       File permissions.
-* Read-only mode:                       Global options.
-* read-only repository access:          Read-only access.
-* readers (admin file):                 Read-only access.
-* Recursive (directory descending):     Recursive behavior.
-* Reference manual (files):             Administrative files.
-* Reference manual for variables:       Environment variables.
-* Reference, commands:                  Invoking CVS.
-* regular expression syntax:            syntax.
-* Release (subcommand):                 release.
-* Releases, revisions and versions:     Versions revisions releases.
-* Releasing your working copy:          Cleaning up.
-* Remote repositories:                  Remote repositories.
-* Remove (subcommand):                  Removing files.
-* Removing a change:                    Merging two revisions.
-* removing directories:                 Removing directories.
-* Removing files:                       Removing files.
-* Removing your working copy:           Cleaning up.
-* Renaming directories:                 Moving directories.
-* Renaming files:                       Moving files.
-* Replacing a log message:              admin options.
-* Reporting bugs (CVS):                 What is CVS?.
-* Reporting bugs (manual):              BUGS.
-* Repositories, multiple:               Multiple repositories.
-* Repositories, remote:                 Remote repositories.
-* Repository (intro):                   Repository.
-* Repository, example:                  Repository.
-* Repository, how data is stored:       Repository storage.
-* Repository, setting up:               Creating a repository.
-* reserved checkouts:                   Multiple developers.
-* Resetting sticky tags:                Sticky tags.
-* Resolving a conflict:                 Conflicts example.
-* Restoring old version of removed file: Sticky tags.
-* Resurrecting old version of dead file: Sticky tags.
-* Retrieving an old revision using tags: Tags.
-* reverting to repository version:      Editing files.
-* Revision keyword:                     Keyword list.
-* Revision management:                  Revision management.
-* Revision numbers:                     Revision numbers.
-* Revision tree:                        Revision numbers.
-* Revision tree, making branches:       Branches.
-* Revisions, merging differences between: Merging two revisions.
-* Revisions, versions and releases:     Versions revisions releases.
-* Right-hand options:                   Common options.
-* rsh:                                  Connecting via rsh.
-* Rtag (subcommand):                    rtag.
-* rtag, creating a branch using:        Creating a branch.
-* Saving space:                         admin options.
-* SCCS, importing files from:           From other version control systems.
-* Security:                             File permissions.
-* server, CVS:                          Remote repositories.
-* setgid:                               File permissions.
-* Setting up a repository:              Creating a repository.
-* setuid:                               File permissions.
-* Signum Support:                       Preface.
-* Source keyword:                       Keyword list.
-* Source, getting CVS source:           What is CVS?.
-* Source, getting from CVS:             Getting the source.
-* Specifying dates:                     Common options.
-* Spreading information:                Informing others.
-* Starting a project with CVS:          Starting a new project.
-* State keyword:                        Keyword list.
-* Status (subcommand):                  status.
-* Status of a file:                     File status.
-* Status of a module:                   modules.
-* sticky date:                          Sticky tags.
-* Sticky tags:                          Sticky tags.
-* Sticky tags, resetting:               Sticky tags.
-* Storing log messages:                 loginfo.
-* Structure:                            Structure.
-* Subdirectories:                       Recursive behavior.
-* Support, getting CVS support:         Preface.
-* Symbolic name (tag):                  Tags.
-* Syntax of info files:                 syntax.
-* Tag (subcommand):                     tag.
-* Tag program:                          modules.
-* tag, command, introduction:           Tags.
-* tag, example:                         Tags.
-* Tag, retrieving old revisions:        Tags.
-* Tag, symbolic name:                   Tags.
-* taginfo:                              user-defined logging.
-* Tags:                                 Tags.
-* Tags, sticky:                         Sticky tags.
-* tc, Trivial Compiler (example):       A sample session.
-* Team of developers:                   Multiple developers.
-* TEMP:                                 Environment variables.
-* Template for log message:             rcsinfo.
-* temporary files, location of:         Environment variables.
-* Third-party sources:                  Tracking sources.
-* Time:                                 Common options.
-* timezone, in input:                   Common options.
-* timezone, in output:                  log.
-* TMP:                                  Environment variables.
-* TMPDIR:                               Environment variables.
-* TMPDIR, overriding:                   Global options.
-* Trace:                                Global options.
-* Traceability:                         History browsing.
-* Tracking sources:                     Tracking sources.
-* Transactions, atomic, lack of:        Concurrency.
-* Trivial Compiler (example):           A sample session.
-* Typical repository:                   Repository.
-* umask, for repository files:          File permissions.
-* Undoing a change:                     Merging two revisions.
-* unedit (subcommand):                  Editing files.
-* Unknown:                              File status.
-* unreserved checkouts:                 Multiple developers.
-* Unresolved Conflict:                  File status.
-* Up-to-date:                           File status.
-* Update (subcommand):                  update.
-* Update program:                       modules.
-* update, introduction:                 Updating a file.
-* Updating a file:                      Updating a file.
-* USER:                                 Environment variables.
-* user aliases:                         Password authentication server.
-* users (admin file):                   Getting Notified.
-* Vendor:                               Tracking sources.
-* Vendor branch:                        Tracking sources.
-* verifymsg (admin file):               verifymsg.
-* versions, of CVS:                     Compatibility.
-* Versions, revisions and releases:     Versions revisions releases.
-* Viewing differences:                  Viewing differences.
-* watch add (subcommand):               Getting Notified.
-* watch off (subcommand):               Setting a watch.
-* watch on (subcommand):                Setting a watch.
-* watch remove (subcommand):            Getting Notified.
-* watchers (subcommand):                Watch information.
-* Watches:                              Watches.
-* Wdiff (import example):               First import.
-* What (shell command):                 Using keywords.
-* What branches are good for:           Branches motivation.
-* What is CVS?:                         What is CVS?.
-* When to commit:                       When to commit.
-* Work-session, example of:             A sample session.
-* Working copy:                         Multiple developers.
-* Working copy, removing:               Cleaning up.
-* Wrappers:                             Wrappers.
-* writers (admin file):                 Read-only access.
-* zone, time, in input:                 Common options.
-* zone, time, in output:                log.
+* editinfo example::            Editinfo example
+
+
+File: cvs.info,  Node: editinfo example,  Up: editinfo
+
+Editinfo example
+----------------
+
+   The following is a little silly example of a `editinfo' file,
+together with the corresponding `rcsinfo' 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 `/usr/cvssupport/tc.template'.
+
+     BugId:
+
+   The script `/usr/cvssupport/bugid.edit' is used to edit the log
+message.
+
+     #!/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
+
+   The `editinfo' file contains this line:
+
+     ^tc     /usr/cvssupport/bugid.edit
+
+   The `rcsinfo' file contains this line:
+
+     ^tc     /usr/cvssupport/tc.template
+
+
+File: cvs.info,  Node: loginfo,  Next: rcsinfo,  Prev: editinfo,  Up: Administrative files
+
+Loginfo
+=======
+
+   The `loginfo' file is used to control where `cvs commit' 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 `$CVSROOT'.  If a match is found, then the remainder of
+the line is a filter program that should expect log information on its
+standard input.
+
+   If the repository name does not match any of the regular expressions
+in this file, the `DEFAULT' line is used, if it is specified.
+
+   All occurrences of the name `ALL' appearing as a regular expression
+are used in addition to the first matching regular expression or
+`DEFAULT'.
+
+   The first matching regular expression is used.
+
+   *Note commit files::, for a description of the syntax of the
+`loginfo' file.
+
+   The user may specify a format string as part of the filter.  The
+string is composed of a `%' followed by a space, or followed by a single
+format character, or followed by a set of format characters surrounded
+by `{' and `}' as separators.  The format characters are:
+
+s
+     file name
+
+V
+     old version number (pre-checkin)
+
+v
+     new version number (post-checkin)
+
+   All other characters that appear in a format string expand to an
+empty field (commas separating fields are still provided).
+
+   For example, some valid format strings are `%', `%s', `%{s}', and
+`%{sVv}'.
+
+   The output will be a string of tokens separated by spaces.  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
+`/u/src/master/yoyodyne/tc' is the repository, `%{sVv}' is the format
+string, and three files (ChangeLog, Makefile, foo.c) were modified, the
+output might be:
+
+     yoyodyne/tc ChangeLog,1.1,1.2 Makefile,1.3,1.4 foo.c,1.12,1.13
+
+   As another example, `%{}' means that only the name of the repository
+will be generated.
+
+   Note: when CVS is accessing a remote repository, `loginfo' will be
+run on the _remote_ (i.e., server) side, not the client side (*note
+Remote repositories::).
+
+* Menu:
+
+* loginfo example::             Loginfo example
+* Keeping a checked out copy::  Updating a tree on every checkin
+
+
+File: cvs.info,  Node: loginfo example,  Next: Keeping a checked out copy,  Up: loginfo
+
+Loginfo example
+---------------
+
+   The following `loginfo' file, together with the tiny shell-script
+below, appends all log messages to the file
+`$CVSROOT/CVSROOT/commitlog', and any commits to the administrative
+files (inside the `CVSROOT' directory) are also logged in
+`/usr/adm/cvsroot-log'.  Commits to the `prog1' directory are mailed to
+ceder.
+
+     ALL             /usr/local/bin/cvs-log $CVSROOT/CVSROOT/commitlog $USER
+     ^CVSROOT        /usr/local/bin/cvs-log /usr/adm/cvsroot-log
+     ^prog1          Mail -s %s ceder
+
+   The shell-script `/usr/local/bin/cvs-log' looks like this:
+
+     #!/bin/sh
+     (echo "------------------------------------------------------";
+      echo -n $2"  ";
+      date;
+      echo;
+      cat) >> $1
+
+
+File: cvs.info,  Node: Keeping a checked out copy,  Prev: loginfo example,  Up: loginfo
+
+Keeping a checked out copy
+--------------------------
+
+   It is often useful to maintain a directory tree which contains files
+which correspond to the latest version in the repository.  For example,
+other developers might want to refer to the latest sources without
+having to check them out, or you might be maintaining a web site with
+CVS and want every checkin to cause the files used by the web server to
+be updated.
+
+   The way to do this is by having loginfo invoke `cvs update'.  Doing
+so in the naive way will cause a problem with locks, so the `cvs update'
+must be run in the background.  Here is an example for unix (this
+should all be on one line):
+
+     ^cyclic-pages		(date; cat; (sleep 2; cd /u/www/local-docs;
+      cvs -q update -d) &) >> $CVSROOT/CVSROOT/updatelog 2>&1
+
+   This will cause checkins to repository directories starting with
+`cyclic-pages' to update the checked out tree in `/u/www/local-docs'.
+
+
+File: cvs.info,  Node: rcsinfo,  Next: cvsignore,  Prev: loginfo,  Up: Administrative files
+
+Rcsinfo
+=======
+
+   The `rcsinfo' file can be used to specify a form to edit when
+filling out the commit log.  The `rcsinfo' file has a syntax similar to
+the `verifymsg', `commitinfo' and `loginfo' files.  *Note syntax::.
+Unlike the other files the second part is _not_ a command-line
+template.  Instead, the part after the regular expression should be a
+full pathname to a file containing the log message template.
+
+   If the repository name does not match any of the regular expressions
+in this file, the `DEFAULT' line is used, if it is specified.
+
+   All occurrences of the name `ALL' appearing as a regular expression
+are used in addition to the first matching regular expression or
+`DEFAULT'.
+
+   The log message template will be used as a default log message.  If
+you specify a log message with `cvs commit -m MESSAGE' or `cvs commit -f
+FILE' that log message will override the template.
+
+   *Note verifymsg::, for an example `rcsinfo' file.
 
+   When CVS is accessing a remote repository, the contents of `rcsinfo'
+at the time a directory is first checked out will specify a template
+which does not then change.  If you edit `rcsinfo' or its templates,
+you may need to check out a new working directory.
 
diff --git a/gnu/usr.bin/cvs/doc/cvs.info-9 b/gnu/usr.bin/cvs/doc/cvs.info-9
index 64931cb0e91..3b644fe1ce9 100644
--- a/gnu/usr.bin/cvs/doc/cvs.info-9
+++ b/gnu/usr.bin/cvs/doc/cvs.info-9
@@ -1,5 +1,8 @@
-This is Info file cvs.info, produced by Makeinfo-1.64 from the input
-file ../../work/ccvs/doc/cvs.texinfo.
+This is cvs.info, produced by makeinfo version 4.0 from cvs.texinfo.
+
+START-INFO-DIR-ENTRY
+* CVS: (cvs).          Concurrent Versions System
+END-INFO-DIR-ENTRY
 
    Copyright (C) 1992, 1993 Signum Support AB Copyright (C) 1993, 1994
 Free Software Foundation, Inc.
@@ -10,561 +13,632 @@ preserved on all copies.
 
    Permission is granted to copy and distribute modified versions of
 this manual under the conditions for verbatim copying, provided also
-that the section entitled "GNU General Public License" is included
-exactly as in the original, and provided that the entire resulting
-derived work is distributed under the terms of a permission notice
-identical to this one.
+that the entire resulting derived work is distributed under the terms
+of a permission notice identical to this one.
 
    Permission is granted to copy and distribute translations of this
 manual into another language, under the above conditions for modified
-versions, except that the section entitled "GNU General Public License"
-and this permission notice may be included in translations approved by
-the Free Software Foundation instead of in the original English.
+versions, except that this permission notice may be stated in a
+translation approved by the Free Software Foundation.
 
 
-File: cvs.info,  Node: Index,  Prev: Copying,  Up: Top
+File: cvs.info,  Node: Index,  Prev: BUGS,  Up: Top
 
 Index
 *****
 
 * Menu:
 
-* !, in modules file:                   Excluding directories.
-* &, in modules file:                   Ampersand modules.
-* -a, in modules file:                  Alias modules.
-* -d, in modules file:                  Module options.
-* -e, in modules file:                  Module options.
-* -i, in modules file:                  Module options.
-* -j (merging branches):                Merging a branch.
-* -k (keyword substitution):            Substitution modes.
-* -o, in modules file:                  Module options.
-* -s, in modules file:                  Module options.
-* -t, in modules file:                  Module options.
-* -u, in modules file:                  Module options.
-* .# files:                             update output.
-* .bashrc, setting CVSROOT in:          Specifying a repository.
-* .cshrc, setting CVSROOT in:           Specifying a repository.
-* .cvsrc file:                          ~/.cvsrc.
-* .profile, setting CVSROOT in:         Specifying a repository.
-* .tcshrc, setting CVSROOT in:          Specifying a repository.
+* !, in modules file:                    Excluding directories.
+* #cvs.lock, removing:                   Concurrency.
+* #cvs.lock, technical details:          Locks.
+* #cvs.rfl, and backups:                 Backing up.
+* #cvs.rfl, removing:                    Concurrency.
+* #cvs.rfl, technical details:           Locks.
+* #cvs.tfl:                              Locks.
+* #cvs.wfl, removing:                    Concurrency.
+* #cvs.wfl, technical details:           Locks.
+* &, in modules file:                    Ampersand modules.
+* -a, in modules file:                   Alias modules.
+* -d, in modules file:                   Module options.
+* -e, in modules file <1>:               Module options.
+* -e, in modules file:                   Module program options.
+* -i, in modules file <1>:               Module program options.
+* -i, in modules file:                   Module options.
+* -j (merging branches):                 Merging a branch.
+* -j (merging branches), and keyword substitution: Merging and keywords.
+* -k (keyword substitution):             Substitution modes.
+* -kk, to avoid conflicts during a merge: Merging and keywords.
+* -o, in modules file <1>:               Module options.
+* -o, in modules file:                   Module program options.
+* -s, in modules file:                   Module options.
+* -t, in modules file <1>:               Module options.
+* -t, in modules file:                   Module program options.
+* -u, in modules file <1>:               Module program options.
+* -u, in modules file:                   Module options.
+* .# files:                              update output.
+* .bashrc, setting CVSROOT in:           Specifying a repository.
+* .cshrc, setting CVSROOT in:            Specifying a repository.
+* .cvsrc file:                           ~/.cvsrc.
+* .profile, setting CVSROOT in:          Specifying a repository.
+* .tcshrc, setting CVSROOT in:           Specifying a repository.
 * /usr/local/cvsroot, as example repository: Repository.
-* :ext::                                Connecting via rsh.
-* :gserver::                            GSSAPI authenticated.
-* :kserver::                            Kerberos authenticated.
-* :local::                              Repository.
-* :pserver::                            Password authentication client.
-* :server::                             Connecting via rsh.
-* <<<<<<<:                              Conflicts example.
-* =======:                              Conflicts example.
-* >>>>>>>:                              Conflicts example.
-* __ files (VMS):                       update output.
-* abandoning work:                      Editing files.
-* Access a branch:                      Accessing branches.
-* add (subcommand):                     Adding files.
-* Adding a tag:                         Tags.
-* Adding files:                         Adding files.
-* Admin (subcommand):                   admin.
-* Administrative files (intro):         Intro administrative files.
-* Administrative files (reference):     Administrative files.
-* Administrative files, editing them:   Intro administrative files.
-* Alias modules:                        Alias modules.
-* ALL in commitinfo:                    commitinfo.
-* Ampersand modules:                    Ampersand modules.
-* annotate (subcommand):                annotate.
-* Atomic transactions, lack of:         Concurrency.
-* attic:                                Attic.
-* authenticated client, using:          Password authentication client.
-* authenticating server, setting up:    Password authentication server.
-* authentication, stream:               Global options.
-* Author keyword:                       Keyword list.
-* Automatically ignored files:          cvsignore.
-* Avoiding editor invocation:           Common options.
-* Backing up, repository:               Backing up.
-* Base directory, in CVS directory:     Working directory storage.
-* BASE, as reserved tag name:           Tags.
-* BASE, special tag:                    Common options.
-* Baserev file, in CVS directory:       Working directory storage.
-* Baserev.tmp file, in CVS directory:   Working directory storage.
-* bill of materials:                    Builds.
-* Binary files:                         Binary files.
-* Branch merge example:                 Merging a branch.
-* Branch number <1>:                    Branches and revisions.
-* Branch number:                        Revision numbers.
-* Branch, accessing:                    Accessing branches.
-* Branch, check out:                    Accessing branches.
-* Branch, creating a:                   Creating a branch.
-* Branch, identifying:                  Accessing branches.
-* Branch, retrieving:                   Accessing branches.
-* Branch, vendor-:                      Tracking sources.
-* Branches motivation:                  Branches motivation.
-* Branches, copying changes between:    Branching and merging.
-* Branches, sticky:                     Accessing branches.
-* Branching:                            Branching and merging.
-* Bringing a file up to date:           Updating a file.
-* Bugs in this manual or CVS:           BUGS.
-* Bugs, reporting:                      BUGS.
-* builds:                               Builds.
-* Changes, copying between branches:    Branching and merging.
-* Changing a log message:               admin options.
-* Check out a branch:                   Accessing branches.
-* checked out copy, keeping:            Keeping a checked out copy.
-* Checkin program:                      Module options.
-* Checkin.prog file, in CVS directory:  Working directory storage.
-* Checking commits:                     commitinfo.
-* Checking out source:                  Getting the source.
-* Checkout (subcommand):                checkout.
-* Checkout program:                     Module options.
-* checkout, as term for getting ready to edit: Editing files.
-* Checkout, example:                    Getting the source.
-* checkoutlist:                         CVSROOT storage.
-* choosing, reserved or unreserved checkouts: Choosing a model.
-* Cleaning up:                          Cleaning up.
-* Client/Server Operation:              Remote repositories.
-* Co (subcommand):                      checkout.
-* Command reference:                    Invoking CVS.
-* Command structure:                    Structure.
-* comment leader:                       admin options.
-* Commit (subcommand):                  commit.
-* Commit files:                         commit files.
-* Commit, when to:                      When to commit.
-* Commitinfo:                           commitinfo.
-* Committing changes:                   Committing your changes.
-* Common options:                       Common options.
-* Common syntax of info files:          syntax.
-* compatibility, between CVS versions:  Compatibility.
-* COMSPEC, environment variable:        Environment variables.
-* config, in CVSROOT:                   config.
-* Conflict markers:                     Conflicts example.
-* Conflict resolution:                  Conflicts example.
-* Conflicts (merge example):            Conflicts example.
-* Contributors (CVS program):           What is CVS?.
-* Contributors (manual):                Credits.
-* copying a repository:                 Moving a repository.
-* Copying changes:                      Branching and merging.
-* Correcting a log message:             admin options.
-* Creating a branch:                    Creating a branch.
-* Creating a project:                   Starting a new project.
-* Creating a repository:                Creating a repository.
-* Credits (CVS program):                What is CVS?.
-* Credits (manual):                     Credits.
-* CVS 1.6, and watches:                 Watches Compatibility.
-* CVS command structure:                Structure.
-* CVS directory, in repository:         CVS in repository.
-* CVS directory, in working directory:  Working directory storage.
-* CVS passwd file:                      Password authentication server.
-* CVS, history of:                      What is CVS?.
-* CVS, introduction to:                 What is CVS?.
-* CVS, versions of:                     Compatibility.
-* CVS/Base directory:                   Working directory storage.
-* CVS/Baserev file:                     Working directory storage.
-* CVS/Baserev.tmp file:                 Working directory storage.
-* CVS/Checkin.prog file:                Working directory storage.
-* CVS/Entries file:                     Working directory storage.
-* CVS/Entries.Backup file:              Working directory storage.
-* CVS/Entries.Log file:                 Working directory storage.
-* CVS/Entries.Static file:              Working directory storage.
-* CVS/Notify file:                      Working directory storage.
-* CVS/Notify.tmp file:                  Working directory storage.
-* CVS/Repository file:                  Working directory storage.
-* CVS/Root file:                        Specifying a repository.
-* CVS/Tag file:                         Working directory storage.
-* CVS/Template file:                    Working directory storage.
-* CVS/Update.prog file:                 Working directory storage.
-* CVS_CLIENT_LOG, environment variable: Environment variables.
-* CVS_CLIENT_PORT:                      Kerberos authenticated.
+* :ext:, setting up:                     Connecting via rsh.
+* :ext:, troubleshooting:                Connection.
+* :fork:, setting up:                    Connecting via fork.
+* :gserver:, setting up:                 GSSAPI authenticated.
+* :kserver:, setting up:                 Kerberos authenticated.
+* :local:, setting up:                   Repository.
+* :pserver:, setting up:                 Password authentication client.
+* :pserver:, troubleshooting:            Connection.
+* :server:, setting up:                  Connecting via rsh.
+* :server:, troubleshooting:             Connection.
+* <<<<<<<:                               Conflicts example.
+* =======:                               Conflicts example.
+* >>>>>>>:                               Conflicts example.
+* __ files (VMS):                        update output.
+* Abandoning work:                       Editing files.
+* Access a branch:                       Accessing branches.
+* add (subcommand):                      Adding files.
+* Adding a tag:                          Tags.
+* Adding files:                          Adding files.
+* Admin (subcommand):                    admin.
+* Administrative files (intro):          Intro administrative files.
+* Administrative files (reference):      Administrative files.
+* Administrative files, editing them:    Intro administrative files.
+* Alias modules:                         Alias modules.
+* ALL in commitinfo:                     commitinfo.
+* Ampersand modules:                     Ampersand modules.
+* annotate (subcommand):                 annotate.
+* Atomic transactions, lack of:          Concurrency.
+* Attic:                                 Attic.
+* Authenticated client, using:           Password authentication client.
+* Authenticating server, setting up:     Password authentication server.
+* Authentication, stream:                Global options.
+* Author keyword:                        Keyword list.
+* Automatically ignored files:           cvsignore.
+* Avoiding editor invocation:            Common options.
+* Backing up, repository:                Backing up.
+* Base directory, in CVS directory:      Working directory storage.
+* BASE, as reserved tag name:            Tags.
+* BASE, special tag:                     Common options.
+* Baserev file, in CVS directory:        Working directory storage.
+* Baserev.tmp file, in CVS directory:    Working directory storage.
+* Bill of materials:                     Builds.
+* Binary files:                          Binary files.
+* Branch merge example:                  Merging a branch.
+* Branch number <1>:                     Branches and revisions.
+* Branch number:                         Revision numbers.
+* Branch, accessing:                     Accessing branches.
+* Branch, check out:                     Accessing branches.
+* Branch, creating a:                    Creating a branch.
+* Branch, identifying:                   Accessing branches.
+* Branch, retrieving:                    Accessing branches.
+* Branch, vendor-:                       Tracking sources.
+* Branches motivation:                   Branches motivation.
+* Branches, copying changes between:     Branching and merging.
+* Branches, sticky:                      Accessing branches.
+* Branching:                             Branching and merging.
+* Bringing a file up to date:            Updating a file.
+* Bugs in this manual or CVS:            BUGS.
+* Bugs, reporting:                       BUGS.
+* Builds:                                Builds.
+* Changes, copying between branches:     Branching and merging.
+* Changing a log message:                admin options.
+* Check out a branch:                    Accessing branches.
+* Checked out copy, keeping:             Keeping a checked out copy.
+* Checkin program:                       Module options.
+* Checkin.prog file, in CVS directory:   Working directory storage.
+* Checking commits:                      commitinfo.
+* Checking out source:                   Getting the source.
+* checkout (subcommand):                 checkout.
+* Checkout program:                      Module options.
+* Checkout, as term for getting ready to edit: Editing files.
+* Checkout, example:                     Getting the source.
+* checkoutlist:                          checkoutlist.
+* Choosing, reserved or unreserved checkouts: Choosing a model.
+* Cleaning up:                           Cleaning up.
+* Client/Server Operation:               Remote repositories.
+* Client/Server Operation, port specification <1>: Remote repositories.
+* Client/Server Operation, port specification: Password authentication server.
+* co (subcommand):                       checkout.
+* Command reference:                     Invoking CVS.
+* Command structure:                     Structure.
+* Comment leader:                        admin options.
+* commit (subcommand):                   commit.
+* Commit files:                          commit files.
+* Commit, when to:                       When to commit.
+* Commitinfo:                            commitinfo.
+* Committing changes:                    Committing your changes.
+* Common options:                        Common options.
+* Common syntax of info files:           syntax.
+* Compatibility, between CVS versions:   Compatibility.
+* Compression <1>:                       Global options.
+* Compression:                           Invoking CVS.
+* COMSPEC, environment variable:         Environment variables.
+* config, in CVSROOT:                    config.
+* Conflict markers:                      Conflicts example.
+* Conflict resolution:                   Conflicts example.
+* Conflicts (merge example):             Conflicts example.
+* Contributors (CVS program):            What is CVS?.
+* Contributors (manual):                 Credits.
+* Copying a repository:                  Moving a repository.
+* Copying changes:                       Branching and merging.
+* Correcting a log message:              admin options.
+* Creating a branch:                     Creating a branch.
+* Creating a project:                    Starting a new project.
+* Creating a repository:                 Creating a repository.
+* Credits (CVS program):                 What is CVS?.
+* Credits (manual):                      Credits.
+* CVS 1.6, and watches:                  Watches Compatibility.
+* CVS command structure:                 Structure.
+* CVS directory, in repository:          CVS in repository.
+* CVS directory, in working directory:   Working directory storage.
+* CVS passwd file:                       Password authentication server.
+* CVS, history of:                       What is CVS?.
+* CVS, introduction to:                  What is CVS?.
+* CVS, versions of:                      Compatibility.
+* CVS/Base directory:                    Working directory storage.
+* CVS/Baserev file:                      Working directory storage.
+* CVS/Baserev.tmp file:                  Working directory storage.
+* CVS/Checkin.prog file:                 Working directory storage.
+* CVS/Entries file:                      Working directory storage.
+* CVS/Entries.Backup file:               Working directory storage.
+* CVS/Entries.Log file:                  Working directory storage.
+* CVS/Entries.Static file:               Working directory storage.
+* CVS/Notify file:                       Working directory storage.
+* CVS/Notify.tmp file:                   Working directory storage.
+* CVS/Repository file:                   Working directory storage.
+* CVS/Root file:                         Specifying a repository.
+* CVS/Tag file:                          Working directory storage.
+* CVS/Template file:                     Working directory storage.
+* CVS/Update.prog file:                  Working directory storage.
+* CVS_CLIENT_LOG, environment variable:  Environment variables.
+* CVS_CLIENT_PORT:                       Kerberos authenticated.
 * CVS_IGNORE_REMOTE_ROOT, environment variable: Environment variables.
-* CVS_PASSFILE, environment variable:   Password authentication client.
-* CVS_RCMD_PORT, environment variable:  Environment variables.
-* CVS_RSH, environment variable:        Environment variables.
-* CVS_SERVER, environment variable:     Connecting via rsh.
+* CVS_PASSFILE, environment variable:    Password authentication client.
+* CVS_RCMD_PORT, environment variable:   Environment variables.
+* CVS_RSH, environment variable:         Environment variables.
+* CVS_SERVER, and :fork::                Connecting via fork.
+* CVS_SERVER, environment variable:      Connecting via rsh.
 * CVS_SERVER_SLEEP, environment variable: Environment variables.
-* CVSEDITOR, environment variable:      Committing your changes.
-* cvsignore (admin file), global:       cvsignore.
-* CVSIGNORE, environment variable:      Environment variables.
-* CVSREAD, environment variable:        Environment variables.
-* CVSREAD, overriding:                  Global options.
-* cvsroot:                              Repository.
-* CVSROOT (file):                       Administrative files.
-* CVSROOT, environment variable:        Specifying a repository.
-* CVSROOT, module name:                 Intro administrative files.
-* CVSROOT, multiple repositories:       Multiple repositories.
-* CVSROOT, overriding:                  Global options.
-* CVSROOT, storage of files:            CVSROOT storage.
-* CVSROOT/config:                       config.
-* CVSUMASK, environment variable:       File permissions.
-* cvswrappers (admin file):             Wrappers.
+* cvsadmin:                              admin.
+* CVSEDITOR, environment variable:       Committing your changes.
+* CVSEDITOR, internal variable:          Variables.
+* cvsignore (admin file), global:        cvsignore.
+* CVSIGNORE, environment variable:       Environment variables.
+* CVSREAD, environment variable:         Environment variables.
+* CVSREAD, overriding:                   Global options.
+* cvsroot:                               Repository.
+* CVSROOT (file):                        Administrative files.
+* CVSROOT, environment variable:         Specifying a repository.
+* CVSROOT, internal variable:            Variables.
+* CVSROOT, module name:                  Intro administrative files.
+* CVSROOT, multiple repositories:        Multiple repositories.
+* CVSROOT, overriding:                   Global options.
+* CVSROOT, storage of files:             CVSROOT storage.
+* CVSROOT/config:                        config.
+* CVSUMASK, environment variable:        File permissions.
+* cvswrappers (admin file):              Wrappers.
 * CVSWRAPPERS, environment variable <1>: Environment variables.
-* CVSWRAPPERS, environment variable:    Wrappers.
-* Cyclic Software:                      BUGS.
-* Date keyword:                         Keyword list.
-* Dates:                                Common options.
-* dead state:                           Attic.
-* Decimal revision number:              Revision numbers.
-* DEFAULT in commitinfo:                commitinfo.
-* DEFAULT in editinfo:                  editinfo.
-* DEFAULT in verifymsg:                 verifymsg.
-* Defining a module:                    Defining the module.
-* Defining modules (intro):             Intro administrative files.
-* Defining modules (reference manual):  modules.
-* Deleting files:                       Removing files.
-* Deleting revisions:                   admin options.
-* Deleting sticky tags:                 Sticky tags.
-* Descending directories:               Recursive behavior.
-* Diff:                                 Viewing differences.
-* Diff (subcommand):                    diff.
-* Differences, merging:                 Merging two revisions.
-* Directories, moving:                  Moving directories.
-* directories, removing:                Removing directories.
-* Directory, descending:                Recursive behavior.
-* Disjoint repositories:                Multiple repositories.
-* Distributing log messages:            loginfo.
-* driver.c (merge example):             Conflicts example.
-* edit (subcommand):                    Editing files.
-* editinfo (admin file):                editinfo.
-* Editing administrative files:         Intro administrative files.
-* Editing the modules file:             Defining the module.
-* Editor, avoiding invocation of:       Common options.
-* EDITOR, environment variable:         Committing your changes.
-* EDITOR, overriding:                   Global options.
-* Editor, specifying per module:        editinfo.
-* editors (subcommand):                 Watch information.
-* emerge:                               Conflicts example.
-* encryption:                           Global options.
-* Entries file, in CVS directory:       Working directory storage.
+* CVSWRAPPERS, environment variable:     Wrappers.
+* Date keyword:                          Keyword list.
+* Dates:                                 Common options.
+* Dead state:                            Attic.
+* Decimal revision number:               Revision numbers.
+* DEFAULT in commitinfo:                 commitinfo.
+* DEFAULT in editinfo:                   editinfo.
+* DEFAULT in verifymsg:                  verifymsg.
+* Defining a module:                     Defining the module.
+* Defining modules (intro):              Intro administrative files.
+* Defining modules (reference manual):   modules.
+* Deleting files:                        Removing files.
+* Deleting revisions:                    admin options.
+* Deleting sticky tags:                  Sticky tags.
+* Deleting tags:                         Modifying tags.
+* Descending directories:                Recursive behavior.
+* Device nodes:                          Special Files.
+* Diff:                                  Viewing differences.
+* diff (subcommand):                     diff.
+* Differences, merging:                  Merging two revisions.
+* Directories, moving:                   Moving directories.
+* Directories, removing:                 Removing directories.
+* Directory, descending:                 Recursive behavior.
+* Disjoint repositories:                 Multiple repositories.
+* Distributing log messages:             loginfo.
+* driver.c (merge example):              Conflicts example.
+* edit (subcommand):                     Editing files.
+* editinfo (admin file):                 editinfo.
+* Editing administrative files:          Intro administrative files.
+* Editing the modules file:              Defining the module.
+* Editor, avoiding invocation of:        Common options.
+* EDITOR, environment variable:          Committing your changes.
+* EDITOR, internal variable:             Variables.
+* EDITOR, overriding:                    Global options.
+* Editor, specifying per module:         editinfo.
+* editors (subcommand):                  Watch information.
+* emerge:                                Conflicts example.
+* Encryption:                            Global options.
+* Entries file, in CVS directory:        Working directory storage.
 * Entries.Backup file, in CVS directory: Working directory storage.
-* Entries.Log file, in CVS directory:   Working directory storage.
+* Entries.Log file, in CVS directory:    Working directory storage.
 * Entries.Static file, in CVS directory: Working directory storage.
-* Environment variables:                Environment variables.
-* Errors, reporting:                    BUGS.
-* Example of a work-session:            A sample session.
-* Example of merge:                     Conflicts example.
-* Example, branch merge:                Merging a branch.
-* excluding directories, in modules file: Excluding directories.
-* exit status, of commitinfo:           commitinfo.
-* exit status, of CVS:                  Exit status.
-* exit status, of editor:               Error messages.
-* exit status, of taginfo:              user-defined logging.
-* exit status, of verifymsg:            verifymsg.
-* Export (subcommand):                  export.
-* Export program:                       Module options.
-* Fetching source:                      Getting the source.
-* File had conflicts on merge:          File status.
-* File locking:                         Multiple developers.
-* File permissions, general:            File permissions.
-* File permissions, Windows-specific:   Windows permissions.
-* File status:                          File status.
-* Files, moving:                        Moving files.
-* Files, reference manual:              Administrative files.
-* Fixing a log message:                 admin options.
-* Forcing a tag match:                  Common options.
-* Form for log message:                 rcsinfo.
-* Format of CVS commands:               Structure.
-* Getting started:                      A sample session.
-* Getting the source:                   Getting the source.
-* Global cvsignore:                     cvsignore.
-* Global options:                       Global options.
-* Group:                                File permissions.
-* GSSAPI:                               GSSAPI authenticated.
-* HEAD, as reserved tag name:           Tags.
-* HEAD, special tag:                    Common options.
-* Header keyword:                       Keyword list.
-* History (subcommand):                 history.
-* History browsing:                     History browsing.
-* History file:                         history file.
-* History files:                        Repository files.
-* History of CVS:                       What is CVS?.
-* HOME, environment variable:           Environment variables.
-* HOMEDRIVE, environment variable:      Environment variables.
-* HOMEPATH, environment variable:       Environment variables.
-* Id keyword:                           Keyword list.
-* Ident (shell command):                Using keywords.
-* Identifying a branch:                 Accessing branches.
-* Identifying files:                    Keyword substitution.
-* Ignored files:                        cvsignore.
-* Ignoring files:                       cvsignore.
-* Import (subcommand):                  import.
-* Importing files:                      From files.
+* Environment variables:                 Environment variables.
+* environment variables, passed to administrative files: Variables.
+* Errors, reporting:                     BUGS.
+* Example of a work-session:             A sample session.
+* Example of merge:                      Conflicts example.
+* Example, branch merge:                 Merging a branch.
+* Excluding directories, in modules file: Excluding directories.
+* Exit status, of commitinfo:            commitinfo.
+* Exit status, of CVS:                   Exit status.
+* Exit status, of editor:                Error messages.
+* Exit status, of taginfo:               user-defined logging.
+* Exit status, of verifymsg:             verifymsg.
+* export (subcommand):                   export.
+* Export program:                        Module options.
+* Fetching source:                       Getting the source.
+* File had conflicts on merge:           File status.
+* File locking:                          Multiple developers.
+* File permissions, general:             File permissions.
+* File permissions, Windows-specific:    Windows permissions.
+* File status:                           File status.
+* Files, moving:                         Moving files.
+* Files, reference manual:               Administrative files.
+* Fixing a log message:                  admin options.
+* Forcing a tag match:                   Common options.
+* fork, access method:                   Connecting via fork.
+* Form for log message:                  rcsinfo.
+* Format of CVS commands:                Structure.
+* Getting started:                       A sample session.
+* Getting the source:                    Getting the source.
+* Global cvsignore:                      cvsignore.
+* Global options:                        Global options.
+* Group:                                 File permissions.
+* gserver (client/server connection method), port specification <1>: Remote repositories.
+* gserver (client/server connection method), port specification: Password authentication server.
+* GSSAPI:                                GSSAPI authenticated.
+* Gzip <1>:                              Global options.
+* Gzip:                                  Invoking CVS.
+* Hard links:                            Special Files.
+* HEAD, as reserved tag name:            Tags.
+* HEAD, special tag:                     Common options.
+* Header keyword:                        Keyword list.
+* history (subcommand):                  history.
+* History browsing:                      History browsing.
+* History file:                          history file.
+* History files:                         Repository files.
+* History of CVS:                        What is CVS?.
+* HOME, environment variable:            Environment variables.
+* HOMEDRIVE, environment variable:       Environment variables.
+* HOMEPATH, environment variable:        Environment variables.
+* Id keyword:                            Keyword list.
+* Ident (shell command):                 Using keywords.
+* Identifying a branch:                  Accessing branches.
+* Identifying files:                     Keyword substitution.
+* Ignored files:                         cvsignore.
+* Ignoring files:                        cvsignore.
+* import (subcommand):                   import.
+* Importing files:                       From files.
 * Importing files, from other version control systems: From other version control systems.
-* Importing modules:                    First import.
-* Index:                                Index.
-* Info files (syntax):                  syntax.
-* Informing others:                     Informing others.
-* init (subcommand):                    Creating a repository.
-* installed images (VMS):               File permissions.
-* Introduction to CVS:                  What is CVS?.
-* Invoking CVS:                         Invoking CVS.
-* Isolation:                            History browsing.
-* Join:                                 Merging a branch.
-* keeping a checked out copy:           Keeping a checked out copy.
-* kerberos:                             Kerberos authenticated.
-* Keyword expansion:                    Keyword substitution.
-* Keyword List:                         Keyword list.
-* Keyword substitution:                 Keyword substitution.
-* Kflag:                                Substitution modes.
-* kinit:                                Kerberos authenticated.
-* Known bugs in this manual or CVS:     BUGS.
-* Layout of repository:                 Repository.
-* Left-hand options:                    Global options.
-* Linear development:                   Revision numbers.
-* link, symbolic, importing:            import output.
-* List, mailing list:                   What is CVS?.
-* Locally Added:                        File status.
-* Locally Modified:                     File status.
-* Locally Removed:                      File status.
-* Locker keyword:                       Keyword list.
-* Locking files:                        Multiple developers.
-* locks, cvs:                           Concurrency.
-* Log (subcommand):                     log.
-* Log information, saving:              history file.
-* Log keyword:                          Keyword list.
-* Log message entry:                    Committing your changes.
-* Log message template:                 rcsinfo.
-* Log message, correcting:              admin options.
-* log message, verifying:               verifymsg.
-* Log messages:                         loginfo.
-* Log messages, editing:                editinfo.
-* Login (subcommand):                   Password authentication client.
-* loginfo (admin file):                 loginfo.
-* Logout (subcommand):                  Password authentication client.
-* Mail, automatic mail on commit:       Informing others.
-* Mailing list:                         What is CVS?.
-* Mailing log messages:                 loginfo.
-* Main trunk and branches:              Branching and merging.
-* make:                                 Builds.
-* Many repositories:                    Multiple repositories.
-* Markers, conflict:                    Conflicts example.
-* Merge, an example:                    Conflicts example.
-* Merge, branch example:                Merging a branch.
-* Merging:                              Branching and merging.
-* Merging a branch:                     Merging a branch.
-* Merging a file:                       Updating a file.
-* Merging two revisions:                Merging two revisions.
-* mkmodules:                            Error messages.
+* Importing modules:                     First import.
+* Index:                                 Index.
+* Info files (syntax):                   syntax.
+* Informing others:                      Informing others.
+* init (subcommand):                     Creating a repository.
+* Installed images (VMS):                File permissions.
+* Internal variables:                    Variables.
+* Introduction to CVS:                   What is CVS?.
+* Invoking CVS:                          Invoking CVS.
+* Isolation:                             History browsing.
+* Join:                                  Merging a branch.
+* Keeping a checked out copy:            Keeping a checked out copy.
+* Kerberos, using :gserver::             GSSAPI authenticated.
+* Kerberos, using :kserver::             Kerberos authenticated.
+* Kerberos, using kerberized rsh:        Connecting via rsh.
+* Keyword expansion:                     Keyword substitution.
+* Keyword List:                          Keyword list.
+* Keyword substitution:                  Keyword substitution.
+* Keyword substitution, and merging:     Merging and keywords.
+* Keyword substitution, changing modes:  Substitution modes.
+* Kflag:                                 Substitution modes.
+* kinit:                                 Kerberos authenticated.
+* Known bugs in this manual or CVS:      BUGS.
+* kserver (client/server connection method), port specification <1>: Password authentication server.
+* kserver (client/server connection method), port specification: Remote repositories.
+* Layout of repository:                  Repository.
+* Left-hand options:                     Global options.
+* Linear development:                    Revision numbers.
+* Link, symbolic, importing:             import output.
+* List, mailing list:                    What is CVS?.
+* Locally Added:                         File status.
+* Locally Modified:                      File status.
+* Locally Removed:                       File status.
+* LockDir, in CVSROOT/config:            config.
+* Locker keyword:                        Keyword list.
+* Locking files:                         Multiple developers.
+* Locks, cvs, and backups:               Backing up.
+* Locks, cvs, introduction:              Concurrency.
+* Locks, cvs, technical details:         Locks.
+* log (subcommand):                      log.
+* Log information, saving:               history file.
+* Log keyword:                           Keyword list.
+* Log message entry:                     Committing your changes.
+* Log message template:                  rcsinfo.
+* Log message, correcting:               admin options.
+* Log message, verifying:                verifymsg.
+* Log messages:                          loginfo.
+* Log messages, editing:                 editinfo.
+* LogHistory, in CVSROOT/config:         config.
+* Login (subcommand):                    Password authentication client.
+* loginfo (admin file):                  loginfo.
+* Logout (subcommand):                   Password authentication client.
+* Mail, automatic mail on commit:        Informing others.
+* Mailing list:                          What is CVS?.
+* Mailing log messages:                  loginfo.
+* Main trunk and branches:               Branching and merging.
+* make:                                  Builds.
+* Many repositories:                     Multiple repositories.
+* Markers, conflict:                     Conflicts example.
+* Merge, an example:                     Conflicts example.
+* Merge, branch example:                 Merging a branch.
+* Merging:                               Branching and merging.
+* Merging a branch:                      Merging a branch.
+* Merging a file:                        Updating a file.
+* Merging two revisions:                 Merging two revisions.
+* Merging, and keyword substitution:     Merging and keywords.
+* mkmodules:                             Error messages.
 * Modifications, copying between branches: Branching and merging.
-* Module status:                        Module options.
-* Module, defining:                     Defining the module.
-* Modules (admin file):                 modules.
-* Modules file:                         Intro administrative files.
-* Modules file, changing:               Defining the module.
-* modules.db:                           CVSROOT storage.
-* modules.dir:                          CVSROOT storage.
-* modules.pag:                          CVSROOT storage.
-* Motivation for branches:              Branches motivation.
-* moving a repository:                  Moving a repository.
-* Moving directories:                   Moving directories.
-* Moving files:                         Moving files.
-* moving tags:                          tag options.
-* Multiple developers:                  Multiple developers.
-* Multiple repositories:                Multiple repositories.
-* Name keyword:                         Keyword list.
-* Name, symbolic (tag):                 Tags.
-* Needs Checkout:                       File status.
-* Needs Merge:                          File status.
-* Needs Patch:                          File status.
-* Newsgroups:                           What is CVS?.
-* notify (admin file):                  Getting Notified.
-* Notify file, in CVS directory:        Working directory storage.
-* Notify.tmp file, in CVS directory:    Working directory storage.
-* Number, branch <1>:                   Branches and revisions.
-* Number, branch:                       Revision numbers.
-* Number, revision-:                    Revision numbers.
-* option defaults:                      ~/.cvsrc.
-* Options, global:                      Global options.
-* options, in modules file:             Module options.
-* Outdating revisions:                  admin options.
-* Overlap:                              Updating a file.
-* Overriding CVSREAD:                   Global options.
-* Overriding CVSROOT:                   Global options.
-* Overriding EDITOR:                    Global options.
-* Overriding RCSBIN:                    Global options.
-* Overriding TMPDIR:                    Global options.
-* Overview:                             Overview.
-* Parallel repositories:                Multiple repositories.
-* passwd (admin file):                  Password authentication server.
-* password client, using:               Password authentication client.
-* password server, setting up:          Password authentication server.
-* PATH, environment variable:           Environment variables.
-* Per-directory sticky tags/dates:      Working directory storage.
-* Per-module editor:                    editinfo.
-* permissions, general:                 File permissions.
-* permissions, Windows-specific:        Windows permissions.
-* Policy:                               When to commit.
-* Precommit checking:                   commitinfo.
-* Pserver (subcommand):                 Password authentication server.
-* PVCS, importing files from:           From other version control systems.
-* RCS history files:                    Repository files.
-* RCS revision numbers:                 Tags.
-* RCS, importing files from:            From other version control systems.
-* RCS-style locking:                    Multiple developers.
-* RCSBIN, in CVSROOT/config:            config.
-* RCSBIN, overriding:                   Global options.
-* RCSfile keyword:                      Keyword list.
-* rcsinfo (admin file):                 rcsinfo.
-* Rdiff (subcommand):                   rdiff.
-* read-only files, and -r:              Global options.
-* read-only files, and CVSREAD:         Environment variables.
-* read-only files, and watches:         Setting a watch.
-* read-only files, in repository:       File permissions.
-* Read-only mode:                       Global options.
-* read-only repository access:          Read-only access.
-* readers (admin file):                 Read-only access.
-* Recursive (directory descending):     Recursive behavior.
-* Reference manual (files):             Administrative files.
-* Reference manual for variables:       Environment variables.
-* Reference, commands:                  Invoking CVS.
-* regular expression syntax:            syntax.
-* Regular modules:                      Regular modules.
-* Release (subcommand):                 release.
-* Releases, revisions and versions:     Versions revisions releases.
-* Releasing your working copy:          Cleaning up.
-* Remote repositories:                  Remote repositories.
-* Remove (subcommand):                  Removing files.
-* Removing a change:                    Merging two revisions.
-* removing directories:                 Removing directories.
-* Removing files:                       Removing files.
-* Removing your working copy:           Cleaning up.
-* Renaming directories:                 Moving directories.
-* Renaming files:                       Moving files.
-* renaming tags:                        tag options.
-* Replacing a log message:              admin options.
-* Reporting bugs:                       BUGS.
-* Repositories, multiple:               Multiple repositories.
-* Repositories, remote:                 Remote repositories.
-* Repository (intro):                   Repository.
-* Repository file, in CVS directory:    Working directory storage.
-* Repository, backing up:               Backing up.
-* Repository, example:                  Repository.
-* Repository, how data is stored:       Repository storage.
-* repository, moving:                   Moving a repository.
-* Repository, setting up:               Creating a repository.
-* reserved checkouts:                   Multiple developers.
-* Resetting sticky tags:                Sticky tags.
-* Resolving a conflict:                 Conflicts example.
-* Restoring old version of removed file: Sticky tags.
-* Resurrecting old version of dead file: Sticky tags.
-* Retrieve a branch:                    Accessing branches.
+* Module status:                         Module options.
+* Module, defining:                      Defining the module.
+* Modules (admin file):                  modules.
+* Modules file:                          Intro administrative files.
+* Modules file program options:          Module program options.
+* Modules file, changing:                Defining the module.
+* modules.db:                            CVSROOT storage.
+* modules.dir:                           CVSROOT storage.
+* modules.pag:                           CVSROOT storage.
+* Motivation for branches:               Branches motivation.
+* Moving a repository:                   Moving a repository.
+* Moving directories:                    Moving directories.
+* Moving files:                          Moving files.
+* Moving tags:                           Modifying tags.
+* Multiple developers:                   Multiple developers.
+* Multiple repositories:                 Multiple repositories.
+* Name keyword:                          Keyword list.
+* Name, symbolic (tag):                  Tags.
+* Needs Checkout:                        File status.
+* Needs Merge:                           File status.
+* Needs Patch:                           File status.
+* Newsgroups:                            What is CVS?.
+* notify (admin file):                   Getting Notified.
+* Notify file, in CVS directory:         Working directory storage.
+* Notify.tmp file, in CVS directory:     Working directory storage.
+* Number, branch <1>:                    Revision numbers.
+* Number, branch:                        Branches and revisions.
+* Number, revision-:                     Revision numbers.
+* Option defaults:                       ~/.cvsrc.
+* Options, global:                       Global options.
+* Options, in modules file:              Module options.
+* Outdating revisions:                   admin options.
+* Overlap:                               Updating a file.
+* Overriding CVSREAD:                    Global options.
+* Overriding CVSROOT:                    Global options.
+* Overriding EDITOR:                     Global options.
+* Overriding RCSBIN:                     Global options.
+* Overriding TMPDIR:                     Global options.
+* Overview:                              Overview.
+* Ownership, saving in CVS:              Special Files.
+* Parallel repositories:                 Multiple repositories.
+* passwd (admin file):                   Password authentication server.
+* Password client, using:                Password authentication client.
+* Password server, setting up:           Password authentication server.
+* PATH, environment variable:            Environment variables.
+* Per-directory sticky tags/dates:       Working directory storage.
+* Per-module editor:                     editinfo.
+* Permissions, general:                  File permissions.
+* Permissions, saving in CVS:            Special Files.
+* Permissions, Windows-specific:         Windows permissions.
+* Policy:                                When to commit.
+* port, specifying for remote repositories <1>: Remote repositories.
+* port, specifying for remote repositories: Password authentication server.
+* Precommit checking:                    commitinfo.
+* pserver (client/server connection method), port specification <1>: Remote repositories.
+* pserver (client/server connection method), port specification: Password authentication server.
+* pserver (subcommand):                  Password authentication server.
+* PVCS, importing files from:            From other version control systems.
+* RCS history files:                     Repository files.
+* RCS revision numbers:                  Tags.
+* RCS, importing files from:             From other version control systems.
+* RCS-style locking:                     Multiple developers.
+* RCSBIN, in CVSROOT/config:             config.
+* RCSBIN, internal variable:             Variables.
+* RCSBIN, overriding:                    Global options.
+* RCSfile keyword:                       Keyword list.
+* rcsinfo (admin file):                  rcsinfo.
+* rdiff (subcommand):                    rdiff.
+* Read-only files, and -r:               Global options.
+* Read-only files, and CVSREAD:          Environment variables.
+* Read-only files, and watches:          Setting a watch.
+* Read-only files, in repository:        File permissions.
+* Read-only mode:                        Global options.
+* Read-only repository access:           Read-only access.
+* readers (admin file):                  Read-only access.
+* Recursive (directory descending):      Recursive behavior.
+* Reference manual (files):              Administrative files.
+* Reference manual for variables:        Environment variables.
+* Reference, commands:                   Invoking CVS.
+* Regular expression syntax:             syntax.
+* Regular modules:                       Regular modules.
+* release (subcommand):                  release.
+* Releases, revisions and versions:      Versions revisions releases.
+* Releasing your working copy:           Cleaning up.
+* Remote repositories:                   Remote repositories.
+* Remote repositories, port specification <1>: Remote repositories.
+* Remote repositories, port specification: Password authentication server.
+* Remove (subcommand):                   Removing files.
+* Removing a change:                     Merging two revisions.
+* Removing directories:                  Removing directories.
+* Removing files:                        Removing files.
+* Removing tags:                         Modifying tags.
+* Removing your working copy:            Cleaning up.
+* Renaming directories:                  Moving directories.
+* Renaming files:                        Moving files.
+* Renaming tags:                         Modifying tags.
+* Replacing a log message:               admin options.
+* Reporting bugs:                        BUGS.
+* Repositories, multiple:                Multiple repositories.
+* Repositories, remote:                  Remote repositories.
+* Repositories, remote, port specification <1>: Remote repositories.
+* Repositories, remote, port specification: Password authentication server.
+* Repository (intro):                    Repository.
+* Repository file, in CVS directory:     Working directory storage.
+* Repository, backing up:                Backing up.
+* Repository, example:                   Repository.
+* Repository, how data is stored:        Repository storage.
+* Repository, moving:                    Moving a repository.
+* Repository, setting up:                Creating a repository.
+* Reserved checkouts:                    Multiple developers.
+* Resetting sticky tags:                 Sticky tags.
+* Resolving a conflict:                  Conflicts example.
+* Restoring old version of removed file: Merging two revisions.
+* Resurrecting old version of dead file: Merging two revisions.
+* Retrieve a branch:                     Accessing branches.
 * Retrieving an old revision using tags: Tags.
-* reverting to repository version:      Editing files.
-* Revision keyword:                     Keyword list.
-* Revision management:                  Revision management.
-* Revision numbers:                     Revision numbers.
-* Revision numbers (branches):          Branches and revisions.
-* Revision tree:                        Revision numbers.
-* Revision tree, making branches:       Branching and merging.
+* Reverting to repository version:       Editing files.
+* Revision keyword:                      Keyword list.
+* Revision management:                   Revision management.
+* Revision numbers:                      Revision numbers.
+* Revision numbers (branches):           Branches and revisions.
+* Revision tree:                         Revision numbers.
+* Revision tree, making branches:        Branching and merging.
 * Revisions, merging differences between: Merging two revisions.
-* Revisions, versions and releases:     Versions revisions releases.
-* Right-hand options:                   Common options.
-* Root file, in CVS directory:          Specifying a repository.
-* rsh:                                  Connecting via rsh.
-* Rtag (subcommand):                    rtag.
-* rtag, creating a branch using:        Creating a branch.
-* Saving space:                         admin options.
-* SCCS, importing files from:           From other version control systems.
+* Revisions, versions and releases:      Versions revisions releases.
+* Right-hand options:                    Common options.
+* Root file, in CVS directory:           Specifying a repository.
+* rsh:                                   Connecting via rsh.
+* rsh replacements (Kerberized, SSH, &c): Connecting via rsh.
+* rtag (subcommand):                     Tagging by date/tag.
+* rtag, creating a branch using:         Creating a branch.
+* Saving space:                          admin options.
+* SCCS, importing files from:            From other version control systems.
 * Security, file permissions in repository: File permissions.
-* security, GSSAPI:                     GSSAPI authenticated.
-* security, kerberos:                   Kerberos authenticated.
-* security, of pserver:                 Password authentication security.
-* security, setuid:                     File permissions.
-* server, CVS:                          Remote repositories.
-* server, temporary directories:        Server temporary directory.
-* setgid:                               File permissions.
-* Setting up a repository:              Creating a repository.
-* setuid:                               File permissions.
-* Signum Support:                       BUGS.
-* Source keyword:                       Keyword list.
-* Source, getting CVS source:           What is CVS?.
-* Source, getting from CVS:             Getting the source.
-* Specifying dates:                     Common options.
-* Spreading information:                Informing others.
-* Starting a project with CVS:          Starting a new project.
-* State keyword:                        Keyword list.
-* Status of a file:                     File status.
-* Status of a module:                   Module options.
-* sticky date:                          Sticky tags.
-* Sticky tags:                          Sticky tags.
-* Sticky tags, resetting:               Sticky tags.
-* Sticky tags/dates, per-directory:     Working directory storage.
-* Storing log messages:                 loginfo.
-* stream authentication:                Global options.
-* Structure:                            Structure.
-* Subdirectories:                       Recursive behavior.
-* Support, getting CVS support:         BUGS.
-* symbolic link, importing:             import output.
-* Symbolic name (tag):                  Tags.
-* Syntax of info files:                 syntax.
-* SystemAuth, in CVSROOT/config:        config.
-* Tag (subcommand):                     tag.
-* Tag file, in CVS directory:           Working directory storage.
-* Tag program:                          Module options.
-* tag, command, introduction:           Tags.
-* tag, creating a branch using:         Creating a branch.
-* tag, example:                         Tags.
-* Tag, retrieving old revisions:        Tags.
-* Tag, symbolic name:                   Tags.
-* taginfo:                              user-defined logging.
-* Tags:                                 Tags.
-* tags, renaming:                       tag options.
-* Tags, sticky:                         Sticky tags.
-* tc, Trivial Compiler (example):       A sample session.
-* Team of developers:                   Multiple developers.
-* TEMP, environment variable:           Environment variables.
-* Template file, in CVS directory:      Working directory storage.
-* Template for log message:             rcsinfo.
-* temporary directories, and server:    Server temporary directory.
-* temporary files, location of:         Environment variables.
-* Third-party sources:                  Tracking sources.
-* Time:                                 Common options.
-* timezone, in input:                   Common options.
-* timezone, in output:                  log.
-* TMP, environment variable:            Environment variables.
-* TMPDIR, environment variable:         Environment variables.
-* TMPDIR, overriding:                   Global options.
-* Trace:                                Global options.
-* Traceability:                         History browsing.
-* Tracking sources:                     Tracking sources.
-* Transactions, atomic, lack of:        Concurrency.
-* Trivial Compiler (example):           A sample session.
-* Typical repository:                   Repository.
-* umask, for repository files:          File permissions.
-* Undoing a change:                     Merging two revisions.
-* unedit (subcommand):                  Editing files.
-* Unknown:                              File status.
-* unreserved checkouts:                 Multiple developers.
-* Up-to-date:                           File status.
-* Update (subcommand):                  update.
-* Update program:                       Module options.
-* update, introduction:                 Updating a file.
-* update, to display file status:       File status.
-* Update.prog file, in CVS directory:   Working directory storage.
-* Updating a file:                      Updating a file.
-* user aliases:                         Password authentication server.
-* users (admin file):                   Getting Notified.
-* Vendor:                               Tracking sources.
-* Vendor branch:                        Tracking sources.
-* verifymsg (admin file):               verifymsg.
-* versions, of CVS:                     Compatibility.
-* Versions, revisions and releases:     Versions revisions releases.
-* Viewing differences:                  Viewing differences.
-* watch add (subcommand):               Getting Notified.
-* watch off (subcommand):               Setting a watch.
-* watch on (subcommand):                Setting a watch.
-* watch remove (subcommand):            Getting Notified.
-* watchers (subcommand):                Watch information.
-* Watches:                              Watches.
-* Wdiff (import example):               First import.
-* web pages, maintaining with CVS:      Keeping a checked out copy.
-* What (shell command):                 Using keywords.
-* What branches are good for:           Branches motivation.
-* What is CVS not?:                     What is CVS not?.
-* What is CVS?:                         What is CVS?.
-* When to commit:                       When to commit.
-* Windows, and permissions:             Windows permissions.
-* Work-session, example of:             A sample session.
-* Working copy:                         Multiple developers.
-* Working copy, removing:               Cleaning up.
-* Wrappers:                             Wrappers.
-* writers (admin file):                 Read-only access.
-* zone, time, in input:                 Common options.
-* zone, time, in output:                log.
+* Security, GSSAPI:                      GSSAPI authenticated.
+* Security, kerberos:                    Kerberos authenticated.
+* Security, of pserver:                  Password authentication security.
+* Security, setuid:                      File permissions.
+* Server, CVS:                           Remote repositories.
+* Server, temporary directories:         Server temporary directory.
+* Setgid:                                File permissions.
+* Setting up a repository:               Creating a repository.
+* Setuid:                                File permissions.
+* Signum Support:                        BUGS.
+* Source keyword:                        Keyword list.
+* Source, getting CVS source:            What is CVS?.
+* Source, getting from CVS:              Getting the source.
+* Special files:                         Special Files.
+* Specifying dates:                      Common options.
+* Spreading information:                 Informing others.
+* SSH (rsh replacement):                 Connecting via rsh.
+* Starting a project with CVS:           Starting a new project.
+* State keyword:                         Keyword list.
+* Status of a file:                      File status.
+* Status of a module:                    Module options.
+* Sticky date:                           Sticky tags.
+* Sticky tags:                           Sticky tags.
+* Sticky tags, resetting:                Sticky tags.
+* Sticky tags/dates, per-directory:      Working directory storage.
+* Storing log messages:                  loginfo.
+* Stream authentication:                 Global options.
+* Structure:                             Structure.
+* Subdirectories:                        Recursive behavior.
+* Support, getting CVS support:          BUGS.
+* Symbolic link, importing:              import output.
+* Symbolic links:                        Special Files.
+* Symbolic name (tag):                   Tags.
+* Syntax of info files:                  syntax.
+* SystemAuth, in CVSROOT/config:         config.
+* tag (subcommand):                      Tagging the working directory.
+* Tag file, in CVS directory:            Working directory storage.
+* Tag program:                           Module options.
+* tag, command, introduction:            Tags.
+* tag, creating a branch using:          Creating a branch.
+* Tag, example:                          Tags.
+* Tag, retrieving old revisions:         Tags.
+* Tag, symbolic name:                    Tags.
+* taginfo:                               user-defined logging.
+* Tags:                                  Tags.
+* Tags, deleting:                        Modifying tags.
+* Tags, moving:                          Modifying tags.
+* Tags, renaming:                        Modifying tags.
+* Tags, sticky:                          Sticky tags.
+* tc, Trivial Compiler (example):        A sample session.
+* Team of developers:                    Multiple developers.
+* TEMP, environment variable:            Environment variables.
+* Template file, in CVS directory:       Working directory storage.
+* Template for log message:              rcsinfo.
+* Temporary directories, and server:     Server temporary directory.
+* Temporary files, location of:          Environment variables.
+* Third-party sources:                   Tracking sources.
+* Time:                                  Common options.
+* Timezone, in input:                    Common options.
+* Timezone, in output:                   log.
+* TMP, environment variable:             Environment variables.
+* TMPDIR, environment variable:          Environment variables.
+* TMPDIR, overriding:                    Global options.
+* TopLevelAdmin, in CVSROOT/config:      config.
+* Trace:                                 Global options.
+* Traceability:                          History browsing.
+* Tracking sources:                      Tracking sources.
+* Transactions, atomic, lack of:         Concurrency.
+* Trivial Compiler (example):            A sample session.
+* Typical repository:                    Repository.
+* Umask, for repository files:           File permissions.
+* Undoing a change:                      Merging two revisions.
+* unedit (subcommand):                   Editing files.
+* Unknown:                               File status.
+* Unreserved checkouts:                  Multiple developers.
+* Up-to-date:                            File status.
+* update (subcommand):                   update.
+* Update program:                        Module options.
+* Update, introduction:                  Updating a file.
+* update, to display file status:        File status.
+* Update.prog file, in CVS directory:    Working directory storage.
+* Updating a file:                       Updating a file.
+* User aliases:                          Password authentication server.
+* User variables:                        Variables.
+* USER, internal variable:               Variables.
+* users (admin file):                    Getting Notified.
+* Variables:                             Variables.
+* Vendor:                                Tracking sources.
+* Vendor branch:                         Tracking sources.
+* verifymsg (admin file):                verifymsg.
+* version (subcommand):                  Invoking CVS.
+* Versions, of CVS:                      Compatibility.
+* Versions, revisions and releases:      Versions revisions releases.
+* Viewing differences:                   Viewing differences.
+* VISUAL, environment variable:          Committing your changes.
+* VISUAL, internal variable:             Variables.
+* watch add (subcommand):                Getting Notified.
+* watch off (subcommand):                Setting a watch.
+* watch on (subcommand):                 Setting a watch.
+* watch remove (subcommand):             Getting Notified.
+* watchers (subcommand):                 Watch information.
+* Watches:                               Watches.
+* wdiff (import example):                First import.
+* Web pages, maintaining with CVS:       Keeping a checked out copy.
+* What (shell command):                  Using keywords.
+* What branches are good for:            Branches motivation.
+* What is CVS not?:                      What is CVS not?.
+* What is CVS?:                          What is CVS?.
+* When to commit:                        When to commit.
+* Windows, and permissions:              Windows permissions.
+* Work-session, example of:              A sample session.
+* Working copy:                          Multiple developers.
+* Working copy, removing:                Cleaning up.
+* Wrappers:                              Wrappers.
+* writers (admin file):                  Read-only access.
+* Zone, time, in input:                  Common options.
+* Zone, time, in output:                 log.
 
 
diff --git a/gnu/usr.bin/cvs/src/Makefile.in b/gnu/usr.bin/cvs/src/Makefile.in
index c80deab8794..b85aa57c22a 100644
--- a/gnu/usr.bin/cvs/src/Makefile.in
+++ b/gnu/usr.bin/cvs/src/Makefile.in
@@ -180,7 +180,7 @@ cvs_SOURCES = \
 cvs_LDADD = \
 	../diff/libdiff.a \
 	../lib/libcvs.a \
-	../zlib/libz.a \
+	@ZLIB@ \
 	version.o
 
 cvs_EXTRA_DIST = version.c
@@ -229,7 +229,7 @@ am_cvs_OBJECTS = add.$(OBJEXT) admin.$(OBJEXT) annotate.$(OBJEXT) \
 	update.$(OBJEXT) vers_ts.$(OBJEXT) watch.$(OBJEXT) \
 	wrapper.$(OBJEXT) zlib.$(OBJEXT)
 cvs_OBJECTS = $(am_cvs_OBJECTS)
-cvs_DEPENDENCIES = ../diff/libdiff.a ../lib/libcvs.a ../zlib/libz.a \
+cvs_DEPENDENCIES = ../diff/libdiff.a ../lib/libcvs.a @ZLIB_DEPEND@ \
 	version.o
 cvs_LDFLAGS =
 SCRIPTS = $(bin_SCRIPTS)
diff --git a/gnu/usr.bin/cvs/src/client.c b/gnu/usr.bin/cvs/src/client.c
index 999beb31f3b..c8870a6d737 100644
--- a/gnu/usr.bin/cvs/src/client.c
+++ b/gnu/usr.bin/cvs/src/client.c
@@ -4107,7 +4107,7 @@ start_tcp_server (tofdp, fromfdp)
     const char *portenv;
     int port;
     struct hostent *hp;
-    struct sockaddr_in sin;
+    struct sockaddr_in client_sai;
     char *hname;
 
     s = socket (AF_INET, SOCK_STREAM, 0);
@@ -4116,7 +4116,7 @@ start_tcp_server (tofdp, fromfdp)
 
     port = get_cvs_port_number (current_parsed_root);
 
-    hp = init_sockaddr (&sin, current_parsed_root->hostname, port);
+    hp = init_sockaddr (&client_sai, current_parsed_root->hostname, port);
 
     hname = xmalloc (strlen (hp->h_name) + 1);
     strcpy (hname, hp->h_name);
@@ -4128,7 +4128,7 @@ start_tcp_server (tofdp, fromfdp)
 		 inet_ntoa (client_sai.sin_addr), port);
     }
 
-    if (connect (s, (struct sockaddr *) &sin, sizeof sin) < 0)
+    if (connect (s, (struct sockaddr *) &client_sai, sizeof client_sai) < 0)
 	error (1, 0, "connect to %s(%s):%d failed: %s",
 	       current_parsed_root->hostname,
 	       inet_ntoa (client_sai.sin_addr),
@@ -4152,7 +4152,7 @@ start_tcp_server (tofdp, fromfdp)
 	/* We don't care about the checksum, and pass it as zero.  */
 	status = krb_sendauth (KOPT_DO_MUTUAL, s, &ticket, "rcmd",
 			       hname, realm, (unsigned long) 0, &msg_data,
-			       &cred, sched, &laddr, &sin, "KCVSV1.0");
+			       &cred, sched, &laddr, &client_sai, "KCVSV1.0");
 	if (status != KSUCCESS)
 	    error (1, 0, "kerberos authentication failed: %s",
 		   krb_get_err_text (status));
diff --git a/gnu/usr.bin/cvs/src/server.c b/gnu/usr.bin/cvs/src/server.c
index eae6ae95004..762a6d72438 100644
--- a/gnu/usr.bin/cvs/src/server.c
+++ b/gnu/usr.bin/cvs/src/server.c
@@ -5352,7 +5352,10 @@ error 0 %s: no such user\n", username);
     /* Set LOGNAME, USER and CVS_USER in the environment, in case they
        are already set to something else.  */
     {
-	char *env, *cvs_user;
+	char *env;
+#ifdef AUTH_SERVER_SUPPORT
+	char *cvs_user;
+#endif
 
 	env = xmalloc (sizeof "LOGNAME=" + strlen (username));
 	(void) sprintf (env, "LOGNAME=%s", username);
@@ -5362,10 +5365,12 @@ error 0 %s: no such user\n", username);
 	(void) sprintf (env, "USER=%s", username);
 	(void) putenv (env);
 
+#ifdef AUTH_SERVER_SUPPORT
         cvs_user = NULL != CVS_Username ? CVS_Username : "";
         env = xmalloc (sizeof "CVS_USER=" + strlen (cvs_user));
         (void) sprintf (env, "CVS_USER=%s", cvs_user);
         (void) putenv (env);
+#endif
     }
 #endif /* HAVE_PUTENV */
 }