Bring cvs-1.12.9 into the CVS repository
authorMatthew Dillon <dillon@dragonflybsd.org>
Tue, 3 Aug 2004 18:08:51 +0000 (18:08 +0000)
committerMatthew Dillon <dillon@dragonflybsd.org>
Tue, 3 Aug 2004 18:08:51 +0000 (18:08 +0000)
187 files changed:
contrib/cvs-1.12.9/ABOUT-NLS [new file with mode: 0644]
contrib/cvs-1.12.9/AUTHORS [new file with mode: 0644]
contrib/cvs-1.12.9/BUGS [new file with mode: 0644]
contrib/cvs-1.12.9/COPYING [new file with mode: 0644]
contrib/cvs-1.12.9/COPYING.LIB [new file with mode: 0644]
contrib/cvs-1.12.9/DEVEL-CVS [new file with mode: 0644]
contrib/cvs-1.12.9/HACKING [new file with mode: 0644]
contrib/cvs-1.12.9/INSTALL [new file with mode: 0644]
contrib/cvs-1.12.9/MINOR-BUGS [new file with mode: 0644]
contrib/cvs-1.12.9/NEWS [new file with mode: 0644]
contrib/cvs-1.12.9/PROJECTS [new file with mode: 0644]
contrib/cvs-1.12.9/README [new file with mode: 0644]
contrib/cvs-1.12.9/README.DELETED [new file with mode: 0644]
contrib/cvs-1.12.9/README.DRAGONFLY [new file with mode: 0644]
contrib/cvs-1.12.9/TESTS [new file with mode: 0644]
contrib/cvs-1.12.9/TODO [new file with mode: 0644]
contrib/cvs-1.12.9/configure [new file with mode: 0644]
contrib/cvs-1.12.9/contrib/README [new file with mode: 0644]
contrib/cvs-1.12.9/contrib/clmerge.in [new file with mode: 0644]
contrib/cvs-1.12.9/contrib/cln_hist.in [new file with mode: 0644]
contrib/cvs-1.12.9/contrib/commit_prep.in [new file with mode: 0644]
contrib/cvs-1.12.9/contrib/cvs2vendor.sh [new file with mode: 0644]
contrib/cvs-1.12.9/contrib/cvs_acls.in [new file with mode: 0644]
contrib/cvs-1.12.9/contrib/cvshelp.man [new file with mode: 0644]
contrib/cvs-1.12.9/contrib/descend.man [new file with mode: 0644]
contrib/cvs-1.12.9/contrib/intro.doc [new file with mode: 0644]
contrib/cvs-1.12.9/contrib/log.in [new file with mode: 0644]
contrib/cvs-1.12.9/contrib/log_accum.in [new file with mode: 0644]
contrib/cvs-1.12.9/contrib/mfpipe.in [new file with mode: 0644]
contrib/cvs-1.12.9/contrib/rcs-to-cvs.sh [new file with mode: 0644]
contrib/cvs-1.12.9/contrib/rcs2log.sh [new file with mode: 0644]
contrib/cvs-1.12.9/contrib/rcslock.in [new file with mode: 0644]
contrib/cvs-1.12.9/contrib/sccs2rcs.in [new file with mode: 0644]
contrib/cvs-1.12.9/diff/README [new file with mode: 0644]
contrib/cvs-1.12.9/diff/analyze.c [new file with mode: 0644]
contrib/cvs-1.12.9/diff/cmpbuf.c [new file with mode: 0644]
contrib/cvs-1.12.9/diff/cmpbuf.h [new file with mode: 0644]
contrib/cvs-1.12.9/diff/context.c [new file with mode: 0644]
contrib/cvs-1.12.9/diff/diff.c [new file with mode: 0644]
contrib/cvs-1.12.9/diff/diff.h [new file with mode: 0644]
contrib/cvs-1.12.9/diff/diff3.c [new file with mode: 0644]
contrib/cvs-1.12.9/diff/diffrun.h [new file with mode: 0644]
contrib/cvs-1.12.9/diff/dir.c [new file with mode: 0644]
contrib/cvs-1.12.9/diff/ed.c [new file with mode: 0644]
contrib/cvs-1.12.9/diff/ifdef.c [new file with mode: 0644]
contrib/cvs-1.12.9/diff/io.c [new file with mode: 0644]
contrib/cvs-1.12.9/diff/normal.c [new file with mode: 0644]
contrib/cvs-1.12.9/diff/side.c [new file with mode: 0644]
contrib/cvs-1.12.9/diff/system.h [new file with mode: 0644]
contrib/cvs-1.12.9/diff/util.c [new file with mode: 0644]
contrib/cvs-1.12.9/diff/version.c [new file with mode: 0644]
contrib/cvs-1.12.9/doc/cvs.1 [new file with mode: 0644]
contrib/cvs-1.12.9/doc/cvs.texinfo [new file with mode: 0644]
contrib/cvs-1.12.9/doc/cvsclient.texi [new file with mode: 0644]
contrib/cvs-1.12.9/doc/version-client.texi [new file with mode: 0644]
contrib/cvs-1.12.9/doc/version.texi [new file with mode: 0644]
contrib/cvs-1.12.9/lib/README [new file with mode: 0644]
contrib/cvs-1.12.9/lib/argmatch.c [new file with mode: 0644]
contrib/cvs-1.12.9/lib/asnprintf.c [new file with mode: 0644]
contrib/cvs-1.12.9/lib/basename.c [new file with mode: 0644]
contrib/cvs-1.12.9/lib/dirname.h [new file with mode: 0644]
contrib/cvs-1.12.9/lib/error.h [new file with mode: 0644]
contrib/cvs-1.12.9/lib/exit.h [new file with mode: 0644]
contrib/cvs-1.12.9/lib/exitfail.c [new file with mode: 0644]
contrib/cvs-1.12.9/lib/exitfail.h [new file with mode: 0644]
contrib/cvs-1.12.9/lib/getdate.y [new file with mode: 0644]
contrib/cvs-1.12.9/lib/getline.c [new file with mode: 0644]
contrib/cvs-1.12.9/lib/getline.h [new file with mode: 0644]
contrib/cvs-1.12.9/lib/getndelim2.c [new file with mode: 0644]
contrib/cvs-1.12.9/lib/getndelim2.h [new file with mode: 0644]
contrib/cvs-1.12.9/lib/getnline.c [new file with mode: 0644]
contrib/cvs-1.12.9/lib/getnline.h [new file with mode: 0644]
contrib/cvs-1.12.9/lib/getopt.c [new file with mode: 0644]
contrib/cvs-1.12.9/lib/getopt.h [new file with mode: 0644]
contrib/cvs-1.12.9/lib/getopt1.c [new file with mode: 0644]
contrib/cvs-1.12.9/lib/getpass.c [new file with mode: 0644]
contrib/cvs-1.12.9/lib/gettext.h [new file with mode: 0644]
contrib/cvs-1.12.9/lib/lstat.c [new file with mode: 0644]
contrib/cvs-1.12.9/lib/md5.c [new file with mode: 0644]
contrib/cvs-1.12.9/lib/md5.h [new file with mode: 0644]
contrib/cvs-1.12.9/lib/pathmax.h [new file with mode: 0644]
contrib/cvs-1.12.9/lib/printf-args.c [new file with mode: 0644]
contrib/cvs-1.12.9/lib/printf-args.h [new file with mode: 0644]
contrib/cvs-1.12.9/lib/printf-parse.c [new file with mode: 0644]
contrib/cvs-1.12.9/lib/printf-parse.h [new file with mode: 0644]
contrib/cvs-1.12.9/lib/regex.h [new file with mode: 0644]
contrib/cvs-1.12.9/lib/savecwd.c [new file with mode: 0644]
contrib/cvs-1.12.9/lib/savecwd.h [new file with mode: 0644]
contrib/cvs-1.12.9/lib/sighandle.c [new file with mode: 0644]
contrib/cvs-1.12.9/lib/stat.c [new file with mode: 0644]
contrib/cvs-1.12.9/lib/stripslash.c [new file with mode: 0644]
contrib/cvs-1.12.9/lib/system.h [new file with mode: 0644]
contrib/cvs-1.12.9/lib/timespec.h [new file with mode: 0644]
contrib/cvs-1.12.9/lib/unlocked-io.h [new file with mode: 0644]
contrib/cvs-1.12.9/lib/vasnprintf.c [new file with mode: 0644]
contrib/cvs-1.12.9/lib/vasnprintf.h [new file with mode: 0644]
contrib/cvs-1.12.9/lib/wait.h [new file with mode: 0644]
contrib/cvs-1.12.9/lib/xalloc.h [new file with mode: 0644]
contrib/cvs-1.12.9/lib/xgetwd.c [new file with mode: 0644]
contrib/cvs-1.12.9/lib/xmalloc.c [new file with mode: 0644]
contrib/cvs-1.12.9/lib/xselect.h [new file with mode: 0644]
contrib/cvs-1.12.9/lib/xsize.h [new file with mode: 0644]
contrib/cvs-1.12.9/lib/xstrdup.c [new file with mode: 0644]
contrib/cvs-1.12.9/lib/xtime.h [new file with mode: 0644]
contrib/cvs-1.12.9/lib/yesno.c [new file with mode: 0644]
contrib/cvs-1.12.9/man/cvs.5 [new file with mode: 0644]
contrib/cvs-1.12.9/man/cvsbug.8 [new file with mode: 0644]
contrib/cvs-1.12.9/src/add.c [new file with mode: 0644]
contrib/cvs-1.12.9/src/admin.c [new file with mode: 0644]
contrib/cvs-1.12.9/src/annotate.c [new file with mode: 0644]
contrib/cvs-1.12.9/src/buffer.c [new file with mode: 0644]
contrib/cvs-1.12.9/src/buffer.h [new file with mode: 0644]
contrib/cvs-1.12.9/src/checkin.c [new file with mode: 0644]
contrib/cvs-1.12.9/src/checkout.c [new file with mode: 0644]
contrib/cvs-1.12.9/src/classify.c [new file with mode: 0644]
contrib/cvs-1.12.9/src/client.c [new file with mode: 0644]
contrib/cvs-1.12.9/src/client.h [new file with mode: 0644]
contrib/cvs-1.12.9/src/commit.c [new file with mode: 0644]
contrib/cvs-1.12.9/src/create_adm.c [new file with mode: 0644]
contrib/cvs-1.12.9/src/cvs.h [new file with mode: 0644]
contrib/cvs-1.12.9/src/cvsbug.in [new file with mode: 0644]
contrib/cvs-1.12.9/src/cvsrc.c [new file with mode: 0644]
contrib/cvs-1.12.9/src/diff.c [new file with mode: 0644]
contrib/cvs-1.12.9/src/edit.c [new file with mode: 0644]
contrib/cvs-1.12.9/src/edit.h [new file with mode: 0644]
contrib/cvs-1.12.9/src/entries.c [new file with mode: 0644]
contrib/cvs-1.12.9/src/error.c [new file with mode: 0644]
contrib/cvs-1.12.9/src/exithandle.c [new file with mode: 0644]
contrib/cvs-1.12.9/src/expand_path.c [new file with mode: 0644]
contrib/cvs-1.12.9/src/fileattr.c [new file with mode: 0644]
contrib/cvs-1.12.9/src/fileattr.h [new file with mode: 0644]
contrib/cvs-1.12.9/src/filesubr.c [new file with mode: 0644]
contrib/cvs-1.12.9/src/find_names.c [new file with mode: 0644]
contrib/cvs-1.12.9/src/hardlink.c [new file with mode: 0644]
contrib/cvs-1.12.9/src/hardlink.h [new file with mode: 0644]
contrib/cvs-1.12.9/src/hash.c [new file with mode: 0644]
contrib/cvs-1.12.9/src/hash.h [new file with mode: 0644]
contrib/cvs-1.12.9/src/history.c [new file with mode: 0644]
contrib/cvs-1.12.9/src/history.h [new file with mode: 0644]
contrib/cvs-1.12.9/src/ignore.c [new file with mode: 0644]
contrib/cvs-1.12.9/src/import.c [new file with mode: 0644]
contrib/cvs-1.12.9/src/lock.c [new file with mode: 0644]
contrib/cvs-1.12.9/src/log-buffer.c [new file with mode: 0644]
contrib/cvs-1.12.9/src/log-buffer.h [new file with mode: 0644]
contrib/cvs-1.12.9/src/log.c [new file with mode: 0644]
contrib/cvs-1.12.9/src/login.c [new file with mode: 0644]
contrib/cvs-1.12.9/src/logmsg.c [new file with mode: 0644]
contrib/cvs-1.12.9/src/ls.c [new file with mode: 0644]
contrib/cvs-1.12.9/src/main.c [new file with mode: 0644]
contrib/cvs-1.12.9/src/mkmodules.c [new file with mode: 0644]
contrib/cvs-1.12.9/src/modules.c [new file with mode: 0644]
contrib/cvs-1.12.9/src/myndbm.c [new file with mode: 0644]
contrib/cvs-1.12.9/src/myndbm.h [new file with mode: 0644]
contrib/cvs-1.12.9/src/no_diff.c [new file with mode: 0644]
contrib/cvs-1.12.9/src/parseinfo.c [new file with mode: 0644]
contrib/cvs-1.12.9/src/patch.c [new file with mode: 0644]
contrib/cvs-1.12.9/src/rcs.c [new file with mode: 0644]
contrib/cvs-1.12.9/src/rcs.h [new file with mode: 0644]
contrib/cvs-1.12.9/src/rcscmds.c [new file with mode: 0644]
contrib/cvs-1.12.9/src/recurse.c [new file with mode: 0644]
contrib/cvs-1.12.9/src/release.c [new file with mode: 0644]
contrib/cvs-1.12.9/src/remove.c [new file with mode: 0644]
contrib/cvs-1.12.9/src/repos.c [new file with mode: 0644]
contrib/cvs-1.12.9/src/root.c [new file with mode: 0644]
contrib/cvs-1.12.9/src/root.h [new file with mode: 0644]
contrib/cvs-1.12.9/src/rsh-client.c [new file with mode: 0644]
contrib/cvs-1.12.9/src/rsh-client.h [new file with mode: 0644]
contrib/cvs-1.12.9/src/run.c [new file with mode: 0644]
contrib/cvs-1.12.9/src/scramble.c [new file with mode: 0644]
contrib/cvs-1.12.9/src/server.c [new file with mode: 0644]
contrib/cvs-1.12.9/src/server.h [new file with mode: 0644]
contrib/cvs-1.12.9/src/socket-client.c [new file with mode: 0644]
contrib/cvs-1.12.9/src/socket-client.h [new file with mode: 0644]
contrib/cvs-1.12.9/src/stack.c [new file with mode: 0644]
contrib/cvs-1.12.9/src/stack.h [new file with mode: 0644]
contrib/cvs-1.12.9/src/status.c [new file with mode: 0644]
contrib/cvs-1.12.9/src/subr.c [new file with mode: 0644]
contrib/cvs-1.12.9/src/tag.c [new file with mode: 0644]
contrib/cvs-1.12.9/src/update.c [new file with mode: 0644]
contrib/cvs-1.12.9/src/update.h [new file with mode: 0644]
contrib/cvs-1.12.9/src/vers_ts.c [new file with mode: 0644]
contrib/cvs-1.12.9/src/version.c [new file with mode: 0644]
contrib/cvs-1.12.9/src/watch.c [new file with mode: 0644]
contrib/cvs-1.12.9/src/watch.h [new file with mode: 0644]
contrib/cvs-1.12.9/src/wrapper.c [new file with mode: 0644]
contrib/cvs-1.12.9/src/zlib.c [new file with mode: 0644]
contrib/cvs-1.12.9/tools/README [new file with mode: 0644]

diff --git a/contrib/cvs-1.12.9/ABOUT-NLS b/contrib/cvs-1.12.9/ABOUT-NLS
new file mode 100644 (file)
index 0000000..da27fad
--- /dev/null
@@ -0,0 +1,5 @@
+Automake started requiring this file after I included the gettext support from
+GNULIB <http://savannah.gnu.org/projects/gnulib>.  I'm not sure why, exactly,
+but there was an nls.m4 macro I had to import which claims that NLS stands for
+"Native Language Support".  If someone would like to replace this ABOUT-NLS
+file with a more appropriate one, please do.
diff --git a/contrib/cvs-1.12.9/AUTHORS b/contrib/cvs-1.12.9/AUTHORS
new file mode 100644 (file)
index 0000000..300b6dc
--- /dev/null
@@ -0,0 +1,88 @@
+Authors of GNU CVS
+
+The conflict-resolution algorithms and much of the administrative file
+definitions of CVS were based on the original package written by Dick Grune
+at Vrije Universiteit in Amsterdam <dick@cs.vu.nl>, and posted to
+comp.sources.unix in the volume 6 release sometime in 1986.  This original
+version was a collection of shell scripts.  I am thankful that Dick made
+his work available.
+
+Brian Berliner from Prisma, Inc. (now at Sun Microsystems, Inc.)
+<berliner@sun.com> converted the original CVS shell scripts into reasonably
+fast C and added many, many features to support software release control
+functions.  See the manual page in the "man" directory.  A copy of the
+USENIX article presented at the Winter 1990 USENIX Conference, Washington
+D.C., is included in the "doc" directory.
+
+Jeff Polk from BSDI <polk@bsdi.com> converted the CVS 1.2
+sources into much more readable and maintainable C code.  He also added a
+whole lot of functionality and modularity to the code in the process.
+See the bottom of the NEWS file (from about 1992).
+
+david d `zoo' zuhn <zoo@armadillo.com> contributed the working base code
+for CVS 1.4 Alpha.  His work carries on from work done by K. Richard Pixley
+and others at Cygnus Support.  The CVS 1.4 upgrade is due in large part to
+Zoo's efforts.
+
+David G. Grubbs <dgg@odi.com> contributed the CVS "history" and "release"
+commands.  As well as the ever-so-useful "-n" option of CVS which tells CVS
+to show what it would do, without actually doing it.  He also contributed
+support for the .cvsignore file.
+
+The Free Software Foundation (GNU) contributed most of the portability
+framework that CVS now uses.  This can be found in the "configure" script,
+the Makefile's, and basically most of the "lib" directory.
+
+K. Richard Pixley, Cygnus Support <rich@cygnus.com> contributed many bug
+fixes/enhancement as well as completing early reviews of the CVS 1.3 manual
+pages.
+
+Roland Pesch, then of Cygnus Support <roland@wrs.com> contributed
+brand new cvs(1) and cvs(5) manual pages.  Thanks to him for saving us
+from poor use of our language!
+
+Paul Sander, HaL Computer Systems, Inc. <paul@hal.com> wrote and
+contributed the code in lib/sighandle.c.  I added support for POSIX, BSD,
+and non-POSIX/non-BSD systems.
+
+Jim Kingdon and others at Cygnus Support <info@cygnus.com> wrote the
+remote repository access code.
+
+Larry Jones and Derek Price <derek@ximbiot.com> have been maintaining and
+enhancing CVS for some years.  Mark D. Baushke <mdb@cvshome.org> came on in
+2003.
+
+There have been many, many contributions not listed here.  Consult the
+individual ChangeLog files in each directory for a more complete idea.
+
+In addition to the above contributors, the following Beta testers
+deserve special mention for their support.  This is only a partial
+list; if you have helped in this way and would like to be listed, let
+bug-cvs know (as described in the Cederqvist manual).
+
+       Mark D. Baushke <mdb@cisco.com>
+       Per Cederqvist <ceder@signum.se>
+       J.T. Conklin <jtc@cygnus.com>
+       Vince DeMarco <vdemarco@fdcsrvr.cs.mci.com>
+       Paul Eggert <eggert@twinsun.com>
+       Lal George <george@research.att.com>
+       Dean E. Hardi <Dean.E.Hardi@ccmail.jpl.nasa.gov>
+       Mike Heath <mike@pencom.com>
+       Jim Kingdon <kingdon@cygnus.com>
+       Bernd Leibing <bernd.leibing@rz.uni-ulm.de>
+       Benedict Lofstedt <benedict@tusc.com.au>
+       Dave Love <d.love@dl.ac.uk>
+       Robert Lupton the Good <rhl@astro.princeton.edu>
+       Tom McAliney <tom@hilco.com>
+       Eberhard Mattes <mattes@azu.informatik.uni-stuttgart.de>
+       Jim Meyering <meyering@comco.com>
+       Thomas Mohr <mohr@lts.sel.alcatel.de>
+       Thomas Nilsson <thoni@softlab.se>
+       Raye Raskin <raye.raskin@lia.com>
+       Harlan Stenn <harlan@landmark.com>
+       Gunnar Tornblom <gunnar.tornblom@senet.abb.se>
+       Greg A. Woods <woods@planix.com>
+
+Many contributors have added code to the "contrib" directory.  See the
+README file there for a list of what is available.  There is also a
+contributed GNU Emacs CVS-mode in tools/pcl-cvs.
diff --git a/contrib/cvs-1.12.9/BUGS b/contrib/cvs-1.12.9/BUGS
new file mode 100644 (file)
index 0000000..5d9b3e3
--- /dev/null
@@ -0,0 +1,122 @@
+See the Cederqvist manual (cvs.texinfo) for information on how to
+report bugs (and what will happen to your bug reports if you do).
+
+The following is a list of some of the known bugs.  It may or may not
+be comprehensive.  We would dearly love for people to volunteer to
+help us keep it up to date (for starters, if you notice any
+inaccuracies, please let bug-cvs know as described in the Cederqvist
+manual).  There are some other reported bugs in MINOR-BUGS; the
+difference, at least in theory, is that those bugs are less serious.
+
+
+* For platform-specific information (in some cases including known
+bugs), see README.VMS, windows-NT/README, or os2/README.  There is no
+similar file for the unix-like operating systems (not yet, at least).
+This file also might contain some platform-specific bugs.
+
+
+* If your login name contains a space or various other characters
+(particularly an issue on Windows), CVS will have trouble (it will
+write invalid RCS files, probably).  The fix would be to have CVS
+change such characters to underscores before writing them to the RCS
+file.  Furthermore, the LOGNAME or USER environment variables usually
+won't override the system login name, so this can be hard to work
+around.
+
+
+* If you specify the -w global option to client/server CVS, it only
+overrides a CVSREAD environment variable set on the client, not a
+CVSREAD variable which was set on the server (for example, in .bashrc
+when the server was run via rsh).  The fix of course will be to
+provide a "Option-read-write" request which sends -w, in addition to
+"Global_option -r" which sends -r.
+
+
+* Symbolic links to files will not work with or without LockDir.  In the
+repository, you should avoid using symbolic links to files since this issue
+can cause data loss.  Symlinks are only a problem when writing files.  If your
+repository does not allow any write access, symlinks are not a problem.
+
+
+* Symbolic links to directories will not work with LockDir.  In the
+repository, you should avoid using symbolic links to directories if
+you intend to use LockDir as the correct directory will NOT be locked
+by CVS during write.  Directory symlinks are not recommended, but should work
+as long as LockDir is not being used.  Symlinks are only a problem when
+writing files.  If your repository does not allow any write access, symlinks
+are never a problem, whether or not LockDir is in use.
+
+
+* The -m option to "cvs add" does not work with client/server CVS.
+CVS will accept the option, but it won't actually set the
+file's description.
+
+
+* cvs update walks into a user's work directory if there's a directory
+  of the same name in the repository even if the user's directory
+  doesn't yet have a CVS admin sub-directory.  This can greatly confuse
+  users who try to add the same directory at nearly the same time.
+
+
+* From: "Charles M. Hannum" <mycroft@ai.mit.edu>
+  To: info-cvs@prep.ai.mit.edu
+  Subject: Still one more bug
+  Date: Sat, 25 Feb 1995 17:01:15 -0500
+  
+  mycroft@duality [1]; cd /usr/src/lib/libc
+  mycroft@duality [1]; cvs diff -C2 '-D1 day ago' -Dnow
+  cvs server: Diffing .
+  cvs server: Diffing DB
+  cvs [server aborted]: could not chdir to DB: No such file or directory
+  mycroft@duality [1];
+  
+  `DB' is an old directory, which no longer has files in it, and is
+  removed automatically when I use the `-P' option to checkout.
+  
+  This error doesn't occur when run locally.
+  
+  P.S.  Is anyone working on fixing these bugs?
+
+
+* CVS does not always seem to be waiting to the next filesystem timestamp
+quanta after commits.  So far this has only shown up in testing under the BSDI
+OS.  The symptoms are that ocassionally CVS will not notice that modified files
+are modified, though the file must be modified within a short time after the
+commit, probably milliseconds or seconds, for this symptom to be noticed.  One
+suspected cause is that one of the calls to sleep_past() is being called with
+an incorrect value, though this does not explain why symptoms have only been
+noticed under BSDI.
+
+
+* Spaces in arguments to `cvs diff' are currently split on spaces and tabs
+before being passed to diff.  This can often cause diff to abort since it can
+no longer interpret its options string and if it can, coincidentally,
+interpret its option string, then the problem may be output in unexpected
+formats.
+
+
+* `release' of a project subdir does not remove the `subdir' entry from
+  `./CVS/Entries'.
+
+
+* CVS currently breaks at an assertion failure when `cvs ls <filename>' is used
+  to list information for a single file.
+
+* Most of the remote commands are encountering assertion failures when listing
+  the toplevel of the repository (e.g. `cvs rlog .').  This appears to be
+  related to the symlinked CVS root fix.
+
+
+* Status
+
+  This experimental version of CVS contains new features which may not have
+  been tested as thoroughly as the stable release.  It is classified as:
+
+                          /*-------------.
+                          | Experimental |
+                          `-------------*/
+
+                     /*-------------------------.
+                     | Sane for full scale use. |
+                     `-------------------------*/
+
diff --git a/contrib/cvs-1.12.9/COPYING b/contrib/cvs-1.12.9/COPYING
new file mode 100644 (file)
index 0000000..57da8a4
--- /dev/null
@@ -0,0 +1,251 @@
+[I have snipped the snail mail address of the FSF because it has
+changed in the past and is likely to change again.  The current
+address should be at http://www.gnu.org/]
+
+                   GNU GENERAL PUBLIC LICENSE
+                    Version 1, February 1989
+
+ Copyright (C) 1989 Free Software Foundation, Inc.
+ Everyone is permitted to copy and distribute verbatim copies
+ of this license document, but changing it is not allowed.
+
+                           Preamble
+
+  The license agreements of most software companies try to keep users
+at the mercy of those companies.  By contrast, our 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.  The
+General Public License applies to the Free Software Foundation's
+software and to any other program whose authors commit to using it.
+You can use it for your programs, too.
+
+  When we speak of free software, we are referring to freedom, not
+price.  Specifically, the General Public License is designed to make
+sure that you have the freedom to give away or sell copies of free
+software, 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 a 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 tell them 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.
+
+  The precise terms and conditions for copying, distribution and
+modification follow.
+\f
+                   GNU GENERAL PUBLIC LICENSE
+   TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
+
+  0. This License Agreement 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 work containing the
+Program or a portion of it, either verbatim or with modifications.  Each
+licensee is addressed as "you".
+
+  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
+General Public License and to the absence of any warranty; and give any
+other recipients of the Program a copy of this General Public License
+along with the Program.  You may charge a fee for the physical act of
+transferring a copy.
+
+  2. You may modify your copy or copies of the Program or any portion of
+it, and copy and distribute such modifications under the terms of Paragraph
+1 above, provided that you also do the following:
+
+    a) cause the modified files to carry prominent notices stating that
+    you changed the files and the date of any change; and
+
+    b) cause the whole of any work that you distribute or publish, that
+    in whole or in part contains the Program or any part thereof, either
+    with or without modifications, to be licensed at no charge to all
+    third parties under the terms of this General Public License (except
+    that you may choose to grant warranty protection to some or all
+    third parties, at your option).
+
+    c) If the modified program normally reads commands interactively when
+    run, you must cause it, when started running for such interactive use
+    in the simplest and most usual 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 General
+    Public License.
+
+    d) 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.
+
+Mere aggregation of another independent work with the Program (or its
+derivative) on a volume of a storage or distribution medium does not bring
+the other work under the scope of these terms.
+\f
+  3. You may copy and distribute the Program (or a portion or derivative of
+it, under Paragraph 2) in object code or executable form under the terms of
+Paragraphs 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
+    Paragraphs 1 and 2 above; or,
+
+    b) accompany it with a written offer, valid for at least three
+    years, to give any third party free (except for a nominal charge
+    for the cost of distribution) a complete machine-readable copy of the
+    corresponding source code, to be distributed under the terms of
+    Paragraphs 1 and 2 above; or,
+
+    c) accompany it with the information you received as to where the
+    corresponding source code may be obtained.  (This alternative is
+    allowed only for noncommercial distribution and only if you
+    received the program in object code or executable form alone.)
+
+Source code for a work means the preferred form of the work for making
+modifications to it.  For an executable file, complete source code means
+all the source code for all modules it contains; but, as a special
+exception, it need not include source code for modules which are standard
+libraries that accompany the operating system on which the executable
+file runs, or for standard header files or definitions files that
+accompany that operating system.
+
+  4. You may not copy, modify, sublicense, distribute or transfer the
+Program except as expressly provided under this General Public License.
+Any attempt otherwise to copy, modify, sublicense, distribute or transfer
+the Program is void, and will automatically terminate your rights to use
+the Program under this License.  However, parties who have received
+copies, or rights to use copies, from you under this General Public
+License will not have their licenses terminated so long as such parties
+remain in full compliance.
+
+  5. By copying, distributing or modifying 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.
+
+  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.
+\f
+  7. 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 the 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
+the license, you may choose any version ever published by the Free Software
+Foundation.
+
+  8. 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
+
+  9. 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.
+
+  10. 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
+\f
+       Appendix: 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 humanity, 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 1, 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.
+
+    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.
+
+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) 19xx 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 a sample; alter the names:
+
+  Yoyodyne, Inc., hereby disclaims all copyright interest in the
+  program `Gnomovision' (a program to direct compilers to make passes
+  at assemblers) written by James Hacker.
+
+  <signature of Ty Coon>, 1 April 1989
+  Ty Coon, President of Vice
+
+That's all there is to it!
diff --git a/contrib/cvs-1.12.9/COPYING.LIB b/contrib/cvs-1.12.9/COPYING.LIB
new file mode 100644 (file)
index 0000000..5e5cda2
--- /dev/null
@@ -0,0 +1,484 @@
+[I have snipped the snail mail address of the FSF because it has
+changed in the past and is likely to change again.  The current
+address should be at http://www.gnu.org/]
+
+                 GNU LIBRARY GENERAL PUBLIC LICENSE
+                      Version 2, June 1991
+
+ Copyright (C) 1991 Free Software Foundation, Inc.
+ Everyone is permitted to copy and distribute verbatim copies
+ of this license document, but changing it is not allowed.
+
+[This is the first released version of the library GPL.  It is
+ numbered 2 because it goes with version 2 of the ordinary GPL.]
+
+                           Preamble
+
+  The licenses for most software are designed to take away your
+freedom to share and change it.  By contrast, the GNU General Public
+Licenses are intended to guarantee your freedom to share and change
+free software--to make sure the software is free for all its users.
+
+  This license, the Library General Public License, applies to some
+specially designated Free Software Foundation software, and to any
+other libraries whose authors decide to use it.  You can use it for
+your libraries, 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 library, or if you modify it.
+
+  For example, if you distribute copies of the library, whether gratis
+or for a fee, you must give the recipients all the rights that we gave
+you.  You must make sure that they, too, receive or can get the source
+code.  If you link a program with the library, you must provide
+complete object files to the recipients so that they can relink them
+with the library, after making changes to the library and recompiling
+it.  And you must show them these terms so they know their rights.
+
+  Our method of protecting your rights has two steps: (1) copyright
+the library, and (2) offer you this license which gives you legal
+permission to copy, distribute and/or modify the library.
+
+  Also, for each distributor's protection, we want to make certain
+that everyone understands that there is no warranty for this free
+library.  If the library is modified by someone else and passed on, we
+want its recipients to know that what they have is not the original
+version, so that any problems introduced by others will not reflect on
+the original authors' reputations.
+\f
+  Finally, any free program is threatened constantly by software
+patents.  We wish to avoid the danger that companies distributing free
+software will individually obtain patent licenses, thus in effect
+transforming the program into proprietary software.  To prevent this,
+we have made it clear that any patent must be licensed for everyone's
+free use or not licensed at all.
+
+  Most GNU software, including some libraries, is covered by the ordinary
+GNU General Public License, which was designed for utility programs.  This
+license, the GNU Library General Public License, applies to certain
+designated libraries.  This license is quite different from the ordinary
+one; be sure to read it in full, and don't assume that anything in it is
+the same as in the ordinary license.
+
+  The reason we have a separate public license for some libraries is that
+they blur the distinction we usually make between modifying or adding to a
+program and simply using it.  Linking a program with a library, without
+changing the library, is in some sense simply using the library, and is
+analogous to running a utility program or application program.  However, in
+a textual and legal sense, the linked executable is a combined work, a
+derivative of the original library, and the ordinary General Public License
+treats it as such.
+
+  Because of this blurred distinction, using the ordinary General
+Public License for libraries did not effectively promote software
+sharing, because most developers did not use the libraries.  We
+concluded that weaker conditions might promote sharing better.
+
+  However, unrestricted linking of non-free programs would deprive the
+users of those programs of all benefit from the free status of the
+libraries themselves.  This Library General Public License is intended to
+permit developers of non-free programs to use free libraries, while
+preserving your freedom as a user of such programs to change the free
+libraries that are incorporated in them.  (We have not seen how to achieve
+this as regards changes in header files, but we have achieved it as regards
+changes in the actual functions of the Library.)  The hope is that this
+will lead to faster development of free libraries.
+
+  The precise terms and conditions for copying, distribution and
+modification follow.  Pay close attention to the difference between a
+"work based on the library" and a "work that uses the library".  The
+former contains code derived from the library, while the latter only
+works together with the library.
+
+  Note that it is possible for a library to be covered by the ordinary
+General Public License rather than by this special one.
+\f
+                 GNU LIBRARY GENERAL PUBLIC LICENSE
+   TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
+
+  0. This License Agreement applies to any software library which
+contains a notice placed by the copyright holder or other authorized
+party saying it may be distributed under the terms of this Library
+General Public License (also called "this License").  Each licensee is
+addressed as "you".
+
+  A "library" means a collection of software functions and/or data
+prepared so as to be conveniently linked with application programs
+(which use some of those functions and data) to form executables.
+
+  The "Library", below, refers to any such software library or work
+which has been distributed under these terms.  A "work based on the
+Library" means either the Library or any derivative work under
+copyright law: that is to say, a work containing the Library or a
+portion of it, either verbatim or with modifications and/or translated
+straightforwardly into another language.  (Hereinafter, translation is
+included without limitation in the term "modification".)
+
+  "Source code" for a work means the preferred form of the work for
+making modifications to it.  For a library, 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 library.
+
+  Activities other than copying, distribution and modification are not
+covered by this License; they are outside its scope.  The act of
+running a program using the Library is not restricted, and output from
+such a program is covered only if its contents constitute a work based
+on the Library (independent of the use of the Library in a tool for
+writing it).  Whether that is true depends on what the Library does
+and what the program that uses the Library does.
+  
+  1. You may copy and distribute verbatim copies of the Library's
+complete 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 distribute a copy of this License along with the
+Library.
+
+  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.
+\f
+  2. You may modify your copy or copies of the Library or any portion
+of it, thus forming a work based on the Library, 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) The modified work must itself be a software library.
+
+    b) You must cause the files modified to carry prominent notices
+    stating that you changed the files and the date of any change.
+
+    c) You must cause the whole of the work to be licensed at no
+    charge to all third parties under the terms of this License.
+
+    d) If a facility in the modified Library refers to a function or a
+    table of data to be supplied by an application program that uses
+    the facility, other than as an argument passed when the facility
+    is invoked, then you must make a good faith effort to ensure that,
+    in the event an application does not supply such function or
+    table, the facility still operates, and performs whatever part of
+    its purpose remains meaningful.
+
+    (For example, a function in a library to compute square roots has
+    a purpose that is entirely well-defined independent of the
+    application.  Therefore, Subsection 2d requires that any
+    application-supplied function or table used by this function must
+    be optional: if the application does not supply it, the square
+    root function must still compute square roots.)
+
+These requirements apply to the modified work as a whole.  If
+identifiable sections of that work are not derived from the Library,
+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 Library, 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 Library.
+
+In addition, mere aggregation of another work not based on the Library
+with the Library (or with a work based on the Library) on a volume of
+a storage or distribution medium does not bring the other work under
+the scope of this License.
+
+  3. You may opt to apply the terms of the ordinary GNU General Public
+License instead of this License to a given copy of the Library.  To do
+this, you must alter all the notices that refer to this License, so
+that they refer to the ordinary GNU General Public License, version 2,
+instead of to this License.  (If a newer version than version 2 of the
+ordinary GNU General Public License has appeared, then you can specify
+that version instead if you wish.)  Do not make any other change in
+these notices.
+\f
+  Once this change is made in a given copy, it is irreversible for
+that copy, so the ordinary GNU General Public License applies to all
+subsequent copies and derivative works made from that copy.
+
+  This option is useful when you wish to copy part of the code of
+the Library into a program that is not a library.
+
+  4. You may copy and distribute the Library (or a portion or
+derivative of it, under Section 2) in object code or executable form
+under the terms of Sections 1 and 2 above provided that you 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.
+
+  If distribution of 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 satisfies the requirement to
+distribute the source code, even though third parties are not
+compelled to copy the source along with the object code.
+
+  5. A program that contains no derivative of any portion of the
+Library, but is designed to work with the Library by being compiled or
+linked with it, is called a "work that uses the Library".  Such a
+work, in isolation, is not a derivative work of the Library, and
+therefore falls outside the scope of this License.
+
+  However, linking a "work that uses the Library" with the Library
+creates an executable that is a derivative of the Library (because it
+contains portions of the Library), rather than a "work that uses the
+library".  The executable is therefore covered by this License.
+Section 6 states terms for distribution of such executables.
+
+  When a "work that uses the Library" uses material from a header file
+that is part of the Library, the object code for the work may be a
+derivative work of the Library even though the source code is not.
+Whether this is true is especially significant if the work can be
+linked without the Library, or if the work is itself a library.  The
+threshold for this to be true is not precisely defined by law.
+
+  If such an object file uses only numerical parameters, data
+structure layouts and accessors, and small macros and small inline
+functions (ten lines or less in length), then the use of the object
+file is unrestricted, regardless of whether it is legally a derivative
+work.  (Executables containing this object code plus portions of the
+Library will still fall under Section 6.)
+
+  Otherwise, if the work is a derivative of the Library, you may
+distribute the object code for the work under the terms of Section 6.
+Any executables containing that work also fall under Section 6,
+whether or not they are linked directly with the Library itself.
+\f
+  6. As an exception to the Sections above, you may also compile or
+link a "work that uses the Library" with the Library to produce a
+work containing portions of the Library, and distribute that work
+under terms of your choice, provided that the terms permit
+modification of the work for the customer's own use and reverse
+engineering for debugging such modifications.
+
+  You must give prominent notice with each copy of the work that the
+Library is used in it and that the Library and its use are covered by
+this License.  You must supply a copy of this License.  If the work
+during execution displays copyright notices, you must include the
+copyright notice for the Library among them, as well as a reference
+directing the user to the copy of this License.  Also, you must do one
+of these things:
+
+    a) Accompany the work with the complete corresponding
+    machine-readable source code for the Library including whatever
+    changes were used in the work (which must be distributed under
+    Sections 1 and 2 above); and, if the work is an executable linked
+    with the Library, with the complete machine-readable "work that
+    uses the Library", as object code and/or source code, so that the
+    user can modify the Library and then relink to produce a modified
+    executable containing the modified Library.  (It is understood
+    that the user who changes the contents of definitions files in the
+    Library will not necessarily be able to recompile the application
+    to use the modified definitions.)
+
+    b) Accompany the work with a written offer, valid for at
+    least three years, to give the same user the materials
+    specified in Subsection 6a, above, for a charge no more
+    than the cost of performing this distribution.
+
+    c) If distribution of the work is made by offering access to copy
+    from a designated place, offer equivalent access to copy the above
+    specified materials from the same place.
+
+    d) Verify that the user has already received a copy of these
+    materials or that you have already sent this user a copy.
+
+  For an executable, the required form of the "work that uses the
+Library" must include any data and utility programs needed for
+reproducing the executable from it.  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.
+
+  It may happen that this requirement contradicts the license
+restrictions of other proprietary libraries that do not normally
+accompany the operating system.  Such a contradiction means you cannot
+use both them and the Library together in an executable that you
+distribute.
+\f
+  7. You may place library facilities that are a work based on the
+Library side-by-side in a single library together with other library
+facilities not covered by this License, and distribute such a combined
+library, provided that the separate distribution of the work based on
+the Library and of the other library facilities is otherwise
+permitted, and provided that you do these two things:
+
+    a) Accompany the combined library with a copy of the same work
+    based on the Library, uncombined with any other library
+    facilities.  This must be distributed under the terms of the
+    Sections above.
+
+    b) Give prominent notice with the combined library of the fact
+    that part of it is a work based on the Library, and explaining
+    where to find the accompanying uncombined form of the same work.
+
+  8. You may not copy, modify, sublicense, link with, or distribute
+the Library except as expressly provided under this License.  Any
+attempt otherwise to copy, modify, sublicense, link with, or
+distribute the Library 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.
+
+  9. 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 Library or its derivative works.  These actions are
+prohibited by law if you do not accept this License.  Therefore, by
+modifying or distributing the Library (or any work based on the
+Library), you indicate your acceptance of this License to do so, and
+all its terms and conditions for copying, distributing or modifying
+the Library or works based on it.
+
+  10. Each time you redistribute the Library (or any work based on the
+Library), the recipient automatically receives a license from the
+original licensor to copy, distribute, link with or modify the Library
+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.
+\f
+  11. 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 Library at all.  For example, if a patent
+license would not permit royalty-free redistribution of the Library 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 Library.
+
+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.
+
+  12. If the distribution and/or use of the Library is restricted in
+certain countries either by patents or by copyrighted interfaces, the
+original copyright holder who places the Library 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.
+
+  13. The Free Software Foundation may publish revised and/or new
+versions of the Library 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 Library
+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 Library does not specify a
+license version number, you may choose any version ever published by
+the Free Software Foundation.
+\f
+  14. If you wish to incorporate parts of the Library into other free
+programs whose distribution conditions are incompatible with these,
+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
+
+  15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO
+WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW.
+EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR
+OTHER PARTIES PROVIDE THE LIBRARY "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
+LIBRARY IS WITH YOU.  SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME
+THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
+
+  16. 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 LIBRARY 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
+LIBRARY (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 LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF
+SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH
+DAMAGES.
+
+                    END OF TERMS AND CONDITIONS
+\f
+     Appendix: How to Apply These Terms to Your New Libraries
+
+  If you develop a new library, and you want it to be of the greatest
+possible use to the public, we recommend making it free software that
+everyone can redistribute and change.  You can do so by permitting
+redistribution under these terms (or, alternatively, under the terms of the
+ordinary General Public License).
+
+  To apply these terms, attach the following notices to the library.  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 library's name and a brief idea of what it does.>
+    Copyright (C) <year>  <name of author>
+
+    This library is free software; you can redistribute it and/or
+    modify it under the terms of the GNU Library General Public
+    License as published by the Free Software Foundation; either
+    version 2 of the License, or (at your option) any later version.
+
+    This library 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
+    Library General Public License for more details.
+
+    You should have received a copy of the GNU Library General Public
+    License along with this library; if not, write to the Free
+    Software Foundation, Inc.
+
+Also add information on how to contact you by electronic and paper mail.
+
+You should also get your employer (if you work as a programmer) or your
+school, if any, to sign a "copyright disclaimer" for the library, if
+necessary.  Here is a sample; alter the names:
+
+  Yoyodyne, Inc., hereby disclaims all copyright interest in the
+  library `Frob' (a library for tweaking knobs) written by James Random Hacker.
+
+  <signature of Ty Coon>, 1 April 1990
+  Ty Coon, President of Vice
+
+That's all there is to it!
diff --git a/contrib/cvs-1.12.9/DEVEL-CVS b/contrib/cvs-1.12.9/DEVEL-CVS
new file mode 100644 (file)
index 0000000..464003c
--- /dev/null
@@ -0,0 +1,61 @@
+                        CVS Development Policies
+
+This file, DEVEL-CVS, contains the policies by which the CVS
+development group operates.  Also see the HACKING file.
+
+----------------------------------------------------------------------
+Charter for the devel-cvs mailing list:
+
+The CVS Developers' List <dev@ccvs.cvshome.org> exists to help people
+with access to the CVS source repository co-ordinate changes, make
+releases, and administer the repository.
+
+Everyone who has been given checkin access to the repository for the
+CVS sources should read devel-cvs.  Only those with checkin access may
+send messages to the list.
+
+The devel-cvs list may be used to discuss:
+- administrivia regarding the CVS source repository and release
+  process, and
+- changes and features intended for inclusion in the official CVS
+  release (either source code or documentation), which someone plans
+  to implement, or has implemented.
+
+The devel-cvs list should not be used to discuss:
+- changes or features to packages other than the CVS release
+  (e.g., related packages like tkCVS, RAD/CVS, or other groups'
+  distributions of CVS, like RCVS, etc.),
+- changes which nobody has offered to implement, or
+- the philosophy of CVS (as opposed to a specific change to CVS).
+These topics should either go on info-cvs, or have a new mailing list
+created for them.
+
+The topic restrictions in this charter do not reflect the development
+group's future plans for CVS; rather, they reflect a topic
+classification which the group finds helpful.
+
+----------------------------------------------------------------------
+Policies regarding the CVS source repository:
+
+By checking items into the repository, developers agree to permit
+distribution of such items under the terms of the GNU Public License.
+
+----------------------------------------------------------------------
+Procedure for dealing with people who want to be developers:
+
+People who want checkin access are first requested to send
+patches and have them reviewed by a developer.  If they submit some
+good ones (preferably over a period of time, to demonstrate sustained
+interest), then one of the developers can ask the devel-cvs mailing
+list whether it is OK to make this person a developer (after first
+sending the prospective developer a copy of this file and then having
+the prospective developer say they want to be a developer).  If there
+are no objections, the person will be made a developer.
+
+----------------------------------------------------------------------
+Policy regarding checkout-only access:
+
+Checkout-only access to the CVS repository is available to all, on an
+anonymous basis (no need for registration or other complications).
+The exact technical mechanisms by which it is available are not
+covered by this policy.
diff --git a/contrib/cvs-1.12.9/HACKING b/contrib/cvs-1.12.9/HACKING
new file mode 100644 (file)
index 0000000..ec35043
--- /dev/null
@@ -0,0 +1,308 @@
+How to write code for CVS
+
+* Source
+
+Patches against the development version of CVS are most likely to be accepted:
+
+       $ cvs -d:pserver:anoncvs@cvs.cvshome.org/cvsroot co ccvs
+
+* Compiler options
+
+If you are using GCC, you'll want to configure with -Wall, which can
+detect many programming errors.  This is not the default because it
+might cause spurious warnings, but at least on some machines, there
+should be no spurious warnings.  For example:
+
+       $ CFLAGS="-g -Wall" ./configure
+
+Configure is not very good at remembering this setting; it will get
+wiped out whenever you do a ./config.status --recheck, so you'll need
+to use:
+
+       $ CFLAGS="-g -Wall" ./config.status --recheck
+
+* Indentation style
+
+CVS mostly uses a consistent indentation style which looks like this:
+
+void
+foo (char *arg, int c)
+{
+    long aflag;
+
+    if (arg != NULL)
+    {
+       bar (arg);
+       baz (arg);
+    }
+
+    switch (c)
+    {
+       case 'A':
+           aflag = 1;
+           break;
+    }
+
+    printf ("Literal string line 1\n"
+           "Literal string line 2\n"
+           "Literal string line 3\n");
+}
+
+The file cvs-format.el contains settings for emacs and the NEWS file
+contains a set of options for the indent program which I haven't tried
+but which are correct as far as I know.  You will find some code which
+does not conform to this indentation style; the plan is to reindent it
+as those sections of the code are changed (one function at a time,
+perhaps).
+
+In a submitted patch it is acceptable to refrain from changing the
+indentation of large blocks of code to minimize the size of the patch;
+the person checking in such a patch should reindent it.
+
+* Portability
+
+The general rule for portability is that it is only worth including
+portability cruft for systems on which people are actually testing and
+using new CVS releases.  Without testing, CVS will fail to be portable
+for any number of unanticipated reasons.
+
+CVS is now assuming a freestanding C89 compiler.  If you don't have one, you
+should find an old release of GCC that did not require a freestanding C89
+compiler to build, build that on your system, build a newer release of GCC
+if you wish, then build CVS using GCC as your freestanding C89 compiler.
+
+A freestanding C89 compiler is guaranteed to support function prototypes,
+void *, and assert().
+
+The following headers can be assumed and are included from lib/system.h for a
+freestanding C89 implementation: <float.h>, <limits.h>, <stdarg.h>, <stddef.h>.
+We are not assuming the other standard headers listed by C89 (hosted headers)
+because these four headers are the only headers guaranteed to be shipped with
+a C89 compiler (frestanding compiler).  We are not currently assuming that the
+system the compiler is running on provides the rest of the C89 headers.
+
+The following C89 hosted headers can be assumed due to their presence in UNIX
+version 7 and are included from lib/system.h: <assert.h>, <ctype.h>, <errno.h>,
+<math.h>, <setjmp.h>, <signal.h>, <stdio.h>.  <time.h> can also be assumed but
+is included via lib/xtime.h via lib/system.h to include some Autoconf magic
+which avoids including <time.h> and <sys/time.h> on systems that can't handle
+both.
+
+The following C89 headers are also assumed since we believe GCC includes them
+even on systems where it is installed as a freestanding compiler when the
+system lacks them, despite their not being required: <stdlib.h>, <string.h>.
+When the system does not lack these headers, they can sometimes not be
+standards compatible, but GCC provides a script, `fixincludes', for the purpose
+of fixing ANSI conformance problems and we think we can rely on asking users to
+either use GCC or run this script to fix conformance problems manually.  A
+GNULIB developer has made a statement that if this turns out to be a problem,
+GNULIB <stdlib.h> and <string.h> substitutes could be included in GNULIB, so if
+we discover the problem, this should be discussed on <bug-gnulib@gnu.org>.
+
+A substitute C99 <stdbool.h> is included from GNULIB for platforms that lack
+this header.  Please see the comments in the lib/stdbool_.h file for its
+limitations.
+
+<sys/types.h> can be assumed despite a lack of a presence in even C99, since
+it has been around nearly forever and noone has ever complained about our code
+assuming its existance.
+
+CVS has also been assuming <pwd.h> for some time.  I am unsure of the
+rationale.
+
+A substitute POSIX.2 <fnmatch.h> header and fnmatch() function is provided for
+systems that lack them.  Similarly for the non-standard <alloca.h> header and
+alloca() function.  Other substitute headers and functions are also provided
+when needed.  See the lib directory or the srclist.txt file for more
+information.
+
+Please do not use multi-line strings.  Despite their common acceptance by many
+compilers, they are not part of the ANSI C specification.  As of GCC version
+3.3, they are no longer supported.  See the Indentation Style section above for
+an example of a literal string which is not multi-line but which will print
+multiple lines.
+
+* Other style issues
+
+When composing header files, do not declare function prototypes using the
+`extern' storage-class identifier.  Under C89, there is no functional
+difference between a function declaration with and without `extern', unless the 
+function is declared `static'.  This is NOT the case for global variables.
+Global variables declared in header files MUST be declared `extern'.  For
+example:
+
+/* Global variables */
+extern int foo;
+extern char *bar;
+
+/* Function declarations */
+int make_foo(void);
+char *make_bar(int _foobar);
+
+* Run-time behaviors
+
+Use assert() to check "can't happen" conditions internal to CVS.  We
+realize that there are functions in CVS which instead return NULL or
+some such value (thus confusing the meaning of such a returned value),
+but we want to fix that code.  Of course, bad input data, a corrupt
+repository, bad options, etc., should always print a real error
+message instead.
+
+Do not use arbitrary limits (such as PATH_MAX) except perhaps when the
+operating system or some external interface requires it.  We spent a
+lot of time getting rid of them, and we don't want to put them back.
+If you find any that we missed, please report it as with other bugs.
+In most cases such code will create security holes (for example, for
+anonymous readonly access via the CVS protocol, or if a WWW cgi script
+passes client-supplied arguments to CVS).
+
+Although this is a long-term goal, it also would be nice to move CVS
+in the direction of reentrancy.  This reduces the size of the data
+segment and will allow a multi-threaded server if that is desirable.
+It is also useful to write the code so that it can be easily be made
+reentrant later.  For example, if you need to pass data to some functions,
+you need a static variable, but use a single pointer so that when the function
+is fixed to pass along the argument, then the code can easily use that
+argument.
+
+* Coding standards in general
+
+Generally speaking the GNU coding standards are mostly used by CVS
+(but see the exceptions mentioned above, such as indentation style,
+and perhaps an exception or two we haven't mentioned).  This is the
+file standards.text at the GNU FTP sites.
+
+Filenames for .c and .h files may contain _ but should not contain -
+(the latter causes Visual C++ 2.1 to create makefiles which Visual C++
+4.0 cannot use).
+
+* Regenerating Build Files (UNIX)
+
+On UNIX, if you wish to change the Build files, you will need Autoconf and
+Automake.
+
+Some combinations of Automake and Autoconf versions may break the
+CVS build if file timestamps aren't set correctly and people don't
+have the same versions the developers do, so the rules to run them
+automatically aren't included in the generated Makefiles unless you run
+configure with --enable-maintainer-mode.
+
+The CVS Makefiles and configure script were built using Automake 1.7.9 and
+Autoconf 2.58, respectively.
+
+There is a known bug in Autoconf 2.57 that will prevent the configure
+scripts it generates from working on some platforms.  Other combinations of
+autotool versions may or may not work.  If you get other versions to work,
+please send a report to <bug-cvs@gnu.org>.
+
+* Regenerating Build Files (Windows)
+
+If for some reason you end up regenerating the *.mak files to submit a patch,
+please run windows-NT/fix-msvc-mak.pl to remove the absolute paths from the
+generated *.mak files before generating any patches.
+
+* Writing patches (strategy)
+
+Only some kinds of changes are suitable for inclusion in the
+"official" CVS.  Bugfixes, where CVS's behavior contradicts the
+documentation and/or expectations that everyone agrees on, should be
+OK (strategically).  For features, the desirable attributes are that
+the need is clear and that they fit nicely into the architecture of
+CVS.  Is it worth the cost (in terms of complexity or any other
+tradeoffs involved)?  Are there better solutions?
+
+If the design is not yet clear (which is true of most features), then
+the design is likely to benefit from more work and community input.
+Make a list of issues, or write documentation including rationales for
+how one would use the feature.  Discuss it with coworkers, a
+newsgroup, or a mailing list, and see what other people think.
+Distribute some experimental patches and see what people think.  The
+intention is arrive at some kind of rough community consensus before
+changing the "official" CVS.  Features like zlib, encryption, and
+the RCS library have benefitted from this process in the past.
+
+If longstanding CVS behavior, that people may be relying on, is
+clearly deficient, it can be changed, but only slowly and carefully.
+For example, the global -q option was introduced in CVS 1.3 but the
+command -q options, which the global -q replaced, were not removed
+until CVS 1.6.
+
+* Writing patches (tactics)
+
+When you first distribute a patch it may be suitable to just put forth
+a rough patch, or even just an idea.  But before the end of the
+process the following should exist:
+
+  - ChangeLog entry (see the GNU coding standards for details).
+
+  - Changes to the NEWS file and cvs.texinfo, if the change is a
+    user-visible change worth mentioning.
+
+  - Somewhere, a description of what the patch fixes (often in
+    comments in the code, or maybe the ChangeLog or documentation).
+
+  - Most of the time, a test case (see TESTS).  It can be quite
+    frustrating to fix a bug only to see it reappear later, and adding
+    the case to the testsuite, where feasible, solves this and other
+    problems.  See the TESTS file for notes on writing new tests.
+
+If you solve several unrelated problems, it is generally easier to
+consider the desirability of the changes if there is a separate patch
+for each issue.  Use context diffs or unidiffs for patches.
+
+Include words like "I grant permission to distribute this patch under
+the terms of the GNU Public License" with your patch.  By sending a
+patch to bug-cvs@gnu.org, you implicitly grant this permission.
+
+Submitting a patch to bug-cvs is the way to reach the people who have
+signed up to receive such submissions (including CVS developers), but
+there may or may not be much (or any) response.  If you want to pursue
+the matter further, you are probably best off working with the larger
+CVS community.  Distribute your patch as widely as desired (mailing
+lists, newsgroups, web sites, whatever).  Write a web page or other
+information describing what the patch is for.  It is neither practical
+nor desirable for all/most contributions to be distributed through the
+"official" (whatever that means) mechanisms of CVS releases and CVS
+developers.  Now, the "official" mechanisms do try to incorporate
+those patches which seem most suitable for widespread usage, together
+with test cases and documentation.  So if a patch becomes sufficiently
+popular in the CVS community, it is likely that one of the CVS
+developers will eventually try to do something with it.  But dealing
+with the CVS developers may be the last step of the process rather
+than the first.
+
+* What is the schedule for the next release?
+
+There isn't one.  That is, upcoming releases are not announced (or
+even hinted at, really) until the feature freeze which is
+approximately 2 weeks before the final release (at this time test
+releases start appearing and are announced on info-cvs).  This is
+intentional, to avoid a last minute rush to get new features in.
+
+* Mailing lists
+
+Anyone can add themselves to the following mailing lists:
+
+    dev.  Unless you are accepted as a CVS developer as
+      described in the DEVEL-CVS file, you will only be able to
+      read this list, not send to it.  The charter of the list is
+      also in DEVEL-CVS.
+    cvs.  The only messages sent to this list are sent
+      automatically, via the CVS `loginfo' mechanism, when someone
+      checks something in to the master CVS repository.
+    test-results.  The only messages sent to this list are sent
+      automatically, daily, by a script which runs "make check"
+      and "make remotecheck" on the master CVS sources.
+
+To subscribe to dev, cvs, or test-results, send
+a message to "<list>-subscribe@ccvs.cvshome.org" or visit
+http://ccvs.cvshome.org/servlets/ProjectMailingListList and follow the
+instructions there.
+
+One other list related to CVS development is bug-cvs.  This is the
+list which users are requested to send bug reports to.  Anyone can
+subscribe; to do so send mail to bug-cvs-request@gnu.org.
+
+Other CVS discussions take place on the info-cvs mailing list
+(send mail to info-cvs-request@gnu.org to subscribe) or on
+the newsgroup comp.software.config-mgmt.
diff --git a/contrib/cvs-1.12.9/INSTALL b/contrib/cvs-1.12.9/INSTALL
new file mode 100644 (file)
index 0000000..a164b62
--- /dev/null
@@ -0,0 +1,483 @@
+First, read the README file.  If you're still happy...
+
+First you need to obtain and install the CVS executables.  If you got
+a distribution which contains executables, consult the installation
+instructions for that distribution.  If you got source code, do not
+panic.  On many platforms building CVS from source code is a
+straightforward process requiring no programming knowledge.  See the
+section BUILDING FROM SOURCE CODE at the end of this file, which
+includes a list of platforms which have been tested.
+
+-------------------------------------------------------------------------------
+
+1) Take a look at the CVS documentation, if desired.  For most
+   purposes you want doc/cvs.texinfo, also known as _Version Management
+   with CVS_ by Per Cederqvist et al.  Looking at it might be as simple
+   as "info cvs" but this will depend on your installation; see README
+   for more details.
+
+   See what CVS can do for you, and if it fits your environment (or can
+   possibly be made to fit your environment).  If things look good,
+   continue on.  Alternately, just give CVS a try first then figure out
+   what it is good for.
+
+2) Set the CVSROOT environment variable to where you want to put your
+   source repository.  See the "Setting up the repository" section of
+   the Cederqvist manual for details, but the quick summary is just to
+   pick some directory.  We'll use /src/master as an example.  For
+   users of a POSIX shell (sh/bash/ksh) on unix, the following
+   commands can be placed in user's ~/.profile, ~/.bash_profile file;
+   or in the site-wide /etc/profile:
+
+       CVSROOT=/src/master; export CVSROOT
+
+   For C shell users on unix place the following commands in the
+   user's ~/.cshrc, ~/.login, or /etc/chsrc file:
+
+       setenv CVSROOT /src/master
+
+   For Windows users, supposing the repository will be in
+   d:\src\master, place the following line in c:\autoexec.bat.  On
+   Windows 95, autoexec.bat might not already exist.  In that case,
+   just create a new file containing the following line.
+
+       set CVSROOT=:local:d:\src\master
+
+   If these environment variables are not already set in your current
+   shell, set them now by typing the above line at the command prompt
+   (or source the login script you just edited).
+   The instructions for the remaining steps assume that you have set
+   the CVSROOT environment variable.
+
+3) Create the master source repository.  Again, the details are in
+   the "Setting up the repository" section of cvs.texinfo; the
+   one-line summary is:
+
+       $ cvs init
+
+   In this and subsequent examples we use "$" to indicate the command
+   prompt; do not type the "$".
+
+4) It might be a good idea to jump right in and put some sources or
+   documents directly under CVS control.  From within the top-level
+   directory of your source tree, run the following commands:
+
+       $ cvs import -m "test distribution" ccvs CVS_DIST CVS-TEST
+
+   (Those last three items are, respectively, a repository location, a
+   "vendor tag", and a "release tag".  You don't need to understand
+   them yet, but read the section "Starting new projects" in the
+   Cederqvist manual for details).
+
+5) Having done step 4, one should be able to checkout a fresh copy of the
+   sources you just imported and hack away at the sources with the
+   following command:
+
+      $ cd
+      $ cvs checkout ccvs
+
+   This will make the directory "ccvs" in your current directory and
+   populate it with the appropriate files and directories.
+
+6) You may wish to customize the various administrative files, in particular
+   modules.  See the Cederqvist manual for details.
+
+7) Read the NEWS file to see what's new.
+
+8) Hack away.
+
+-------------------------------------------------------------------------------
+
+BUILDING FROM SOURCE CODE
+
+Tested platforms
+
+CVS has been tested on the following platforms.  The most recent
+version of CVS reported to have been tested is indicated, but more
+recent versions of CVS probably will work too.  Please send updates to
+this list to bug-cvs@gnu.org (doing so in the form of a diff
+to this file, or at least exact suggested text, is encouraged).
+"tested" means, at a minimum, that CVS compiles and appears to work on
+simple (manual) testing.  In many cases it also means "make check"
+and/or "make remotecheck" passes, but we don't try to list the
+platforms for which that is true.
+
+Alpha:
+       DEC Alpha running OSF/1 version 1.3 using cc (about 1.4A2)
+       DEC Alpha running OSF/1 version 2.0 (1.8)
+       DEC Alpha running OSF/1 version 2.1 (about 1.4A2)
+       DEC Alpha running OSF/1 version 3.0 (1.5.95) (footnote 7)
+       DEC Alpha running OSF/1 version 3.2 (1.9)
+       Alpha running alpha-dec-osf4.0 (1.10)
+       DEC Alpha running Digital UNIX v4.0C using gcc 2.7.2.2 (1.9.14)
+       DEC Alpha running VMS 6.2 (1.8.85 client-only)
+       Alpha running NetBSD 1.2E (1.10)
+Cray:
+       J90 (CVS 970215 snapshot)
+       T3E (CVS 970215 snapshot)
+HPPA:
+       HP 9000/710 running HP-UX 8.07A using gcc (about 1.4A2)
+       HPPA running HP-UX 9 (1.8)
+        HPPA 1.1 running HP-UX A.09.03 (1.5.95) (footnote 8)
+        HPPA 1.1 running HP-UX A.09.04 (1.7.1)
+       HPPA running HP-UX 9.05 (1.9)
+       HPPA running HP-UX 10.01 (1.7)
+       HPPA running HP-UX 10.20 (1.10.7)
+       HPPA running HP-UX 11.11 (1.11.13) (footnote 12)
+       HPPA 2.0 running HP-UX 10.20 (1.10.9) (footnote 13)
+       NextSTEP 3.3 (1.7)
+i386 family:
+       Solaris 2.4 using gcc (about 1.4A2)
+       Solaris 2.6 (1.9)
+       UnixWare v1.1.1 using gcc (about 1.4A2)
+       Unixware 2.1 (1.8.86)
+       Unixware 7 (1.9.29)
+       ISC 4.0.1 (1.8.87)
+       Linux (kernel 1.2.x) (1.8.86)
+       Linux (kernel 2.0.x, RedHat 4.2) (1.10)
+       Linux (kernel 2.0.x, RedHat 5.x) (1.10)
+       Linux (kernel 2.2.x, RedHat 6.x) (1.10.8)
+       Linux (kernel 2.2.x, RedHat 7.x) (1.11)
+       BSDI 4.0 (1.10.7)
+       FreeBSD 2.1.5-stable (1.8.87)
+       NextSTEP 3.3 (1.7)
+       SCO Unix 3.2.4.2, gcc 2.7.2 (1.8.87) (footnote 4)
+       SCO OpenServer 5.0.5 (1.10.2)
+       Sequent DYNIX/ptx4.0 (1.10 or so) (remove -linet)
+       Sequent Dynix/PTX 4.1.4 (1.9.20 or so + patches)
+       Lynx 2.3.0 080695 (1.6.86) (footnote 9)
+       Windows NT 3.51 (1.8.86 client; 1.8.3 local)
+       Windows NT 3.51 service pack 4 (1.9)
+       Windows NT 3.51 service pack 5 (1.9) -- DOES NOT WORK (footnote 11)
+       Windows NT 4.0 (1.9 client and local)
+       Windows NT 4.0 (1.11 client and local - build & test, but no test suite)
+       Windows 95 (1.9 client and local)
+       QNX (1.9.1 + patches for strippath() and va_list)
+       OS/2 Version 3 using IBM C/C++ Tools 2.01 (1.8.86 + patches, client)
+       OS/2 Version 3 using EMX 0.9c (1.9.22, client)
+       OS/2 Version 3 using Watcom version ? (? - has this been tested?)
+m68k:
+       Sun 3 running SunOS 4.1.1_U1 w/ bundled K&R /usr/5bin/cc (1.8.86+)
+       NextSTEP 3.3p1 (1.8.87)
+       Lynx 2.3.0 062695 (1.6.86) (footnote 9)
+       NetBSD/mac68k (1.9.28)
+m88k:
+       Data General AViiON running dgux 5.4R2.10 (1.5)
+       Data General AViiON running dgux 5.4R3.10 (1.7.1)
+       Harris Nighthawk 5800 running CX/UX 7.1 (1.5) (footnote 6)
+MIPS:
+       DECstation running Ultrix 4.2a (1.4.90)
+       DECstation running Ultrix 4.3 (1.10)
+       SGI running Irix 4.0.5H using gcc and cc (about 1.4A2) (footnote 2)
+       SGI running Irix 5.3 (1.10)
+       SGI running Irix 6.2 using SGI MIPSpro 6.2 and beta 7.2 compilers (1.9)
+       SGI running Irix-6.2 (1.9.8)
+       SGI running IRIX 6.4 (1.10)
+       SGI running IRIX 6.5 (1.10.7)
+       Siemens-Nixdorf RM600 running SINIX-Y (1.6)
+PowerPC or RS/6000:
+       IBM RS/6000 running AIX 3.1 using gcc and cc (1.6.86)
+       IBM RS/6000 running AIX 3.2.5 (1.8)
+       IBM RS/6000 running AIX 4.1 (1.9)
+       IBM RS/6000 running AIX 4.3 (1.10.7)
+       Lynx 2.3.1 120495 (1.6.86) (footnote 9)
+       Lynx 2.5 (1.9) (footnote 10)
+       MkLinux DR3 GENERIC #6 (1.10.5.1) (presumably LinuxPPC too)
+       Mac OS X Darwin 6.6 Darwin Kernel Version 6.6 (1.11.1p1)
+       Mac OS X Darwin 5.5 Darwin Kernel Version 5.5 (1.11.6) (footnote 12)
+       Mac OS X Darwin 5.5 Darwin Kernel Version 5.5 (1.12.1) (footnote 12)
+SPARC:
+       Sun SPARC running SunOS 4.1.x (1.10)
+       Sun SPARCstation 10 running Solaris 2.3 using gcc and cc (about 1.4A2)
+       Sun SPARCstation running Solaris 2.4 using gcc and cc (about 1.5.91)
+       Sun SPARC running Solaris 2.5 (1.8.87)
+       Sun SPARC running Solaris 2.5.1 using gcc 2.7.2.2 (1.9.14)
+       Sun SPARC running Solaris 2.6 (1.10.7)
+       Sun UltraSPARC running Solaris 2.6 using gcc 2.8.1 (1.10)
+       NextSTEP 3.3 (1.7)
+       Sun SPARC running Linux 2.0.17, gcc 2.7.2 (1.8.87)
+       Sun UltraSPARC running Solaris 2.8 using gcc 2.95.3
+VAX:
+       VAX running VMS 6.2 (1.9+patches, client-only)
+         (see README.VMS for information on necessary hacks).
+
+(footnote 2)
+       Some Irix 4.0 systems may core dump in malloc while running
+       CVS.  We believe this is a bug in the Irix malloc.  You can
+       workaround this bug by linking with "-lmalloc" if necessary.
+       (about 1.4A2).
+
+(footnote 4) Comment out the include of sys/time.h in src/server.c. (1.4.93)
+       You also may have to make sure TIME_WITH_SYS_TIME is undef'ed.
+
+(footnote 6) Build in ucb universe with COFF compiler tools.  Put
+       /usr/local/bin first in PATH while doing a configure, make
+       and install of GNU diffutils-2.7, rcs-5.7, then cvs-1.5.
+
+(footnote 7) Manoj Srivastava <srivasta@pilgrim.umass.edu> reports
+        success with this configure command:
+  CC=cc CFLAGS='-O2 -Olimit 2000 -std1' ./configure --verbose alpha-dec-osf
+
+(footnote 8) Manoj Srivastava <srivasta@pilgrim.umass.edu> reports
+        success with this configure command:
+  CC=cc CFLAGS='+O2 -Aa -D_HPUX_SOURCE' ./configure --verbose hppa1.1-hp-hpux
+
+(footnote 9) 
+    Had to configure with ./configure --host=<arch>-lynx.
+
+    In src/cvs.h, protected the waitpid prototype with ifdef _POSIX_SOURCE.
+    (I might try building with gcc -mposix -D_POSIX_SOURCE.)
+
+    LynxOS has <dirent.h>, but you don't want to use it.
+    You want to use <sys/dir.h> instead.
+    So after running configure I had to undef HAVE_DIRENT_H and
+    define HAVE_SYS_DIR_H.
+
+(footnote 10)
+    Had to compile with "make LIBS=-lbsd" (to get gethostbyname
+    and getservbyname).
+
+(footnote 11)
+    when I do a `cvs init' I get this message:
+      ci: 'RCS/loginfo,v' is not a regular file
+      ci:  RCS/loginfo,v: Invalid argument
+      cvs [init aborted]: failed to checkin n:/safe/CVSROOT/loginfo
+
+(footnote 12)
+    Need to `configure --without-gssapi' unless you have installed Kerberos 5
+    libraries on the system yourself.  For some reason Apple ships OS X with
+    the Kerberos 5 headers installed and not the libraries, which confuses the
+    current configure script.  Some HP, BSD, & Sun boxes have similar problems.
+
+(footnote 13)
+    A build under HP PA-RISC 2.0 will probably not run under PA-RISC 1.1
+    unless "+DAportable" is added to the HP ANSI cc compiler flags.
+
+-------------------------------------------------------------------------------
+
+Building from source code under Unix:
+
+1)  Run "configure":
+
+       $ ./configure
+
+    You can specify an alternate destination to override the default with
+    the --prefix option:
+
+       $ ./configure --prefix=/usr/local/gnu
+
+    or some path that is more appropriate for your site.  The default prefix
+    value is "/usr/local", with binaries in sub-directory "bin", manual
+    pages in sub-directory "man", and libraries in sub-directory "lib".
+
+    A normal build of CVS will create an executable which supports
+    local, server, or client CVS (if you don't know the difference,
+    it is described in the Repository chapter of doc/cvs.texinfo).  If
+    you do not intend to use client or server CVS, you may want to
+    prevent these features from being included in the executable you
+    build. You can do this with the --disable-client and
+    --disable-server options:
+
+       $ ./configure --disable-client --disable-server
+
+    Typically this can reduce the size of the executable by around 30%.
+
+    If you are building CVS with the server enabled, you can disable
+    server flow control using the --disable-server-flow-control
+    If you are working with a large remote repository and a 'cvs
+    checkout' is swamping your network and memory, enable flow control.
+    You will end up with even less probability of a consistent checkout
+    (see Concurrency in cvs.texinfo), but CVS doesn't try to guarantee
+    that anyway.  The master server process will monitor how far it is
+    getting behind, if it reaches the high water mark, it will signal
+    the child process to stop generating data when convenient (ie: no
+    locks are held, currently at the beginning of a new directory).
+    Once the buffer has drained sufficiently to reach the low water
+    mark, it will be signalled to start again.  You may override the
+    default hi/low watermarks here too by passing
+    '<lowwater>,<highwater>', in bytes, as an argument to
+    --enable-server-flow-control.  The low water mark defaults to one
+    megabyte and the high water mark defaults to two megabytes.
+
+       $ ./configure --enable-server-flow-control=1M,2M
+
+    The --with-tmpdir argument to configure may be used to set a
+    specific directory for use as a default temporary directory.  If not
+    set, configure will pick the first directory it finds which it has
+    read, write, and execute permissions to from $TMPDIR, $TMP, $TEMP,
+    /tmp, and /var/tmp, in that order.  Failing that, it will use /tmp.
+
+    The --with-umask argument to configure can be used to change
+    the default umask used by the CVS server executable.
+
+    Unlike previous versions of CVS, you do not need to install RCS
+    or GNU diff.  
+
+    If you are using gcc and are planning to modify CVS, you may want to
+    configure with -Wall; see the file HACKING for details.
+
+    If you have Kerberos 4 installed, you can specify the location of
+    the header files and libraries using the --with-krb4=DIR option.
+    DIR should be a directory with subdirectories include and lib
+    holding the Kerberos 4 header files and libraries, respectively.
+    The default value is /usr/kerberos.
+
+    If you want to enable support for encryption over Kerberos, use
+    the --enable-encryption option.  This option is disabled by
+    default.
+
+    If you want to disable automatic dependency tracking in the makefiles,
+    use the '--disable-dependency-tracking' option:
+
+       $ ./configure --disable-dependency-tracking
+
+    This avoids problems on some platforms.  See the note at the end of this
+    file on BSD.
+
+    Try './configure --help' for further information on its usage.
+
+    NOTE ON CVS's USE OF NDBM:
+
+       By default, CVS uses some built-in ndbm emulation code to allow
+       CVS to work in a heterogeneous environment.  However, if you have
+       a very large modules database, this may not work well.  You will
+       need to supply the --disable-cvs-ndbm option to configure to
+       accomplish this.  If you do this, the following comments apply.  If
+       not, you may safely skip these comments.
+
+       If you configure CVS to use the real ndbm(3) libraries and
+       you do not have them installed in a "normal" place, you will
+       probably want to get the GNU version of ndbm (gdbm) and install
+       that before running the CVS configure script.  Be aware that the
+       GDBM 1.5 release does NOT install the <ndbm.h> header file included
+       with the release automatically.  You may have to install it by hand.
+
+       If you configure CVS to use the ndbm(3) libraries, you cannot
+       compile CVS with GNU cc (gcc) on Sun-4 SPARC systems.  However, gcc
+       2.0 may have fixed this limitation if -fpcc-struct-return is
+       defined.  When using gcc on other systems to compile CVS, you *may*
+       need to specify the -fpcc-struct-return option to gcc (you will
+       *know* you have to if "cvs checkout" core dumps in some ndbm
+       function).  You can do this as follows:
+
+           $ CC='gcc -fpcc-struct-return' ./configure
+
+       for sh, bash, and ksh users and:
+
+           % setenv CC 'gcc -fpcc-struct-return'
+           % ./configure
+
+       for csh and tcsh users.
+
+    END OF NOTE FOR NDBM GUNK.
+
+2)  Try to build it:
+
+       $ make
+
+    This will (hopefully) make the needed CVS binaries within the
+    "src" directory.  If something fails for your system, and you want
+    to submit a bug report, you may wish to include your
+    "config.status" file, your host type, operating system and
+    compiler information, make output, and anything else you think
+    will be helpful.
+
+3)  Run the regression tests (optional).
+
+    You may also wish to validate the correctness of the new binary by
+    running the regression tests.  If they succeed, that is nice to
+    know.  However, if they fail, it doesn't tell you much.  Often it
+    will just be a problem with running the tests on your machine,
+    rather than a problem with CVS.  Unless you will have the time to
+    determine which of the two it is in case of failure, you might
+    want to save yourself the time and just not run the tests.
+
+    If you want to run the tests, see the file TESTS for more information.
+
+4)  Install the binaries/documentation:
+
+       $ make install
+
+    Depending on your installation's configuration, you may need to be
+    root to do this.
+
+-------------------------------------------------------------------------------
+
+Detailed information about your interaction with "configure":
+
+The "configure" script and its interaction with its options and the
+environment is described here.  For more detailed documentation about
+"configure", please run `./configure --help' or refer to the GNU Autoconf
+documentation.
+
+Supported options are:
+
+       --srcdir=DIR            Useful for compiling on many different
+                               machines sharing one source tree.
+       --prefix=DIR            The root of where to install the
+                               various pieces of CVS (/usr/local).
+       --exec_prefix=DIR       If you want executables in a
+                               host-dependent place and shared
+                               things in a host-independent place.
+
+The following environment variables override configure's default
+behaviour:
+
+       CC                      If not set, tries to use gcc first,
+                               then cc.  Also tries to use "-g -O"
+                               as options, backing down to -g
+                               alone if that doesn't work.
+       INSTALL                 If not set, tries to use "install", then
+                               "./install-sh" as a final choice.
+       RANLIB                  If not set, tries to determine if "ranlib"
+                               is available, choosing "echo" if it doesn't
+                               appear to be.
+       YACC                    If not set, tries to determine if "bison"
+                               is available, choosing "yacc" if it doesn't
+                               appear to be.
+
+-------------------------------------------------------------------------------
+
+Building from source code under Windows NT/95/98/2000:
+
+You may find interesting information in windows-NT/README.
+
+* Using Microsoft Visual C++ 5.x+.
+
+1) Using Microsoft Visual C++ 5.x+, open the project `cvsnt.dsw',
+   in the top directory of the CVS distribution.  If you have an older
+   version of Visual C++, take a look at windows-NT/README.
+2) Choose "Build cvs.exe" from the "Project" menu.
+3) MSVC will place the executable file cvs.exe in WinRel, or whatever
+   your target directory is.
+
+* From the top level directory, with MSVC++ 5.x+ installed, something like the
+following also works:
+
+       C:\> vcvars32
+       C:\> nmake /f cvsnt.mak CFG="cvsnt - Win32 Debug"
+
+* Using the Cygwin development environment <http://cygwin.com>, Windows clients
+  and servers can be built using the instructions for building on UNIX.  For
+  deploying the CVS server on Windows NT, see the `cygrunsrv' executable that
+  comes with Cygwin.
+
+* You might also try <http://wincvs.org> & <http://www.cvsnt.org>.
+
+-------------------------------------------------------------------------------
+
+Building from source code under other platforms:
+
+For OS/2, see os2/README and emx/README.
+
+For VMS, see README.VMS
+
+Mac OS X: Builds fine, just like UNIX.
+
+For older versions of Mac OS, you might try <http://wincvs.org>.
+
+For a Java client, see jCVS (which is a separate package from CVS
+itself, but which might be preferable to the Macintosh port mentioned
+above, for example).
+
+-------------------------------------------------------------------------------
diff --git a/contrib/cvs-1.12.9/MINOR-BUGS b/contrib/cvs-1.12.9/MINOR-BUGS
new file mode 100644 (file)
index 0000000..9eb0e7b
--- /dev/null
@@ -0,0 +1,61 @@
+Low-priority bugs go here.  Actually, most every documented bug is
+"low-priority"--in the sense that if it is documented it means noone
+has gotten around to fixing it.
+
+
+* "cvs update -ko -p -r REV file" doesn't seem to pay attention to the
+  '-ko', at least in client/server mode.  A simple work around is to
+  temporarily change the db file with "cvs admin -ko file", then switch
+  it back to the original modes after the checkout (probably '-kkv').
+
+* "cvs status" has a difference in its output between local and
+  client/server mode.  Namely there's a tab character followed by a
+  ctime(3)-style date string at the end of the "Working revision:"
+  field.
+
+* commands which don't work in a local working directory should probably
+  ignore any CVS/Root values and revert to using CVSROOT alone.  The
+  current use of CVS/Root can be very confusing if you forget you're in
+  a working directory for a remote module -- something that's very easy
+  to do since CVS hides the client operation very well, esp. for
+  commands which fail for this reason.  The only clue might be the word
+  "server" in a message such as this:
+       cvs server: cannot find module `patch' - ignored
+
+* cvs init may gave a strange error at times:
+       ttyp4:<woods@clapton> $ cvs -d /local/src-CVS init
+       cvs [init aborted]: cannot open CVS/Root: No such file or directory
+  but it seemed to work just the same....  Note that at the time CVSROOT
+  was set to point to a CVS server using the ":server:" option.
+
+* If a ~/CVS/Root file exists on the server and you are using rsh to
+connect to the server, CVS may loose its mind (this was reported in
+May 1995 and I suspect the symptoms have changed, but I have no
+particular reason to think the bug is fixed -kingdon, Sep 96).
+
+* (Jeff Johnson <jbj@jbj.org>)
+  I tried a "cvs status -v" and received the following:
+
+  ? CVS
+  ? programs/CVS
+  ? tests/CVS
+  cvs server: Examining .
+  ===================================================================
+  File: Install.dec            Status: Up-to-date
+  ...
+  
+  I claim that CVS dirs should be ignored.
+  (This reportedly happens if "cvs add CVS" (or "cvs add *")
+  is followed by "cvs status", in client/server mode - CVS 1.9).
+
+* On remote checkout, files don't have the right time/date stamps in
+  the CVS/Entries files.  Doesn't look like the C/S protocol has any
+  way to send this information along (according to cvsclient.texi).
+  Perhaps we can spiff it up a bit by using the conflict field for the
+  stamp on the checkout/update command.  Please note that this really
+  doesn't do very much for us even if we get it done.
+
+* Does the function that lists the available modules in the repository
+  belong under the "checkout" function?  Perhaps it is more logically
+  grouped with the "history" function or we should create a new "info"
+  function?
diff --git a/contrib/cvs-1.12.9/NEWS b/contrib/cvs-1.12.9/NEWS
new file mode 100644 (file)
index 0000000..f75b952
--- /dev/null
@@ -0,0 +1,1767 @@
+Changes since 1.12.8:
+*********************
+
+SERVER SECURITY FIXES
+
+* Thanks to Stefan Esser & Sebastian Krahmer, several potential security
+  problems have been fixed.  The ones which were considered dangerous enough
+  to catalogue were assigned issue numbers CAN-2004-0416, CAN-2004-0417, &
+  CAN-2004-0418 by the Common Vulnerabilities and Exposures Project.  Please
+  see <http://www.cve.mitre.org> for more information.
+
+* A potential buffer overflow vulnerability in the server has been fixed.
+  This addresses the Common Vulnerabilities and Exposures Project's issue
+  #CAN-2004-0414.  Please see <http://www.cve.mitre.org> for more information.
+
+NEW FEATURES
+
+* `cvs log' & `cvs ls' now output local times when both the server and client
+  are 1.12.9 or greater.
+
+DEVELOPER NOTES
+
+* The windows-NT/config.h.in file is now generated dynamically from the
+  root config.h.in file and a few inputs in the windows-NT directory in hopes
+  of keeping it more in sync with the root config.h.in file.
+
+Changes from 1.12.7 to 1.12.8:
+******************************
+
+SERVER SECURITY FIXES
+
+* A potential buffer overflow vulnerability in the server has been fixed.
+  Prior to this patch, a malicious client could potentially use carefully
+  crafted server requests to run arbitrary programs on the CVS server machine.
+  This addresses the Common Vulnerabilities and Exposures Project's issue
+  #CAN-2004-0396.  Please see <http://www.cve.mitre.org> for more information.
+
+NEW FEATURES
+
+* Some redundant output generated by the `cvs commit' command has been removed.
+
+* Most output from the `cvs commit' command is suppressed when the -Q global
+  option is specified.
+
+* Repository directory browsing via `cvs rls' & `cvs ls' commands.  Expect
+  changes in the long format output soon.  The "entries" format output should
+  remain fairly stable for automated parsers.
+
+* Glob matches, as specified in ignore lists and wrapper options, now conform
+  to the POSIX.2 specification for fnmatch on all platforms.
+
+* The Windows MS Visual C++ project files, including the nmake build files,
+  are now generated with MSVC++ 6.0, but should still work with MSVC++ 5.0.
+
+BUG FIXES
+
+* The cvs.1 man page is now generated automatically from a section of the CVS
+  Manual.
+
+* Thanks to a report from Mark Andrews at the Internet Systems Consortium, the
+  :ext: connection method no longer relies on a transparent transport that uses
+  an argument processor that can handle arbitrary ordering of options and other
+  arguments when using a username other than the caller's.
+
+* Thanks to Ken Raeburn at MIT, directory deletion, whether via `cvs release'
+  or empty directory pruning, now works on network shares under Windows XP.
+
+Changes from 1.12.6 to 1.12.7:
+******************************
+
+SERVER SECURITY ISSUES
+
+* Piped checkouts of paths above $CVSROOT no longer work.  Previously, clients
+  could have requested the contents of RCS archive files anywhere on a CVS
+  server.  This addresses CVE issue CAN-2004-0405.  Please see
+  <http://www.cve.mitre.org> for more information.
+
+CLIENT SECURITY ISSUES
+
+* Clients now check paths from the server to verify that they are within one of
+  the sandboxes the user requested be updated.  Previously, a trojan server
+  could have written or overwritten files anywhere the user had access,
+  presenting a serious security risk.  This addresses CVE issue CAN-2004-1080.
+  Please see <http://www.cve.mitre.org> for more information.
+
+GENERAL USER ISSUES
+
+* Imported the most recent version of regex from GNULIB, which actually means
+  some systems will use now their native regex functions instead of compiling
+  CVS's.  Users should notice no changes in CVS responses to regular
+  expressions.  If you do, please report them to <bug-cvs@gnu.org>.
+
+* CVS now accepts the location of HTTP tunnel web proxies as part of the
+  CVSROOT string.  Actually using a proxy remains untested.  Please report
+  problems and successes to <bug-cvs@gnu.org>.
+
+* Configure no longer checks the $TMPDIR, $TMP, & $TEMP variables to set the
+  default temporary directory.
+
+* CVS on Cygwin correctly handles X:\ style paths.
+
+* Import now uses backslash rather than slash on Windows when checking for
+  "CVS" directories to ignore in import commands.
+
+* Relative paths containing up-references (`..') should now work in
+  client/server mode (client fix).
+
+* A race condition between the ordering of messages from CVS and messages from
+  called scripts in client/server mode has been removed (server fix).
+
+* The check_cvs and cvscheck scripts in the contrib directory have been renamed
+  validate_repo and sandbox_status, respectively, in the interests of clarity.
+
+* The Windows MS Visual C++ 6.0 project files have been brought up to date.
+  The nmake build files were regenerated from these files with MSVC++ 5.0.
+
+* A memory allocation bug on Windows that could cause at least executions of
+  `cvs status' to fail has been fixed (client fix).
+
+* Resurrected files now get their modes and timestamps set correctly and a
+  longstanding bug involving resurrection of an uncommitted removal has been
+  fixed (server fix).
+
+* Some resurrection (cvs add) status messages have changed slightly.
+
+* `cvs release' now works with Kerberos or GSSAPI encryption enabled (server
+  fix).
+
+* File resurrection from a previously existing revision no longer just reports
+  that it works (server fix).
+
+* Misc error & status message corrections.
+
+* Diffing of locally added files against arbitrary revisions in an RCS archive
+  is now allowed when a file of the same name exists or used to exist on some
+  branch (server fix).
+
+* Some user messages have been updated for consistency and spelling.
+
+DEVELOPER ISSUES
+
+* The message source differentiation in the test suite between client and
+  server executables has been repaired.
+
+Changes from 1.12.5 to 1.12.6:
+******************************
+
+GENERAL USER ISSUES
+
+* CVSROOT/*info scripts may not work as expected with executables compiled
+  using VC++ under Windows since all quoting is currently done according to
+  Bourne Shell rules, which probably don't look like command.com rules.
+  Patches gratefully accepted.
+
+* Imports will now always ignore directories and files named `CVS' to avoid
+  violating assumptions made by other parts of CVS.
+
+* Directories specified to `checkout -d' are no longer required to exist.  This
+  consolidates some behavior between `-d' options specified in the modules file
+  and `checkout -d' as well as removing some prior differences between local
+  and client/server mode operation.
+
+* A problem with `cvs release' of subdirs that could corrupt CVS/Entries files
+  has been fixed (client/server).
+
+* The CVS server's protocol check for unused data from the client is no longer
+  called automatically at program exit in order to avoid potential recursive
+  calls to error when the first close is due to memory allocation or similar
+  problems that cause calls to error() to fail.  The check is still made when
+  the server program exits normally.
+
+* The CVSROOT/*info files want a new command format and the old style strings
+  have been deprecated.  Please see the manual for more information on the new
+  format.
+
+* The spec file has been updated to work with more recent versions of RPM.
+
+* Some more GNULIB functions have been imported and/or updated for portability
+  reasons.
+
+* Several memory leaks have been plugged.
+
+* A seg fault which always occurred after waiting on another process's lock
+  in order to establish a promotable lock is now avoided.
+
+* An unlikely potential segfault when using the :fork: connection method has
+  been fixed.
+
+* The CVS server has had the protocol check for unused data from the client
+  partially restored.
+
+* A fix has been included that should avoid a very rare race condition that
+  could cause a CVS server to exit with a "broken pipe" message.
+
+* Infinite alias loops in the modules file are now checked for and avoided.
+
+* Clients on case insensitive systems now preserve the case of directories in
+  CVS/Entries, in addition to files, for use in communications with the CVS
+  server.
+
+* Misc status message fixes for consistency.
+
+* Some previously untested behavior is now being tested.
+
+* Server no longer claims to support the "Case" request.
+
+* Case insensitive clients once again preserve the case of filenames in
+  CVS/Entries for communication with the server, as specified in the CVS
+  client/server protocol spec.  Note that all CVS _servers_ still lack support
+  for case insensitive clients - servers are relying on the client to preserve
+  the case of checked out files.
+
+* Thanks to Ville Skytt√§ the man page has a few less spelling errors and is
+  slightly more accurate.
+
+* Thanks to Ville Skytt√§ some unused variables were removed from the log_accum
+  Perl script in contrib.
+
+* Thanks to Alexey Mahotkin, a bug that prevented CVS from being compiled with
+  Kerberos 4 authentication enabled has been fixed.
+
+* A minor bug that caused CVS to fail to report an inifinte alias loop in the
+  modules file when portions of the alias definition contained trailing slashes
+  has been fixed.
+
+* A bug in the gzip code that could cause heap corruption and segfaults in CVS
+  servers talking to clients less than 1.8 and some modern third-party CVS
+  clients has been fixed.
+
+* mktemp.sh is now included with the source distribution so that the rcs2log
+  and cvsbug executables may be run on systems which do not contain an
+  implementation of mktemp.
+
+* Misc documentation fixes.
+
+DEVELOPER ISSUES
+
+* xmalloc, xstrdup, & some other memory allocating functions are now available
+  vi GNULIB versions imported into lib.
+
+* The asnprintf() & vasnprintf() functions are now available due to a GNULIB
+  implementation.
+
+* Misc cosmetic, readability, and commenting fixes.
+
+Changes between 1.12.4 and 1.12.5:
+**********************************
+
+SERVER SECURITY ISSUES
+
+* pserver can no longer be configured to run as root via the
+  $CVSROOT/CVSROOT/passwd file, so if your passwd file is compromised, it no
+  longer leads directly to a root hack.  Attempts to root will also be logged
+  via the syslog.
+
+GENERAL USER ISSUES
+
+* The Windows build files were updated to allow building of the current version
+  under Windows.
+
+Changes between 1.12.3 and 1.12.4:
+**********************************
+
+GENERAL USER ISSUES
+
+* The CVS server no longer locks more than a directory at a time for write, so
+  large commits & tags should now have a much harder time blocking other
+  operations.
+
+* Add support for large files. Use --disable-largefile to omit support
+  for large files.
+
+Changes between 1.12.2 and 1.12.3:
+**********************************
+
+SERVER SECURITY ISSUES
+
+* Malformed module requests could cause the CVS server to attempt to create
+  directories and possibly files at the root of the filesystem holding the CVS
+  repository.  Filesystem permissions usually prevent the creation of these
+  misplaced directories, but nevertheless, the CVS server now rejects the
+  malformed requests.
+
+GENERAL USER ISSUES
+
+* Support for case insensitive clients has been removed.  This is not as
+  drastic as it sounds, as all of the current tests still pass without
+  modification when run from a case insensitive client to a case sensitive
+  server.  In the end this should provide a major stability improvement.
+
+* A minor problem that prevented the correct version of a system ZLIB from
+  being detected on some platforms has been fixed.
+
+* Attempts to use the global `-l' option, removed from both client and server
+  as of version 1.12.1, will now elicit a warning rather than a fatal error
+  from the server.
+
+* The configure script now tests whether it is building CVS on a case
+  insensitive file system.  If it is, CVS assumes that all file systems on this
+  platform will be case insensitive.  This is useful for getting the case
+  insensitivity flag set correctly when compiling on Mac OS X and under Cygwin
+  on Windows.  Autodetection can be overridden using the
+  --disable-case-sensitivity and --enable-case-sensitivity arguments to
+  configure.
+
+DEVELOPER ISSUES
+
+* A new set of tests to test issues specific to case insensitive clients and
+  servers has also been added.
+
+* Support has been added to the test suite to support testing over a :ext: link
+  to another machine, subject to some stringent requirements.  This support can
+  be used, for instance, to test the operation of a case insensitive client
+  against a case sensitive server.  Please see the comments in TEST and the
+  src/sanity.sh test script itself for more.
+
+* We've standardized on Automake 1.7.9 to get a bug fix.  See the note below
+  on the Autoconf upgrade for more details.
+
+* We've standardized on Autoconf version 2.58 to avoid a bug and get at a few
+  new macros.  Again, this should only really affect developers, though it is
+  possible that CVS will now compile on a few new platforms.  Please see the
+  section of the INSTALL file about using the autotools if you are compiling
+  CVS yourself.
+
+Changes between 1.12.1 and 1.12.2:
+
+* Misc cleanup, reorganization, and other minor fixes.
+
+* A behavior change in `cvs up -jrev1 -jrev2' for modified files with a base
+  revision of rev2 (ie, checked-out version matches rev2 and file has been
+  modified).  The operation is no longer ignored and instead is passed to
+  diff3.  This will potentially re-apply the diffs between the two revisions to
+  a modified local file.  Status messages like from a standard merge have also
+  been added when the file would not or does not change due to this merge
+  request ("[file] already contains the changes between [revisions]...").
+
+* A build problem that caused warnings and slower builds on systems without a
+working getline() function (e.g. Mac OS X 10.1) has been fixed.
+
+* A build problem that prevented the CVS executable from being built on systems
+with the gettext library installed has been fixed.
+
+* A bug which could stop `cvs admin -mTAG:message' from recursing has been
+  fixed.
+
+* Misc documentation cleanup and fixes.
+
+* Some of the contrib scripts, some of the documentation, and sanity.sh were
+  modified to use and recommend more portable commands rather than using and
+  recommending commands which were not compatible with the POSIX 1003.1-2001
+  specification.
+
+* CVS now knows how to report, as well as record, `P' record types.
+
+* When running the `cvs history' command, clients will now send the
+  long-accepted `-e' option, for all records, rather than explicitly requesting
+  `P' record types, a request which servers prior to 1.11.7 will reject with a
+  fatal error message.
+
+* A problem with locating files requested by case insensitive clients which was
+  accidentally introduced in 1.11.6 as part of a fix for a data loss problem
+  involving `cvs add's from case insensitive clients has been fixed.  The
+  relevant error message was `cvs [<command> aborted]: filE,v is ambiguous;
+  could mean FILE,v or file,v'.
+
+* A problem in the CVS getpass library that could cause passwords to echo on
+  some systems has been fixed.
+
+* A segfault that could occur in very rare cases where the stat of a file
+  failed during a diff has been fixed.
+
+* Any user with write privleges to the CVSROOT/checkoutlist file could pass
+arbitrary format strings directly through to a printf function.  This was
+probably bad and has been fixed.  White space at the beginning of error strings
+in checkoutlist is now ignored properly.
+
+* A chmod 0600 that CVS performed on temp files it created designed to work
+around a bug in versions of GLIBC eariler than 2.0.7 has been removed since it
+still left a race condition open to exploitation and provided a false sense of
+security.  If you are linking CVS against a version of GLIBC prior to 2.0.7,
+you should consider upgrading GLIBC.
+
+* The CVSROOT/editinfo file is no longer referenced by CVS.  This funcitonality
+has been deprecated for over six years and removing it will presumably not
+cause anyone any problems.
+
+* In client/server mode, most messages from CVS now contain the actual
+command name rather than the generic "server".
+
+* A long-standing bug that prevented most client/server updates from being
+logged in the history file has been fixed.
+
+* Updates done via a patch ("P" status) are now logged in the history file
+by default and the corresponding "P" history record type is now documented.
+If you're setting the LogHistory option in your CVSROOT/config file, you may
+want to add "P" to the list of record types.
+
+* CVS now will always compile its own getpass() function (originally from
+GNULIB) in favor of any system one that may exist.  This avoids some problems
+with long passwords on some systems and updates us to POSIX.2 compliance, since
+getpass() was removed from the POSIX.2 specification.
+
+* Support for pre-ANSI compilers has been removed.  Our minimum support level
+now assumes at least a freestanding C89 compilers.  See the HACKING file for
+more information.  If you *really* need K&R support, our Makefile.am files
+should only need minor tweaking to get them to run the ansi2knr script from the
+Automake project.  If you get this working, please send a patch to
+<bug-cvs@gnu.org>.
+
+* Experimental support for Pluggable Authentication Modules (PAM) has been
+added, though it is not compiled by default.  If you like this feature (or
+don't), please send us feedback.  See the Cederqvist, `./configure --help',
+and the INSTALL file for more.
+
+* Command line keyword expansion modes no longer override binary keyword
+expansion modes.
+
+* New LocalKeyword and KeywordExpand options to CVSROOT/config which
+FreeBSD, OpenBSD, and NetBSD users may find familiar as the "tag" and
+"tagexpand" options used for many years. The CVSHeader keyword has
+also been added to the mixture.
+
+* A bug that allowed a write lock to be created in a directory despite
+there being existing read locks when using LockDir in CVSROOT/config has
+been fixed.
+
+* A bug with short patches (`rdiff -s') which caused rdiff to sometimes report
+differences that did not exist has been fixed.
+
+* Some minor corrections were made to the diff code to keep diff & rdiff from
+printing diff headers with empty change texts when two files have different
+revision numbers but the same content.
+
+* The global '-l' option, which suppressed history logging, has been removed
+from both client and server.
+
+Changes from 1.11.5 to 1.12.1:
+
+* The new --with-external-zlib option can be passed to configure to compile
+CVS against an external installed zlib.
+
+* A warning message is now issued if an administrative file contains
+more than one DEFAULT entry.
+
+* An error running a verifymsg script (such as referencing an unset user
+variable or the script not existing) now causes the verification to
+fail.
+
+* Errors in administrative files commands (like unset user variables)
+are no longer reported unless the command is actually executed.
+
+* When a file is initially checked out, its last access time is now set
+to the current time rather than being set to the time the file was last
+checked in like the modification time is.
+
+* The Checkin.prog and Update.prog functionality has been removed.  This
+fuctionality previously allowed executables to be specified in the modules file
+to be run at update and checkin time, but users could edit these files on a per
+workspace basis, creating a security hole.
+
+* CVSROOTs which contain a symlink to a real repository should work.
+
+* contrib/rcs2log and src/cvsbug now use the BSD mktemp program to create
+their temp files and directories on systems which provide it.
+
+* Added a UserAdminOptions configuration option to CVSROOT/config to
+control which `cvs admin' commands are not restricted to the `cvsadmin'
+group.
+
+* If the rcsinfo specified template changes after a user has checked
+out a tree, the template in the users' tree will be updated rather
+than remaining static from the time of the original checkout.
+
+* Added a CVSREADONLYFS environment variable and `-R' cvs global
+option to turn on read-only repository mode for local repositories.
+This allows users to checkout from a CDROM repository or other
+read-only filesystem.
+
+* There is a new CVS_LOCAL_BRANCH_NUM environment variable, which
+may be used to give control over the branch number to be used next.
+Useful for having local changes in a CVSup mirrored repository.
+
+* Miscellaneous documentation corrections.
+
+* Corrected the path in a failed write error message.
+
+* Autoconf and Automake are no longer run automatically unless you run
+configure with --enable-maintainer-mode.  Accordingly, noautomake.sh is
+no longer needed and has been removed.
+
+* We've standardized on Automake version 1.7.5 and Autoconf version 2.57 to get
+at a few new macros.  Again, this should only really affect developers.  See
+the section of the INSTALL file about using the autotools if you are compiling
+CVS yourself.
+
+Changes from 1.11.4 to 1.11.5:
+
+* Fixed a security hole in the CVS server by which users with read only access
+could gain write access.  This issue does not affect client builds.  The
+Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the
+name CAN-2003-0015 to this issue.  See
+<http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0015> for more
+information.
+
+* Fixed some bugs where revision numbers starting with 0 (like 0.3)
+weren't correctly handled.  (CVS doesn't normally use such revision
+numbers, but users may be able to force it to do so and old RCS files
+might.)
+
+Changes from 1.11.3 to 1.11.4:
+
+* Some minor changes to allow the code to compile on Windows platforms.
+
+Changes from 1.11.2 to 1.11.3:
+
+* The tag/rtag code has been fixed to once again lock just a single
+directory at a time.
+
+* There was a bug where certain error conditions could cause the server
+to go into an infinite loop.  There was also a bug that caused a
+compressed connection from an older client to hang on shutdown.  These
+bugs have been fixed.
+
+* Fixed a bug that caused the server to reject most watch commands.
+
+* When waiting for another user's lock, the message timestamps are now
+in UTC rather than the server's local time.
+
+* The options.h file is no longer used.  This fixes a bug that occurred when
+1.11.2 was compiled on Windows platforms.
+
+* We've standardized on Automake version 1.6.3 and Autoconf version 2.53.
+They are cleaner, less bug prone, and will hopfully allow me to start updating
+sanity.sh to use Autotest and Autoshell.  Again, this should only really affect
+developers.  See the section of the INSTALL file about using the autotools if
+you are compiling CVS yourself.
+
+* Fixed a bug in the log/rlog code when a revision range crosses a
+branch point.
+
+* Fixed a bug where filenames starting with - would be misinterpreted as
+options when using client/server mode.
+
+Changes from 1.11.1p1 to 1.11.2:
+
+* There is a new feature, enabled by RereadLogAfterVerify in CVSROOT/config,
+which tells CVS to reread the log message after running the verifymsg
+script.  This allows the verifymsg script to reformat or otherwise
+modify the log message.
+
+* The interpretation of revision ranges using :: in "log" and "rlog"
+has changed: a::b now excludes the log message from revision a but
+includes the log message from revision b.  Also, revision ranges that
+cross branch points should now work.
+
+* zlib has been updated to version 1.4.  There is a security advisory
+out in regards to 1.3.  This should fix that problem.
+
+* The "log" and "rlog" commands now have a -S option to suppress the
+header information when no revisions are selected.
+
+* A serious error that allowed read-only users to tag files has been
+corrected.
+
+* The "annotate" command will no longer annotate binary files unless
+you specify the new -F option.
+
+* The "tag" and "rtag" commands will no longer move or delete branch
+tags unless you use the new -B option.  (This prevents accidental
+changes to branch tags that are hard to undo.)
+
+* We've standardized on the 1.5 Automake release for the moment.  Again, this
+should only really affect developers.  See the section of the INSTALL file
+about using the autotools if you are compiling CVS yourself.
+
+Changes from 1.11.1 to 1.11.1p1:
+
+* Read only access was broken - now fixed.
+
+Changes from 1.11 to 1.11.1:
+
+* There was a locking bug in the tag/rtag code that could lose changes
+made to a file while the tag operation was in progress.  This has been
+fixed, but all of the directories being tagged are now locked for the
+entire duration of the tag operation rather than only one directory at a
+time.
+
+* The "cvs diff" command now accepts the -y/--side=by-side and -T/
+--initial-tab options.  (To use these options with a remote repository,
+both the client and the server must support them.)
+
+* The expansion of the loginfo format string has changed slightly. 
+Previously, the expansion was surrounded by single quotes ('); if a file
+name contained a single quote character, the string would not be parsed
+as a single entity by the Unix shell (and it would not be possible to
+parse it unambiguously).  Now the expansion is surrounded by double
+quotes (") and any embedded dollar signs ($), backticks (`), backslashes
+(\), and double quotes are preceded by a backslash.  This is parsed as a
+single entity by the shell reguardless of content.  This change should
+not be noticable unless you're not using a Unix shell or you have
+embedded the format string inside a double quoted string.
+
+* There was a bug in the diff code which sometimes caused conflicts to
+be flagged which shouldn't have been.  This has been fixed.
+
+* New "cvs rlog" and "cvs rannotate" commands have been added to get log
+messages and annotations without having to have a checked-out copy.
+
+* Exclusive revision ranges have been added to "cvs log" using ::
+(similar to "cvs admin -o").
+
+* The VMS client now accepts wildcards if you're running VMS 7.x.
+
+* ZLIB has been updated to version 1.1.3, the most current version.  This
+includes mostly some optimizations and minor bug fixes.
+
+* The ~/.cvspass file has a slightly modified format.  CVSROOTs are now
+stored in a new canonical form - hostnames are now case insensitive and
+port numbers are always stored in the new format.  Until a new login for
+a particular CVSROOT is performed with the new version of CVS, new and
+old versions of CVS should interoperate invisibly.  After that point, an
+extra login using the old version of CVS may be necessary to continue to
+allow the new and old versions of CVS to interoperate using the same
+~/.cvspass file and CVSROOT. The exception to this rule occurs when the
+CVSROOTs used with the different versions use case insensitively
+different hostnames, for example, "empress", and "empress.2-wit.com".
+
+* A password and a port number may now be specified in CVSROOT for
+pserver connections.  The new format is:
+
+    :pserver:[[user][:password]@]host[:[port]]/path
+
+Note that passwords specified in a checkout command will be saved in the
+clear in the CVS/Root file in each created directory, so this is not
+recommended, except perhaps when accessing anonymous repositories or the
+like.
+
+* The distribution has been converted to use Automake.  This shouldn't
+affect most users except to ease some portability concerns, but if you
+are building from the repository and encounter problems with the
+makefiles, you might try running ./noautomake.sh after a fresh update
+-AC.
+
+Changes from 1.10 to 1.11:
+
+* The "cvs update" command has a new -C option to get clean copies from
+the repository, abandoning any local changes.
+
+* The new "cvs version" command gives a short version message.  If
+the repository is remote, both the client and server versions are
+reported.
+
+* "cvs admin -t" now works correctly in client/server mode.
+
+* The "cvs history" command output format has changed -- the date
+now includes the year and is given is ISO 8601 format (yyyy-mm-dd).
+Also, the new LogHistory option in CVSROOT/config can be used to
+control what information gets recorded in the log file and code has
+been added to record file removals.
+
+* The buggy PreservePermissions code has been disabled.
+
+* Anonymous read-only access can now be done without requiring a
+password.  On the server side, simply give that user (presumably
+`anonymous') an empty password in the CVSROOT/passwd file, and then
+any received password will authenticate successfully.
+
+* There is a new access method :fork: which is similar to :local:
+except that it is implemented via the CVS remote protocol, and thus
+has a somewhat different set of quirks and bugs.
+
+* The -d command line option no longer updates the CVS/Root file.  For
+one thing, the CVS 1.9/1.10 behavior never had updated CVS/Root in
+subdirectories, and for another, it didn't seem that popular in
+general.  So this change restores the CVS 1.8 behavior (which is also
+the CVS 1.9/1.10 behavior if the environment variable
+CVS_IGNORE_REMOTE_ROOT is set; with this change,
+CVS_IGNORE_REMOTE_ROOT no longer has any effect).
+
+* It is now possible for a single CVS command to recurse into several
+CVS roots.  This includes roots which are located on several servers,
+or which are both remote and local.  CVS will make connections to as
+many servers as necessary.
+
+* It is now possible to put the CVS lock files in a directory
+set by the new LockDir option in CVSROOT/config.  The default
+continues to be to put the lock files in the repository itself.
+
+Changes from 1.9 to 1.10:
+
+* A bug was discovered in the -t/-f wrapper support that can cause
+serious data loss.  Because of this (and also the fact that it doesn't
+work at all in client/server mode), the -t/-f wrapper code has been
+disabled until it can be fixed.
+
+* There is a new feature, enabled by TopLevelAdmin in CVSROOT/config,
+which tells CVS to modify the behavior of the "checkout" command.  The
+command now creates a CVS directory at the top level of the new
+working directory, in addition to CVS directories created within
+checked-out directories.  See the Cederqvist for details.
+
+* There is an optional set of features, enabled by PreservePermissions
+in CVSROOT/config, which allow CVS to store unix-specific file
+information such as permissions, file ownership, and links.  See the
+Cederqvist for details.
+
+* One can now authenticate and encrypt using the GSSAPI network
+security interface.  For details see the Cederqvist's description of
+specifying :gserver: in CVSROOT, and the -a global option.
+
+* All access to RCS files is now implemented internally rather than by
+calling RCS programs.  The main user-visible consequence of this is
+that there is no need to worry about making sure that CVS finds the
+correct version of RCS.  The -b global option and the RCSBIN setting
+in CVSROOT/config are still accepted but don't do anything.  The
+$RCSBIN internal variable in administrative files is no longer
+accepted.
+
+* There is a new syntax, "cvs admin -orev1::rev2", which collapses the
+revisions between rev1 and rev2 without deleting rev1 or rev2
+themselves.
+
+* There is a new administrative file CVSROOT/config which allows one
+to specify miscellaneous aspects of CVS configuration.  Currently
+supported here:
+
+  - SystemAuth, allows you to prevent pserver from checking for system
+  usernames/passwords.
+
+For more information see the "config" section of cvs.texinfo.
+
+* When setting up the pserver server, one now must specify the
+allowable CVSROOT directories in inetd.conf.  See the Password
+authentication server section of cvs.texinfo for details.  Note that
+this implies that everyone who is running a pserver server must edit
+inetd.conf when upgrading their CVS.
+
+* The client no longer needs an external patch program (assuming both
+the client and the server have been updated to the new version).
+
+* "cvs admin [options]" will now recurse.  In previous versions of
+CVS, it was an error and one needed to specify "cvs admin [options] ."
+to recurse.  This change brings admin in line with the other CVS
+commands.
+
+* New "logout" command to remove the password for a remote cvs
+repository from the cvspass file.
+
+* Read-only repository access is implemented for the
+password-authenticated server (other access methods are just governed
+by Unix file permissions, since they require login access to the
+repository machine anyway).  See the "Repository" section of
+cvs.texinfo for details, including a discussion of security issues.
+Note that the requirement that read-only users be able to create locks
+and write the history file still applies.
+
+* There is a new administrative file verifymsg which is like editinfo
+but merely validates the message, rather than also getting it from the
+user.  It therefore works with client/server CVS or if one uses the -m
+or -F options to commit.  See the verifymsg section of cvs.texinfo for
+details.
+
+* The %s format formerly accepted in loginfo has been extended to
+formats such as %{sVv}, so that loginfo scripts have access to the
+version numbers being changed.  See the Loginfo section of cvs.texinfo
+for details.
+
+* The postscript documentation (doc/cvs.ps) shipped with CVS is now
+formatted for US letter size instead of A4.  This is not because we
+consider this size "better" than A4, but because we believe that the
+US letter version will print better on A4 paper than the other way
+around.
+
+* The "cvs export" command is now logged in the history file and there
+is a "cvs history -x E" command to select history file entries
+produced by export.
+
+* CVS no longer uses the CVS_PASSWORD environment variable.  Storing
+passwords in cleartext in an environment variable is a security risk,
+especially since (on BSD variants) any user on the system can display
+any process's environment using 'ps'.  Users should use the 'cvs
+login' command instead.
+
+
+Changes from 1.8 to 1.9:
+
+* Windows NT client should now work on Windows 95 as well.
+
+* New option "--help-synonyms" prints a list of all recognized command
+synonyms.
+
+* The "log" command is now implemented internally rather than via the
+RCS "rlog" program.  The main user-visible consequence is that
+symbolic branch names now work (for example "cvs log -rbranch1").
+Also, the date formats accepted by -d have changed.  They previously
+had been a bewildering variety of poorly-documented date formats.  Now
+they are the same as the date formats accepted by the -D options to
+the other CVS commands, which is also a (different) bewildering
+variety of poorly-documented date formats, but at least we are
+consistently bewildering :-).
+
+* Encryption is now supported over a Kerberos client/server
+connection.  The new "-x" global option requests it.  You must
+configure with the --enable-encryption option in order to enable
+encryption.
+
+* The format of the CVS commit message has changed slightly when
+committing changes on a branch.  The tag on which the commit is
+ocurring is now reported correctly in all cases.
+
+* New flag -k in wrappers allows you to specify the keyword expansion
+mode for added files based on their name.  For example, you can
+specify that files whose name matches *.exe are binary by default.
+See the Wrappers section of cvs.texinfo for more details.
+
+* Remote CVS with the "-z" option now uses the zlib library (included
+with CVS) to compress all communication between the client and the
+server, rather than invoking gzip on each file separately.  This means
+that compression is better and there is no need for an external gzip
+program (except to interoperate with older version of CVS).
+
+* The "cvs rlog" command is deprecated and running it will print a
+warning; use the synonymous "cvs log" command instead.  It is
+confusing for rlog to mean the same as log because some other CVS
+commands are in pairs consisting of a plain command which operates on
+a working directory and an "r" command which does not (diff/rdiff;
+tag/rtag).
+
+* "cvs diff" has a bunch of new options, mostly long options.  Most of
+these work only if rcsdiff and diff support them, and are named the
+same as the corresponding options to diff.
+
+* The -q and -Q command options to "cvs diff" were removed (use the
+global options instead).  This brings "cvs diff" into line with the
+rest of the CVS commands.
+
+* The "annotate" command can now be used to annotate a revision other
+than the head revision on the trunk (see the -r, -D, and -f options in
+the annotate node of cvs.texinfo for details).
+
+* The "tag" command has a new option "-c" which checks that all files
+  are not locally modified before tagging.
+
+* The -d command line option now overrides the cvsroot setting stored
+in the CVS/Root file in each working directory, and specifying -d will
+cause CVS/Root to be updated.
+
+* Local (non-client/server) CVS now runs on Windows NT.  See
+windows-NT/README for details.
+
+* The CVSROOT variable specification has changed to support more
+access methods.  In addition to "pserver," "server" (internal rsh
+client), "ext" (external rsh client), "kserver" (kerberos), and
+"local" (local filesystem access) can now be specified.  For more
+details on each method, see cvs.texinfo (there is an index entry for
+:local: and each of the other access methods).
+
+* The "login" command no longer prompts the user for username and
+hostname, since one will have to provide that information via the `-d'
+flag or by setting CVSROOT.
+
+Changes from 1.7 to 1.8:
+
+* New "cvs annotate" command to display the last modification for each
+line of a file, with the revision number, user checking in the
+modification, and date of the modification.  For more information see
+the `annotate' node in cvs.texinfo.
+
+* The cvsinit shell script has been replaced by a cvs init command.
+The cvs init command creates some example administrative files which
+are similar to the files found in the examples directory (and copied
+by cvsinit) in previous releases.
+
+* Added the patterns *.olb *.exe _$* *$ to default ignore list.
+
+* There is now a $USER internal variable for *info files.
+
+* There is no longer a separate `mkmodules' program; the functionality
+is now built into `cvs'.  If upgrading an old repository, it is OK to
+leave in the lines in the modules file which run mkmodules (the
+mkmodules actions will get done twice, but that is harmless); you will
+probably want to remove them once you are no longer using the old CVS.
+
+* One can now specify user variables in *info files via the
+${=varname} syntax; there is a -s global option to set them.  See the
+Variables node in cvs.texinfo for details.
+
+Changes from 1.6 to 1.7:
+
+* The default ignore list has changed slightly: *.obj has been added
+and CVS* has been changed to CVS CVS.adm.
+
+* CVS now supports password authentication when accessing remote
+repositories; this is useful for sites that can't use rsh (because of
+a firewall, for example), and also don't have kerberos.  See node
+"Password authenticated" (in "Remote repositories", in
+doc/cvs.texinfo) for more details.  Note: This feature requires both
+the client and server to be upgraded.
+
+* Using the -kb option to specify binary files now works--most cases
+did not work before.  See the "Binary files" section of
+doc/cvs.texinfo for details.
+
+* New developer communication features.  See the "Watches" section of
+doc/cvs.texinfo for details.
+
+* RCS keyword "Name" supported for "cvs update -r <tag>" and "cvs
+checkout -r <tag>".
+
+* If there is a group whose name matches a compiled in value which
+defaults to "cvsadmin", only members of that group can use "cvs
+admin".  This replaces the CVS_NOADMIN option.
+
+* CVS now sets the modes of files in the repository based on the
+CVSUMASK environment variable or a compiled in value defaulting to
+002.  This way other developers will be able to access the files in
+the repository regardless of the umask of the developer creating them.
+
+* The command names in .cvsrc now match the official name of the
+command, not the one (possibly an alias) by which it was invoked.  If
+you had previously relied on "cvs di" and "cvs diff" using different
+options, instead use a shell function or alias (for example "alias
+cvsdi='cvs diff -u'").  You also can specify global CVS options (like
+"-z") using the command name "cvs".
+
+Changes from 1.5 to 1.6:
+
+* Del updated the man page to include all of the new features
+of CVS 1.6.
+
+* "cvs tag" now supports a "-r | -D" option for tagging an already
+tagged revision / specific revision of a file.
+
+* There is a "taginfo" file in CVSROOT that supports filtering and
+recording of tag operations.
+
+* Long options support added, including --help and --version options.
+
+* "cvs release" no longer cares whether or not the directory being
+released has an entry in the `modules' file.
+
+* The modules file now takes a -e option which is used instead of -o
+for "cvs export".  If your modules file has a -o option which you want
+to be used for "cvs export", change it to specify -e as well as -o.
+
+* "cvs export" now takes a -k option to set RCS keyword expansion.
+This way you can export binary files.  If you want the old behavior,
+you need to specify -kv.
+
+* "cvs update", "cvs rdiff", "cvs checkout", "cvs import", "cvs
+release", "cvs rtag", and "cvs tag" used to take -q and -Q options
+after the command name (e.g. "cvs update -q").  This was confusing
+because other commands, such as "cvs ci", did not.  So the options
+after the command name have been removed and you must now specify, for
+example, "cvs -q update", which has been supported since CVS 1.3.
+
+* New "wrappers" feature.  This allows you to set a hook which
+transforms files on their way in and out of cvs (apparently on the
+NeXT there is some particular usefulness in tarring things up in the
+repository).  It also allows you to declare files as merge-by-copy
+which means that instead of trying to merge the file, CVS will merely
+copy the new version.  There is a CVSROOT/cvswrappers file and an
+optionsl ~/.cvswrappers file to support this feature.
+
+* You can set CVSROOT to user@host:dir, not just host:dir, if your
+username on the server host is different than on the client host.
+
+* VISUAL is accepted as well as EDITOR.
+
+* $CVSROOT is expanded in *info files.
+
+Changes from 1.4A2 to 1.5:
+
+* Remote implementation.  This is very helpful when collaborating on a
+project with someone across a wide-area network.  This release can
+also be used locally, like other CVS versions, if you have no need for
+remote access.
+
+Here are some of the features of the remote implementation:
+- It uses reliable transport protocols (TCP/IP) for remote repository
+  access, not NFS.  NFS is unusable over long distances (and sometimes
+  over short distances)
+- It transfers only those files that have changed in the repository or
+  the working directory.  To save transmission time, it will transfer
+  patches when appropriate, and can compress data for transmission.
+- The server never holds CVS locks while waiting for a reply from the client;
+  this makes the system robust when used over flaky networks.
+
+The remote features are documented in doc/cvsclient.texi in the CVS
+distribution, but the main doc file, cvs.texinfo, has not yet been
+updated to include the remote features.
+
+* Death support.  See src/README-rm-add for more information on this.
+
+* Many speedups, especially from jtc@cygnus.com.
+
+* CVS 1.2 compatibility code has been removed as a speedup.  If you
+have working directories checked out by CVS 1.2, CVS 1.3 or 1.4A2 will
+try to convert them, but CVS 1.5 and later will not (if the working
+directory is up to date and contains no extraneous files, you can just
+remove it, and then check out a new working directory).  Likewise if
+your repository contains a CVSROOT.adm directory instead of a CVSROOT
+directory, you need to rename it.
+
+Fri Oct 21 20:58:54 1994  Brian Berliner  <berliner@sun.com>
+
+       * Changes between CVS 1.3 and CVS 1.4 Alpha-2
+
+       * A new program, "cvsbug", is provided to let you send bug reports
+       directly to the CVS maintainers.  Please use it instead of sending
+       mail to the info-cvs mailing list.  If your build fails, you may
+       have to invoke "cvsbug" directly from the "src" directory as
+       "src/cvsbug.sh".
+
+       * A new User's Guide and Tutorial, written by Per Cederqvist
+       <ceder@signum.se> of Signum Support.  See the "doc" directory.  A
+       PostScript version is included as "doc/cvs.ps".
+
+       * The Frequesntly Asked Questions file, FAQ, has been added to the
+       release.  Unfortunately, its contents are likely out-of-date.
+
+       * The "cvsinit" shell script is now installed in the $prefix/bin
+       directory like the other programs.  You can now create new
+       CVS repositories with great ease.
+
+       * Index: lines are now printed on output from 'diff' and 'rdiff',
+       in order to facilitate application of patches to multiple subdirs.
+
+       * Support for a ~/.cvsrc file, which allows you to specify options
+       that are always supposed to be given to a specific command.  This
+       feature shows the non-orthogonality of the option set, since while
+       there may be an option to turn something on, the option to turn
+       that same thing off may not exist.
+
+       * You can now list subdirectories that you wish to ignore in a
+       modules listing, such as:
+
+               gcc  -a gnu/gcc, !gnu/gcc/testsuites
+
+       which will check out everything underneath gnu/gcc, except
+       everything underneath gnu/gcc/testsuites.
+
+       * It is now much harder to accidentally overwrite an existing tag
+       name, since attempting to move a tag name will result in a error,
+       unless the -F (force) flag is given to the tag subcommands.
+
+       * Better error checking on matching of the repository used to
+       check code out from against the repository the current cvs
+       commnands would use. (Thanks to Mark Baushke <mdb@cisco.com>)
+
+       * Better support for sites with multiple CVSROOT repositories has
+       been contributed.  The file "CVS/Root" in your working directory
+       is created to hold the full path to the CVS repository and a
+       simple check is made against your current CVSROOT setting.
+
+       * You can now specify an RCS keyword substitution value when you
+       import files into the repository.
+
+       * Uses a much newer version of Autoconf, and conforms to the GNU
+       coding standards much more closely.  No, it still doesn't have
+       long option names.
+
+       * Code cleanup.  Many passes through gcc -Wall helped to identify
+       a number of questionable constructs.  Most arbitrary length limits
+       were removed.
+
+       * Profiling to determine bottlenecks helped to identify the best
+       places to spend time speeding up the code, which was then done.  A
+       number of performance enhancements in filename matching have sped
+       up checkouts.
+
+       * Many more contributions have been added to the "contrib"
+       directory.  See the README file in that directory for more
+       information.
+
+       * "cvs commit" will try harder to not change the file's
+       modification time after the commit.  If the file does not change
+       as a result of the commit operation, CVS will preserve the
+       original modification time, thus speeding up future make-type
+       builds.
+
+       * "cvs commit" now includes any removed files in the (optional)
+       pre-commit checking program that may be invoked.  Previously, only
+       added and modified files were included.
+
+       * It is now possible to commit a file directly onto the trunk at a
+       specific revision level by doing "cvs commit -r3.0 file.c", where
+       "3.0" specifies the revision you wish to create.  The file must be
+       up-to-date with the current head of the trunk for this to succeed.
+
+       * "cvs commit" will now function with a pre-commit program that
+       has arguments specified in the "commitinfo" file.
+
+       * The "mkmodules" program will now look within the
+       $CVSROOT/CVSROOT/checkoutlist" file for any additional files that
+       should be automatically checked out within CVSROOT; mkmodules also
+       tries harder to preserve any execute bits the files may have
+       originally had.
+
+       * "cvs diff" is much more accurate about its exit status now.  It
+       now returns the maximum exit status of any invoked diff.
+
+       * The "-I !" option is now supported for the import and update
+       commands correctly.  It will properly clear the ignore list now.
+
+       * Some problems with "cvs import" handling of .cvsignore have been
+       fixed; as well, some rampant recursion problems with import have
+       also been fixed.
+
+       * "cvs rdiff" (aka "cvs patch") now tries to set the modify time
+       of any temporary files it uses to match those specified for the
+       particular revision.  This allows a more accurate patch image to
+       be created.
+
+       * "cvs status" has improved revision descriptions.  "Working
+       revision" is used for the revision of the working file that you
+       edit directly; "Repository revision" is the revision of the file
+       with the $CVSROOT source repository.  Also, the output is clearer
+       with regard to sticky and branch revisions.
+
+       * CVS no longer dumps core when given a mixture of directories and
+       files in sub-directories (as in "cvs ci file1 dir1/file2").
+       Instead, arguments are now clumped into their respective directory
+       and operated on in chunks, together.
+
+       * If the CVSEDITOR environment variable is set, that editor is
+       used for log messages instead of the EDITOR environment variable.
+       This makes it easy to substitute intelligent programs to make more
+       elaborate log messages.  Contributed by Mark D Baushke
+       (mdb@cisco.com).
+
+       * Command argument changes:
+       cvs:                    The "-f" option has been added to ignore
+                               the ~/.cvsrc file.
+       commit:                 Renamed the "-f logfile" option to the
+                               "-F logfile" option.  Added the "-f"
+                               option to force a commit of the specified
+                               files (this disables recursion).
+       history:                Added "-t timezone" option to force any
+                               date-specific output into the specified
+                               timezone.
+       import:                 Added "-d" option to use the file's
+                               modification time as the time of the
+                               import. Added "-k sub" option to set the
+                               default RCS keyword substitution mode for
+                               newly-created files.
+       remove:                 Added "-f" option to force the file's
+                               automatic removal if it still exists in
+                               the working directory (use with caution).
+       rtag:                   Added "-F" option to move the tag if it
+                               already exists -- new default is to NOT
+                               move tags automatically.
+       tag:                    Added "-F" option to move the tag if it
+                               already exists -- new default is to NOT
+                               move tags automatically.
+
+Tue Apr  7 15:55:25 1992  Brian Berliner  (berliner at sun.com)
+
+       * Changes between CVS 1.3 Beta-3 and official CVS 1.3!
+
+       * A new shell script is provided, "./cvsinit", which can be run at
+       install time to help setup your $CVSROOT area.  This can greatly
+       ease your entry into CVS usage.
+
+       * The INSTALL file has been updated to include the machines on
+       which CVS has compiled successfully.  I think CVS 1.3 is finally
+       portable.  Thanks to all the Beta testers!
+
+       * Support for the "editinfo" file was contributed.  This file
+       (located in $CVSROOT/CVSROOT) can be used to specify a special
+       "editor" to run on a per-directory basis within the repository,
+       instead of the usual user's editor.  As such, it can verify that
+       the log message entered by the user is of the appropriate form
+       (contains a bugid and test validation, for example).
+
+       * The manual pages cvs(1) and cvs(5) have been updated.
+
+       * The "mkmodules" command now informs you when your modules file
+       has duplicate entries.
+
+       * The "add" command now preserves any per-directory sticky tag when
+       you add a new directory to your checked-out sources.
+
+       * The "admin" command is now a fully recursive interface to the
+       "rcs" program which operates on your checked-out sources.  It no
+       longer requires you to specify the full path to the RCS file.
+
+       * The per-file sticky tags can now be effectively removed with
+       "cvs update -A file", even if you had checked out the whole
+       directory with a per-directory sticky tag.  This allows a great
+       deal of flexibility in managing the revisions that your checked-out
+       sources are based upon (both per-directory and per-file sticky
+       tags).
+
+       * The "cvs -n commit" command now works, to show which files are
+       out-of-date and will cause the real commit to fail, or which files
+       will fail any pre-commit checks.  Also, the "cvs -n import ..."
+       command will now show you what it would've done without actually
+       doing it.
+
+       * Doing "cvs commit modules" to checkin the modules file will no
+       properly run the "mkmodules" program (assuming you have setup your
+       $CVSROOT/CVSROOT/modules file to do so).
+
+       * The -t option in the modules file (which specifies a program to
+       run when you do a "cvs rtag" operation on a module) now gets the
+       symbolic tag as the second argument when invoked.
+
+       * When the source repository is locked by another user, that user's
+       login name will be displayed as the holder of the lock.
+
+       * Doing "cvs checkout module/file.c" now works even if
+       module/file.c is in the Attic (has been removed from main-line
+       development).
+
+       * Doing "cvs commit */Makefile" now works as one would expect.
+       Rather than trying to commit everything recursively, it will now
+       commit just the files specified.
+
+       * The "cvs remove" command is now fully recursive.  To schedule a
+       file for removal, all you have to do is "rm file" and "cvs rm".
+       With no arguments, "cvs rm" will schedule all files that have been
+       physically removed for removal from the source repository at the
+       next "cvs commit".
+
+       * The "cvs tag" command now prints "T file" for each file that was
+       tagged by this invocation and "D file" for each file that had the
+       tag removed (as with "cvs tag -d").
+
+       * The -a option has been added to "cvs rtag" to force it to clean
+       up any old, matching tags for files that have been removed (in the
+       Attic) that may not have been touched by this tag operation.  This
+       can help keep a consistent view with your tag, even if you re-use
+       it frequently.
+
+Sat Feb 29 16:02:05 1992  Brian Berliner  (berliner at sun.com)
+
+       * Changes between CVS 1.3 Beta-2 and CVS 1.3 Beta-3
+
+       * Many portability fixes, thanks to all the Beta testers!  With any
+       luck, this Beta release will compile correctly on most anything.
+       Hey, what are we without our dreams.
+
+       * CVS finally has support for doing isolated development on a
+       branch off the current (or previous!) revisions.  This is also
+       extremely nice for generating patches for previously released
+       software while development is progressing on the next release.
+       Here's an example of creating a branch to fix a patch with the 2.0
+       version of the "foo" module, even though we are already well into
+       the 3.0 release.  Do:
+
+               % cvs rtag -b -rFOO_2_0 FOO_2_0_Patch foo
+               % cvs checkout -rFOO_2_0_Patch foo
+               % cd foo
+               [[ hack away ]]
+               % cvs commit
+
+       A physical branch will be created in the RCS file only when you
+       actually commit the change.  As such, forking development at some
+       random point in time is extremely light-weight -- requiring just a
+       symbolic tag in each file until a commit is done.  To fork
+       development at the currently checked out sources, do:
+
+               % cvs tag -b Personal_Hack
+               % cvs update -rPersonal_Hack
+               [[ hack away ]]
+               % cvs commit
+
+       Now, if you decide you want the changes made in the Personal_Hack
+       branch to be merged in with other changes made in the main-line
+       development, you could do:
+
+               % cvs commit                 # to make Personal_Hack complete
+               % cvs update -A              # to update sources to main-line
+               % cvs update -jPersonal_Hack # to merge Personal_Hack
+
+       to update your checked-out sources, or:
+
+               % cvs checkout -jPersonal_Hack module
+
+       to checkout a fresh copy.
+
+       To support this notion of forked development, CVS reserves
+       all even-numbered branches for its own use.  In addition, CVS
+       reserves the ".0" and ".1" branches.  So, if you intend to do your
+       own branches by hand with RCS, you should use odd-numbered branches
+       starting with ".3", as in "1.1.3", "1.1.5", 1.2.9", ....
+
+       * The "cvs commit" command now supports a fully functional -r
+       option, allowing you to commit your changes to a specific numeric
+       revision or symbolic tag with full consistency checks.  Numeric
+       tags are useful for bringing your sources all up to some revision
+       level:
+
+               % cvs commit -r2.0
+
+       For symbolic tags, you can only commit to a tag that references a
+       branch in the RCS file.  One created by "cvs rtag -b" or from
+       "cvs tag -b" is appropriate (see below).
+
+       * Roland Pesch <pesch@cygnus.com> and K. Richard Pixley
+       <rich@cygnus.com> were kind enough to contribute two new manual
+       pages for CVS: cvs(1) and cvs(5).  Most of the new CVS 1.3 features
+       are now documented, with the exception of the new branch support
+       added to commit/rtag/tag/checkout/update.
+
+       * The -j options of checkout/update have been added.  The "cvs join"
+       command has been removed.
+
+       With one -j option, CVS will 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.  E.g., If the file foo.c is based on
+       revision 1.6 and I want to remove the changes made between 1.3 and
+       1.5, I might do:
+
+               % cvs update -j1.5 -j1.3 foo.c          # note the order...
+
+       In addition, each -j option can contain on 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, as in:
+
+               -jSymbolic_Tag:Date_Specifier
+
+       An example might be what "cvs import" tells you to do when you have
+       just imported sources that have conflicts with local changes:
+
+               % cvs checkout -jTAG:yesterday -jTAG module
+
+       which tells CVS to merge in the changes made to the branch
+       specified by TAG in the last 24 hours.  If this is not what is
+       intended, substitute "yesterday" for whatever format of date that
+       is appropriate, like:
+
+               % cvs checkout -jTAG:'1 week ago' -jTAG module
+
+       * "cvs diff" now supports the special tags "BASE" and "HEAD".  So,
+       the command:
+
+               % cvs diff -u -rBASE -rHEAD
+
+       will effectively show the changes made by others (in unidiff
+       format) that will be merged into your working sources with your
+       next "cvs update" command.  "-rBASE" resolves to the revision that
+       your working file is based on.  "-rHEAD" resolves to the current
+       head of the branch or trunk that you are working on.
+
+       * The -P option of "cvs checkout" now means to Prune empty
+       directories, as with "update".  The default is to not remove empty
+       directories.  However, if you do "checkout" with any -r options, -P
+       will be implied.  I.e., checking out with a tag will cause empty
+       directories to be pruned automatically.
+
+       * The new file INSTALL describes how to install CVS, including
+       detailed descriptions of interfaces to "configure".
+
+       * The example loginfo file in examples/loginfo has been updated to
+       use the perl script included in contrib/log.pl.  The nice thing
+       about this log program is that it records the revision numbers of
+       your change in the log message.
+
+       Example files for commitinfo and rcsinfo are now included in the
+       examples directory.
+
+       * All "#if defined(__STDC__) && __STDC__ == 1" lines have been
+       changed to be "#if __STDC__" to fix some problems with the former.
+
+       * The lib/regex.[ch] files have been updated to the 1.3 release of
+       the GNU regex package.
+
+       * The ndbm emulation routines included with CVS 1.3 Beta-2 in the
+       src/ndbm.[ch] files has been moved into the src/myndbm.[ch] files
+       to avoid any conflict with the system <ndbm.h> header file.  If
+       you had a previous CVS 1.3 Beta release, you will want to "cvs
+       remove ndbm.[ch]" form your copy of CVS as well.
+
+       * "cvs add" and "cvs remove" are a bit more verbose, telling you
+       what to do to add/remove your file permanently.
+
+       * We no longer mess with /dev/tty in "commit" and "add".
+
+       * More things are quiet with the -Q option set.
+
+       * New src/config.h option:  If CVS_BADROOT is set, CVS will not
+       allow people really logged in as "root" to commit changes.
+
+       * "cvs diff" exits with a status of 0 if there were no diffs, 1 if
+       there were diffs, and 2 if there were errors.
+
+       * "cvs -n diff" is now supported so that you can still run diffs
+       even while in the middle of committing files.
+
+       * Handling of the CVS/Entries file is now much more robust.
+
+       * The default file ignore list now includes "*.so".
+
+       * "cvs import" did not expand '@' in the log message correctly.  It
+       does now.  Also, import now uses the ignore file facility
+       correctly.
+
+       Import will now tell you whether there were conflicts that need to
+       be resolved, and how to resolve them.
+
+       * "cvs log" has been changed so that you can "log" things that are
+       not a part of the current release (in the Attic).
+
+       * If you don't change the editor message on commit, CVS now prompts
+       you with the choice:
+
+               !)reuse this message unchanged for remaining dirs
+
+       which allows you to tell CVS that you have no intention of changing
+       the log message for the remainder of the commit.
+
+       * It is no longer necessary to have CVSROOT set if you are using
+       the -H option to get Usage information on the commands.
+
+       * Command argument changes:
+       checkout:               -P handling changed as described above.
+                               New -j option (up to 2 can be specified)
+                               for doing rcsmerge kind of things on
+                               checkout.
+       commit:                 -r option now supports committing to a
+                               numeric or symbolic tags, with some
+                               restrictions.  Full consistency checks will
+                               be done.
+                               Added "-f logfile" option, which tells
+                               commit to glean the log message from the
+                               specified file, rather than invoking the
+                               editor.
+       rtag:                   Added -b option to create a branch tag,
+                               useful for creating a patch for a previous
+                               release, or for forking development.
+       tag:                    Added -b option to create a branch tag,
+                               useful for creating a patch for a previous
+                               release, or for forking development.
+       update:                 New -j option (up to 2 can be specified)
+                               for doing rcsmerge kind of things on
+                               update.
+
+Thu Jan  9 10:51:35 MST 1992 Jeff Polk (polk at BSDI.COM)
+
+       * Changes between CVS 1.3 Beta-1 and CVS 1.3 Beta-2
+
+       * Thanks to K. Richard Pixley at Cygnus we now have function
+       prototypes in all the files
+
+       * Some small changes to configure for portability.  There have
+       been other portability problems submitted that have not been fixed
+       (Brian will be working on those).  Additionally all __STDC__
+       tests have been modified to check __STDC__ against the constant 1 
+       (this is what the Second edition of K&R says must be true).
+
+       * Lots of additional error checking for forked processes (run_exec)
+       (thanks again to K. Richard Pixley)
+
+       * Lots of miscellaneous bug fixes - including but certainly not 
+       limited to:
+               various commit core dumps
+               various update core dumps
+               bogus results from status with numeric sticky tags
+               commitprog used freed memory
+               Entries file corruption caused by No_Difference
+               commit to revision broken (now works if branch exists)
+               ignore file processing broken for * and !
+               ignore processing didn't handle memory reasonably
+               miscellaneous bugs in the recursion processor
+               file descriptor leak in ParseInfo
+               CVSROOT.adm->CVSROOT rename bug
+               lots of lint fixes
+
+       * Reformatted all the code in src (with GNU indent) and then 
+       went back and fixed prototypes, etc since indent gets confused.  The
+       rationale is that it is better to do it sooner than later and now
+       everything is consistent and will hopefully stay that way.
+       The basic options to indent were: "-bad -bbb -bap -cdb -d0 -bl -bli0 
+       -nce -pcs -cs -cli4 -di1 -nbc -psl -lp -i4 -ip4 -c41"  and then
+       miscellaneous formatting fixes were applied.  Note also that the 
+       "-nfc1" or "-nfca" may be appropriate in files where comments have
+       been carefully formatted (e.g, modules.c).
+
+Sat Dec 14 20:35:22 1991  Brian Berliner  (berliner at sun.com)
+
+       * Changes between CVS 1.2 and CVS 1.3 Beta are described here.
+
+       * Lots of portability work.  CVS now uses the GNU "configure"
+       script to dynamically determine the features provided by your
+       system.  It probably is not foolproof, but it is better than
+       nothing.  Please let me know of any portability problems.  Some
+       file names were changed to fit within 14-characters.
+
+       * CVS has a new RCS parser that is much more flexible and
+       extensible.  It should read all known RCS ",v" format files.
+
+       * Most of the commands now are fully recursive, rather than just
+       operating on the current directory alone.  This includes "commit",
+       which makes it real easy to do an "atomic" commit of all the
+       changes made to a CVS hierarchy of sources.  Most of the commands
+       also correctly handle file names that are in directories other than
+       ".", including absolute path names.  Commands now accept the "-R"
+       option to force recursion on (though it is always the default now)
+       and the "-l" option to force recursion off, doing just "." and not
+       any sub-directories.
+
+       * CVS supports many of the features provided with the RCS 5.x
+       distribution - including the new "-k" keyword expansion options.  I
+       recommend using RCS 5.x (5.6 is the current official RCS version)
+       and GNU diff 1.15 (or later) distributions with CVS.
+
+       * Checking out files with symbolic tags/dates is now "sticky", in
+       that CVS remembers the tag/date used for each file (and directory)
+       and will use that tag/date automatically on the next "update" call.
+       This stickyness also holds for files checked out with the the new
+       RCS 5.x "-k" options.
+
+       * The "cvs diff" command now recognizes all of the rcsdiff 5.x
+       options.  Unidiff format is available by installing the GNU
+       diff 1.15 distribution.
+
+       * The old "CVS.adm" directories created on checkout are now called
+       "CVS" directories, to look more like "RCS" and "SCCS".  Old CVS.adm
+       directories are automagically converted to CVS directories.  The
+       old "CVSROOT.adm" directory within the source repository is
+       automagically changed into a "CVSROOT" directory as well.
+
+       * Symbolic links in the source repository are fully supported ONLY
+       if you use RCS 5.6 or later and (of course) your system supports
+       symlinks.
+
+       * A history database has been contributed which maintains the
+       history of certain CVS operations, as well as providing a wide array
+       of querying options.
+
+       * The "cvs" program has a "-n" option which can be used with the
+       "update" command to show what would be updated without actually
+       doing the update, like:  "cvs -n update".  All usage statements
+       have been cleaned up and made more verbose.
+
+       * The module database parsing has been rewritten.  The new format
+       is compatible with the old format, but with much more
+       functionality.  It allows modules to be created that grab pieces or
+       whole directories from various different parts of your source
+       repository.  Module-relative specifications are also correctly
+       recognized now, like "cvs checkout module/file.c".
+
+       * A configurable template can be specified such that on a "commit", 
+       certain directories can supply a template that the user must fill
+       before completing the commit operation.
+
+       * A configurable pre-commit checking program can be specified which
+       will run to verify that a "commit" can happen.  This feature can be
+       used to restrict certain users from changing certain pieces of the
+       source repository, or denying commits to the entire source
+       repository.
+
+       * The new "cvs export" command is much like "checkout", but
+       establishes defaults suitable for exporting code to others (expands
+       out keywords, forces the use of a symbolic tag, and does not create
+       "CVS" directories within the checked out sources.
+
+       * The new "cvs import" command replaces the deprecated "checkin"
+       shell script and is used to import sources into CVS control.  It is
+       also much faster for the first-time import.  Some algorithmic
+       improvements have also been made to reduce the number of
+       conflicting files on next-time imports.
+
+       * The new "cvs admin" command is basically an interface to the
+       "rcs" program.  (Not yet implemented very well).
+
+       * Signal handling (on systems with BSD or POSIX signals) is much
+       improved.  Interrupting CVS now works with a single interrupt!
+
+       * CVS now invokes RCS commands by direct fork/exec rather than
+       calling system(3).  This improves performance by removing a call to
+       the shell to parse the arguments.
+
+       * Support for the .cvsignore file has been contributed.  CVS will
+       now show "unknown" files as "? filename" as the result of an "update"
+       command.  The .cvsignore file can be used to add files to the
+       current list of ignored files so that they won't show up as unknown.
+
+       * Command argument changes:
+       cvs:            Added -l to turn off history logging.
+                       Added -n to show what would be done without actually
+                       doing anything.
+                       Added -q/-Q for quiet and really quiet settings.
+                       Added -t to show debugging trace.
+       add:            Added -k to allow RCS 5.x -k options to be specified.
+       admin:          New command; an interface to rcs(1).
+       checkout:       Added -A to reset sticky tags/date/options.
+                       Added -N to not shorten module paths.
+                       Added -R option to force recursion.
+                       Changed -p (prune empty directories) to -P option.
+                       Changed -f option; forcing tags match is now default.
+                       Added -p option to checkout module to standard output.
+                       Added -s option to cat the modules db with status.
+                       Added -d option to checkout in the specified directory.
+                       Added -k option to use RCS 5.x -k support.
+       commit:         Removed -a option; use -l instead.
+                       Removed -f option.
+                       Added -l option to disable recursion.
+                       Added -R option to force recursion.
+                       If no files specified, commit is recursive.
+       diff:           Now recognizes all RCS 5.x rcsdiff options.
+                       Added -l option to disable recursion.
+                       Added -R option to force recursion.
+       history:        New command; displays info about CVS usage.
+       import:         Replaces "checkin" shell script; imports sources
+                       under CVS control.  Ignores files on the ignore
+                       list (see -I option or .cvsignore description above).
+       export:         New command; like "checkout", but w/special options
+                       turned on by default to facilitate exporting sources.
+       join:           Added -B option to join from base of the branch;
+                       join now defaults to only joining with the top two
+                       revisions on the branch.
+                       Added -k option for RCS 5.x -k support.
+       log:            Supports all RCS 5.x options.
+                       Added -l option to disable recursion.
+                       Added -R option to force recursion.
+       patch:          Changed -f option; forcing tags match is now default.
+                       Added -c option to force context-style diffs.
+                       Added -u option to support unidiff-style diffs.
+                       Added -V option to support RCS specific-version
+                       keyword expansion formats.
+                       Added -R option to force recursion.
+       remove:         No option changes.  It's a bit more verbose.
+       rtag:           Equivalent to the old "cvs tag" command.
+                       No option changes.  It's a lot faster for re-tag.
+       status:         New output formats with more information.
+                       Added -l option to disable recursion.
+                       Added -R option to force recursion.
+                       Added -v option to show symbolic tags for files.
+       tag:            Functionality changed to tag checked out files
+                       rather than modules; use "rtag" command to get the
+                       old "cvs tag" behaviour.
+       update:         Added -A to reset sticky tags/date/options.
+                       Changed -p (prune empty directories) to -P option.
+                       Changed -f option; forcing tags match is now default.
+                       Added -p option to checkout module to standard output.
+                       Added -I option to add files to the ignore list.
+                       Added -R option to force recursion.
+
+       Major Contributors:
+
+       * Jeff Polk <polk@bsdi.com> rewrote most of the grody code of CVS
+       1.2.  He made just about everything dynamic (by using malloc),
+       added a generic hashed list manager, re-wrote the modules database
+       parsing in a compatible - but extended way, generalized directory
+       hierarchy recursion for virtually all the commands (including
+       commit!), generalized the loginfo file to be used for pre-commit
+       checks and commit templates, wrote a new and flexible RCS parser,
+       fixed an uncountable number of bugs, and helped in the design of
+       future CVS features.  If there's anything gross left in CVS, it's
+       probably my fault!
+
+       * David G. Grubbs <dgg@odi.com> contributed the CVS "history" and
+       "release" commands.  As well as the ever-so-useful "-n" option of
+       CVS which tells CVS to show what it would do, without actually
+       doing it.  He also contributed support for the .cvsignore file.
+
+       * Paul Sander, HaL Computer Systems, Inc. <paul@hal.com> wrote and
+       contributed the code in lib/sighandle.c.  I added support for
+       POSIX, BSD, and non-POSIX/non-BSD systems.
+
+       * Free Software Foundation contributed the "configure" script and
+       other compatibility support in the "lib" directory, which will help
+       make CVS much more portable.
+
+       * Many others have contributed bug reports and enhancement requests.
+       Some have even submitted actual code which I have not had time yet
+       to integrate into CVS.  Maybe for the next release.
+
+       * Thanks to you all!
+
+Wed Feb  6 10:10:58 1991  Brian Berliner  (berliner at sun.com)
+
+       * Changes from CVS 1.0 Patchlevel 1 to CVS 1.0 Patchlevel 2; also
+       known as "Changes from CVS 1.1 to CVS 1.2".
+
+       * Major new support with this release is the ability to use the
+       recently-posted RCS 5.5 distribution with CVS 1.2.  See below for
+       other assorted bug-fixes that have been thrown in.
+
+       * ChangeLog (new): Added Emacs-style change-log file to CVS 1.2
+       release.  Chronological description of changes between release.
+
+       * README: Small fixes to installation instructions.  My email
+       address is now "berliner@sun.com".
+
+       * src/Makefile: Removed "rcstime.h".  Removed "depend" rule.
+
+       * src/partime.c:  Updated to RCS 5.5 version with hooks for CVS.
+       * src/maketime.c: Updated to RCS 5.5 version with hooks for CVS.
+       * src/rcstime.h:  Removed from the CVS 1.2 distribution.
+       Thanks to Paul Eggert <eggert@twinsun.com> for these changes.
+
+       * src/checkin.csh: Support for RCS 5.5 parsing.
+       Thanks to Paul Eggert <eggert@twinsun.com> for this change.
+
+       * src/collect_sets.c (Collect_Sets): Be quieter if "-f" option is
+       specified.  When checking out files on-top-of other files that CVS
+       doesn't know about, run a diff in the hopes that they are really
+       the same file before aborting.
+
+       * src/commit.c (branch_number): Fix for RCS 5.5 parsing.
+       Thanks to Paul Eggert <eggert@twinsun.com> for this change.
+
+       * src/commit.c (do_editor): Bug fix - fprintf missing argument
+       which sometimes caused core dumps.
+
+       * src/modules.c (process_module): Properly NULL-terminate
+       update_dir[] in all cases.
+
+       * src/no_difference.c (No_Difference): The wrong RCS revision was
+       being registered in certain (strange) cases.
+
+       * src/patch.c (get_rcsdate): New algorithm.  No need to call
+       maketime() any longer.
+       Thanks to Paul Eggert <eggert@twinsun.com> for this change.
+
+       * src/patchlevel.h: Increased patch level to "2".
+
+       * src/subr.c (isdir, islink): Changed to compare stat mode bits
+       correctly.
+
+       * src/tag.c (tag_file): Added support for following symbolic links
+       that are in the master source repository when tagging.  Made tag
+       somewhat quieter in certain cases.
+
+       * src/update.c (update_process_lists): Unlink the user's file if it
+       was put on the Wlist, meaning that the user's file is not modified
+       and its RCS file has been removed by someone else.
+
+       * src/update.c (update): Support for "cvs update dir" to correctly
+       just update the argument directory "dir".
+
+       * src/cvs.h: Fixes for RCS 5.5 parsing.
+       * src/version_number.c (Version_Number): Fixes for parsing RCS 5.5
+       and older RCS-format files.
+       Thanks to Paul Eggert <eggert@twinsun.com> for these changes.
+
+       * src/version_number.c (Version_Number): Bug fixes for "-f" option.
+       Bug fixes for parsing with certain branch numbers.  RCS
+       revision/symbol parsing is much more solid now.
+
+Wed Feb 14 10:01:33 1990  Brian Berliner  (berliner at sun.com)
+
+       * Changes from CVS 1.0 Patchlevel 0 to CVS 1.0 Patchlevel 1; also
+       known as "Changes from CVS 1.0 to CVS 1.1".
+
+       * src/patch.c (get_rcsdate): Portability fix.  Replaced call to
+       timelocal() with call to maketime().
+
+Mon Nov 19 23:15:11 1990  Brian Berliner  (berliner at prisma.com)
+
+       * Sent CVS 1.0 release to comp.sources.unix moderator and FSF.
+
+       * Special thanks to Dick Grune <dick@cs.vu.nl> for his work on the
+       1986 version of CVS and making it available to the world.  Dick's
+       version is available on uunet.uu.net in the
+       comp.sources.unix/volume6/cvs directory.
diff --git a/contrib/cvs-1.12.9/PROJECTS b/contrib/cvs-1.12.9/PROJECTS
new file mode 100644 (file)
index 0000000..b46eb2a
--- /dev/null
@@ -0,0 +1,53 @@
+This is a list of projects for CVS.  In general, unlike the things in
+the TODO file, these need more analysis to determine if and how
+worthwhile each task is.
+
+I haven't gone through TODO, but it's likely that it has entries that
+are actually more appropriate for this list.
+
+0. Improved Efficency
+
+* CVS uses a single doubly linked list/hash table data structure for
+  all of its lists.  Since the back links are only used for deleting
+  list nodes it might be beneficial to use singly linked lists or a
+  tree structure.  Most likely, a single list implementation will not
+  be appropriate for all uses.
+
+  One easy change would be to remove the "type" field out of the list
+  and node structures.  I have found it to be of very little use when
+  debugging, and each instance eats up a word of memory.  This can add
+  up and be a problem on memory-starved machines.
+
+  Profiles have shown that on fast machines like the Alpha, fsortcmp()
+  is one of the hot spots.
+
+* Dynamically allocated character strings are created, copied, and
+  destroyed throughout CVS.  The overhead of malloc()/strcpy()/free()
+  needs to be measured.  If significant, it could be minimized by using a
+  reference counted string "class".
+
+* File modification time is stored as a character string.  It might be
+  worthwile to use a time_t internally if the time to convert a time_t
+  (from struct stat) to a string is greater that the time to convert a
+  ctime style string (from the entries file) to a time_t.  time_t is
+  an machine-dependant type (although it's pretty standard on UN*X
+  systems), so we would have to have different conversion routines.
+  Profiles show that both operations are called about the same number
+  of times.
+
+* stat() is one of the largest performance bottlenecks on systems
+  without the 4.4BSD filesystem.  By spliting information out of
+  the filesystem (perhaps the "rename database") we should be 
+  able to improve performance.
+
+* Parsing RCS files is very expensive.  This might be unnecessary if
+  RCS files are only used as containers for revisions, and tag,
+  revision, and date information was available in easy to read 
+  (and modify) indexes.  This becomes very apparent with files
+  with several hundred revisions.
+
+1. Improved testsuite/sanity check script
+
+* Need to use a code coverage tool to determine how much the sanity
+  script tests, and fill in the holes.
+
diff --git a/contrib/cvs-1.12.9/README b/contrib/cvs-1.12.9/README
new file mode 100644 (file)
index 0000000..ec46859
--- /dev/null
@@ -0,0 +1,117 @@
+                               CVS Kit
+
+               Copyright (c) 1993-1994 Brian Berliner
+          Copyright (c) 1992 Brian Berliner and Jeff Polk
+              Copyright (c) 1989-1992, Brian Berliner
+              Copyright (c) 1998-2004 Free Software Foundation,
+                                      Derek Price,
+                                      & Ximbiot <http://ximbiot.com>
+                        All Rights Reserved
+
+    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 1, 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.
+
+-------------------------------------------------------------------------------
+
+Welcome to CVS!
+
+If you have problems or think you have found a bug in CVS, see the
+section BUGS in the CVS manual (also known as Version Management with
+CVS by Per Cederqvist et al, or cvs.texinfo--see below for details).
+
+If you are thinking of submitting changes to CVS, see the
+file HACKING.
+
+Please consult the INSTALL file for information on tested
+configurations.  If you have a comment about an already tested
+configuration, or have tried CVS on a new configuration, please let us
+know as described in INSTALL.  Free software only works if we all help
+out.
+
+Finally, we cannot guarantee that this release will not completely wipe out
+all of your work from your system.  We do some simple testing before each
+release, but you are completely on your own.  We recommend testing this
+release on a source repository that is not critical to your work.  THIS
+SOFTWARE IS SUPPLIED COMPLETELY "AS IS".  NO WARRANTY....
+
+Thanks for your support!
+
+       -The CVS Team
+
+-------------------------------------------------------------------------------
+
+What Is CVS?
+
+CVS is a version control system, which allows you to keep old versions
+of files (usually source code), keep a log of who, when, and why
+changes occurred, etc., like RCS or SCCS.  It handles multiple
+developers, multiple directories, triggers to enable/log/control
+various operations, and can work over a wide area network.  The
+following tasks are not included; they can be done in conjunction with
+CVS but will tend to require some script-writing and software other
+than CVS: bug-tracking, build management (that is, make and make-like
+tools), and automated testing.
+
+And a whole lot more.  See the manual for more information.
+
+-------------------------------------------------------------------------------
+
+Notes to people upgrading from a previous release of CVS:
+
+See the NEWS file for a description of features new in this version.
+
+See the Compatibility section of the manual for information on
+compatibility between CVS versions.  The quick summary is that as long
+as you not using the optional watch features, there are no
+compatibility problems with CVS 1.5 or later.
+
+-------------------------------------------------------------------------------
+
+Installation:
+
+Please read the INSTALL file for installation instructions.  Brief summary:
+
+       $ ./configure
+       $ make
+       (run the regression tests if desired)
+       $ make install
+       (create a repository if you don't already have one)
+
+The documentation is in the doc subdirectory.  cvs.texinfo is the main
+manual; cvs.info* and cvs.ps are the info and postscript versions,
+respectively, generated from cvs.texinfo.  The postscript version is
+for US letter size paper; we do this not because we consider this size
+"better" than A4, but because we believe that the US letter version
+will print better on A4 paper than the other way around. If you want a
+version formatted for A4, add the line @afourpaper near the start of
+cvs.texinfo and re-generate cvs.ps using TeX.
+
+-------------------------------------------------------------------------------
+
+* How do I get up-to-date information and information about other
+versions of CVS?
+
+On the web, http://www.loria.fr/~molli/cvs-index.html.
+
+See also 
+       http://www.cvshome.org
+
+The mailing list for CVS is info-cvs@gnu.org.  Send
+subscription and removal requests for that list to
+info-cvs-request@gnu.org.
+
+The newsgroup for CVS (and other configuration management systems) is
+comp.software.config-mgmt.  There is not yet a CVS-specific newsgroup,
+but perhaps if comp.software.config-mgmt gets enough CVS discussion,
+then it will be possible to create one.
+
+-------------------------------------------------------------------------------
+
+Credits:  See the AUTHORS file.
diff --git a/contrib/cvs-1.12.9/README.DELETED b/contrib/cvs-1.12.9/README.DELETED
new file mode 100644 (file)
index 0000000..dceebe6
--- /dev/null
@@ -0,0 +1,157 @@
+.cvsignore
+ChangeLog
+ChangeLog.zoo
+FAQ
+Makefile.am
+Makefile.in
+README.VMS
+aclocal.m4
+build.com
+compile
+config.guess
+config.h.in
+config.rpath
+config.sub
+configure.in
+contrib/.cvsignore
+contrib/ChangeLog
+contrib/Makefile.am
+contrib/Makefile.in
+contrib/debug_check_log.sh
+contrib/descend.sh
+contrib/dirfns.shar
+contrib/newcvsroot.sh
+contrib/pvcs2rcs.in
+contrib/rcs2sccs.sh
+contrib/sandbox_status.man
+contrib/sandbox_status.sh
+contrib/validate_repo.in
+cvs-format.el
+cvs.spec
+cvs.spec.in
+cvsnt.dep
+cvsnt.dsp
+cvsnt.dsw
+cvsnt.mak
+depcomp
+diff/ChangeLog
+diff/Makefile.am
+diff/Makefile.in
+diff/build_diff.com
+diff/diagmeet.note
+diff/libdiff.dep
+diff/libdiff.dsp
+diff/libdiff.mak
+doc/.cvsignore
+doc/ChangeLog
+doc/ChangeLog.fsf
+doc/Makefile.am
+doc/Makefile.in
+doc/RCSFILES
+doc/cvs-paper.ms
+doc/cvs-paper.ps
+doc/cvs.info
+doc/cvs.info-1
+doc/cvs.info-10
+doc/cvs.info-11
+doc/cvs.info-2
+doc/cvs.info-3
+doc/cvs.info-4
+doc/cvs.info-5
+doc/cvs.info-6
+doc/cvs.info-7
+doc/cvs.info-8
+doc/cvs.info-9
+doc/cvs.man.footer
+doc/cvs.man.header
+doc/cvs.ps
+doc/cvsclient.info
+doc/cvsclient.info-1
+doc/cvsclient.info-2
+doc/cvsclient.info-3
+doc/cvsclient.ps
+doc/mdate-sh
+doc/mkman.in
+doc/stamp-1
+doc/stamp-vti
+doc/texinfo.tex
+emx
+install-sh
+lib/.cvsignore
+lib/ChangeLog
+lib/ChangeLog.fsf
+lib/Makefile.am
+lib/Makefile.in
+lib/alloca_.h
+lib/atexit.c
+lib/build_lib.com
+lib/dirname.c
+lib/dup2.c
+lib/fncase.c
+lib/fnmatch.c
+lib/fnmatch_.h
+lib/fnmatch_loop.c
+lib/fseeko.c
+lib/ftello.c
+lib/ftruncate.c
+lib/getdate.c
+lib/getdate.h
+lib/gethostname.c
+lib/getpagesize.h
+lib/gettime.c
+lib/gettimeofday.c
+lib/libcvs.dep
+lib/libcvs.dsp
+lib/libcvs.mak
+lib/malloc.c
+lib/memmove.c
+lib/mkdir.c
+lib/mkstemp.c
+lib/mktime.c
+lib/nanosleep.c
+lib/realloc.c
+lib/regex.c
+lib/rename.c
+lib/stdbool_.h
+lib/strerror.c
+lib/strftime.c
+lib/strstr.c
+lib/strtoul.c
+lib/tempname.c
+lib/time_r.c
+lib/time_r.h
+lib/valloc.c
+lib/waitpid.c
+m4
+man/.cvsignore
+man/ChangeLog
+man/Makefile.am
+man/Makefile.in
+mdate-sh
+missing
+mkinstalldirs
+mktemp.sh
+os2
+src/.cvsignore
+src/ChangeLog
+src/ChangeLog-9194
+src/ChangeLog-9395
+src/ChangeLog-96
+src/ChangeLog-97
+src/Makefile.am
+src/Makefile.in
+src/build_src.com
+src/gssapi-client.c
+src/gssapi-client.h
+src/kerberos4-client.c
+src/kerberos4-client.h
+src/sanity.config.sh.in
+src/sanity.sh
+tools/.cvsignore
+tools/ChangeLog
+tools/Makefile.am
+tools/Makefile.in
+vms
+windows-NT
+ylwrap
+zlib
diff --git a/contrib/cvs-1.12.9/README.DRAGONFLY b/contrib/cvs-1.12.9/README.DRAGONFLY
new file mode 100644 (file)
index 0000000..e0df75a
--- /dev/null
@@ -0,0 +1,42 @@
+
+                       CVS-1.12.9 AS USED BY DRAGONFLY
+
+    This directory contains a selected set of files from the gnu 
+    cvs-1.12.9.tar.gz distribution.   No files have been moved
+    or modified from their extracted position.
+
+    This distribution was downloaded from the following site:
+
+       http://ccvs.cvshome.org/servlets/ProjectDownloadList
+
+    DO NOT CREATE OR EDIT ANY FILES IN THIS DIRECTORY HIERARCHY!  THIS
+    HIERARCHY REPRESENTS AN EXACT COPY, MINUS UNNEEDED FILES, OF THE
+    ORIGINAL ARCHIVE.  All modifications are made in the 
+    DragonFly build wrapper, in /usr/src/gnu/usr.bin/cvs,
+    by creating overrides or performing surgery on the distribution into
+    local files.  The only additional files added to this directory
+    are README.DRAGONFLY and README.DELETED. 
+
+    UPGRADE PROCDURE:
+
+       * download a new cvs-1.12.X dist greater then 1.12.9
+
+       * extract the archive into this directory, overlaying the
+         existing files.
+
+       * A 'cvs update' will show you what has changed ('M') relative 
+         to what we had before.  There will be hundreds of files marked
+         '?' which, if not needed, should be deleted and NOT COMMITTED.
+         If any new files are needed you can cvs add and commit them.
+
+       * Check overrides and patches in /usr/src/gnu/usr.bin/cvs and
+         modify as appropriate.
+
+         DO NOT MAKE ANY EDITS TO THE DISTRIBUTION IN THIS CONTRIB
+         DIRECTORY, OTHER THEN TO ADD OR DELETE FILES ASSOCIATED WITH THE
+         GNU DISTRIBUTION.
+
+       * Check to see if [src]/gnu/usr.bin/cvs/lib/config.h.proto needs
+         to be modified.
+
+    The file README.DELETED contains a list of deleted files.
diff --git a/contrib/cvs-1.12.9/TESTS b/contrib/cvs-1.12.9/TESTS
new file mode 100644 (file)
index 0000000..ddba947
--- /dev/null
@@ -0,0 +1,248 @@
+To run the tests:
+
+       $ make check
+
+Note that if your /bin/sh doesn't support shell functions, you'll
+have to try something like this, where "/bin/sh5" is replaced by the
+pathname of a shell which handles normal shell functions:
+
+       $ make SHELL=/bin/sh5 check
+
+Also note that you must be logged in as a regular user, not root.
+
+WARNING:  This test can take quite a while to run, esp. if your
+disks are slow or over-loaded.
+
+The tests work in /tmp/cvs-sanity (which the tests create) by default.
+If for some reason you want them to work in a different directory, you
+can set the TESTDIR environment variable to the desired location
+before running them.
+
+The tests use a number of tools (awk, expr, id, tr, etc.) that are not
+required for running CVS itself.  In most cases, the standard vendor-
+supplied versions of these tools work just fine, but there are some
+exceptions -- expr in particular is heavily used and many vendor
+versions are deficient in one way or another.  Note that some vendors
+provide multiple versions of tools (typically an ancient, traditional
+version and a new, standards-conforming version), so you may already
+have a usable version even if the default version isn't.  If you don't
+have a suitable tool, you can probably get one from the GNU Project (see
+http://www.gnu.org).  At this writting, expr and id are both part of the
+GNU shellutils package, tr is part of the GNU textutils package, and awk
+is part of the GNU gawk package.  The test script tries to verify that
+the tools exist and are usable; if not, it tries to find the GNU
+versions and use them instead.  If it can't find the GNU versions
+either, it will print an error message and, depending on the severity of
+the deficiency, it may exit.  There are environment variables you can
+set to use a particular version of a tool -- see the test script
+(src/sanity.sh) for details.
+
+Some of the tests use fairly long command lines -- this usually isn't a
+problem, but if you have a very short command line length limit (or a
+lot of environment variables), you may run into trouble.  Also, some of
+the tests expect your local timezone to be an integral number of hours
+from UTC -- if you usually use a fractional timezone, use a different
+(integral) timezone when running the tests to avoid spurious failures.
+
+If running the tests produces the output "FAIL:" followed by the name
+of the test that failed, then the details on the failure are in the
+file check.log.  If it says "exit status is " followed by a number,
+then the exit status of the command under test was not what the test
+expected.  If it says "** expected:" followed by a regular expression
+followed by "** got:" followed by some text, then the regular
+expression is the output which the test expected, and the text is the
+output which the command under test actually produced.  In some cases
+you'll have to look closely to see how they differ; the debug_check_log
+script in the contrib directory can assist in this process.
+
+If output from "make remotecheck" is out of order compared to what is
+expected (for example,
+
+   a
+   b
+   cvs foo: this is a demo
+
+is expected and
+
+   a
+   cvs foo: this is a demo
+   b
+
+is output), this is probably a well-known bug in the CVS server
+(search for "out-of-order" in src/server.c for a comment explaining
+the cause).  It is a real pain in running the testsuite, but if you
+are lucky and/or your machine is fast and/or lightly loaded, you won't
+run into it.  Running the tests again might succeed if the first run
+failed in this manner.
+
+For more information on what goes in check.log, and how the tests are
+run in general, you'll have to read sanity.sh.  Depending on just what
+you are looking for, and how familiar you are with the Bourne shell
+and regular expressions, it will range from relatively straightforward
+to obscure.
+
+If you choose to submit a bug report based on tests failing, be
+aware that, as with all bug reports, you may or may not get a
+response, and your odds might be better if you include enough
+information to reproduce the bug, an analysis of what is going
+wrong (if you have the time to provide one), etc.  The check.log
+file is the first place to look.
+
+ABOUT STDOUT AND STDERR
+***********************
+
+The sanity.sh test framework combines stdout and stderr and for tests
+to pass requires that output appear in the given order.  Some people
+suggest that ordering between stdout and stderr should not be
+required, or to put it another way, that the out-of-order bug referred
+to above, and similar behaviors, should be considered features, or at
+least tolerable.  The reasoning behind the current behavior is that
+having the output appear in a certain order is the correct behavior
+for users using CVS interactively--that users get confused if the
+order is unpredictable.
+
+ABOUT TEST FRAMEWORKS
+*********************
+
+People periodically suggest using dejagnu or some other test
+framework.  A quick look at sanity.sh should make it clear that there
+are indeed reasons to be dissatisfied with the status quo.  Ideally a
+replacement framework would achieve the following:
+
+1.  Widely portable, including to a wide variety of unices, NT, Win95,
+OS/2, VMS, probably DOS and Win3, etc.
+
+2.  Nicely match extended regular expressions of unlimited length.
+
+3.  Be freely redistributable, and if possible already the kind of
+thing people might have already installed.  The harder it is to get
+and install the framework, the less people will run the tests.
+
+The various contenders are:
+
+* Bourne shell and GNU expr (the status quo).  Falls short on #1
+(we've only tried unix and NT, although MKS might help with other DOS
+mutants).  #3 is pretty good (the main dependency is GNU expr which is
+fairly widely available).
+
+* Bourne shell with a new regexp matcher we would distribute with
+CVS.  This means maintaining a regexp matcher and the makefiles which
+go with it.  Not clearly a win over Bourne shell and GNU expr.
+
+* Bourne shell, and use sed to remove variable portions of output, and
+thus produce a form that can be compared with cmp or diff (this
+sidesteps the need for a full regular expression matcher as mentioned
+in #2 above).  The C News tests are said to work this way.  This would
+appear to rely on variable portions of output having a certain syntax
+and might spuriously recognize them out of context (this issue needs
+more investigation; it isn't clear how big a problem it is in
+practice).  Same portability issues as the other choices based on the
+Bourne shell.
+
+* Dejagnu.  This is overkill; most of dejagnu is either unnecessary
+(e.g. libraries for communicating with target boards) or undesirable
+(e.g. the code which stats every file in sight to find the tests).  On
+the plus side, dejagnu is probably closer than any of the other
+choices to having everything which is needed already there.
+
+* Write our own small framework directly in tcl and distribute with
+CVS.  The tests would look much like dejagnu tests, but we'd avoid the
+unnecessary baggage.  The only dependency would be on tcl (that is,
+wish).
+
+* perl or python or <any other serious contenders here?>
+
+It is worth thinking about how to:
+
+a.  include spaces in arguments which we pass to the program under
+test (sanity.sh dotest cannot do this; see test rcs-9 for a
+workaround).
+
+b.  pass stdin to the program under test (sanity.sh, again, handles
+this by bypassing dotest).
+
+c.  have a send-expect type dialog with the program under test
+    (e.g. see server-7 or pserver-4 which want to talk the CVS
+    protocol, or the many tests which need to answer the prompt of "cvs
+    release", e.g. deep-5).
+
+ABOUT ADDING YOUR OWN TESTS
+***************************
+
+As stated in the HACKING file, patches are not accepted without documentation
+and tests.  Many people seem to be scared off by the large size of the
+sanity.sh script, but it is not really very complicated.
+
+You can probably ignore most of the begining of the script.  This section
+just sets some environment variables and finds the tools the script needs to
+run.
+
+There is one main loop you can find by grepping for "The big loop".  This loop
+repeatedly calls a case statement where the individual cases are of the form:
+
+    testname)
+            ...
+            ;;
+
+If you add a complete new test be sure to add it into the default list of tests
+(grep for 'tests=' near the begining of the script) as well as the case
+statement.  During debugging, be aware that the sanity.sh usage allows for a '-f
+testname' option to continue through the default list "from" a particular test
+as well as interpreting everything in argv past the required options as test
+names to run individual tests.
+
+Within each major test section, individual tests usually look like:
+
+    dotest testname-subtestname "shell command" "optionally multiline regexp"
+
+Tests should always start in $testdir and create a subdirectory to operate in
+and remove their cruft and end back in $testdir.  The dotest functions output
+failure messages and exit if the shell command exits with the wrong exit code or
+its stdin/stderr output doesn't match the regexp.  There are a few dotest
+variations, most notably dotest_fail for expected non-zero exit codes.
+
+Other than that the script is mostly vanilla Bourne shell.  There are a few
+constructs used for versatility and portability.  You can grep for the ones I
+miss, but here are a few important ones.  I'm leaving off long explanations
+after the first few since it probably gives you the idea and the data is in
+sanity.sh.
+
+Note that the boolean variables contain shell commands which return true or
+false when executed and are intended to be used like,
+"if $remote; then ... ; else ... ; fi"
+
+
+   * $testdir   = the directory this test is taking place in
+     (CVSROOT=$testdir/cvsroot or CVSROOT=:fork:$testdir/cvsroot)
+   * $testcvs   = full path to the cvs executable we are testing
+   * $PLUS      = expr dependant uninterpreted '+' since this can vary
+   * $DOTSTAR   = expr dependant _interpreted_ .* since some exprs don't match
+                  EOL
+   * $username  = regexp to match a username
+   * $hostname  = regexp to match a hostname
+   * $SPROG     = regexp to match server progname in CVS error messages.  For
+                  tests run in local and remote mode, this is usually the
+                  string to test for, since some messages can be printed either
+                  by the CVS client or CVS server, dependant on the mode.  In
+                  local mode it will = $PROG.
+   * $PROG      = regexp to match client progname in CVS error messages.  Use
+                  this to match error messages known to be printed only from
+                  the CVS client.
+   * $remote    = ':' (true) or 'false', depending on whether the script is
+                  running with a remote CVSROOT
+   * $keep      = ':' (true) or 'false'.  When set, the first test run will
+                  leave any files and directories it created in $testdir and
+                  exit when complete.
+   * $servercvs = cvs executable to be run as CVS_SERVER in remote testing
+   * $testcvs_server_support
+                = ':' (true) or 'false', depending whether server support was
+                  detected in the ${testcvs} executable.
+
+And, of course, some characters like '.' in regexps need to be '\' escaped when
+you mean them literally.  Some characters may be interpreted by the shell,
+e.g. backquotes and '$', are usually either escaped or replaced with '.'.
+dotest adds the final '$' anchor to the regexp itself and all the expr
+implementations I know of implicitly supply the start anchor ('^').
+
+If you only make a few mistakes, the work is, of course, still usable, though we
+may send the patch back to you for repair.  :)
diff --git a/contrib/cvs-1.12.9/TODO b/contrib/cvs-1.12.9/TODO
new file mode 100644 (file)
index 0000000..f536361
--- /dev/null
@@ -0,0 +1,878 @@
+The "TODO" file!                              -*-Indented-Text-*-
+
+22. Catch signals for cleanup when "add"ing files.
+
+24. Insist on a log message.
+    (If done, this should be configurable via commitinfo or some new
+    config file -kingdon, Jun 1995).
+
+30. Add "rdiff" & "rtag" program options to the modules database.  These
+    commands seem hard to use since these commands deal directly with the
+    RCS ,v files.  (perhaps should think a little harder about what this is
+    trying to accomplish and what the best way is -kingdon, Jul 1997).
+
+31. Think hard about ^C recovery.
+    One particular issue: RCS removes the ,foo.c, file on ^C and CVS
+    doesn't.
+
+38. Think hard about using RCS state information to allow one to checkin
+    a new vendor release without having it be accessed until it has been
+    integrated into the local changes.
+
+39. Think about a version of "cvs update -j" which remembers what from
+    that other branch is already merged.  This has pitfalls--it could
+    easily lead to invisible state which could confuse users very
+    rapidly--but having to create a tag or some such mechanism to keep
+    track of what has been merged is a pain.  Take a look at PRCS 1.2.
+    PRCS 1.0 was particularly bad the way it handled the "invisible
+    state", but 1.2 is significantly better.
+
+49. cvs xxx commands should be able to deal with files in other
+    directories.  I want to do a cvs add foo/bar.c.
+    [[ most commands now use the generic recursion processor, but not all;
+    this note is left here to remind me to fix the others ]]
+
+52. SCCS has a feature that I would *love* to see in CVS, as it is very
+    useful.  One may make a private copy of SCCS suid to a particular user,
+    so other users in the authentication list may check files in and out of
+    a project directory without mucking about with groups.  Is there any
+    plan to provide a similar functionality to CVS?  Our site (and, I'd
+    imagine, many other sites with large user bases) has decided against
+    having the user-groups feature of unix available to the users, due to
+    perceived administrative, technical and performance headaches.  A tool
+    such as CVS with features that provide group-like functionality would
+    be a huge help.
+
+62. Consider using revision controlled files and directories to handle the
+    new module format -- consider a cvs command front-end to
+    add/delete/modify module contents, maybe.
+
+63. The "import" and vendor support commands (co -j) need to be documented
+    better.
+
+66. Length of the CVS temporary files must be limited to 14 characters for
+    System-V stupid support.  As well as the length on the CVS.adm files.
+
+72. Consider re-design of the module -t options to use the file system more
+    intuitively.
+
+73. Consider an option (in .cvsrc?) to automatically add files that are new
+    and specified to commit.
+
+79. Might be nice to have some sort of interface to Sun's Translucent
+    (?) File System and tagged revisions.
+
+82. Maybe the import stuff should allow an arbitrary revision to be
+    specified.
+
+84. Improve the documentation about administration of the repository and
+    how to add/remove files and the use of symbolic links.
+
+85. Make symbolic links a valid thing to put under version control.
+    Perhaps use one of the tag fields in the RCS file?  Note that we
+    can only support symlinks that are relative and within the scope of
+    the sources being controlled.
+
+92. Look into this:
+       After a bit of soul searching via dbx, I realized my sin was that I'd
+       specified "echo" as the program to call from loginfo. The commit
+       procedure worked fine till it hit my echo, then silently aborted
+       leaving the lockfiles intact. Since I needn't use the loginfo
+       facility, I simply removed those commands and it all works.
+
+93. Need to think hard about release and development environments.  Think
+    about execsets as well.
+
+98. If diff3 bombs out (too many differences) cvs then thinks that the file
+    has been updated and is OK to be commited even though the file 
+    has not yet been merged.
+
+100. Checked out files should have revision control support.  Maybe.
+
+102. Perhaps directory modes should be propagated on all import check-ins.
+     Not necessarily uid/gid changes.
+
+103. setuid/setgid on files is suspect.
+
+104. cvs should recover nicely on unreadable files/directories.
+
+105. cvs should have administrative tools to allow for changing permissions
+     and modes and what not.  In particular, this would make cvs a
+     more attractive alternative to rdist.
+
+107. It should be possible to specify a list of symbolic revisions to
+     checkout such that the list is processed in reverse order looking for
+     matches within the RCS file for the symbolic revision.  If there is
+     not a match, the next symbolic rev on the list is checked, and so on,
+     until all symbolic revs are exhausted.  This would allow one to, say,
+     checkout "4.0" + "4.0.3" + "4.0.3Patch1" + "4.0.3Patch2" to get the
+     most recent 4.x stuff.  This is usually handled by just specifying the
+     right release_tag, but most people forget to do this.
+
+108. If someone creates a whole new directory (i.e. adds it to the cvs
+     repository) and you happen to have a directory in your source farm by
+     the same name, when you do your cvs update -d it SILENTLY does
+     *nothing* to that directory.  At least, I think it was silent;
+     certainly, it did *not* abort my cvs update, as it would have if the
+     same thing had happened with a file instead of a directory.
+
+109. I had gotten pieces of the sys directory in the past but not a
+     complete tree.  I just did something like:
+
+        cvs get *
+
+     Where sys was in * and got the message
+
+        cvs get: Executing 'sys/tools/make_links sys'
+        sh: sys/tools/make_links: not found
+
+     I suspect this is because I didn't have the file in question,
+     but I do not understand how I could fool it into getting an
+     error.  I think a later cvs get sys seemed to work so perhaps
+     something is amiss in handling multiple arguments to cvs get?
+
+113. The "cvs update" command should tee its output to a log file in ".".
+     (why?  What is wrong with piping stdout to "tee"? -kingdon, Jun 1995)
+
+119. When importing a directory tree that is under SCCS/RCS control,
+     consider an option to have import checkout the SCCS/RCS files if
+     necessary.  (This is if someone wants to import something which
+     is in RCS or SCCS without preserving the history, but makes sure
+     they do get the latest versions.  It isn't clear to me how useful
+     that is -kingdon, June 1996).
+
+122. If Name_Repository fails, it currently causes CVS to die completely.  It
+     should instead return NULL and have the caller do something reasonable
+     (???  -what is reasonable?  I'm not sure there is a real problem here.
+     -kingdon, June 1996).
+
+123. Add a flag to import to not build vendor branches for local code.
+     (See `importb' tests in src/sanity.sh for more details).
+
+124. Anyway, I thought you might want to add something like the following
+     to the cvs man pages:
+
+     BUGS
+       The sum of the sizes of a module key and its contents are
+       limited.  See ndbm(3).
+
+126. Do an analysis to see if CVS is forgetting to close file descriptors.
+     Especially when committing many files (more than the open file limit
+     for the particular UNIX).
+
+127. Look at *info files; they should all be quiet if the files are not
+     there.  Should be able to point at a RCS directory and go.
+
+130. cvs diff with no -r arguments does not need to look up the current RCS
+     version number since it only cares about what's in the Entries file.
+     This should make it much faster.
+
+     It should ParseEntries itself and access the entries list much like
+     Version_TS does (sticky tags and sticky options may need to be
+     supported here as well).  Then it should only diff the things that
+     have the wrong time stamp (the ones that look modified).
+
+134. Make a statement about using hard NFS mounts to your source
+     repository.  Look into checking NULL fgets() returns with ferror() to
+     see if an error had occurred.  (we should be checking for errors, quite
+     aside from NFS issues -kingdon, June 1996).
+
+137. Some sites might want CVS to fsync() the RCS ,v file to protect
+     against nasty hardware errors.  There is a slight performance hit with
+     doing so, though, so it should be configurable in the .cvsrc file.
+     Also, along with this, we should look at the places where CVS itself
+     could be a little more synchronous so as not to lose data.
+     [[ I've done some of this, but it could use much more ]]
+
+138. Some people have suggested that CVS use a VPATH-like environment
+     variable to limit the amount of sources that need to be duplicated for
+     sites with giant source trees and no disk space.
+
+141. Import should accept modules as its directory argument.  If we're
+     going to implement this, we should think hard about how modules
+     might be expanded and how to handle those cases.
+
+143. Update the documentation to show that the source repository is
+     something far away from the files that you work on.  (People who
+     come from an RCS background are used to their `repository' being
+     _very_ close to their working directory.)
+
+144. Have cvs checkout look for the environment variable CVSPREFIX
+     (or CVSMODPREFIX or some such).  If it's set, then when looking
+     up an alias in the modules database, first look it up with the
+     value of CVSPREFIX attached, and then look for the alias itself.
+     This would be useful when you have several projects in a single
+     repository.  You could have aliases abc_src and xyz_src and
+     tell people working on project abc to put "setenv CVSPREFIX abc_"
+     in their .cshrc file (or equivalent for other shells).
+     Then they could do "cvs co src" to get a copy of their src
+     directory, not xyz's.  (This should create a directory called
+     src, not abc_src.)
+
+145. After you create revision 1.1.1.1 in the previous scenario, if
+     you do "cvs update -r1 filename" you get revision 1.1, not
+     1.1.1.1.  It would be nice to get the later revision.  Again,
+     this restriction comes from RCS and is probably hard to
+     change in CVS.  Sigh.
+
+     |"cvs update -r1 filename" does not tell RCS to follow any branches.  CVS
+     |tries to be consistent with RCS in this fashion, so I would not change
+     |this.  Within CVS we do have the flexibility of extending things, like
+     |making a revision of the form "-r1HEAD" find the most recent revision
+     |(branch or not) with a "1." prefix in the RCS file.  This would get what
+     |you want maybe.
+      
+     This would be very useful.  Though I would prefer an option
+     such as "-v1" rather than "-r1HEAD".  This option might be
+     used quite often.
+
+146. The merging of files should be controlled via a hook so that programs
+     other than "rcsmerge" can be used, like Sun's filemerge or emacs's
+     emerge.el.  (but be careful in making this work client/server--it means
+     doing the interactive merging at the end after the server is done).
+     (probably best is to have CVS do the non-interactive part and
+     tell the user about where the files are (.#foo.c.working and
+     .#foo.c.1.5 or whatever), so they can do the interactive part at
+     that point -kingdon, June 1996).
+
+149. Maybe there should be an option to cvs admin that allows a user to
+     change the Repository/Root file with some degree of error checking?
+     Something like "cvs admin reposmv /old/path /new/pretty/path".  Before
+     it does the replace it check to see that the files
+     /new/pretty/path/<dir>/<files> exist.
+
+     The obvious cases are where one moves the repository to another
+     machine or directory.  But there are other cases, like where the
+     user might want to change from :pserver: to :ext:, use a different
+     server (if there are two server machines which share the
+     repository using a networked file system), etc.
+
+     The status quo is a bit of a mess (as of, say, CVS 1.9).  It is
+     that the -d global option has two moderately different uses.  One
+     is to use a totally different repository (in which case we'd
+     probably want to give an error if it disagreed with CVS/Root, as
+     CVS 1.8 and earlier did).  The other is the "reposmv"
+     functionality above (in which the two repositories really are the
+     same, and we want to update the CVS/Root files).  In CVS 1.9 and
+     1.10, -d rewrites the CVS/Root file (but not in subdirectories).
+     This behavior was not particularly popular and has been since
+     reverted.
+
+     This whole area is a rather bad pile of individual decisions which
+     accumulated over time, some of them probably bad decisions with
+     hindsight.  But we didn't get into this mess overnight, and we're
+     not going to get out of it overnight (that is, we need to come up
+     with a replacement behavior, document what parts of the status
+     quo are deprecated, probably circulate some unofficial patches, &c).
+
+     (this item originally added 2 Feb 1992 but revised since).
+
+150. I have a customer request for a way to specify log message per
+     file, non-interactively before the commit, such that a single, fully
+     recursive commit prompts for one commit message, and concatenates the
+     per file messages for each file.  In short, one commit, one editor
+     session, log messages allowed to vary across files within the commit.
+     Also, the per file messages should be allowed to be written when the
+     files are changed, which may predate the commit considerably.
+
+     A new command seems appropriate for this.  The state can be saved in the
+     CVS directory.  I.e.,
+
+        % cvs message foo.c
+        Enter log message for foo.c
+        >> fixed an uninitialized variable
+        >> ^D
+
+     The text is saved as CVS/foo.c,m (or some such name) and commit
+     is modified to append (prepend?) the text (if found) to the log
+     message specified at commit time.  Easy enough.  (having cvs
+     commit be non-interactive takes care of various issues like
+     whether to connect to the server before or after prompting for a
+     message (see comment in commit.c at call to start_server).  Also
+     would clean up the kludge for what to do with the message from
+     do_editor if the up-to-date check fails (see commit.c client code).
+
+     I'm not sure about the part above about having commit prompt
+     for an overall message--part of the point is having commit
+     non-interactive and somehow combining messages seems like (excess?)
+     hair.
+
+     Would be nice to do this so it allows users more flexibility in
+     specifying messages per-directory ("cvs message -l") or per-tree
+     ("cvs message") or per-file ("cvs message foo.c"), and fixes the
+     incompatibility between client/server (per-tree) and
+     non-client/server (per-directory).
+
+     A few interesting issues with this: (1) if you do a cvs update or
+     some other operation which changes the working directory, do you
+     need to run "cvs message" again (it would, of course, bring up
+     the old message which you could accept)?  Probably yes, after all
+     merging in some conflicts might change the situation.  (2) How do
+     you change the stored messages if you change your mind before the
+     commit (probably run "cvs message" again, as hinted in (1))?
+
+151. Also, is there a flag I am missing that allows replacing Ulrtx_Build
+     by Ultrix_build?  I.E. I would like a tag replacement to be a one step
+     operation rather than a two step "cvs rtag -r Ulrtx_Build Ultrix_Build"
+     followed by "cvs rtag -d Ulrtx_Build"
+
+152. The "cvs -n" option does not work as one would expect for all the
+     commands.  In particular, for "commit" and "import", where one would
+     also like to see what it would do, without actually doing anything.
+
+153. There should be some command (maybe I just haven't figured out
+     which one...) to import a source directory which is already
+     RCS-administered without losing all prior RCS gathered data.
+     Thus, it would have to examine the RCS files and choose a
+     starting version and branch higher than previous ones used.
+     (Check out rcs-to-cvs and see if it addresses this issue.)
+
+154. When committing the modules file, a pre-commit check should be done to
+     verify the validity of the new modules file before allowing it to be
+     committed.
+
+155. The options for "cvs history" are mutually exclusive, even though
+     useful queries can be done if they are not, as in specifying both
+     a module and a tag.  A workaround is to specify the module, then
+     run the output through grep to only display lines that begin with
+     T, which are tag lines.  (Better perhaps if we redesign the whole
+     "history" business -- check out doc/cvs.texinfo for the entire
+     rant.)
+
+156. Also, how hard would it be to allow continuation lines in the
+     {commit,rcs,log}info files? It would probably be useful with all of
+     the various flags that are now available, or if somebody has a lot of
+     files to put into a module.
+
+158. If I do a recursive commit and find that the same RCS file is checked
+     out (and modified!) in two different places within my checked-out
+     files (but within the realm of a single "commit"), CVS will commit the
+     first change, then overwrite that change with the second change.  We
+     should catch this (typically unusual) case and issue an appropriate
+     diagnostic and die.
+
+160. The checks that the commit command does should be extended to make
+     sure that the revision that we will lock is not already locked by
+     someone else.  Maybe it should also lock the new revision if the old
+     revision was already locked by the user as well, thus moving the lock
+     forward after the commit.
+
+163. The rtag/tag commands should have an option that removes the specified
+     tag from any file that is in the attic.  This allows one to re-use a
+     tag (like "Mon", "Tue", ...) all the time and still have it tag the
+     real main-line code.
+
+165. The "import" command will create RCS files automatically, but will
+     screw-up when trying to create long file names on short file name
+     file systems.  Perhaps import should be a bit more cautious.
+
+166. There really needs to be a "Getting Started" document which describes
+     some of the new CVS philosophies.  Folks coming straight from SCCS or
+     RCS might be confused by "cvs import".  Also need to explain:
+               - How one might setup their $CVSROOT
+               - What all the tags mean in an "import" command
+               - Tags are important; revision numbers are not
+
+170. Is there an "info" file that can be invoked when a file is checked out, or
+     updated ?  What I want to do is to advise users, particularly novices, of
+     the state of their working source whenever they check something out, as
+     a sanity check.
+     For example, I've written a perl script which tells you what branch you're
+     on, if any.  Hopefully this will help guard against mistaken checkins to
+     the trunk, or to the wrong branch.  I suppose I can do this in
+     "commitinfo", but it'd be nice to advise people before they edit their
+     files.
+  
+     It would also be nice if there was some sort of "verboseness" switch to
+     the checkout and update commands that could turn this invocation of the
+     script off, for mature users.
+
+173. Need generic date-on-branch handling.  Currently, many commands
+     allow both -r and -D, but that's problematic for commands like diff
+     that interpret that as two revisions rather than a single revision.
+     Checkout and update -j takes tag:date which is probably a better
+     solution overall.
+
+174. I would like to see "cvs release" modified so that it only removes files
+     which are known to CVS - all the files in the repository, plus those which
+     are listed in .cvsignore.  This way, if you do leave something valuable in
+     a source tree you can "cvs release -d" the tree and your non-CVS goodies
+     are still there.  If a user is going to leave non-CVS files in their source
+     trees, they really should have to clean them up by hand.
+
+175. And, in the feature request department, I'd dearly love a command-line
+     interface to adding a new module to the CVSROOT/modules file.
+
+176. If you use the -i flag in the modules file, you can control access
+     to source code; this is a Good Thing under certain circumstances. I
+     just had a nasty thought, and on experiment discovered that the
+     filter specified by -i is _not_ run before a cvs admin command; as
+     this allows a user to go behind cvs's back and delete information
+     (cvs admin -o1.4 file) this seems like a serious problem.
+
+177. We've got some external vendor source that sits under a source code
+     hierarchy, and when we do a cvs update, it gets wiped out because
+     its tag is different from the "main" distribution. I've tried to
+     use "-I" to ignore the directory, as well as .cvsignore, but this
+     doesn't work.
+
+179. "cvs admin" does not log its actions with loginfo, nor does it check
+     whether the action is allowed with commitinfo.  It should.
+
+180. "cvs edit" should show you who is already editing the files,
+     probably (that is, do "cvs editors" before executing, or some
+     similar result).  (But watch out for what happens if the network
+     is down!).
+
+182.  There should be a way to show log entries corresponding to
+changes from tag "foo" to tag "bar".  "cvs log -rfoo:bar" doesn't cut
+it, because it erroneously shows the changes associated with the
+change from the revision before foo to foo.  I'm not sure that is ever
+a useful or logical behavior ("cvs diff -r foo -r bar" gets this
+right), but is compatibility an issue?  See
+http://www.cyclic.com/cvs/unoff-log.txt for an unofficial patch.
+
+183.  "cvs status" should report on Entries.Static flag and CVS/Tag (how?
+maybe a "cvs status -d" to give directory status?).  There should also
+be more documentation of how these get set and how/when to re-set them.
+
+184.  Would be nice to implement the FreeBSD MD5-based password hash
+algorithm in pserver.  For more info see "6.1. DES, MD5, and Crypt" in
+the FreeBSD Handbook, and src/lib/libcrypt/crypt.c in the FreeBSD
+sources.  Certainly in the context of non-unix servers this algorithm
+makes more sense than the traditional unix crypt() algorithm, which
+suffers from export control problems.
+
+185.  A frequent complaint is that keyword expansion causes conflicts
+when merging from one branch to another.  The first step is
+documenting CVS's existing features in this area--what happens with
+various -k options in various places?  The second step is thinking
+about whether there should be some new feature and if so how it should
+be designed.  For example, here is one thought:
+
+    rcs' co command needs a new -k option.  The new option should expand
+    $Log entries without expanding $Revision entries.  This would
+    allow cvs to use rcsmerge in such a way that joining branches into
+    main lines would neither generate extra collisions on revisions nor
+    drop log lines.
+
+The details of this are out of date (CVS no longer invokes "co", and
+any changes in this area would be done by bypassing RCS rather than
+modifying it), but even as to the general idea, I don't have a clear
+idea about whether it would be good (see what I mean about the need
+for better documentation?  I work on CVS full-time, and even I don't
+understand the state of the art on this subject).
+
+186.  There is a frequent discussion of multisite features.
+
+* There may be some overlap with the client/server CVS, which is good
+especially when there is a single developer at each location.  But by
+"multisite" I mean something in which each site is more autonomous, to
+one extent or another.
+
+* Vendor branches are the closest thing that CVS currently has for
+multisite features.  They have fixable drawbacks (such as poor
+handling of added and removed files), and more fundamental drawbacks
+(when you import a vendor branch, you are importing a set of files,
+not importing any knowledge of their version history outside the
+current repository).
+
+* One approach would be to require checkins (or other modifications to
+the repository) to succeed at a write quorum of sites (51%) before
+they are allowed to complete.  To work well, the network should be
+reliable enough that one can typically get to that many sites.  When a
+server which has been out of touch reconnects, it would want to update
+its data before doing anything else.  Any of the servers can service
+all requests locally, except perhaps for a check that they are
+up-to-date.  The way this differs from a run-of-the-mill distributed
+database is that if one only allows reversible operations via this
+mechanism (exclude "cvs admin -o", "cvs tag -d", &c), then each site
+can back up the others, such that failures at one site, including
+something like deleting all the sources, can be recovered from.  Thus
+the sites need not trust each other as much as for many shared
+databases, and the system may be resilient to many types of
+organizational failures.  Sometimes I call this design the
+"CVScluster" design.
+
+* Another approach is a master/slave one.  Checkins happen at the
+master site, and slave sites need to check whether their local
+repository is up to date before relying on its information.
+
+* Another approach is to have each site own a particular branch.  This
+one is the most tolerant of flaky networks; if checkins happen at each
+site independently there is no particular problem.  The big question
+is whether merges happen only manually, as with existing CVS branches,
+or whether there is a feature whereby there are circumstances in which
+merges from one branch to the other happen automatically (for example,
+the case in which the branches have not diverged).  This might be a
+legitimate question to ask even quite aside from multisite features.
+
+187.  Might want to separate out usage error messages and help
+messages.  The problem now is that if you specify an invalid option,
+for example, the error message is lost among all the help text.  In
+the new regime, the error message would be followed by a one-line
+message directing people to the appropriate help option ("cvs -H
+<command>" or "cvs --help-commands" or whatever, according to the
+situation).  I'm not sure whether this change would be controversial
+(as defined in HACKING), so there might be a need for further
+discussion or other actions other than just coding.
+
+188.  Option parsing and .cvsrc has at least one notable limitation.
+If you want to set a global option only for some CVS commands, there
+is no way to do it (for example, if one wants to set -q only for
+"rdiff").  I am told that the "popt" package from RPM
+(http://www.rpm.org) could solve this and other problems (for example,
+if the syntax of option stuff in .cvsrc is similar to RPM, that would
+be great from a user point of view).  It would at least be worth a
+look (it also provides a cleaner API than getopt_long).
+
+Another issue which may or may not be related is the issue of
+overriding .cvsrc from the command line.  The cleanest solution might
+be to have options in mutually exclusive sets (-l/-R being a current
+example, but --foo/--no-foo is a better way to name such options).  Or
+perhaps there is some better solution.
+
+189.  Renaming files and directories is a frequently discussed topic.
+
+Some of the problems with the status quo:
+
+a.  "cvs annotate" cannot operate on both the old and new files in a
+single run.  You need to run it twice, once for the new name and once
+for the old name.
+
+b.  "cvs diff" (or "cvs diff -N") shows a rename as a removal of the
+old file and an addition of the new one.  Some people would like to
+see the differences between the file contents (but then how would we
+indicate the fact that the file has been renamed?  Certainly the
+notion that "patch(1)" has of renames is as a removal and addition).
+
+c.  "cvs log" should be able to show the changes between two
+tags/dates, even in the presence of adds/removes/renames (I'm not sure
+what the status quo is on this; see also item #182).
+
+d.  Renaming directories is way too hard.
+
+Implementations:
+
+It is perhaps premature to try to design implementation details
+without answering some of the above questions about desired behaviors
+but several general implementations get mentioned.
+
+i.  No fundamental changes (for example, a "cvs rename" command which
+operated on directories could still implement the current recommended
+practice for renaming directories, which is to rename each of the
+files contained therein via an add and a remove).  One thing to note
+that the status quo gets right is proper merges, even with adds and
+removals (Well, mostly right at least.  There are a *LOT* of different
+cases; see the testsuite for some of them).
+
+ii.  Rename database.  In this scheme the files in the repository
+would have some arbitrary name, and then a separate rename database
+would indicate the current correspondence between the filename in the
+working directory and the actual storage.  As far as I know this has
+never been designed in detail for CVS.
+
+iii.  A modest change in which the RCS files would contain some
+information such as "renamed from X" or "renamed to Y".  That is, this
+would be generally similar to the log messages which are suggested
+when one renames via an add and a removal, but would be
+computer-parseable.  I don't think anyone has tried to flesh out any
+details here either.
+
+It is interesting to note that in solution ii. version numbers in the
+"new file" start where the "old file" left off, while in solutions
+i. and iii., version numbers restart from 1.1 each time a file is
+renamed.  Except perhaps in the case where we rename a file from foo
+to bar and then back to foo.  I'll shut up now.
+
+Regardless of the method we choose, we need to address how renames
+affect existing CVS behaviors.  For example, what happens when you
+rename a file on a branch but not the trunk and then try to merge the
+two?  What happens when you rename a file on one branch and delete it
+on another and try to merge the two?
+
+Ideally, we'd come up with a way to parameterize the problem and
+simply write up a lookup table to determine the correct behavior.
+
+190.  The meaning of the -q and -Q global options is very ad hoc;
+there is no clear definition of which messages are suppressed by them
+and which are not.  Here is a classification of the current meanings
+of -q; I don't know whether anyone has done a similar investigation of
+-Q:
+
+  a.  The "warm fuzzies" printed upon entering each directory (for
+  example, "cvs update: Updating sdir").  The need for these messages
+  may be decreased now that most of CVS uses ->fullname instead of
+  ->file in messages (a project which is *still* not 100% complete,
+  alas).  However, the issue of whether CVS can offer status as it
+  runs is an important one.  Of course from the command line it is
+  hard to do this well and one ends up with options like -q.  But
+  think about emacs, jCVS, or other environments which could flash you
+  the latest status line so you can see whether the system is working
+  or stuck.
+
+  b.  Other cases where the message just offers information (rather
+  than an error) and might be considered unnecessarily verbose.  These
+  have a certain point to them, although it isn't really clear whether
+  it should be the same option as the warm fuzzies or whether it is
+  worth the conceptual hair:
+
+    add.c: scheduling %s `%s' for addition (may be an issue)
+    modules.c: %s %s: Executing '%s' (I can see how that might be noise,
+      but...)
+    remove.c: scheduling `%s' for removal (analogous to the add.c one)
+    update.c: Checking out %s (hmm, that message is a bit on the noisy side...)
+      (but the similar message in annotate is not affected by -q).
+
+  c.  Suppressing various error messages.  This is almost surely
+  bogus.
+
+    commit.c: failed to remove tag `%s' from `%s' (Questionable.
+      Rationale might be that we already printed another message
+      elsewhere but why would it be necessary to avoid
+      the extra message in such an uncommon case?)
+    commit.c: failed to commit dead revision for `%s' (likewise)
+    remove.c: file `%s' still in working directory (see below about rm
+      -f analogy)
+    remove.c: nothing known about `%s' (looks dubious to me, especially in
+      the case where the user specified it explicitly).
+    remove.c: removed `%s' (seems like an obscure enough case that I fail
+      to see the appeal of being cryptically concise here).
+    remove.c: file `%s' already scheduled for removal (now it is starting
+      to look analogous to the infamous rm -f option).
+    rtag.c: cannot find tag `%s' in `%s' (more rm -f like behavior)
+    rtag.c: failed to remove tag `%s' from `%s' (ditto)
+    tag.c: failed to remove tag %s from %s (see above about whether RCS_*
+      has already printed an error message).
+    tag.c: couldn't tag added but un-commited file `%s' (more rm -f
+      like behavior)
+    tag.c: skipping removed but un-commited file `%s' (ditto)
+    tag.c: cannot find revision control file for `%s' (ditto, but at first
+      glance seems even worse, as this would seem to be a "can't happen"
+      condition)
+
+191.  Storing RCS files, especially binary files, takes rather more
+space than it could, typically.
+  - The virtue of the status quo is that it is simple to implement.
+    Of course it is also simplest in terms of dealing with compatibility.
+  - Just storing the revisions as separate gzipped files is a common 
+    technique.  It also is pretty simple (no new algorithms, CVS
+    already has zlib around).  Of course for some files (such as files
+    which are already compressed) the gzip step won't help, but
+    something which can at least sometimes avoid rewriting the entire
+    RCS file for each new revision would, I would think, be a big
+    speedup for large files.
+  - Josh MacDonald has written a tool called xdelta which produces
+    differences (that is, sufficient information to transform the old
+    to the new) which looks for common sequences of bytes, like RCS
+    currently does, but which is not based on lines.  This seems to do
+    quite well for some kinds of files (e.g. FrameMaker documents,
+    text files), and not as well for others (anything which is already
+    compressed, executables).  xdelta 1.10 also is faster than GNU diff.
+  - Karl Fogel has thought some about using a difference technique
+    analogous to fractal compression (see the comp.compression FAQ for
+    more on fractal compression, including at least one patent to
+    watch for; I don't know how analogous Karl's ideas are to the
+    techniques described there).
+  - Quite possibly want some documented interface by which a site can
+    plug in their choice of external difference programs (with the
+    ability to choose the program based on filename, magic numbers,
+    or some such).
+
+192.  "cvs update" using an absolute pathname does not work if the
+working directory is not a CVS-controlled directory with the correct
+CVSROOT.  For example, the following will fail:
+
+  cd /tmp
+  cvs -d /repos co foo
+  cd /
+  cvs update /tmp/foo
+
+It is possible to read the CVSROOT from the administrative files in
+the directory specified by the absolute pathname argument to update.
+In that case, the last command above would be equivalent to:
+
+  cd /tmp/foo
+  cvs update .
+
+This can be problematic, however, if we ask CVS to update two
+directories with different CVSROOTs.  Currently, CVS has no way of
+changing CVSROOT mid-stream.  Consider the following:
+
+  cd /tmp
+  cvs -d /repos1 co foo
+  cvs -d /repos2 co bar
+  cd /
+  cvs update /tmp/foo /tmp/bar
+
+To make that example work, we need to think hard about:
+
+  - where and when CVSROOT-related variables get set
+  - who caches said variables for later use
+  - how the remote protocol should be extended to handle sending a new
+    repository mid-stream
+  - how the client should maintain connections to a variety of servers
+    in a single invocation.
+
+Because those issues are hairy, I suspect that having a change in
+CVSROOT be an error would be a better move.
+
+193.  The client relies on timestamps to figure out whether a file is
+(maybe) modified.  If something goes awry, then it ends up sending
+entire files to the server to be checked, and this can be quite slow
+especially over a slow network.  A couple of things that can happen:
+(a) other programs, like make, use timestamps, so one ends up needing
+to do "touch foo" and otherwise messing with timestamps, (b) changing
+the timezone offset (e.g. summer vs. winter or moving a machine)
+should work on unix, but there may be problems with non-unix.
+
+Possible solutions:
+
+   a.  Store a checksum for each file in CVS/Entries or some such
+   place.  What to do about hash collisions is interesting: using a
+   checksum, like MD5, large enough to "never" have collisions
+   probably works in practice (of course, if there is a collision then
+   all hell breaks loose because that code path was not tested, but
+   given the tiny, tiny probability of that I suppose this is only an
+   aesthetic issue).
+
+   b.  I'm not thinking of others, except storing the whole file in
+   CVS/Base, and I'm sure using twice the disk space would be
+   unpopular.
+
+194.  CVS does not separate the "metadata" from the actual revision
+history; it stores them both in the RCS files.  Metadata means tags
+and header information such as the number of the head revision.
+Storing the metadata separately could speed up "cvs tag" enormously,
+which is a big problem for large repositories.  It could also probably
+make CVS's locking much less in the way (see comment in do_recursion
+about "two-pass design").
+
+195.  Many people using CVS over a slow link are interested in whether
+the remote protocol could be any more efficient with network
+bandwidth.  This item is about one aspect of that--how the server
+sends a new version of a file the client has a different version of,
+or vice versa.
+
+a.  Cases in which the status quo already sends a diff.  For most text
+files, this is probably already close to optimal.  For binary files,
+and anomalous (?) text files (e.g. those in which it would help to do
+moves, as well as adds and deletes), it might be worth looking into other
+difference algorithms (see item #191).
+
+b.  Cases in which the status quo does not send a diff (e.g. "cvs
+commit").
+
+b1.  With some frequency, people suggest rsync or a similar algorithm
+(see ftp://samba.anu.edu.au/pub/rsync/).  This could speed things up,
+and in some ways involves the most minimal changes to the default CVS
+paradigm.  There are some downsides though: (1) there is an extra
+network turnaround, (2) the algorithm needs to transmit some data to
+discover what difference type programs can discover locally (although
+this is only about 1% of the size of the files).
+
+b2.  If one is willing to require that users use "cvs edit" before
+editing a file on the client side (in some cases, a development
+environment like emacs can make this fairly easy), then the Modified
+request in the protocol could be extended to allow the client to just
+send differences instead of entire files.  In the degenerate case
+(e.g. "cvs diff" without arguments) the required network traffic is
+reduced to zero, and the client need not even contact the server.
+
+197.  Analyze the difference between CVS_UNLINK & unlink_file.  As far as I
+can tell, unlink_file aborts in noexec mode and CVS_UNLINK does not.  I'm not
+sure it would be possible to remove even the use of temp files in noexec mode,
+but most unlinks should probably be using unlink_file and not CVS_UNLINK.
+
+198.  Remove references to deprecated cvs_temp_name function.
+
+199.  Add test for login & logout functionality, including support for
+backwards compatibility with old CVSROOTs.
+
+200.  Make a 'cvs add' without write access a non-fatal error so that
+the user's Entries file is updated and future 'cvs diffs' will work
+properly.  This should ease patch submission.
+
+201.  cvs_temp_file should be creating temporary files in a privately owned
+subdirectory of of temp due to security issues on some systems.
+
+202.  Enable rdiff to accept most diff options.  Make rdiff output look
+like diff's.  Make CVS diff garbage go to stderr and only standard diff
+output go to stdout.
+
+203.  Add val-tags additions to the tagging code.  Don't remove the
+update additions since val-tags could still be used as a cache when the
+repository was imported from elsewhere (the tags weren't applied with a
+version which wrote val-tags).
+
+204.  Add test case for compression.  A buf_shutdown error using compression
+wasn't caught by the test suite.
+
+205.  There are lots of cases where trailing slashes on directory names
+and other non-canonical paths confuse CVS.  Most of the cases that do
+work are handled on an ad-hoc basis.  We need to come up with a coherent
+strategy to address path canonicalization and apply it consistently.
+
+208.  Merge enhancements to the diff package back into the original GNU source.
+
+209.  Go through this file and try to:
+
+  a.  Verify that items are still valid.
+
+  b.  Create test cases for valid items when they don't exist.
+
+  c.  Remove fixed and no longer applicable items.
+
+210.  Explain to sanity.sh how to deal with paths with spaces and other odd
+characters in them.
+
+211.  Make sanity.sh run under the Win32 bash (cygwin) and maybe other Windex
+environments (e.g. DGSS or whatever the MSVC portability environemnt is called).
+
+212.  Autotestify (see autoconf source) sanity.sh.
+
+213.  Examine desirability of updating the regex library (regex.{c,h}) to the
+more recent versions that come with glibc and emacs.  It might be worth waiting
+for the emacs folks to get their act together and merge their changes into the
+glibc version.
+
+214.  Make options.h options configure script options instead.
+
+215.  Add reditors and rwatchers commands.
+
+       - Is an r* command abstraction layer possible here for the commands
+         where this makes sense?  Would it be simpler?  It seems to me the
+         major operational differences lie in the file list construction.
+
+218.  Fix "checkout -d ." in client/server mode.
+
+221.  Handle spaces in file/directory names.  (Most, if not all, of the
+internal infrastructure already handles them correctly, but most of the
+administrative file interfaces do not.)
+
+223.  Internationalization support.  This probably means using some kind
+of universal character set (ISO 10646?) internally and converting on
+input and output, which opens the locale can of worms.
+
+225.  Add support for --allow-root to server command.
+
+227.  'cvs release' should use the CVS/Root in the directory being released
+when such is specified rather than $CVSROOT.  In my work directory with no CVS
+dir, a release of subdirectories causes the released projects to be tested
+against my $CVSROOT environment variable, which often isn't correct but which
+can complete without generating error messages if the project also exists in
+the other CVSROOT.  This happens a lot with my copies of the ccvs project.
+
+228.  Consider adding -d to commit ala ci.
+
+229.  Improve the locking code to use a random delay with exponential
+backoff ala Ethernet and separate the notification interval from the
+wait interval.
+
+230.  Support for options like compression as part of the CVSROOT might be
+nice.  This should be fairly easy to implement now using the method options.
+
+231.  The `cvs watch off' command needs an extension which enables users in the
+cvsadmin group to turn watch off for users whose logins and email address may
+not exist anymore.
diff --git a/contrib/cvs-1.12.9/configure b/contrib/cvs-1.12.9/configure
new file mode 100644 (file)
index 0000000..f13cf3f
--- /dev/null
@@ -0,0 +1,33263 @@
+#! /bin/sh
+# Guess values for system-dependent variables and create Makefiles.
+# Generated by GNU Autoconf 2.58 for Concurrent Versions System (CVS) 1.12.9.
+#
+# Report bugs to <bug-cvs@gnu.org>.
+#
+# Copyright (C) 1986, 1987, 1988, 1989, 1990, 1991, 1992, 1993, 1994, 1995,
+#               1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003
+#               Free Software Foundation, Inc.
+#
+# 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, 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.
+#
+# Copyright (C) 2003 Free Software Foundation, Inc.
+# This configure script is free software; the Free Software Foundation
+# gives unlimited permission to copy, distribute and modify it.
+## --------------------- ##
+## M4sh Initialization.  ##
+## --------------------- ##
+
+# Be Bourne compatible
+if test -n "${ZSH_VERSION+set}" && (emulate sh) >/dev/null 2>&1; then
+  emulate sh
+  NULLCMD=:
+  # Zsh 3.x and 4.x performs word splitting on ${1+"$@"}, which
+  # is contrary to our usage.  Disable this feature.
+  alias -g '${1+"$@"}'='"$@"'
+elif test -n "${BASH_VERSION+set}" && (set -o posix) >/dev/null 2>&1; then
+  set -o posix
+fi
+DUALCASE=1; export DUALCASE # for MKS sh
+
+# Support unset when possible.
+if ( (MAIL=60; unset MAIL) || exit) >/dev/null 2>&1; then
+  as_unset=unset
+else
+  as_unset=false
+fi
+
+
+# Work around bugs in pre-3.0 UWIN ksh.
+$as_unset ENV MAIL MAILPATH
+PS1='$ '
+PS2='> '
+PS4='+ '
+
+# NLS nuisances.
+for as_var in \
+  LANG LANGUAGE LC_ADDRESS LC_ALL LC_COLLATE LC_CTYPE LC_IDENTIFICATION \
+  LC_MEASUREMENT LC_MESSAGES LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER \
+  LC_TELEPHONE LC_TIME
+do
+  if (set +x; test -z "`(eval $as_var=C; export $as_var) 2>&1`"); then
+    eval $as_var=C; export $as_var
+  else
+    $as_unset $as_var
+  fi
+done
+
+# Required to use basename.
+if expr a : '\(a\)' >/dev/null 2>&1; then
+  as_expr=expr
+else
+  as_expr=false
+fi
+
+if (basename /) >/dev/null 2>&1 && test "X`basename / 2>&1`" = "X/"; then
+  as_basename=basename
+else
+  as_basename=false
+fi
+
+
+# Name of the executable.
+as_me=`$as_basename "$0" ||
+$as_expr X/"$0" : '.*/\([^/][^/]*\)/*$' \| \
+        X"$0" : 'X\(//\)$' \| \
+        X"$0" : 'X\(/\)$' \| \
+        .     : '\(.\)' 2>/dev/null ||
+echo X/"$0" |
+    sed '/^.*\/\([^/][^/]*\)\/*$/{ s//\1/; q; }
+         /^X\/\(\/\/\)$/{ s//\1/; q; }
+         /^X\/\(\/\).*/{ s//\1/; q; }
+         s/.*/./; q'`
+
+
+# PATH needs CR, and LINENO needs CR and PATH.
+# Avoid depending upon Character Ranges.
+as_cr_letters='abcdefghijklmnopqrstuvwxyz'
+as_cr_LETTERS='ABCDEFGHIJKLMNOPQRSTUVWXYZ'
+as_cr_Letters=$as_cr_letters$as_cr_LETTERS
+as_cr_digits='0123456789'
+as_cr_alnum=$as_cr_Letters$as_cr_digits
+
+# The user is always right.
+if test "${PATH_SEPARATOR+set}" != set; then
+  echo "#! /bin/sh" >conf$$.sh
+  echo  "exit 0"   >>conf$$.sh
+  chmod +x conf$$.sh
+  if (PATH="/nonexistent;."; conf$$.sh) >/dev/null 2>&1; then
+    PATH_SEPARATOR=';'
+  else
+    PATH_SEPARATOR=:
+  fi
+  rm -f conf$$.sh
+fi
+
+
+  as_lineno_1=$LINENO
+  as_lineno_2=$LINENO
+  as_lineno_3=`(expr $as_lineno_1 + 1) 2>/dev/null`
+  test "x$as_lineno_1" != "x$as_lineno_2" &&
+  test "x$as_lineno_3"  = "x$as_lineno_2"  || {
+  # Find who we are.  Look in the path if we contain no path at all
+  # relative or not.
+  case $0 in
+    *[\\/]* ) as_myself=$0 ;;
+    *) as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
+for as_dir in $PATH
+do
+  IFS=$as_save_IFS
+  test -z "$as_dir" && as_dir=.
+  test -r "$as_dir/$0" && as_myself=$as_dir/$0 && break
+done
+
+       ;;
+  esac
+  # We did not find ourselves, most probably we were run as `sh COMMAND'
+  # in which case we are not to be found in the path.
+  if test "x$as_myself" = x; then
+    as_myself=$0
+  fi
+  if test ! -f "$as_myself"; then
+    { echo "$as_me: error: cannot find myself; rerun with an absolute path" >&2
+   { (exit 1); exit 1; }; }
+  fi
+  case $CONFIG_SHELL in
+  '')
+    as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
+for as_dir in /bin$PATH_SEPARATOR/usr/bin$PATH_SEPARATOR$PATH
+do
+  IFS=$as_save_IFS
+  test -z "$as_dir" && as_dir=.
+  for as_base in sh bash ksh sh5; do
+        case $as_dir in
+        /*)
+          if ("$as_dir/$as_base" -c '
+  as_lineno_1=$LINENO
+  as_lineno_2=$LINENO
+  as_lineno_3=`(expr $as_lineno_1 + 1) 2>/dev/null`
+  test "x$as_lineno_1" != "x$as_lineno_2" &&
+  test "x$as_lineno_3"  = "x$as_lineno_2" ') 2>/dev/null; then
+            $as_unset BASH_ENV || test "${BASH_ENV+set}" != set || { BASH_ENV=; export BASH_ENV; }
+            $as_unset ENV || test "${ENV+set}" != set || { ENV=; export ENV; }
+            CONFIG_SHELL=$as_dir/$as_base
+            export CONFIG_SHELL
+            exec "$CONFIG_SHELL" "$0" ${1+"$@"}
+          fi;;
+        esac
+       done
+done
+;;
+  esac
+
+  # Create $as_me.lineno as a copy of $as_myself, but with $LINENO
+  # uniformly replaced by the line number.  The first 'sed' inserts a
+  # line-number line before each line; the second 'sed' does the real
+  # work.  The second script uses 'N' to pair each line-number line
+  # with the numbered line, and appends trailing '-' during
+  # substitution so that $LINENO is not a special case at line end.
+  # (Raja R Harinath suggested sed '=', and Paul Eggert wrote the
+  # second 'sed' script.  Blame Lee E. McMahon for sed's syntax.  :-)
+  sed '=' <$as_myself |
+    sed '
+      N
+      s,$,-,
+      : loop
+      s,^\(['$as_cr_digits']*\)\(.*\)[$]LINENO\([^'$as_cr_alnum'_]\),\1\2\1\3,
+      t loop
+      s,-$,,
+      s,^['$as_cr_digits']*\n,,
+    ' >$as_me.lineno &&
+  chmod +x $as_me.lineno ||
+    { echo "$as_me: error: cannot create $as_me.lineno; rerun with a POSIX shell" >&2
+   { (exit 1); exit 1; }; }
+
+  # Don't try to exec as it changes $[0], causing all sort of problems
+  # (the dirname of $[0] is not the place where we might find the
+  # original and so on.  Autoconf is especially sensible to this).
+  . ./$as_me.lineno
+  # Exit status is that of the last command.
+  exit
+}
+
+
+case `echo "testing\c"; echo 1,2,3`,`echo -n testing; echo 1,2,3` in
+  *c*,-n*) ECHO_N= ECHO_C='
+' ECHO_T='     ' ;;
+  *c*,*  ) ECHO_N=-n ECHO_C= ECHO_T= ;;
+  *)       ECHO_N= ECHO_C='\c' ECHO_T= ;;
+esac
+
+if expr a : '\(a\)' >/dev/null 2>&1; then
+  as_expr=expr
+else
+  as_expr=false
+fi
+
+rm -f conf$$ conf$$.exe conf$$.file
+echo >conf$$.file
+if ln -s conf$$.file conf$$ 2>/dev/null; then
+  # We could just check for DJGPP; but this test a) works b) is more generic
+  # and c) will remain valid once DJGPP supports symlinks (DJGPP 2.04).
+  if test -f conf$$.exe; then
+    # Don't use ln at all; we don't have any links
+    as_ln_s='cp -p'
+  else
+    as_ln_s='ln -s'
+  fi
+elif ln conf$$.file conf$$ 2>/dev/null; then
+  as_ln_s=ln
+else
+  as_ln_s='cp -p'
+fi
+rm -f conf$$ conf$$.exe conf$$.file
+
+if mkdir -p . 2>/dev/null; then
+  as_mkdir_p=:
+else
+  test -d ./-p && rmdir ./-p
+  as_mkdir_p=false
+fi
+
+as_executable_p="test -f"
+
+# Sed expression to map a string onto a valid CPP name.
+as_tr_cpp="eval sed 'y%*$as_cr_letters%P$as_cr_LETTERS%;s%[^_$as_cr_alnum]%_%g'"
+
+# Sed expression to map a string onto a valid variable name.
+as_tr_sh="eval sed 'y%*+%pp%;s%[^_$as_cr_alnum]%_%g'"
+
+
+# IFS
+# We need space, tab and new line, in precisely that order.
+as_nl='
+'
+IFS="  $as_nl"
+
+# CDPATH.
+$as_unset CDPATH
+
+
+# Name of the host.
+# hostname on some systems (SVR3.2, Linux) returns a bogus exit status,
+# so uname gets run too.
+ac_hostname=`(hostname || uname -n) 2>/dev/null | sed 1q`
+
+exec 6>&1
+
+#
+# Initializations.
+#
+ac_default_prefix=/usr/local
+ac_config_libobj_dir=.
+cross_compiling=no
+subdirs=
+MFLAGS=
+MAKEFLAGS=
+SHELL=${CONFIG_SHELL-/bin/sh}
+
+# Maximum number of lines to put in a shell here document.
+# This variable seems obsolete.  It should probably be removed, and
+# only ac_max_sed_lines should be used.
+: ${ac_max_here_lines=38}
+
+# Identity of this package.
+PACKAGE_NAME='Concurrent Versions System (CVS)'
+PACKAGE_TARNAME='cvs'
+PACKAGE_VERSION='1.12.9'
+PACKAGE_STRING='Concurrent Versions System (CVS) 1.12.9'
+PACKAGE_BUGREPORT='bug-cvs@gnu.org'
+
+ac_unique_file="src/cvs.h"
+# Factoring default headers for most tests.
+ac_includes_default="\
+#include <stdio.h>
+#if HAVE_SYS_TYPES_H
+# include <sys/types.h>
+#endif
+#if HAVE_SYS_STAT_H
+# include <sys/stat.h>
+#endif
+#if STDC_HEADERS
+# include <stdlib.h>
+# include <stddef.h>
+#else
+# if HAVE_STDLIB_H
+#  include <stdlib.h>
+# endif
+#endif
+#if HAVE_STRING_H
+# if !STDC_HEADERS && HAVE_MEMORY_H
+#  include <memory.h>
+# endif
+# include <string.h>
+#endif
+#if HAVE_STRINGS_H
+# include <strings.h>
+#endif
+#if HAVE_INTTYPES_H
+# include <inttypes.h>
+#else
+# if HAVE_STDINT_H
+#  include <stdint.h>
+# endif
+#endif
+#if HAVE_UNISTD_H
+# include <unistd.h>
+#endif"
+
+gl_header_list=
+gl_func_list=
+ac_subst_vars='SHELL PATH_SEPARATOR PACKAGE_NAME PACKAGE_TARNAME PACKAGE_VERSION PACKAGE_STRING PACKAGE_BUGREPORT exec_prefix prefix program_transform_name bindir sbindir libexecdir datadir sysconfdir sharedstatedir localstatedir libdir includedir oldincludedir infodir mandir build_alias host_alias target_alias DEFS ECHO_C ECHO_N ECHO_T LIBS INSTALL_PROGRAM INSTALL_SCRIPT INSTALL_DATA CYGPATH_W PACKAGE VERSION ACLOCAL AUTOCONF AUTOMAKE AUTOHEADER MAKEINFO AMTAR install_sh STRIP ac_ct_STRIP INSTALL_STRIP_PROGRAM AWK SET_MAKE am__leading_dot ac_prefix_program MAINTAINER_MODE_TRUE MAINTAINER_MODE_FALSE MAINT CC CFLAGS LDFLAGS CPPFLAGS ac_ct_CC EXEEXT OBJEXT DEPDIR am__include am__quote AMDEP_TRUE AMDEP_FALSE AMDEPBACKSLASH CCDEPMODE am__fastdepCC_TRUE am__fastdepCC_FALSE CPP EGREP RANLIB ac_ct_RANLIB LN_S PERL CSH MKTEMP SENDMAIL PR ROFF PS2PDF TEXI2DVI MAKE_TARGETS_IN_VPATH_TRUE MAKE_TARGETS_IN_VPATH_FALSE LIBOBJS MKINSTALLDIRS USE_NLS MSGFMT GMSGFMT XGETTEXT MSGMERGE build build_cpu build_vendor build_os host host_cpu host_vendor host_os LIBICONV LTLIBICONV INTLLIBS LIBINTL LTLIBINTL POSUB STDBOOL_H HAVE__BOOL ALLOCA ALLOCA_H FNMATCH_H LIB_NANOSLEEP YACC YFLAGS LIB_CLOCK_GETTIME HAVE_PUTENV cvs_client_objects KRB4 ZLIB_SUBDIRS ZLIB_CPPFLAGS ZLIB_LIBS with_default_rsh RSH_DFLT EDITOR LTLIBOBJS'
+ac_subst_files='MKTEMP_SH_FUNCTION'
+
+# Initialize some variables set by options.
+ac_init_help=
+ac_init_version=false
+# The variables have the same names as the options, with
+# dashes changed to underlines.
+cache_file=/dev/null
+exec_prefix=NONE
+no_create=
+no_recursion=
+prefix=NONE
+program_prefix=NONE
+program_suffix=NONE
+program_transform_name=s,x,x,
+silent=
+site=
+srcdir=
+verbose=
+x_includes=NONE
+x_libraries=NONE
+
+# Installation directory options.
+# These are left unexpanded so users can "make install exec_prefix=/foo"
+# and all the variables that are supposed to be based on exec_prefix
+# by default will actually change.
+# Use braces instead of parens because sh, perl, etc. also accept them.
+bindir='${exec_prefix}/bin'
+sbindir='${exec_prefix}/sbin'
+libexecdir='${exec_prefix}/libexec'
+datadir='${prefix}/share'
+sysconfdir='${prefix}/etc'
+sharedstatedir='${prefix}/com'
+localstatedir='${prefix}/var'
+libdir='${exec_prefix}/lib'
+includedir='${prefix}/include'
+oldincludedir='/usr/include'
+infodir='${prefix}/info'
+mandir='${prefix}/man'
+
+ac_prev=
+for ac_option
+do
+  # If the previous option needs an argument, assign it.
+  if test -n "$ac_prev"; then
+    eval "$ac_prev=\$ac_option"
+    ac_prev=
+    continue
+  fi
+
+  ac_optarg=`expr "x$ac_option" : 'x[^=]*=\(.*\)'`
+
+  # Accept the important Cygnus configure options, so we can diagnose typos.
+
+  case $ac_option in
+
+  -bindir | --bindir | --bindi | --bind | --bin | --bi)
+    ac_prev=bindir ;;
+  -bindir=* | --bindir=* | --bindi=* | --bind=* | --bin=* | --bi=*)
+    bindir=$ac_optarg ;;
+
+  -build | --build | --buil | --bui | --bu)
+    ac_prev=build_alias ;;
+  -build=* | --build=* | --buil=* | --bui=* | --bu=*)
+    build_alias=$ac_optarg ;;
+
+  -cache-file | --cache-file | --cache-fil | --cache-fi \
+  | --cache-f | --cache- | --cache | --cach | --cac | --ca | --c)
+    ac_prev=cache_file ;;
+  -cache-file=* | --cache-file=* | --cache-fil=* | --cache-fi=* \
+  | --cache-f=* | --cache-=* | --cache=* | --cach=* | --cac=* | --ca=* | --c=*)
+    cache_file=$ac_optarg ;;
+
+  --config-cache | -C)
+    cache_file=config.cache ;;
+
+  -datadir | --datadir | --datadi | --datad | --data | --dat | --da)
+    ac_prev=datadir ;;
+  -datadir=* | --datadir=* | --datadi=* | --datad=* | --data=* | --dat=* \
+  | --da=*)
+    datadir=$ac_optarg ;;
+
+  -disable-* | --disable-*)
+    ac_feature=`expr "x$ac_option" : 'x-*disable-\(.*\)'`
+    # Reject names that are not valid shell variable names.
+    expr "x$ac_feature" : ".*[^-_$as_cr_alnum]" >/dev/null &&
+      { echo "$as_me: error: invalid feature name: $ac_feature" >&2
+   { (exit 1); exit 1; }; }
+    ac_feature=`echo $ac_feature | sed 's/-/_/g'`
+    eval "enable_$ac_feature=no" ;;
+
+  -enable-* | --enable-*)
+    ac_feature=`expr "x$ac_option" : 'x-*enable-\([^=]*\)'`
+    # Reject names that are not valid shell variable names.
+    expr "x$ac_feature" : ".*[^-_$as_cr_alnum]" >/dev/null &&
+      { echo "$as_me: error: invalid feature name: $ac_feature" >&2
+   { (exit 1); exit 1; }; }
+    ac_feature=`echo $ac_feature | sed 's/-/_/g'`
+    case $ac_option in
+      *=*) ac_optarg=`echo "$ac_optarg" | sed "s/'/'\\\\\\\\''/g"`;;
+      *) ac_optarg=yes ;;
+    esac
+    eval "enable_$ac_feature='$ac_optarg'" ;;
+
+  -exec-prefix | --exec_prefix | --exec-prefix | --exec-prefi \
+  | --exec-pref | --exec-pre | --exec-pr | --exec-p | --exec- \
+  | --exec | --exe | --ex)
+    ac_prev=exec_prefix ;;
+  -exec-prefix=* | --exec_prefix=* | --exec-prefix=* | --exec-prefi=* \
+  | --exec-pref=* | --exec-pre=* | --exec-pr=* | --exec-p=* | --exec-=* \
+  | --exec=* | --exe=* | --ex=*)
+    exec_prefix=$ac_optarg ;;
+
+  -gas | --gas | --ga | --g)
+    # Obsolete; use --with-gas.
+    with_gas=yes ;;
+
+  -help | --help | --hel | --he | -h)
+    ac_init_help=long ;;
+  -help=r* | --help=r* | --hel=r* | --he=r* | -hr*)
+    ac_init_help=recursive ;;
+  -help=s* | --help=s* | --hel=s* | --he=s* | -hs*)
+    ac_init_help=short ;;
+
+  -host | --host | --hos | --ho)
+    ac_prev=host_alias ;;
+  -host=* | --host=* | --hos=* | --ho=*)
+    host_alias=$ac_optarg ;;
+
+  -includedir | --includedir | --includedi | --included | --include \
+  | --includ | --inclu | --incl | --inc)
+    ac_prev=includedir ;;
+  -includedir=* | --includedir=* | --includedi=* | --included=* | --include=* \
+  | --includ=* | --inclu=* | --incl=* | --inc=*)
+    includedir=$ac_optarg ;;
+
+  -infodir | --infodir | --infodi | --infod | --info | --inf)
+    ac_prev=infodir ;;
+  -infodir=* | --infodir=* | --infodi=* | --infod=* | --info=* | --inf=*)
+    infodir=$ac_optarg ;;
+
+  -libdir | --libdir | --libdi | --libd)
+    ac_prev=libdir ;;
+  -libdir=* | --libdir=* | --libdi=* | --libd=*)
+    libdir=$ac_optarg ;;
+
+  -libexecdir | --libexecdir | --libexecdi | --libexecd | --libexec \
+  | --libexe | --libex | --libe)
+    ac_prev=libexecdir ;;
+  -libexecdir=* | --libexecdir=* | --libexecdi=* | --libexecd=* | --libexec=* \
+  | --libexe=* | --libex=* | --libe=*)
+    libexecdir=$ac_optarg ;;
+
+  -localstatedir | --localstatedir | --localstatedi | --localstated \
+  | --localstate | --localstat | --localsta | --localst \
+  | --locals | --local | --loca | --loc | --lo)
+    ac_prev=localstatedir ;;
+  -localstatedir=* | --localstatedir=* | --localstatedi=* | --localstated=* \
+  | --localstate=* | --localstat=* | --localsta=* | --localst=* \
+  | --locals=* | --local=* | --loca=* | --loc=* | --lo=*)
+    localstatedir=$ac_optarg ;;
+
+  -mandir | --mandir | --mandi | --mand | --man | --ma | --m)
+    ac_prev=mandir ;;
+  -mandir=* | --mandir=* | --mandi=* | --mand=* | --man=* | --ma=* | --m=*)
+    mandir=$ac_optarg ;;
+
+  -nfp | --nfp | --nf)
+    # Obsolete; use --without-fp.
+    with_fp=no ;;
+
+  -no-create | --no-create | --no-creat | --no-crea | --no-cre \
+  | --no-cr | --no-c | -n)
+    no_create=yes ;;
+
+  -no-recursion | --no-recursion | --no-recursio | --no-recursi \
+  | --no-recurs | --no-recur | --no-recu | --no-rec | --no-re | --no-r)
+    no_recursion=yes ;;
+
+  -oldincludedir | --oldincludedir | --oldincludedi | --oldincluded \
+  | --oldinclude | --oldinclud | --oldinclu | --oldincl | --oldinc \
+  | --oldin | --oldi | --old | --ol | --o)
+    ac_prev=oldincludedir ;;
+  -oldincludedir=* | --oldincludedir=* | --oldincludedi=* | --oldincluded=* \
+  | --oldinclude=* | --oldinclud=* | --oldinclu=* | --oldincl=* | --oldinc=* \
+  | --oldin=* | --oldi=* | --old=* | --ol=* | --o=*)
+    oldincludedir=$ac_optarg ;;
+
+  -prefix | --prefix | --prefi | --pref | --pre | --pr | --p)
+    ac_prev=prefix ;;
+  -prefix=* | --prefix=* | --prefi=* | --pref=* | --pre=* | --pr=* | --p=*)
+    prefix=$ac_optarg ;;
+
+  -program-prefix | --program-prefix | --program-prefi | --program-pref \
+  | --program-pre | --program-pr | --program-p)
+    ac_prev=program_prefix ;;
+  -program-prefix=* | --program-prefix=* | --program-prefi=* \
+  | --program-pref=* | --program-pre=* | --program-pr=* | --program-p=*)
+    program_prefix=$ac_optarg ;;
+
+  -program-suffix | --program-suffix | --program-suffi | --program-suff \
+  | --program-suf | --program-su | --program-s)
+    ac_prev=program_suffix ;;
+  -program-suffix=* | --program-suffix=* | --program-suffi=* \
+  | --program-suff=* | --program-suf=* | --program-su=* | --program-s=*)
+    program_suffix=$ac_optarg ;;
+
+  -program-transform-name | --program-transform-name \
+  | --program-transform-nam | --program-transform-na \
+  | --program-transform-n | --program-transform- \
+  | --program-transform | --program-transfor \
+  | --program-transfo | --program-transf \
+  | --program-trans | --program-tran \
+  | --progr-tra | --program-tr | --program-t)
+    ac_prev=program_transform_name ;;
+  -program-transform-name=* | --program-transform-name=* \
+  | --program-transform-nam=* | --program-transform-na=* \
+  | --program-transform-n=* | --program-transform-=* \
+  | --program-transform=* | --program-transfor=* \
+  | --program-transfo=* | --program-transf=* \
+  | --program-trans=* | --program-tran=* \
+  | --progr-tra=* | --program-tr=* | --program-t=*)
+    program_transform_name=$ac_optarg ;;
+
+  -q | -quiet | --quiet | --quie | --qui | --qu | --q \
+  | -silent | --silent | --silen | --sile | --sil)
+    silent=yes ;;
+
+  -sbindir | --sbindir | --sbindi | --sbind | --sbin | --sbi | --sb)
+    ac_prev=sbindir ;;
+  -sbindir=* | --sbindir=* | --sbindi=* | --sbind=* | --sbin=* \
+  | --sbi=* | --sb=*)
+    sbindir=$ac_optarg ;;
+
+  -sharedstatedir | --sharedstatedir | --sharedstatedi \
+  | --sharedstated | --sharedstate | --sharedstat | --sharedsta \
+  | --sharedst | --shareds | --shared | --share | --shar \
+  | --sha | --sh)
+    ac_prev=sharedstatedir ;;
+  -sharedstatedir=* | --sharedstatedir=* | --sharedstatedi=* \
+  | --sharedstated=* | --sharedstate=* | --sharedstat=* | --sharedsta=* \
+  | --sharedst=* | --shareds=* | --shared=* | --share=* | --shar=* \
+  | --sha=* | --sh=*)
+    sharedstatedir=$ac_optarg ;;
+
+  -site | --site | --sit)
+    ac_prev=site ;;
+  -site=* | --site=* | --sit=*)
+    site=$ac_optarg ;;
+
+  -srcdir | --srcdir | --srcdi | --srcd | --src | --sr)
+    ac_prev=srcdir ;;
+  -srcdir=* | --srcdir=* | --srcdi=* | --srcd=* | --src=* | --sr=*)
+    srcdir=$ac_optarg ;;
+
+  -sysconfdir | --sysconfdir | --sysconfdi | --sysconfd | --sysconf \
+  | --syscon | --sysco | --sysc | --sys | --sy)
+    ac_prev=sysconfdir ;;
+  -sysconfdir=* | --sysconfdir=* | --sysconfdi=* | --sysconfd=* | --sysconf=* \
+  | --syscon=* | --sysco=* | --sysc=* | --sys=* | --sy=*)
+    sysconfdir=$ac_optarg ;;
+
+  -target | --target | --targe | --targ | --tar | --ta | --t)
+    ac_prev=target_alias ;;
+  -target=* | --target=* | --targe=* | --targ=* | --tar=* | --ta=* | --t=*)
+    target_alias=$ac_optarg ;;
+
+  -v | -verbose | --verbose | --verbos | --verbo | --verb)
+    verbose=yes ;;
+
+  -version | --version | --versio | --versi | --vers | -V)
+    ac_init_version=: ;;
+
+  -with-* | --with-*)
+    ac_package=`expr "x$ac_option" : 'x-*with-\([^=]*\)'`
+    # Reject names that are not valid shell variable names.
+    expr "x$ac_package" : ".*[^-_$as_cr_alnum]" >/dev/null &&
+      { echo "$as_me: error: invalid package name: $ac_package" >&2
+   { (exit 1); exit 1; }; }
+    ac_package=`echo $ac_package| sed 's/-/_/g'`
+    case $ac_option in
+      *=*) ac_optarg=`echo "$ac_optarg" | sed "s/'/'\\\\\\\\''/g"`;;
+      *) ac_optarg=yes ;;
+    esac
+    eval "with_$ac_package='$ac_optarg'" ;;
+
+  -without-* | --without-*)
+    ac_package=`expr "x$ac_option" : 'x-*without-\(.*\)'`
+    # Reject names that are not valid shell variable names.
+    expr "x$ac_package" : ".*[^-_$as_cr_alnum]" >/dev/null &&
+      { echo "$as_me: error: invalid package name: $ac_package" >&2
+   { (exit 1); exit 1; }; }
+    ac_package=`echo $ac_package | sed 's/-/_/g'`
+    eval "with_$ac_package=no" ;;
+
+  --x)
+    # Obsolete; use --with-x.
+    with_x=yes ;;
+
+  -x-includes | --x-includes | --x-include | --x-includ | --x-inclu \
+  | --x-incl | --x-inc | --x-in | --x-i)
+    ac_prev=x_includes ;;
+  -x-includes=* | --x-includes=* | --x-include=* | --x-includ=* | --x-inclu=* \
+  | --x-incl=* | --x-inc=* | --x-in=* | --x-i=*)
+    x_includes=$ac_optarg ;;
+
+  -x-libraries | --x-libraries | --x-librarie | --x-librari \
+  | --x-librar | --x-libra | --x-libr | --x-lib | --x-li | --x-l)
+    ac_prev=x_libraries ;;
+  -x-libraries=* | --x-libraries=* | --x-librarie=* | --x-librari=* \
+  | --x-librar=* | --x-libra=* | --x-libr=* | --x-lib=* | --x-li=* | --x-l=*)
+    x_libraries=$ac_optarg ;;
+
+  -*) { echo "$as_me: error: unrecognized option: $ac_option
+Try \`$0 --help' for more information." >&2
+   { (exit 1); exit 1; }; }
+    ;;
+
+  *=*)
+    ac_envvar=`expr "x$ac_option" : 'x\([^=]*\)='`
+    # Reject names that are not valid shell variable names.
+    expr "x$ac_envvar" : ".*[^_$as_cr_alnum]" >/dev/null &&
+      { echo "$as_me: error: invalid variable name: $ac_envvar" >&2
+   { (exit 1); exit 1; }; }
+    ac_optarg=`echo "$ac_optarg" | sed "s/'/'\\\\\\\\''/g"`
+    eval "$ac_envvar='$ac_optarg'"
+    export $ac_envvar ;;
+
+  *)
+    # FIXME: should be removed in autoconf 3.0.
+    echo "$as_me: WARNING: you should use --build, --host, --target" >&2
+    expr "x$ac_option" : ".*[^-._$as_cr_alnum]" >/dev/null &&
+      echo "$as_me: WARNING: invalid host type: $ac_option" >&2
+    : ${build_alias=$ac_option} ${host_alias=$ac_option} ${target_alias=$ac_option}
+    ;;
+
+  esac
+done
+
+if test -n "$ac_prev"; then
+  ac_option=--`echo $ac_prev | sed 's/_/-/g'`
+  { echo "$as_me: error: missing argument to $ac_option" >&2
+   { (exit 1); exit 1; }; }
+fi
+
+# Be sure to have absolute paths.
+for ac_var in exec_prefix prefix
+do
+  eval ac_val=$`echo $ac_var`
+  case $ac_val in
+    [\\/$]* | ?:[\\/]* | NONE | '' ) ;;
+    *)  { echo "$as_me: error: expected an absolute directory name for --$ac_var: $ac_val" >&2
+   { (exit 1); exit 1; }; };;
+  esac
+done
+
+# Be sure to have absolute paths.
+for ac_var in bindir sbindir libexecdir datadir sysconfdir sharedstatedir \
+             localstatedir libdir includedir oldincludedir infodir mandir
+do
+  eval ac_val=$`echo $ac_var`
+  case $ac_val in
+    [\\/$]* | ?:[\\/]* ) ;;
+    *)  { echo "$as_me: error: expected an absolute directory name for --$ac_var: $ac_val" >&2
+   { (exit 1); exit 1; }; };;
+  esac
+done
+
+# There might be people who depend on the old broken behavior: `$host'
+# used to hold the argument of --host etc.
+# FIXME: To remove some day.
+build=$build_alias
+host=$host_alias
+target=$target_alias
+
+# FIXME: To remove some day.
+if test "x$host_alias" != x; then
+  if test "x$build_alias" = x; then
+    cross_compiling=maybe
+    echo "$as_me: WARNING: If you wanted to set the --build type, don't use --host.
+    If a cross compiler is detected then cross compile mode will be used." >&2
+  elif test "x$build_alias" != "x$host_alias"; then
+    cross_compiling=yes
+  fi
+fi
+
+ac_tool_prefix=
+test -n "$host_alias" && ac_tool_prefix=$host_alias-
+
+test "$silent" = yes && exec 6>/dev/null
+
+
+# Find the source files, if location was not specified.
+if test -z "$srcdir"; then
+  ac_srcdir_defaulted=yes
+  # Try the directory containing this script, then its parent.
+  ac_confdir=`(dirname "$0") 2>/dev/null ||
+$as_expr X"$0" : 'X\(.*[^/]\)//*[^/][^/]*/*$' \| \
+        X"$0" : 'X\(//\)[^/]' \| \
+        X"$0" : 'X\(//\)$' \| \
+        X"$0" : 'X\(/\)' \| \
+        .     : '\(.\)' 2>/dev/null ||
+echo X"$0" |
+    sed '/^X\(.*[^/]\)\/\/*[^/][^/]*\/*$/{ s//\1/; q; }
+         /^X\(\/\/\)[^/].*/{ s//\1/; q; }
+         /^X\(\/\/\)$/{ s//\1/; q; }
+         /^X\(\/\).*/{ s//\1/; q; }
+         s/.*/./; q'`
+  srcdir=$ac_confdir
+  if test ! -r $srcdir/$ac_unique_file; then
+    srcdir=..
+  fi
+else
+  ac_srcdir_defaulted=no
+fi
+if test ! -r $srcdir/$ac_unique_file; then
+  if test "$ac_srcdir_defaulted" = yes; then
+    { echo "$as_me: error: cannot find sources ($ac_unique_file) in $ac_confdir or .." >&2
+   { (exit 1); exit 1; }; }
+  else
+    { echo "$as_me: error: cannot find sources ($ac_unique_file) in $srcdir" >&2
+   { (exit 1); exit 1; }; }
+  fi
+fi
+(cd $srcdir && test -r ./$ac_unique_file) 2>/dev/null ||
+  { echo "$as_me: error: sources are in $srcdir, but \`cd $srcdir' does not work" >&2
+   { (exit 1); exit 1; }; }
+srcdir=`echo "$srcdir" | sed 's%\([^\\/]\)[\\/]*$%\1%'`
+ac_env_build_alias_set=${build_alias+set}
+ac_env_build_alias_value=$build_alias
+ac_cv_env_build_alias_set=${build_alias+set}
+ac_cv_env_build_alias_value=$build_alias
+ac_env_host_alias_set=${host_alias+set}
+ac_env_host_alias_value=$host_alias
+ac_cv_env_host_alias_set=${host_alias+set}
+ac_cv_env_host_alias_value=$host_alias
+ac_env_target_alias_set=${target_alias+set}
+ac_env_target_alias_value=$target_alias
+ac_cv_env_target_alias_set=${target_alias+set}
+ac_cv_env_target_alias_value=$target_alias
+ac_env_CC_set=${CC+set}
+ac_env_CC_value=$CC
+ac_cv_env_CC_set=${CC+set}
+ac_cv_env_CC_value=$CC
+ac_env_CFLAGS_set=${CFLAGS+set}
+ac_env_CFLAGS_value=$CFLAGS
+ac_cv_env_CFLAGS_set=${CFLAGS+set}
+ac_cv_env_CFLAGS_value=$CFLAGS
+ac_env_LDFLAGS_set=${LDFLAGS+set}
+ac_env_LDFLAGS_value=$LDFLAGS
+ac_cv_env_LDFLAGS_set=${LDFLAGS+set}
+ac_cv_env_LDFLAGS_value=$LDFLAGS
+ac_env_CPPFLAGS_set=${CPPFLAGS+set}
+ac_env_CPPFLAGS_value=$CPPFLAGS
+ac_cv_env_CPPFLAGS_set=${CPPFLAGS+set}
+ac_cv_env_CPPFLAGS_value=$CPPFLAGS
+ac_env_CPP_set=${CPP+set}
+ac_env_CPP_value=$CPP
+ac_cv_env_CPP_set=${CPP+set}
+ac_cv_env_CPP_value=$CPP
+ac_env_YACC_set=${YACC+set}
+ac_env_YACC_value=$YACC
+ac_cv_env_YACC_set=${YACC+set}
+ac_cv_env_YACC_value=$YACC
+ac_env_YFLAGS_set=${YFLAGS+set}
+ac_env_YFLAGS_value=$YFLAGS
+ac_cv_env_YFLAGS_set=${YFLAGS+set}
+ac_cv_env_YFLAGS_value=$YFLAGS
+ac_env_EDITOR_set=${EDITOR+set}
+ac_env_EDITOR_value=$EDITOR
+ac_cv_env_EDITOR_set=${EDITOR+set}
+ac_cv_env_EDITOR_value=$EDITOR
+
+#
+# Report the --help message.
+#
+if test "$ac_init_help" = "long"; then
+  # Omit some internal or obsolete options to make the list less imposing.
+  # This message is too long to be a string in the A/UX 3.1 sh.
+  cat <<_ACEOF
+\`configure' configures Concurrent Versions System (CVS) 1.12.9 to adapt to many kinds of systems.
+
+Usage: $0 [OPTION]... [VAR=VALUE]...
+
+To assign environment variables (e.g., CC, CFLAGS...), specify them as
+VAR=VALUE.  See below for descriptions of some of the useful variables.
+
+Defaults for the options are specified in brackets.
+
+Configuration:
+  -h, --help              display this help and exit
+      --help=short        display options specific to this package
+      --help=recursive    display the short help of all the included packages
+  -V, --version           display version information and exit
+  -q, --quiet, --silent   do not print \`checking...' messages
+      --cache-file=FILE   cache test results in FILE [disabled]
+  -C, --config-cache      alias for \`--cache-file=config.cache'
+  -n, --no-create         do not create output files
+      --srcdir=DIR        find the sources in DIR [configure dir or \`..']
+
+_ACEOF
+
+  cat <<_ACEOF
+Installation directories:
+  --prefix=PREFIX         install architecture-independent files in PREFIX
+                         [$ac_default_prefix]
+  --exec-prefix=EPREFIX   install architecture-dependent files in EPREFIX
+                         [PREFIX]
+
+By default, \`make install' will install all the files in
+\`$ac_default_prefix/bin', \`$ac_default_prefix/lib' etc.  You can specify
+an installation prefix other than \`$ac_default_prefix' using \`--prefix',
+for instance \`--prefix=\$HOME'.
+
+For better control, use the options below.
+
+Fine tuning of the installation directories:
+  --bindir=DIR           user executables [EPREFIX/bin]
+  --sbindir=DIR          system admin executables [EPREFIX/sbin]
+  --libexecdir=DIR       program executables [EPREFIX/libexec]
+  --datadir=DIR          read-only architecture-independent data [PREFIX/share]
+  --sysconfdir=DIR       read-only single-machine data [PREFIX/etc]
+  --sharedstatedir=DIR   modifiable architecture-independent data [PREFIX/com]
+  --localstatedir=DIR    modifiable single-machine data [PREFIX/var]
+  --libdir=DIR           object code libraries [EPREFIX/lib]
+  --includedir=DIR       C header files [PREFIX/include]
+  --oldincludedir=DIR    C header files for non-gcc [/usr/include]
+  --infodir=DIR          info documentation [PREFIX/info]
+  --mandir=DIR           man documentation [PREFIX/man]
+_ACEOF
+
+  cat <<\_ACEOF
+
+Program names:
+  --program-prefix=PREFIX            prepend PREFIX to installed program names
+  --program-suffix=SUFFIX            append SUFFIX to installed program names
+  --program-transform-name=PROGRAM   run sed PROGRAM on installed program names
+
+System types:
+  --build=BUILD     configure for building on BUILD [guessed]
+  --host=HOST       cross-compile to build programs to run on HOST [BUILD]
+_ACEOF
+fi
+
+if test -n "$ac_init_help"; then
+  case $ac_init_help in
+     short | recursive ) echo "Configuration of Concurrent Versions System (CVS) 1.12.9:";;
+   esac
+  cat <<\_ACEOF
+
+Optional Features:
+  --disable-FEATURE       do not include FEATURE (same as --enable-FEATURE=no)
+  --enable-FEATURE[=ARG]  include FEATURE [ARG=yes]
+  --enable-maintainer-mode enable make rules and dependencies not useful
+                          (and sometimes confusing) to the casual installer
+  --disable-dependency-tracking Speeds up one-time builds
+  --enable-dependency-tracking  Do not reject slow dependency extractors
+  --disable-largefile     omit support for large files
+  --disable-nls           do not use Native Language Support
+  --disable-rpath         do not hardcode runtime library paths
+  --enable-cvs-ndbm       Use the NDBM library distributed with CVS rather
+                          than attempting to use a system NDBM library.
+                          Disabling this may not work. (default)
+  --enable-client         Include code for running as a remote client
+                          (default)
+  --enable-password-authenticated-client
+                          Enable pserver as a remote access method in the CVS
+                          client (default)
+  --enable-server         Include code for running as a server (default)
+  --enable-server-flow-control
+                          If you are working with a large remote repository
+                          and a 'cvs checkout' is swamping your network and
+                          memory, define these to enable flow control. You may
+                          optionally pass a low water mark in bytes and a high
+                          water mark in bytes, separated by commas. (default
+                          is enabled 1M,2M)
+  --enable-pam            Use to enable system authentication with PAM instead
+                          of using the simple getpwnam interface. This allows
+                          authentication (in theory) with any PAM module, e.g.
+                          on systems with shadow passwords or via LDAP
+  --enable-case-sensitivity
+                          Force CVS to expect a case sensitive file system.
+                          Enabling this on a case insensitive system should
+                          have little effect on the server or client
+                          operation, though client users may ocassionally be
+                          suprised that the CVS server appears to be case
+                          sensitive. Disabling this for a case sensitive
+                          server disables server support for case insensitive
+                          clients, which can confuse all users of case
+                          insensitive clients contacting the server. Disabling
+                          this for a case sensitive client will cause the
+                          client to ask servers to behave case insensitively,
+                          which could cause confusion for users, but also
+                          probably no real harm. (default autoselects based on
+                          the case sensitivity of the file system containing
+                          the current working directory)
+  --enable-encryption     Enable encryption support (disabled by default)
+  --enable-force-editor   When committing or importing files, you must enter a
+                          log message. Normally, you can do this either via
+                          the -m flag on the command line, the -F flag on the
+                          command line, or an editor will be started for you.
+                          If you like to use logging templates (the rcsinfo
+                          file within the $CVSROOT/CVSROOT directory), you
+                          might want to force people to use the editor even if
+                          they specify a message with -m or -F.
+                          --enable-force-editor will cause the -m or -F
+                          message to be appended to the temp file when the
+                          editor is started. (disabled by default)
+  --enable-lock-compatibility
+                          Include locking code which prevents versions of CVS
+                          earlier than 1.12.4 directly accessing the same
+                          repositiory as this executable from ignoring this
+                          executable's promotable read locks. If only CVS
+                          versions 1.12.4 and later will be accessing your
+                          repository directly (as a server or locally), you
+                          can safely disable this option in return for fewer
+                          disk accesses and a small speed increase. Disabling
+                          this option when versions of CVS earlier than 1,12,4
+                          _will_ be accessing your repository, however, is
+                          *VERY* *VERY* *VERY* dangerous and could result in
+                          data loss. (enabled by default)
+  --enable-rootcommit     Allow the root user to commit files (disabled by
+                          default)
+  --enable-old-info-format-support
+                          Enable support for the pre 1.12.1 *info scripting
+                          hook format strings. Disable this option for a
+                          smaller executable once your scripting hooks have
+                          been updated to use the new *info format strings
+                          (default).
+
+Optional Packages:
+  --with-PACKAGE[=ARG]    use PACKAGE [ARG=yes]
+  --without-PACKAGE       do not use PACKAGE (same as --with-PACKAGE=no)
+  --with-gnu-ld           assume the C compiler uses GNU ld default=no
+  --with-libiconv-prefix=DIR  search for libiconv in DIR/include and DIR/lib
+  --without-libiconv-prefix     don't search for libiconv in includedir and libdir
+  --with-libintl-prefix=DIR  search for libintl in DIR/include and DIR/lib
+  --without-libintl-prefix     don't search for libintl in includedir and libdir
+  --without-included-regex don't compile regex; this is the default on
+                          systems with version 2 of the GNU C library
+                          (use with caution on other system)
+  --with-krb4             Kerberos 4 directory (default /usr/kerberos)
+  --with-gssapi           GSSAPI directory (default autoselects)
+  --with-external-zlib    Use the specified ZLIB library (defaults to the
+                          version distributed with the CVS source)
+  --with-rsh              The default remote shell CVS will use for :ext:
+                          transport (default rsh)
+  --with-editor           The default text editor CVS should use for log
+                          messages (default autoselects)
+  --with-hardcoded-pam-service-name
+                          Use this to hard code a service name for PAM CVS
+                          authentication. The special name, `program_name',
+                          will cause CVS to use whatever name it was invoked
+                          as as the service name. (defaults to `cvs')
+  --with-tmpdir           The temporary directory CVS should use as a default
+                          (default autoselects)
+  --with-umask            Set the umask CVS will use by default in the
+                          repository (default 002)
+  --with-cvs-admin-group=GROUP
+                          The CVS admin command is restricted to the members
+                          of this group. If this group does not exist, all
+                          users are allowed to run CVS admin. To disable the
+                          CVS admin command for all users, create an empty
+                          group by specifying the --with-cvs-admin-group=
+                          option. To disable access control for CVS admin, run
+                          configure with the --without-cvs-admin-group option.
+                          (default 'cvsadmin')
+
+Some influential environment variables:
+  CC          C compiler command
+  CFLAGS      C compiler flags
+  LDFLAGS     linker flags, e.g. -L<lib dir> if you have libraries in a
+              nonstandard directory <lib dir>
+  CPPFLAGS    C/C++ preprocessor flags, e.g. -I<include dir> if you have
+              headers in a nonstandard directory <include dir>
+  CPP         C preprocessor
+  YACC        The `Yet Another C Compiler' implementation to use. Defaults to
+              `bison -y'. Values other than `bison -y' will most likely break
+              on most systems.
+  YFLAGS      YFLAGS contains the list arguments that will be passed by
+              default to Bison. This script will default YFLAGS to the empty
+              string to avoid a default value of `-d' given by some make
+              applications.
+  EDITOR      The text editor CVS will use by default for log messages.
+
+Use these variables to override the choices made by `configure' or to help
+it to find libraries and programs with nonstandard names/locations.
+
+Report bugs to <bug-cvs@gnu.org>.
+_ACEOF
+fi
+
+if test "$ac_init_help" = "recursive"; then
+  # If there are subdirs, report their specific --help.
+  ac_popdir=`pwd`
+  for ac_dir in : $ac_subdirs_all; do test "x$ac_dir" = x: && continue
+    test -d $ac_dir || continue
+    ac_builddir=.
+
+if test "$ac_dir" != .; then
+  ac_dir_suffix=/`echo "$ac_dir" | sed 's,^\.[\\/],,'`
+  # A "../" for each directory in $ac_dir_suffix.
+  ac_top_builddir=`echo "$ac_dir_suffix" | sed 's,/[^\\/]*,../,g'`
+else
+  ac_dir_suffix= ac_top_builddir=
+fi
+
+case $srcdir in
+  .)  # No --srcdir option.  We are building in place.
+    ac_srcdir=.
+    if test -z "$ac_top_builddir"; then
+       ac_top_srcdir=.
+    else
+       ac_top_srcdir=`echo $ac_top_builddir | sed 's,/$,,'`
+    fi ;;
+  [\\/]* | ?:[\\/]* )  # Absolute path.
+    ac_srcdir=$srcdir$ac_dir_suffix;
+    ac_top_srcdir=$srcdir ;;
+  *) # Relative path.
+    ac_srcdir=$ac_top_builddir$srcdir$ac_dir_suffix
+    ac_top_srcdir=$ac_top_builddir$srcdir ;;
+esac
+case "$ac_dir" in
+.) ac_abs_builddir=$ac_builddir;;
+*)
+  case $ac_builddir in
+  .) ac_abs_builddir="$ac_dir";;
+  [\\/]* | ?:[\\/]* ) ac_abs_builddir=$ac_builddir;;
+  *) ac_abs_builddir="$ac_dir"/$ac_builddir;;
+  esac;;
+esac
+case "$ac_dir" in
+.) ac_abs_top_builddir=${ac_top_builddir}.;;
+*)
+  case ${ac_top_builddir}. in
+  .) ac_abs_top_builddir="$ac_dir";;
+  [\\/]* | ?:[\\/]* ) ac_abs_top_builddir=${ac_top_builddir}.;;
+  *) ac_abs_top_builddir="$ac_dir"/${ac_top_builddir}.;;
+  esac;;
+esac
+case "$ac_dir" in
+.) ac_abs_srcdir=$ac_srcdir;;
+*)
+  case $ac_srcdir in
+  .) ac_abs_srcdir="$ac_dir";;
+  [\\/]* | ?:[\\/]* ) ac_abs_srcdir=$ac_srcdir;;
+  *) ac_abs_srcdir="$ac_dir"/$ac_srcdir;;
+  esac;;
+esac
+case "$ac_dir" in
+.) ac_abs_top_srcdir=$ac_top_srcdir;;
+*)
+  case $ac_top_srcdir in
+  .) ac_abs_top_srcdir="$ac_dir";;
+  [\\/]* | ?:[\\/]* ) ac_abs_top_srcdir=$ac_top_srcdir;;
+  *) ac_abs_top_srcdir="$ac_dir"/$ac_top_srcdir;;
+  esac;;
+esac
+
+    cd $ac_dir
+    # Check for guested configure; otherwise get Cygnus style configure.
+    if test -f $ac_srcdir/configure.gnu; then
+      echo
+      $SHELL $ac_srcdir/configure.gnu  --help=recursive
+    elif test -f $ac_srcdir/configure; then
+      echo
+      $SHELL $ac_srcdir/configure  --help=recursive
+    elif test -f $ac_srcdir/configure.ac ||
+          test -f $ac_srcdir/configure.in; then
+      echo
+      $ac_configure --help
+    else
+      echo "$as_me: WARNING: no configuration information is in $ac_dir" >&2
+    fi
+    cd $ac_popdir
+  done
+fi
+
+test -n "$ac_init_help" && exit 0
+if $ac_init_version; then
+  cat <<\_ACEOF
+Concurrent Versions System (CVS) configure 1.12.9
+generated by GNU Autoconf 2.58
+
+Copyright (C) 2003 Free Software Foundation, Inc.
+This configure script is free software; the Free Software Foundation
+gives unlimited permission to copy, distribute and modify it.
+
+Copyright (C) 1986, 1987, 1988, 1989, 1990, 1991, 1992, 1993, 1994, 1995,
+              1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003
+              Free Software Foundation, Inc.
+
+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, 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.
+_ACEOF
+  exit 0
+fi
+exec 5>config.log
+cat >&5 <<_ACEOF
+This file contains any messages produced by compilers while
+running configure, to aid debugging if configure makes a mistake.
+
+It was created by Concurrent Versions System (CVS) $as_me 1.12.9, which was
+generated by GNU Autoconf 2.58.  Invocation command line was
+
+  $ $0 $@
+
+_ACEOF
+{
+cat <<_ASUNAME
+## --------- ##
+## Platform. ##
+## --------- ##
+
+hostname = `(hostname || uname -n) 2>/dev/null | sed 1q`
+uname -m = `(uname -m) 2>/dev/null || echo unknown`
+uname -r = `(uname -r) 2>/dev/null || echo unknown`
+uname -s = `(uname -s) 2>/dev/null || echo unknown`
+uname -v = `(uname -v) 2>/dev/null || echo unknown`
+
+/usr/bin/uname -p = `(/usr/bin/uname -p) 2>/dev/null || echo unknown`
+/bin/uname -X     = `(/bin/uname -X) 2>/dev/null     || echo unknown`
+
+/bin/arch              = `(/bin/arch) 2>/dev/null              || echo unknown`
+/usr/bin/arch -k       = `(/usr/bin/arch -k) 2>/dev/null       || echo unknown`
+/usr/convex/getsysinfo = `(/usr/convex/getsysinfo) 2>/dev/null || echo unknown`
+hostinfo               = `(hostinfo) 2>/dev/null               || echo unknown`
+/bin/machine           = `(/bin/machine) 2>/dev/null           || echo unknown`
+/usr/bin/oslevel       = `(/usr/bin/oslevel) 2>/dev/null       || echo unknown`
+/bin/universe          = `(/bin/universe) 2>/dev/null          || echo unknown`
+
+_ASUNAME
+
+as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
+for as_dir in $PATH
+do
+  IFS=$as_save_IFS
+  test -z "$as_dir" && as_dir=.
+  echo "PATH: $as_dir"
+done
+
+} >&5
+
+cat >&5 <<_ACEOF
+
+
+## ----------- ##
+## Core tests. ##
+## ----------- ##
+
+_ACEOF
+
+
+# Keep a trace of the command line.
+# Strip out --no-create and --no-recursion so they do not pile up.
+# Strip out --silent because we don't want to record it for future runs.
+# Also quote any args containing shell meta-characters.
+# Make two passes to allow for proper duplicate-argument suppression.
+ac_configure_args=
+ac_configure_args0=
+ac_configure_args1=
+ac_sep=
+ac_must_keep_next=false
+for ac_pass in 1 2
+do
+  for ac_arg
+  do
+    case $ac_arg in
+    -no-create | --no-c* | -n | -no-recursion | --no-r*) continue ;;
+    -q | -quiet | --quiet | --quie | --qui | --qu | --q \
+    | -silent | --silent | --silen | --sile | --sil)
+      continue ;;
+    *" "*|*"   "*|*[\[\]\~\#\$\^\&\*\(\)\{\}\\\|\;\<\>\?\"\']*)
+      ac_arg=`echo "$ac_arg" | sed "s/'/'\\\\\\\\''/g"` ;;
+    esac
+    case $ac_pass in
+    1) ac_configure_args0="$ac_configure_args0 '$ac_arg'" ;;
+    2)
+      ac_configure_args1="$ac_configure_args1 '$ac_arg'"
+      if test $ac_must_keep_next = true; then
+       ac_must_keep_next=false # Got value, back to normal.
+      else
+       case $ac_arg in
+         *=* | --config-cache | -C | -disable-* | --disable-* \
+         | -enable-* | --enable-* | -gas | --g* | -nfp | --nf* \
+         | -q | -quiet | --q* | -silent | --sil* | -v | -verb* \
+         | -with-* | --with-* | -without-* | --without-* | --x)
+           case "$ac_configure_args0 " in
+             "$ac_configure_args1"*" '$ac_arg' "* ) continue ;;
+           esac
+           ;;
+         -* ) ac_must_keep_next=true ;;
+       esac
+      fi
+      ac_configure_args="$ac_configure_args$ac_sep'$ac_arg'"
+      # Get rid of the leading space.
+      ac_sep=" "
+      ;;
+    esac
+  done
+done
+$as_unset ac_configure_args0 || test "${ac_configure_args0+set}" != set || { ac_configure_args0=; export ac_configure_args0; }
+$as_unset ac_configure_args1 || test "${ac_configure_args1+set}" != set || { ac_configure_args1=; export ac_configure_args1; }
+
+# When interrupted or exit'd, cleanup temporary files, and complete
+# config.log.  We remove comments because anyway the quotes in there
+# would cause problems or look ugly.
+# WARNING: Be sure not to use single quotes in there, as some shells,
+# such as our DU 5.0 friend, will then `close' the trap.
+trap 'exit_status=$?
+  # Save into config.log some information that might help in debugging.
+  {
+    echo
+
+    cat <<\_ASBOX
+## ---------------- ##
+## Cache variables. ##
+## ---------------- ##
+_ASBOX
+    echo
+    # The following way of writing the cache mishandles newlines in values,
+{
+  (set) 2>&1 |
+    case `(ac_space='"'"' '"'"'; set | grep ac_space) 2>&1` in
+    *ac_space=\ *)
+      sed -n \
+       "s/'"'"'/'"'"'\\\\'"'"''"'"'/g;
+         s/^\\([_$as_cr_alnum]*_cv_[_$as_cr_alnum]*\\)=\\(.*\\)/\\1='"'"'\\2'"'"'/p"
+      ;;
+    *)
+      sed -n \
+       "s/^\\([_$as_cr_alnum]*_cv_[_$as_cr_alnum]*\\)=\\(.*\\)/\\1=\\2/p"
+      ;;
+    esac;
+}
+    echo
+
+    cat <<\_ASBOX
+## ----------------- ##
+## Output variables. ##
+## ----------------- ##
+_ASBOX
+    echo
+    for ac_var in $ac_subst_vars
+    do
+      eval ac_val=$`echo $ac_var`
+      echo "$ac_var='"'"'$ac_val'"'"'"
+    done | sort
+    echo
+
+    if test -n "$ac_subst_files"; then
+      cat <<\_ASBOX
+## ------------- ##
+## Output files. ##
+## ------------- ##
+_ASBOX
+      echo
+      for ac_var in $ac_subst_files
+      do
+       eval ac_val=$`echo $ac_var`
+       echo "$ac_var='"'"'$ac_val'"'"'"
+      done | sort
+      echo
+    fi
+
+    if test -s confdefs.h; then
+      cat <<\_ASBOX
+## ----------- ##
+## confdefs.h. ##
+## ----------- ##
+_ASBOX
+      echo
+      sed "/^$/d" confdefs.h | sort
+      echo
+    fi
+    test "$ac_signal" != 0 &&
+      echo "$as_me: caught signal $ac_signal"
+    echo "$as_me: exit $exit_status"
+  } >&5
+  rm -f core *.core &&
+  rm -rf conftest* confdefs* conf$$* $ac_clean_files &&
+    exit $exit_status
+     ' 0
+for ac_signal in 1 2 13 15; do
+  trap 'ac_signal='$ac_signal'; { (exit 1); exit 1; }' $ac_signal
+done
+ac_signal=0
+
+# confdefs.h avoids OS command line length limits that DEFS can exceed.
+rm -rf conftest* confdefs.h
+# AIX cpp loses on an empty file, so make sure it contains at least a newline.
+echo >confdefs.h
+
+# Predefined preprocessor variables.
+
+cat >>confdefs.h <<_ACEOF
+#define PACKAGE_NAME "$PACKAGE_NAME"
+_ACEOF
+
+
+cat >>confdefs.h <<_ACEOF
+#define PACKAGE_TARNAME "$PACKAGE_TARNAME"
+_ACEOF
+
+
+cat >>confdefs.h <<_ACEOF
+#define PACKAGE_VERSION "$PACKAGE_VERSION"
+_ACEOF
+
+
+cat >>confdefs.h <<_ACEOF
+#define PACKAGE_STRING "$PACKAGE_STRING"
+_ACEOF
+
+
+cat >>confdefs.h <<_ACEOF
+#define PACKAGE_BUGREPORT "$PACKAGE_BUGREPORT"
+_ACEOF
+
+
+# Let the site file select an alternate cache file if it wants to.
+# Prefer explicitly selected file to automatically selected ones.
+if test -z "$CONFIG_SITE"; then
+  if test "x$prefix" != xNONE; then
+    CONFIG_SITE="$prefix/share/config.site $prefix/etc/config.site"
+  else
+    CONFIG_SITE="$ac_default_prefix/share/config.site $ac_default_prefix/etc/config.site"
+  fi
+fi
+for ac_site_file in $CONFIG_SITE; do
+  if test -r "$ac_site_file"; then
+    { echo "$as_me:$LINENO: loading site script $ac_site_file" >&5
+echo "$as_me: loading site script $ac_site_file" >&6;}
+    sed 's/^/| /' "$ac_site_file" >&5
+    . "$ac_site_file"
+  fi
+done
+
+if test -r "$cache_file"; then
+  # Some versions of bash will fail to source /dev/null (special
+  # files actually), so we avoid doing that.
+  if test -f "$cache_file"; then
+    { echo "$as_me:$LINENO: loading cache $cache_file" >&5
+echo "$as_me: loading cache $cache_file" >&6;}
+    case $cache_file in
+      [\\/]* | ?:[\\/]* ) . $cache_file;;
+      *)                      . ./$cache_file;;
+    esac
+  fi
+else
+  { echo "$as_me:$LINENO: creating cache $cache_file" >&5
+echo "$as_me: creating cache $cache_file" >&6;}
+  >$cache_file
+fi
+
+# Check that the precious variables saved in the cache have kept the same
+# value.
+ac_cache_corrupted=false
+for ac_var in `(set) 2>&1 |
+              sed -n 's/^ac_env_\([a-zA-Z_0-9]*\)_set=.*/\1/p'`; do
+  eval ac_old_set=\$ac_cv_env_${ac_var}_set
+  eval ac_new_set=\$ac_env_${ac_var}_set
+  eval ac_old_val="\$ac_cv_env_${ac_var}_value"
+  eval ac_new_val="\$ac_env_${ac_var}_value"
+  case $ac_old_set,$ac_new_set in
+    set,)
+      { echo "$as_me:$LINENO: error: \`$ac_var' was set to \`$ac_old_val' in the previous run" >&5
+echo "$as_me: error: \`$ac_var' was set to \`$ac_old_val' in the previous run" >&2;}
+      ac_cache_corrupted=: ;;
+    ,set)
+      { echo "$as_me:$LINENO: error: \`$ac_var' was not set in the previous run" >&5
+echo "$as_me: error: \`$ac_var' was not set in the previous run" >&2;}
+      ac_cache_corrupted=: ;;
+    ,);;
+    *)
+      if test "x$ac_old_val" != "x$ac_new_val"; then
+       { echo "$as_me:$LINENO: error: \`$ac_var' has changed since the previous run:" >&5
+echo "$as_me: error: \`$ac_var' has changed since the previous run:" >&2;}
+       { echo "$as_me:$LINENO:   former value:  $ac_old_val" >&5
+echo "$as_me:   former value:  $ac_old_val" >&2;}
+       { echo "$as_me:$LINENO:   current value: $ac_new_val" >&5
+echo "$as_me:   current value: $ac_new_val" >&2;}
+       ac_cache_corrupted=:
+      fi;;
+  esac
+  # Pass precious variables to config.status.
+  if test "$ac_new_set" = set; then
+    case $ac_new_val in
+    *" "*|*"   "*|*[\[\]\~\#\$\^\&\*\(\)\{\}\\\|\;\<\>\?\"\']*)
+      ac_arg=$ac_var=`echo "$ac_new_val" | sed "s/'/'\\\\\\\\''/g"` ;;
+    *) ac_arg=$ac_var=$ac_new_val ;;
+    esac
+    case " $ac_configure_args " in
+      *" '$ac_arg' "*) ;; # Avoid dups.  Use of quotes ensures accuracy.
+      *) ac_configure_args="$ac_configure_args '$ac_arg'" ;;
+    esac
+  fi
+done
+if $ac_cache_corrupted; then
+  { echo "$as_me:$LINENO: error: changes in the environment can compromise the build" >&5
+echo "$as_me: error: changes in the environment can compromise the build" >&2;}
+  { { echo "$as_me:$LINENO: error: run \`make distclean' and/or \`rm $cache_file' and start over" >&5
+echo "$as_me: error: run \`make distclean' and/or \`rm $cache_file' and start over" >&2;}
+   { (exit 1); exit 1; }; }
+fi
+
+ac_ext=c
+ac_cpp='$CPP $CPPFLAGS'
+ac_compile='$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >&5'
+ac_link='$CC -o conftest$ac_exeext $CFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS >&5'
+ac_compiler_gnu=$ac_cv_c_compiler_gnu
+
+
+gl_header_list="$gl_header_list fcntl.h"
+gl_header_list="$gl_header_list sys/time.h"
+gl_header_list="$gl_header_list unistd.h"
+gl_func_list="$gl_func_list mempcpy"
+gl_func_list="$gl_func_list isascii"
+gl_func_list="$gl_func_list gettimeofday"
+gl_header_list="$gl_header_list sys/param.h"
+gl_header_list="$gl_header_list wchar.h"
+gl_header_list="$gl_header_list wctype.h"
+gl_header_list="$gl_header_list stdlib.h"
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+am__api_version="1.7"
+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
+  elif test -f $ac_dir/shtool; then
+    ac_aux_dir=$ac_dir
+    ac_install_sh="$ac_aux_dir/shtool install -c"
+    break
+  fi
+done
+if test -z "$ac_aux_dir"; then
+  { { echo "$as_me:$LINENO: error: cannot find install-sh or install.sh in $srcdir $srcdir/.. $srcdir/../.." >&5
+echo "$as_me: error: cannot find install-sh or install.sh in $srcdir $srcdir/.. $srcdir/../.." >&2;}
+   { (exit 1); exit 1; }; }
+fi
+ac_config_guess="$SHELL $ac_aux_dir/config.guess"
+ac_config_sub="$SHELL $ac_aux_dir/config.sub"
+ac_configure="$SHELL $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
+# AmigaOS /C/install, which installs bootblocks on floppy discs
+# 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"
+# OS/2's system install, which has a completely different semantic
+# ./install, which can be erroneously created by make from ./install.sh.
+echo "$as_me:$LINENO: checking for a BSD-compatible install" >&5
+echo $ECHO_N "checking for a BSD-compatible install... $ECHO_C" >&6
+if test -z "$INSTALL"; then
+if test "${ac_cv_path_install+set}" = set; then
+  echo $ECHO_N "(cached) $ECHO_C" >&6
+else
+  as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
+for as_dir in $PATH
+do
+  IFS=$as_save_IFS
+  test -z "$as_dir" && as_dir=.
+  # Account for people who put trailing slashes in PATH elements.
+case $as_dir/ in
+  ./ | .// | /cC/* | \
+  /etc/* | /usr/sbin/* | /usr/etc/* | /sbin/* | /usr/afsws/bin/* | \
+  ?:\\/os2\\/install\\/* | ?:\\/OS2\\/INSTALL\\/* | \
+  /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
+      for ac_exec_ext in '' $ac_executable_extensions; do
+       if $as_executable_p "$as_dir/$ac_prog$ac_exec_ext"; then
+         if test $ac_prog = install &&
+           grep dspmsg "$as_dir/$ac_prog$ac_exec_ext" >/dev/null 2>&1; then
+           # AIX install.  It has an incompatible calling convention.
+           :
+         elif test $ac_prog = install &&
+           grep pwplus "$as_dir/$ac_prog$ac_exec_ext" >/dev/null 2>&1; then
+           # program-specific install script used by HP pwplus--don't use.
+           :
+         else
+           ac_cv_path_install="$as_dir/$ac_prog$ac_exec_ext -c"
+           break 3
+         fi
+       fi
+      done
+    done
+    ;;
+esac
+done
+
+
+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 "$as_me:$LINENO: result: $INSTALL" >&5
+echo "${ECHO_T}$INSTALL" >&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}'
+
+test -z "$INSTALL_DATA" && INSTALL_DATA='${INSTALL} -m 644'
+
+echo "$as_me:$LINENO: checking whether build environment is sane" >&5
+echo $ECHO_N "checking whether build environment is sane... $ECHO_C" >&6
+# 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
+   rm -f conftest.file
+   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 "$as_me:$LINENO: error: ls -t appears to fail.  Make sure there is not a broken
+alias in your environment" >&5
+echo "$as_me: error: ls -t appears to fail.  Make sure there is not a broken
+alias in your environment" >&2;}
+   { (exit 1); exit 1; }; }
+   fi
+
+   test "$2" = conftest.file
+   )
+then
+   # Ok.
+   :
+else
+   { { echo "$as_me:$LINENO: error: newly created file is older than distributed files!
+Check your system clock" >&5
+echo "$as_me: error: newly created file is older than distributed files!
+Check your system clock" >&2;}
+   { (exit 1); exit 1; }; }
+fi
+echo "$as_me:$LINENO: result: yes" >&5
+echo "${ECHO_T}yes" >&6
+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"
+# Double any \ or $.  echo might interpret backslashes.
+# By default was `s,x,x', remove it if useless.
+cat <<\_ACEOF >conftest.sed
+s/[\\$]/&&/g;s/;s,x,x,$//
+_ACEOF
+program_transform_name=`echo $program_transform_name | sed -f conftest.sed`
+rm conftest.sed
+
+
+# expand $ac_aux_dir to an absolute path
+am_aux_dir=`cd $ac_aux_dir && pwd`
+
+test x"${MISSING+set}" = xset || MISSING="\${SHELL} $am_aux_dir/missing"
+# Use eval to expand $SHELL
+if eval "$MISSING --run true"; then
+  am_missing_run="$MISSING --run "
+else
+  am_missing_run=
+  { echo "$as_me:$LINENO: WARNING: \`missing' script is too old or missing" >&5
+echo "$as_me: WARNING: \`missing' script is too old or missing" >&2;}
+fi
+
+for ac_prog in gawk mawk 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 "$as_me:$LINENO: checking for $ac_word" >&5
+echo $ECHO_N "checking for $ac_word... $ECHO_C" >&6
+if test "${ac_cv_prog_AWK+set}" = set; then
+  echo $ECHO_N "(cached) $ECHO_C" >&6
+else
+  if test -n "$AWK"; then
+  ac_cv_prog_AWK="$AWK" # Let the user override the test.
+else
+as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
+for as_dir in $PATH
+do
+  IFS=$as_save_IFS
+  test -z "$as_dir" && as_dir=.
+  for ac_exec_ext in '' $ac_executable_extensions; do
+  if $as_executable_p "$as_dir/$ac_word$ac_exec_ext"; then
+    ac_cv_prog_AWK="$ac_prog"
+    echo "$as_me:$LINENO: found $as_dir/$ac_word$ac_exec_ext" >&5
+    break 2
+  fi
+done
+done
+
+fi
+fi
+AWK=$ac_cv_prog_AWK
+if test -n "$AWK"; then
+  echo "$as_me:$LINENO: result: $AWK" >&5
+echo "${ECHO_T}$AWK" >&6
+else
+  echo "$as_me:$LINENO: result: no" >&5
+echo "${ECHO_T}no" >&6
+fi
+
+  test -n "$AWK" && break
+done
+
+echo "$as_me:$LINENO: checking whether ${MAKE-make} sets \$(MAKE)" >&5
+echo $ECHO_N "checking whether ${MAKE-make} sets \$(MAKE)... $ECHO_C" >&6
+set dummy ${MAKE-make}; ac_make=`echo "$2" | sed 'y,:./+-,___p_,'`
+if eval "test \"\${ac_cv_prog_make_${ac_make}_set+set}\" = set"; then
+  echo $ECHO_N "(cached) $ECHO_C" >&6
+else
+  cat >conftest.make <<\_ACEOF
+all:
+       @echo 'ac_maketemp="$(MAKE)"'
+_ACEOF
+# GNU make sometimes prints "make[1]: Entering...", which would confuse us.
+eval `${MAKE-make} -f conftest.make 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 conftest.make
+fi
+if eval "test \"`echo '$ac_cv_prog_make_'${ac_make}_set`\" = yes"; then
+  echo "$as_me:$LINENO: result: yes" >&5
+echo "${ECHO_T}yes" >&6
+  SET_MAKE=
+else
+  echo "$as_me:$LINENO: result: no" >&5
+echo "${ECHO_T}no" >&6
+  SET_MAKE="MAKE=${MAKE-make}"
+fi
+
+rm -rf .tst 2>/dev/null
+mkdir .tst 2>/dev/null
+if test -d .tst; then
+  am__leading_dot=.
+else
+  am__leading_dot=_
+fi
+rmdir .tst 2>/dev/null
+
+ # test to see if srcdir already configured
+if test "`cd $srcdir && pwd`" != "`pwd`" &&
+   test -f $srcdir/config.status; then
+  { { echo "$as_me:$LINENO: error: source directory already configured; run \"make distclean\" there first" >&5
+echo "$as_me: error: source directory already configured; run \"make distclean\" there first" >&2;}
+   { (exit 1); exit 1; }; }
+fi
+
+# test whether we have cygpath
+if test -z "$CYGPATH_W"; then
+  if (cygpath --version) >/dev/null 2>/dev/null; then
+    CYGPATH_W='cygpath -w'
+  else
+    CYGPATH_W=echo
+  fi
+fi
+
+
+# Define the identity of the package.
+ PACKAGE='cvs'
+ VERSION='1.12.9'
+
+
+# Some tools Automake needs.
+
+ACLOCAL=${ACLOCAL-"${am_missing_run}aclocal-${am__api_version}"}
+
+
+AUTOCONF=${AUTOCONF-"${am_missing_run}autoconf"}
+
+
+AUTOMAKE=${AUTOMAKE-"${am_missing_run}automake-${am__api_version}"}
+
+
+AUTOHEADER=${AUTOHEADER-"${am_missing_run}autoheader"}
+
+
+MAKEINFO=${MAKEINFO-"${am_missing_run}makeinfo"}
+
+
+AMTAR=${AMTAR-"${am_missing_run}tar"}
+
+install_sh=${install_sh-"$am_aux_dir/install-sh"}
+
+# Installed binaries are usually stripped using `strip' when the user
+# run `make install-strip'.  However `strip' might not be the right
+# tool to use in cross-compilation environments, therefore Automake
+# will honor the `STRIP' environment variable to overrule this program.
+if test "$cross_compiling" != no; then
+  if test -n "$ac_tool_prefix"; then
+  # Extract the first word of "${ac_tool_prefix}strip", so it can be a program name with args.
+set dummy ${ac_tool_prefix}strip; ac_word=$2
+echo "$as_me:$LINENO: checking for $ac_word" >&5
+echo $ECHO_N "checking for $ac_word... $ECHO_C" >&6
+if test "${ac_cv_prog_STRIP+set}" = set; then
+  echo $ECHO_N "(cached) $ECHO_C" >&6
+else
+  if test -n "$STRIP"; then
+  ac_cv_prog_STRIP="$STRIP" # Let the user override the test.
+else
+as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
+for as_dir in $PATH
+do
+  IFS=$as_save_IFS
+  test -z "$as_dir" && as_dir=.
+  for ac_exec_ext in '' $ac_executable_extensions; do
+  if $as_executable_p "$as_dir/$ac_word$ac_exec_ext"; then
+    ac_cv_prog_STRIP="${ac_tool_prefix}strip"
+    echo "$as_me:$LINENO: found $as_dir/$ac_word$ac_exec_ext" >&5
+    break 2
+  fi
+done
+done
+
+fi
+fi
+STRIP=$ac_cv_prog_STRIP
+if test -n "$STRIP"; then
+  echo "$as_me:$LINENO: result: $STRIP" >&5
+echo "${ECHO_T}$STRIP" >&6
+else
+  echo "$as_me:$LINENO: result: no" >&5
+echo "${ECHO_T}no" >&6
+fi
+
+fi
+if test -z "$ac_cv_prog_STRIP"; then
+  ac_ct_STRIP=$STRIP
+  # Extract the first word of "strip", so it can be a program name with args.
+set dummy strip; ac_word=$2
+echo "$as_me:$LINENO: checking for $ac_word" >&5
+echo $ECHO_N "checking for $ac_word... $ECHO_C" >&6
+if test "${ac_cv_prog_ac_ct_STRIP+set}" = set; then
+  echo $ECHO_N "(cached) $ECHO_C" >&6
+else
+  if test -n "$ac_ct_STRIP"; then
+  ac_cv_prog_ac_ct_STRIP="$ac_ct_STRIP" # Let the user override the test.
+else
+as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
+for as_dir in $PATH
+do
+  IFS=$as_save_IFS
+  test -z "$as_dir" && as_dir=.
+  for ac_exec_ext in '' $ac_executable_extensions; do
+  if $as_executable_p "$as_dir/$ac_word$ac_exec_ext"; then
+    ac_cv_prog_ac_ct_STRIP="strip"
+    echo "$as_me:$LINENO: found $as_dir/$ac_word$ac_exec_ext" >&5
+    break 2
+  fi
+done
+done
+
+  test -z "$ac_cv_prog_ac_ct_STRIP" && ac_cv_prog_ac_ct_STRIP=":"
+fi
+fi
+ac_ct_STRIP=$ac_cv_prog_ac_ct_STRIP
+if test -n "$ac_ct_STRIP"; then
+  echo "$as_me:$LINENO: result: $ac_ct_STRIP" >&5
+echo "${ECHO_T}$ac_ct_STRIP" >&6
+else
+  echo "$as_me:$LINENO: result: no" >&5
+echo "${ECHO_T}no" >&6
+fi
+
+  STRIP=$ac_ct_STRIP
+else
+  STRIP="$ac_cv_prog_STRIP"
+fi
+
+fi
+INSTALL_STRIP_PROGRAM="\${SHELL} \$(install_sh) -c -s"
+
+# We need awk for the "check" target.  The system "awk" is bad on
+# some platforms.
+
+
+
+
+
+if test "x$prefix" = xNONE; then
+  echo $ECHO_N "checking for prefix by $ECHO_C" >&6
+  # Extract the first word of "cvs", so it can be a program name with args.
+set dummy cvs; ac_word=$2
+echo "$as_me:$LINENO: checking for $ac_word" >&5
+echo $ECHO_N "checking for $ac_word... $ECHO_C" >&6
+if test "${ac_cv_path_ac_prefix_program+set}" = set; then
+  echo $ECHO_N "(cached) $ECHO_C" >&6
+else
+  case $ac_prefix_program in
+  [\\/]* | ?:[\\/]*)
+  ac_cv_path_ac_prefix_program="$ac_prefix_program" # Let the user override the test with a path.
+  ;;
+  *)
+  as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
+for as_dir in $PATH
+do
+  IFS=$as_save_IFS
+  test -z "$as_dir" && as_dir=.
+  for ac_exec_ext in '' $ac_executable_extensions; do
+  if $as_executable_p "$as_dir/$ac_word$ac_exec_ext"; then
+    ac_cv_path_ac_prefix_program="$as_dir/$ac_word$ac_exec_ext"
+    echo "$as_me:$LINENO: found $as_dir/$ac_word$ac_exec_ext" >&5
+    break 2
+  fi
+done
+done
+
+  ;;
+esac
+fi
+ac_prefix_program=$ac_cv_path_ac_prefix_program
+
+if test -n "$ac_prefix_program"; then
+  echo "$as_me:$LINENO: result: $ac_prefix_program" >&5
+echo "${ECHO_T}$ac_prefix_program" >&6
+else
+  echo "$as_me:$LINENO: result: no" >&5
+echo "${ECHO_T}no" >&6
+fi
+
+  if test -n "$ac_prefix_program"; then
+    prefix=`(dirname "$ac_prefix_program") 2>/dev/null ||
+$as_expr X"$ac_prefix_program" : 'X\(.*[^/]\)//*[^/][^/]*/*$' \| \
+        X"$ac_prefix_program" : 'X\(//\)[^/]' \| \
+        X"$ac_prefix_program" : 'X\(//\)$' \| \
+        X"$ac_prefix_program" : 'X\(/\)' \| \
+        .     : '\(.\)' 2>/dev/null ||
+echo X"$ac_prefix_program" |
+    sed '/^X\(.*[^/]\)\/\/*[^/][^/]*\/*$/{ s//\1/; q; }
+         /^X\(\/\/\)[^/].*/{ s//\1/; q; }
+         /^X\(\/\/\)$/{ s//\1/; q; }
+         /^X\(\/\).*/{ s//\1/; q; }
+         s/.*/./; q'`
+    prefix=`(dirname "$prefix") 2>/dev/null ||
+$as_expr X"$prefix" : 'X\(.*[^/]\)//*[^/][^/]*/*$' \| \
+        X"$prefix" : 'X\(//\)[^/]' \| \
+        X"$prefix" : 'X\(//\)$' \| \
+        X"$prefix" : 'X\(/\)' \| \
+        .     : '\(.\)' 2>/dev/null ||
+echo X"$prefix" |
+    sed '/^X\(.*[^/]\)\/\/*[^/][^/]*\/*$/{ s//\1/; q; }
+         /^X\(\/\/\)[^/].*/{ s//\1/; q; }
+         /^X\(\/\/\)$/{ s//\1/; q; }
+         /^X\(\/\).*/{ s//\1/; q; }
+         s/.*/./; q'`
+  fi
+fi
+
+          ac_config_headers="$ac_config_headers config.h"
+
+echo "$as_me:$LINENO: checking whether to enable maintainer-specific portions of Makefiles" >&5
+echo $ECHO_N "checking whether to enable maintainer-specific portions of Makefiles... $ECHO_C" >&6
+    # Check whether --enable-maintainer-mode or --disable-maintainer-mode was given.
+if test "${enable_maintainer_mode+set}" = set; then
+  enableval="$enable_maintainer_mode"
+  USE_MAINTAINER_MODE=$enableval
+else
+  USE_MAINTAINER_MODE=no
+fi;
+  echo "$as_me:$LINENO: result: $USE_MAINTAINER_MODE" >&5
+echo "${ECHO_T}$USE_MAINTAINER_MODE" >&6
+
+
+if test $USE_MAINTAINER_MODE = yes; then
+  MAINTAINER_MODE_TRUE=
+  MAINTAINER_MODE_FALSE='#'
+else
+  MAINTAINER_MODE_TRUE='#'
+  MAINTAINER_MODE_FALSE=
+fi
+
+  MAINT=$MAINTAINER_MODE_TRUE
+
+
+
+
+cat >>confdefs.h <<\_ACEOF
+#define _GNU_SOURCE 1
+_ACEOF
+
+
+DEPDIR="${am__leading_dot}deps"
+
+          ac_config_commands="$ac_config_commands depfiles"
+
+
+am_make=${MAKE-make}
+cat > confinc << 'END'
+am__doit:
+       @echo done
+.PHONY: am__doit
+END
+# If we don't find an include directive, just comment out the code.
+echo "$as_me:$LINENO: checking for style of include used by $am_make" >&5
+echo $ECHO_N "checking for style of include used by $am_make... $ECHO_C" >&6
+am__include="#"
+am__quote=
+_am_result=none
+# First try GNU make style include.
+echo "include confinc" > confmf
+# We grep out `Entering directory' and `Leaving directory'
+# messages which can occur if `w' ends up in MAKEFLAGS.
+# In particular we don't look at `^make:' because GNU make might
+# be invoked under some other name (usually "gmake"), in which
+# case it prints its new name instead of `make'.
+if test "`$am_make -s -f confmf 2> /dev/null | grep -v 'ing directory'`" = "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 "$as_me:$LINENO: result: $_am_result" >&5
+echo "${ECHO_T}$_am_result" >&6
+rm -f confinc confmf
+
+# 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
+
+
+
+ac_ext=c
+ac_cpp='$CPP $CPPFLAGS'
+ac_compile='$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >&5'
+ac_link='$CC -o conftest$ac_exeext $CFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS >&5'
+ac_compiler_gnu=$ac_cv_c_compiler_gnu
+if test -n "$ac_tool_prefix"; then
+  # Extract the first word of "${ac_tool_prefix}gcc", so it can be a program name with args.
+set dummy ${ac_tool_prefix}gcc; ac_word=$2
+echo "$as_me:$LINENO: checking for $ac_word" >&5
+echo $ECHO_N "checking for $ac_word... $ECHO_C" >&6
+if test "${ac_cv_prog_CC+set}" = set; then
+  echo $ECHO_N "(cached) $ECHO_C" >&6
+else
+  if test -n "$CC"; then
+  ac_cv_prog_CC="$CC" # Let the user override the test.
+else
+as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
+for as_dir in $PATH
+do
+  IFS=$as_save_IFS
+  test -z "$as_dir" && as_dir=.
+  for ac_exec_ext in '' $ac_executable_extensions; do
+  if $as_executable_p "$as_dir/$ac_word$ac_exec_ext"; then
+    ac_cv_prog_CC="${ac_tool_prefix}gcc"
+    echo "$as_me:$LINENO: found $as_dir/$ac_word$ac_exec_ext" >&5
+    break 2
+  fi
+done
+done
+
+fi
+fi
+CC=$ac_cv_prog_CC
+if test -n "$CC"; then
+  echo "$as_me:$LINENO: result: $CC" >&5
+echo "${ECHO_T}$CC" >&6
+else
+  echo "$as_me:$LINENO: result: no" >&5
+echo "${ECHO_T}no" >&6
+fi
+
+fi
+if test -z "$ac_cv_prog_CC"; then
+  ac_ct_CC=$CC
+  # Extract the first word of "gcc", so it can be a program name with args.
+set dummy gcc; ac_word=$2
+echo "$as_me:$LINENO: checking for $ac_word" >&5
+echo $ECHO_N "checking for $ac_word... $ECHO_C" >&6
+if test "${ac_cv_prog_ac_ct_CC+set}" = set; then
+  echo $ECHO_N "(cached) $ECHO_C" >&6
+else
+  if test -n "$ac_ct_CC"; then
+  ac_cv_prog_ac_ct_CC="$ac_ct_CC" # Let the user override the test.
+else
+as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
+for as_dir in $PATH
+do
+  IFS=$as_save_IFS
+  test -z "$as_dir" && as_dir=.
+  for ac_exec_ext in '' $ac_executable_extensions; do
+  if $as_executable_p "$as_dir/$ac_word$ac_exec_ext"; then
+    ac_cv_prog_ac_ct_CC="gcc"
+    echo "$as_me:$LINENO: found $as_dir/$ac_word$ac_exec_ext" >&5
+    break 2
+  fi
+done
+done
+
+fi
+fi
+ac_ct_CC=$ac_cv_prog_ac_ct_CC
+if test -n "$ac_ct_CC"; then
+  echo "$as_me:$LINENO: result: $ac_ct_CC" >&5
+echo "${ECHO_T}$ac_ct_CC" >&6
+else
+  echo "$as_me:$LINENO: result: no" >&5
+echo "${ECHO_T}no" >&6
+fi
+
+  CC=$ac_ct_CC
+else
+  CC="$ac_cv_prog_CC"
+fi
+
+if test -z "$CC"; then
+  if test -n "$ac_tool_prefix"; then
+  # Extract the first word of "${ac_tool_prefix}cc", so it can be a program name with args.
+set dummy ${ac_tool_prefix}cc; ac_word=$2
+echo "$as_me:$LINENO: checking for $ac_word" >&5
+echo $ECHO_N "checking for $ac_word... $ECHO_C" >&6
+if test "${ac_cv_prog_CC+set}" = set; then
+  echo $ECHO_N "(cached) $ECHO_C" >&6
+else
+  if test -n "$CC"; then
+  ac_cv_prog_CC="$CC" # Let the user override the test.
+else
+as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
+for as_dir in $PATH
+do
+  IFS=$as_save_IFS
+  test -z "$as_dir" && as_dir=.
+  for ac_exec_ext in '' $ac_executable_extensions; do
+  if $as_executable_p "$as_dir/$ac_word$ac_exec_ext"; then
+    ac_cv_prog_CC="${ac_tool_prefix}cc"
+    echo "$as_me:$LINENO: found $as_dir/$ac_word$ac_exec_ext" >&5
+    break 2
+  fi
+done
+done
+
+fi
+fi
+CC=$ac_cv_prog_CC
+if test -n "$CC"; then
+  echo "$as_me:$LINENO: result: $CC" >&5
+echo "${ECHO_T}$CC" >&6
+else
+  echo "$as_me:$LINENO: result: no" >&5
+echo "${ECHO_T}no" >&6
+fi
+
+fi
+if test -z "$ac_cv_prog_CC"; then
+  ac_ct_CC=$CC
+  # Extract the first word of "cc", so it can be a program name with args.
+set dummy cc; ac_word=$2
+echo "$as_me:$LINENO: checking for $ac_word" >&5
+echo $ECHO_N "checking for $ac_word... $ECHO_C" >&6
+if test "${ac_cv_prog_ac_ct_CC+set}" = set; then
+  echo $ECHO_N "(cached) $ECHO_C" >&6
+else
+  if test -n "$ac_ct_CC"; then
+  ac_cv_prog_ac_ct_CC="$ac_ct_CC" # Let the user override the test.
+else
+as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
+for as_dir in $PATH
+do
+  IFS=$as_save_IFS
+  test -z "$as_dir" && as_dir=.
+  for ac_exec_ext in '' $ac_executable_extensions; do
+  if $as_executable_p "$as_dir/$ac_word$ac_exec_ext"; then
+    ac_cv_prog_ac_ct_CC="cc"
+    echo "$as_me:$LINENO: found $as_dir/$ac_word$ac_exec_ext" >&5
+    break 2
+  fi
+done
+done
+
+fi
+fi
+ac_ct_CC=$ac_cv_prog_ac_ct_CC
+if test -n "$ac_ct_CC"; then
+  echo "$as_me:$LINENO: result: $ac_ct_CC" >&5
+echo "${ECHO_T}$ac_ct_CC" >&6
+else
+  echo "$as_me:$LINENO: result: no" >&5
+echo "${ECHO_T}no" >&6
+fi
+
+  CC=$ac_ct_CC
+else
+  CC="$ac_cv_prog_CC"
+fi
+
+fi
+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 "$as_me:$LINENO: checking for $ac_word" >&5
+echo $ECHO_N "checking for $ac_word... $ECHO_C" >&6
+if test "${ac_cv_prog_CC+set}" = set; then
+  echo $ECHO_N "(cached) $ECHO_C" >&6
+else
+  if test -n "$CC"; then
+  ac_cv_prog_CC="$CC" # Let the user override the test.
+else
+  ac_prog_rejected=no
+as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
+for as_dir in $PATH
+do
+  IFS=$as_save_IFS
+  test -z "$as_dir" && as_dir=.
+  for ac_exec_ext in '' $ac_executable_extensions; do
+  if $as_executable_p "$as_dir/$ac_word$ac_exec_ext"; then
+    if test "$as_dir/$ac_word$ac_exec_ext" = "/usr/ucb/cc"; then
+       ac_prog_rejected=yes
+       continue
+     fi
+    ac_cv_prog_CC="cc"
+    echo "$as_me:$LINENO: found $as_dir/$ac_word$ac_exec_ext" >&5
+    break 2
+  fi
+done
+done
+
+if test $ac_prog_rejected = yes; then
+  # We found a bogon in the path, so make sure we never use it.
+  set dummy $ac_cv_prog_CC
+  shift
+  if test $# != 0; then
+    # We chose a different compiler from the bogus one.
+    # However, it has the same basename, so the bogon will be chosen
+    # first if we set CC to just the basename; use the full file name.
+    shift
+    ac_cv_prog_CC="$as_dir/$ac_word${1+' '}$@"
+  fi
+fi
+fi
+fi
+CC=$ac_cv_prog_CC
+if test -n "$CC"; then
+  echo "$as_me:$LINENO: result: $CC" >&5
+echo "${ECHO_T}$CC" >&6
+else
+  echo "$as_me:$LINENO: result: no" >&5
+echo "${ECHO_T}no" >&6
+fi
+
+fi
+if test -z "$CC"; then
+  if test -n "$ac_tool_prefix"; then
+  for ac_prog in cl
+  do
+    # Extract the first word of "$ac_tool_prefix$ac_prog", so it can be a program name with args.
+set dummy $ac_tool_prefix$ac_prog; ac_word=$2
+echo "$as_me:$LINENO: checking for $ac_word" >&5
+echo $ECHO_N "checking for $ac_word... $ECHO_C" >&6
+if test "${ac_cv_prog_CC+set}" = set; then
+  echo $ECHO_N "(cached) $ECHO_C" >&6
+else
+  if test -n "$CC"; then
+  ac_cv_prog_CC="$CC" # Let the user override the test.
+else
+as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
+for as_dir in $PATH
+do
+  IFS=$as_save_IFS
+  test -z "$as_dir" && as_dir=.
+  for ac_exec_ext in '' $ac_executable_extensions; do
+  if $as_executable_p "$as_dir/$ac_word$ac_exec_ext"; then
+    ac_cv_prog_CC="$ac_tool_prefix$ac_prog"
+    echo "$as_me:$LINENO: found $as_dir/$ac_word$ac_exec_ext" >&5
+    break 2
+  fi
+done
+done
+
+fi
+fi
+CC=$ac_cv_prog_CC
+if test -n "$CC"; then
+  echo "$as_me:$LINENO: result: $CC" >&5
+echo "${ECHO_T}$CC" >&6
+else
+  echo "$as_me:$LINENO: result: no" >&5
+echo "${ECHO_T}no" >&6
+fi
+
+    test -n "$CC" && break
+  done
+fi
+if test -z "$CC"; then
+  ac_ct_CC=$CC
+  for ac_prog in cl
+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 "$as_me:$LINENO: checking for $ac_word" >&5
+echo $ECHO_N "checking for $ac_word... $ECHO_C" >&6
+if test "${ac_cv_prog_ac_ct_CC+set}" = set; then
+  echo $ECHO_N "(cached) $ECHO_C" >&6
+else
+  if test -n "$ac_ct_CC"; then
+  ac_cv_prog_ac_ct_CC="$ac_ct_CC" # Let the user override the test.
+else
+as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
+for as_dir in $PATH
+do
+  IFS=$as_save_IFS
+  test -z "$as_dir" && as_dir=.
+  for ac_exec_ext in '' $ac_executable_extensions; do
+  if $as_executable_p "$as_dir/$ac_word$ac_exec_ext"; then
+    ac_cv_prog_ac_ct_CC="$ac_prog"
+    echo "$as_me:$LINENO: found $as_dir/$ac_word$ac_exec_ext" >&5
+    break 2
+  fi
+done
+done
+
+fi
+fi
+ac_ct_CC=$ac_cv_prog_ac_ct_CC
+if test -n "$ac_ct_CC"; then
+  echo "$as_me:$LINENO: result: $ac_ct_CC" >&5
+echo "${ECHO_T}$ac_ct_CC" >&6
+else
+  echo "$as_me:$LINENO: result: no" >&5
+echo "${ECHO_T}no" >&6
+fi
+
+  test -n "$ac_ct_CC" && break
+done
+
+  CC=$ac_ct_CC
+fi
+
+fi
+
+
+test -z "$CC" && { { echo "$as_me:$LINENO: error: no acceptable C compiler found in \$PATH
+See \`config.log' for more details." >&5
+echo "$as_me: error: no acceptable C compiler found in \$PATH
+See \`config.log' for more details." >&2;}
+   { (exit 1); exit 1; }; }
+
+# Provide some information about the compiler.
+echo "$as_me:$LINENO:" \
+     "checking for C compiler version" >&5
+ac_compiler=`set X $ac_compile; echo $2`
+{ (eval echo "$as_me:$LINENO: \"$ac_compiler --version </dev/null >&5\"") >&5
+  (eval $ac_compiler --version </dev/null >&5) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }
+{ (eval echo "$as_me:$LINENO: \"$ac_compiler -v </dev/null >&5\"") >&5
+  (eval $ac_compiler -v </dev/null >&5) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }
+{ (eval echo "$as_me:$LINENO: \"$ac_compiler -V </dev/null >&5\"") >&5
+  (eval $ac_compiler -V </dev/null >&5) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }
+
+cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+
+int
+main ()
+{
+
+  ;
+  return 0;
+}
+_ACEOF
+ac_clean_files_save=$ac_clean_files
+ac_clean_files="$ac_clean_files a.out a.exe b.out"
+# Try to create an executable without -o first, disregard a.out.
+# It will help us diagnose broken compilers, and finding out an intuition
+# of exeext.
+echo "$as_me:$LINENO: checking for C compiler default output file name" >&5
+echo $ECHO_N "checking for C compiler default output file name... $ECHO_C" >&6
+ac_link_default=`echo "$ac_link" | sed 's/ -o *conftest[^ ]*//'`
+if { (eval echo "$as_me:$LINENO: \"$ac_link_default\"") >&5
+  (eval $ac_link_default) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; then
+  # Find the output, starting from the most likely.  This scheme is
+# not robust to junk in `.', hence go to wildcards (a.*) only as a last
+# resort.
+
+# Be careful to initialize this variable, since it used to be cached.
+# Otherwise an old cache value of `no' led to `EXEEXT = no' in a Makefile.
+ac_cv_exeext=
+# b.out is created by i960 compilers.
+for ac_file in a_out.exe a.exe conftest.exe a.out conftest a.* conftest.* b.out
+do
+  test -f "$ac_file" || continue
+  case $ac_file in
+    *.$ac_ext | *.xcoff | *.tds | *.d | *.pdb | *.xSYM | *.bb | *.bbg | *.o | *.obj )
+       ;;
+    conftest.$ac_ext )
+       # This is the source file.
+       ;;
+    [ab].out )
+       # We found the default executable, but exeext='' is most
+       # certainly right.
+       break;;
+    *.* )
+       ac_cv_exeext=`expr "$ac_file" : '[^.]*\(\..*\)'`
+       # FIXME: I believe we export ac_cv_exeext for Libtool,
+       # but it would be cool to find out if it's true.  Does anybody
+       # maintain Libtool? --akim.
+       export ac_cv_exeext
+       break;;
+    * )
+       break;;
+  esac
+done
+else
+  echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+{ { echo "$as_me:$LINENO: error: C compiler cannot create executables
+See \`config.log' for more details." >&5
+echo "$as_me: error: C compiler cannot create executables
+See \`config.log' for more details." >&2;}
+   { (exit 77); exit 77; }; }
+fi
+
+ac_exeext=$ac_cv_exeext
+echo "$as_me:$LINENO: result: $ac_file" >&5
+echo "${ECHO_T}$ac_file" >&6
+
+# Check the compiler produces executables we can run.  If not, either
+# the compiler is broken, or we cross compile.
+echo "$as_me:$LINENO: checking whether the C compiler works" >&5
+echo $ECHO_N "checking whether the C compiler works... $ECHO_C" >&6
+# FIXME: These cross compiler hacks should be removed for Autoconf 3.0
+# If not cross compiling, check that we can run a simple program.
+if test "$cross_compiling" != yes; then
+  if { ac_try='./$ac_file'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; }; then
+    cross_compiling=no
+  else
+    if test "$cross_compiling" = maybe; then
+       cross_compiling=yes
+    else
+       { { echo "$as_me:$LINENO: error: cannot run C compiled programs.
+If you meant to cross compile, use \`--host'.
+See \`config.log' for more details." >&5
+echo "$as_me: error: cannot run C compiled programs.
+If you meant to cross compile, use \`--host'.
+See \`config.log' for more details." >&2;}
+   { (exit 1); exit 1; }; }
+    fi
+  fi
+fi
+echo "$as_me:$LINENO: result: yes" >&5
+echo "${ECHO_T}yes" >&6
+
+rm -f a.out a.exe conftest$ac_cv_exeext b.out
+ac_clean_files=$ac_clean_files_save
+# Check the compiler produces executables we can run.  If not, either
+# the compiler is broken, or we cross compile.
+echo "$as_me:$LINENO: checking whether we are cross compiling" >&5
+echo $ECHO_N "checking whether we are cross compiling... $ECHO_C" >&6
+echo "$as_me:$LINENO: result: $cross_compiling" >&5
+echo "${ECHO_T}$cross_compiling" >&6
+
+echo "$as_me:$LINENO: checking for suffix of executables" >&5
+echo $ECHO_N "checking for suffix of executables... $ECHO_C" >&6
+if { (eval echo "$as_me:$LINENO: \"$ac_link\"") >&5
+  (eval $ac_link) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; then
+  # If both `conftest.exe' and `conftest' are `present' (well, observable)
+# catch `conftest.exe'.  For instance with Cygwin, `ls conftest' will
+# work properly (i.e., refer to `conftest.exe'), while it won't with
+# `rm'.
+for ac_file in conftest.exe conftest conftest.*; do
+  test -f "$ac_file" || continue
+  case $ac_file in
+    *.$ac_ext | *.xcoff | *.tds | *.d | *.pdb | *.xSYM | *.bb | *.bbg | *.o | *.obj ) ;;
+    *.* ) ac_cv_exeext=`expr "$ac_file" : '[^.]*\(\..*\)'`
+         export ac_cv_exeext
+         break;;
+    * ) break;;
+  esac
+done
+else
+  { { echo "$as_me:$LINENO: error: cannot compute suffix of executables: cannot compile and link
+See \`config.log' for more details." >&5
+echo "$as_me: error: cannot compute suffix of executables: cannot compile and link
+See \`config.log' for more details." >&2;}
+   { (exit 1); exit 1; }; }
+fi
+
+rm -f conftest$ac_cv_exeext
+echo "$as_me:$LINENO: result: $ac_cv_exeext" >&5
+echo "${ECHO_T}$ac_cv_exeext" >&6
+
+rm -f conftest.$ac_ext
+EXEEXT=$ac_cv_exeext
+ac_exeext=$EXEEXT
+echo "$as_me:$LINENO: checking for suffix of object files" >&5
+echo $ECHO_N "checking for suffix of object files... $ECHO_C" >&6
+if test "${ac_cv_objext+set}" = set; then
+  echo $ECHO_N "(cached) $ECHO_C" >&6
+else
+  cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+
+int
+main ()
+{
+
+  ;
+  return 0;
+}
+_ACEOF
+rm -f conftest.o conftest.obj
+if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5
+  (eval $ac_compile) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; then
+  for ac_file in `(ls conftest.o conftest.obj; ls conftest.*) 2>/dev/null`; do
+  case $ac_file in
+    *.$ac_ext | *.xcoff | *.tds | *.d | *.pdb | *.xSYM | *.bb | *.bbg ) ;;
+    *) ac_cv_objext=`expr "$ac_file" : '.*\.\(.*\)'`
+       break;;
+  esac
+done
+else
+  echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+{ { echo "$as_me:$LINENO: error: cannot compute suffix of object files: cannot compile
+See \`config.log' for more details." >&5
+echo "$as_me: error: cannot compute suffix of object files: cannot compile
+See \`config.log' for more details." >&2;}
+   { (exit 1); exit 1; }; }
+fi
+
+rm -f conftest.$ac_cv_objext conftest.$ac_ext
+fi
+echo "$as_me:$LINENO: result: $ac_cv_objext" >&5
+echo "${ECHO_T}$ac_cv_objext" >&6
+OBJEXT=$ac_cv_objext
+ac_objext=$OBJEXT
+echo "$as_me:$LINENO: checking whether we are using the GNU C compiler" >&5
+echo $ECHO_N "checking whether we are using the GNU C compiler... $ECHO_C" >&6
+if test "${ac_cv_c_compiler_gnu+set}" = set; then
+  echo $ECHO_N "(cached) $ECHO_C" >&6
+else
+  cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+
+int
+main ()
+{
+#ifndef __GNUC__
+       choke me
+#endif
+
+  ;
+  return 0;
+}
+_ACEOF
+rm -f conftest.$ac_objext
+if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5
+  (eval $ac_compile) 2>conftest.er1
+  ac_status=$?
+  grep -v '^ *+' conftest.er1 >conftest.err
+  rm -f conftest.er1
+  cat conftest.err >&5
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } &&
+        { ac_try='test -z "$ac_c_werror_flag"
+                        || test ! -s conftest.err'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; } &&
+        { ac_try='test -s conftest.$ac_objext'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; }; then
+  ac_compiler_gnu=yes
+else
+  echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+ac_compiler_gnu=no
+fi
+rm -f conftest.err conftest.$ac_objext conftest.$ac_ext
+ac_cv_c_compiler_gnu=$ac_compiler_gnu
+
+fi
+echo "$as_me:$LINENO: result: $ac_cv_c_compiler_gnu" >&5
+echo "${ECHO_T}$ac_cv_c_compiler_gnu" >&6
+GCC=`test $ac_compiler_gnu = yes && echo yes`
+ac_test_CFLAGS=${CFLAGS+set}
+ac_save_CFLAGS=$CFLAGS
+CFLAGS="-g"
+echo "$as_me:$LINENO: checking whether $CC accepts -g" >&5
+echo $ECHO_N "checking whether $CC accepts -g... $ECHO_C" >&6
+if test "${ac_cv_prog_cc_g+set}" = set; then
+  echo $ECHO_N "(cached) $ECHO_C" >&6
+else
+  cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+
+int
+main ()
+{
+
+  ;
+  return 0;
+}
+_ACEOF
+rm -f conftest.$ac_objext
+if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5
+  (eval $ac_compile) 2>conftest.er1
+  ac_status=$?
+  grep -v '^ *+' conftest.er1 >conftest.err
+  rm -f conftest.er1
+  cat conftest.err >&5
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } &&
+        { ac_try='test -z "$ac_c_werror_flag"
+                        || test ! -s conftest.err'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; } &&
+        { ac_try='test -s conftest.$ac_objext'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; }; then
+  ac_cv_prog_cc_g=yes
+else
+  echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+ac_cv_prog_cc_g=no
+fi
+rm -f conftest.err conftest.$ac_objext conftest.$ac_ext
+fi
+echo "$as_me:$LINENO: result: $ac_cv_prog_cc_g" >&5
+echo "${ECHO_T}$ac_cv_prog_cc_g" >&6
+if test "$ac_test_CFLAGS" = set; then
+  CFLAGS=$ac_save_CFLAGS
+elif test $ac_cv_prog_cc_g = yes; then
+  if test "$GCC" = yes; then
+    CFLAGS="-g -O2"
+  else
+    CFLAGS="-g"
+  fi
+else
+  if test "$GCC" = yes; then
+    CFLAGS="-O2"
+  else
+    CFLAGS=
+  fi
+fi
+echo "$as_me:$LINENO: checking for $CC option to accept ANSI C" >&5
+echo $ECHO_N "checking for $CC option to accept ANSI C... $ECHO_C" >&6
+if test "${ac_cv_prog_cc_stdc+set}" = set; then
+  echo $ECHO_N "(cached) $ECHO_C" >&6
+else
+  ac_cv_prog_cc_stdc=no
+ac_save_CC=$CC
+cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+#include <stdarg.h>
+#include <stdio.h>
+#include <sys/types.h>
+#include <sys/stat.h>
+/* Most of the following tests are stolen from RCS 5.7's src/conf.sh.  */
+struct buf { int x; };
+FILE * (*rcsopen) (struct buf *, struct stat *, int);
+static char *e (p, i)
+     char **p;
+     int i;
+{
+  return p[i];
+}
+static char *f (char * (*g) (char **, int), char **p, ...)
+{
+  char *s;
+  va_list v;
+  va_start (v,p);
+  s = g (p, va_arg (v,int));
+  va_end (v);
+  return s;
+}
+
+/* OSF 4.0 Compaq cc is some sort of almost-ANSI by default.  It has
+   function prototypes and stuff, but not '\xHH' hex character constants.
+   These don't provoke an error unfortunately, instead are silently treated
+   as 'x'.  The following induces an error, until -std1 is added to get
+   proper ANSI mode.  Curiously '\x00'!='x' always comes out true, for an
+   array size at least.  It's necessary to write '\x00'==0 to get something
+   that's true only with -std1.  */
+int osf4_cc_array ['\x00' == 0 ? 1 : -1];
+
+int test (int i, double x);
+struct s1 {int (*f) (int a);};
+struct s2 {int (*f) (double a);};
+int pairnames (int, char **, FILE *(*)(struct buf *, struct stat *, int), int, int);
+int argc;
+char **argv;
+int
+main ()
+{
+return f (e, argv, 0) != argv[0]  ||  f (e, argv, 1) != argv[1];
+  ;
+  return 0;
+}
+_ACEOF
+# Don't try gcc -ansi; that turns off useful extensions and
+# breaks some systems' header files.
+# AIX                  -qlanglvl=ansi
+# Ultrix and OSF/1     -std1
+# HP-UX 10.20 and later        -Ae
+# HP-UX older versions -Aa -D_HPUX_SOURCE
+# SVR4                 -Xc -D__EXTENSIONS__
+for ac_arg in "" -qlanglvl=ansi -std1 -Ae "-Aa -D_HPUX_SOURCE" "-Xc -D__EXTENSIONS__"
+do
+  CC="$ac_save_CC $ac_arg"
+  rm -f conftest.$ac_objext
+if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5
+  (eval $ac_compile) 2>conftest.er1
+  ac_status=$?
+  grep -v '^ *+' conftest.er1 >conftest.err
+  rm -f conftest.er1
+  cat conftest.err >&5
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } &&
+        { ac_try='test -z "$ac_c_werror_flag"
+                        || test ! -s conftest.err'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; } &&
+        { ac_try='test -s conftest.$ac_objext'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; }; then
+  ac_cv_prog_cc_stdc=$ac_arg
+break
+else
+  echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+fi
+rm -f conftest.err conftest.$ac_objext
+done
+rm -f conftest.$ac_ext conftest.$ac_objext
+CC=$ac_save_CC
+
+fi
+
+case "x$ac_cv_prog_cc_stdc" in
+  x|xno)
+    echo "$as_me:$LINENO: result: none needed" >&5
+echo "${ECHO_T}none needed" >&6 ;;
+  *)
+    echo "$as_me:$LINENO: result: $ac_cv_prog_cc_stdc" >&5
+echo "${ECHO_T}$ac_cv_prog_cc_stdc" >&6
+    CC="$CC $ac_cv_prog_cc_stdc" ;;
+esac
+
+# Some people use a C++ compiler to compile C.  Since we use `exit',
+# in C++ we need to declare it.  In case someone uses the same compiler
+# for both compiling C and C++ we need to have the C++ compiler decide
+# the declaration of exit, since it's the most demanding environment.
+cat >conftest.$ac_ext <<_ACEOF
+#ifndef __cplusplus
+  choke me
+#endif
+_ACEOF
+rm -f conftest.$ac_objext
+if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5
+  (eval $ac_compile) 2>conftest.er1
+  ac_status=$?
+  grep -v '^ *+' conftest.er1 >conftest.err
+  rm -f conftest.er1
+  cat conftest.err >&5
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } &&
+        { ac_try='test -z "$ac_c_werror_flag"
+                        || test ! -s conftest.err'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; } &&
+        { ac_try='test -s conftest.$ac_objext'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; }; then
+  for ac_declaration in \
+   '' \
+   'extern "C" void std::exit (int) throw (); using std::exit;' \
+   'extern "C" void std::exit (int); using std::exit;' \
+   'extern "C" void exit (int) throw ();' \
+   'extern "C" void exit (int);' \
+   'void exit (int);'
+do
+  cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+$ac_declaration
+#include <stdlib.h>
+int
+main ()
+{
+exit (42);
+  ;
+  return 0;
+}
+_ACEOF
+rm -f conftest.$ac_objext
+if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5
+  (eval $ac_compile) 2>conftest.er1
+  ac_status=$?
+  grep -v '^ *+' conftest.er1 >conftest.err
+  rm -f conftest.er1
+  cat conftest.err >&5
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } &&
+        { ac_try='test -z "$ac_c_werror_flag"
+                        || test ! -s conftest.err'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; } &&
+        { ac_try='test -s conftest.$ac_objext'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; }; then
+  :
+else
+  echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+continue
+fi
+rm -f conftest.err conftest.$ac_objext conftest.$ac_ext
+  cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+$ac_declaration
+int
+main ()
+{
+exit (42);
+  ;
+  return 0;
+}
+_ACEOF
+rm -f conftest.$ac_objext
+if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5
+  (eval $ac_compile) 2>conftest.er1
+  ac_status=$?
+  grep -v '^ *+' conftest.er1 >conftest.err
+  rm -f conftest.er1
+  cat conftest.err >&5
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } &&
+        { ac_try='test -z "$ac_c_werror_flag"
+                        || test ! -s conftest.err'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; } &&
+        { ac_try='test -s conftest.$ac_objext'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; }; then
+  break
+else
+  echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+fi
+rm -f conftest.err conftest.$ac_objext conftest.$ac_ext
+done
+rm -f conftest*
+if test -n "$ac_declaration"; then
+  echo '#ifdef __cplusplus' >>confdefs.h
+  echo $ac_declaration      >>confdefs.h
+  echo '#endif'             >>confdefs.h
+fi
+
+else
+  echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+fi
+rm -f conftest.err conftest.$ac_objext conftest.$ac_ext
+ac_ext=c
+ac_cpp='$CPP $CPPFLAGS'
+ac_compile='$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >&5'
+ac_link='$CC -o conftest$ac_exeext $CFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS >&5'
+ac_compiler_gnu=$ac_cv_c_compiler_gnu
+
+depcc="$CC"   am_compiler_list=
+
+echo "$as_me:$LINENO: checking dependency style of $depcc" >&5
+echo $ECHO_N "checking dependency style of $depcc... $ECHO_C" >&6
+if test "${am_cv_CC_dependencies_compiler_type+set}" = set; then
+  echo $ECHO_N "(cached) $ECHO_C" >&6
+else
+  if test -z "$AMDEP_TRUE" && test -f "$am_depcomp"; 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 conftest.dir
+  # Copy depcomp to subdir because otherwise we won't find it if we're
+  # using a relative directory.
+  cp "$am_depcomp" conftest.dir
+  cd conftest.dir
+  # We will build objects and dependencies in a subdirectory because
+  # it helps to detect inapplicable dependency modes.  For instance
+  # both Tru64's cc and ICC support -MD to output dependencies as a
+  # side effect of compilation, but ICC will put the dependencies in
+  # the current directory while Tru64 will put them in the object
+  # directory.
+  mkdir sub
+
+  am_cv_CC_dependencies_compiler_type=none
+  if test "$am_compiler_list" = ""; then
+     am_compiler_list=`sed -n 's/^#*\([a-zA-Z0-9]*\))$/\1/p' < ./depcomp`
+  fi
+  for depmode in $am_compiler_list; do
+    # Setup a source with many dependencies, because some compilers
+    # like to wrap large dependency lists on column 80 (with \), and
+    # we should not choose a depcomp mode which is confused by this.
+    #
+    # 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.
+    : > sub/conftest.c
+    for i in 1 2 3 4 5 6; do
+      echo '#include "conftst'$i'.h"' >> sub/conftest.c
+      : > sub/conftst$i.h
+    done
+    echo "${am__include} ${am__quote}sub/conftest.Po${am__quote}" > confmf
+
+    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=sub/conftest.c object=sub/conftest.${OBJEXT-o} \
+       depfile=sub/conftest.Po tmpdepfile=sub/conftest.TPo \
+       $SHELL ./depcomp $depcc -c -o sub/conftest.${OBJEXT-o} sub/conftest.c \
+         >/dev/null 2>conftest.err &&
+       grep sub/conftst6.h sub/conftest.Po > /dev/null 2>&1 &&
+       grep sub/conftest.${OBJEXT-o} sub/conftest.Po > /dev/null 2>&1 &&
+       ${MAKE-make} -s -f confmf > /dev/null 2>&1; then
+      # icc doesn't choke on unknown options, it will just issue warnings
+      # (even with -Werror).  So we grep stderr for any message
+      # that says an option was ignored.
+      if grep 'ignoring option' conftest.err >/dev/null 2>&1; then :; else
+        am_cv_CC_dependencies_compiler_type=$depmode
+        break
+      fi
+    fi
+  done
+
+  cd ..
+  rm -rf conftest.dir
+else
+  am_cv_CC_dependencies_compiler_type=none
+fi
+
+fi
+echo "$as_me:$LINENO: result: $am_cv_CC_dependencies_compiler_type" >&5
+echo "${ECHO_T}$am_cv_CC_dependencies_compiler_type" >&6
+CCDEPMODE=depmode=$am_cv_CC_dependencies_compiler_type
+
+
+
+if
+  test "x$enable_dependency_tracking" != xno \
+  && test "$am_cv_CC_dependencies_compiler_type" = gcc3; then
+  am__fastdepCC_TRUE=
+  am__fastdepCC_FALSE='#'
+else
+  am__fastdepCC_TRUE='#'
+  am__fastdepCC_FALSE=
+fi
+
+
+
+ac_ext=c
+ac_cpp='$CPP $CPPFLAGS'
+ac_compile='$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >&5'
+ac_link='$CC -o conftest$ac_exeext $CFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS >&5'
+ac_compiler_gnu=$ac_cv_c_compiler_gnu
+echo "$as_me:$LINENO: checking how to run the C preprocessor" >&5
+echo $ECHO_N "checking how to run the C preprocessor... $ECHO_C" >&6
+# On Suns, sometimes $CPP names a directory.
+if test -n "$CPP" && test -d "$CPP"; then
+  CPP=
+fi
+if test -z "$CPP"; then
+  if test "${ac_cv_prog_CPP+set}" = set; then
+  echo $ECHO_N "(cached) $ECHO_C" >&6
+else
+      # Double quotes because CPP needs to be expanded
+    for CPP in "$CC -E" "$CC -E -traditional-cpp" "/lib/cpp"
+    do
+      ac_preproc_ok=false
+for ac_c_preproc_warn_flag in '' yes
+do
+  # Use a header file that comes with gcc, so configuring glibc
+  # with a fresh cross-compiler works.
+  # Prefer <limits.h> to <assert.h> if __STDC__ is defined, since
+  # <limits.h> exists even on freestanding compilers.
+  # On the NeXT, cc -E runs the code through the compiler's parser,
+  # not just through cpp. "Syntax error" is here to catch this case.
+  cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+#ifdef __STDC__
+# include <limits.h>
+#else
+# include <assert.h>
+#endif
+                    Syntax error
+_ACEOF
+if { (eval echo "$as_me:$LINENO: \"$ac_cpp conftest.$ac_ext\"") >&5
+  (eval $ac_cpp conftest.$ac_ext) 2>conftest.er1
+  ac_status=$?
+  grep -v '^ *+' conftest.er1 >conftest.err
+  rm -f conftest.er1
+  cat conftest.err >&5
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } >/dev/null; then
+  if test -s conftest.err; then
+    ac_cpp_err=$ac_c_preproc_warn_flag
+    ac_cpp_err=$ac_cpp_err$ac_c_werror_flag
+  else
+    ac_cpp_err=
+  fi
+else
+  ac_cpp_err=yes
+fi
+if test -z "$ac_cpp_err"; then
+  :
+else
+  echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+  # Broken: fails on valid input.
+continue
+fi
+rm -f conftest.err conftest.$ac_ext
+
+  # OK, works on sane cases.  Now check whether non-existent headers
+  # can be detected and how.
+  cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+#include <ac_nonexistent.h>
+_ACEOF
+if { (eval echo "$as_me:$LINENO: \"$ac_cpp conftest.$ac_ext\"") >&5
+  (eval $ac_cpp conftest.$ac_ext) 2>conftest.er1
+  ac_status=$?
+  grep -v '^ *+' conftest.er1 >conftest.err
+  rm -f conftest.er1
+  cat conftest.err >&5
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } >/dev/null; then
+  if test -s conftest.err; then
+    ac_cpp_err=$ac_c_preproc_warn_flag
+    ac_cpp_err=$ac_cpp_err$ac_c_werror_flag
+  else
+    ac_cpp_err=
+  fi
+else
+  ac_cpp_err=yes
+fi
+if test -z "$ac_cpp_err"; then
+  # Broken: success on invalid input.
+continue
+else
+  echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+  # Passes both tests.
+ac_preproc_ok=:
+break
+fi
+rm -f conftest.err conftest.$ac_ext
+
+done
+# Because of `break', _AC_PREPROC_IFELSE's cleaning code was skipped.
+rm -f conftest.err conftest.$ac_ext
+if $ac_preproc_ok; then
+  break
+fi
+
+    done
+    ac_cv_prog_CPP=$CPP
+
+fi
+  CPP=$ac_cv_prog_CPP
+else
+  ac_cv_prog_CPP=$CPP
+fi
+echo "$as_me:$LINENO: result: $CPP" >&5
+echo "${ECHO_T}$CPP" >&6
+ac_preproc_ok=false
+for ac_c_preproc_warn_flag in '' yes
+do
+  # Use a header file that comes with gcc, so configuring glibc
+  # with a fresh cross-compiler works.
+  # Prefer <limits.h> to <assert.h> if __STDC__ is defined, since
+  # <limits.h> exists even on freestanding compilers.
+  # On the NeXT, cc -E runs the code through the compiler's parser,
+  # not just through cpp. "Syntax error" is here to catch this case.
+  cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+#ifdef __STDC__
+# include <limits.h>
+#else
+# include <assert.h>
+#endif
+                    Syntax error
+_ACEOF
+if { (eval echo "$as_me:$LINENO: \"$ac_cpp conftest.$ac_ext\"") >&5
+  (eval $ac_cpp conftest.$ac_ext) 2>conftest.er1
+  ac_status=$?
+  grep -v '^ *+' conftest.er1 >conftest.err
+  rm -f conftest.er1
+  cat conftest.err >&5
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } >/dev/null; then
+  if test -s conftest.err; then
+    ac_cpp_err=$ac_c_preproc_warn_flag
+    ac_cpp_err=$ac_cpp_err$ac_c_werror_flag
+  else
+    ac_cpp_err=
+  fi
+else
+  ac_cpp_err=yes
+fi
+if test -z "$ac_cpp_err"; then
+  :
+else
+  echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+  # Broken: fails on valid input.
+continue
+fi
+rm -f conftest.err conftest.$ac_ext
+
+  # OK, works on sane cases.  Now check whether non-existent headers
+  # can be detected and how.
+  cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+#include <ac_nonexistent.h>
+_ACEOF
+if { (eval echo "$as_me:$LINENO: \"$ac_cpp conftest.$ac_ext\"") >&5
+  (eval $ac_cpp conftest.$ac_ext) 2>conftest.er1
+  ac_status=$?
+  grep -v '^ *+' conftest.er1 >conftest.err
+  rm -f conftest.er1
+  cat conftest.err >&5
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } >/dev/null; then
+  if test -s conftest.err; then
+    ac_cpp_err=$ac_c_preproc_warn_flag
+    ac_cpp_err=$ac_cpp_err$ac_c_werror_flag
+  else
+    ac_cpp_err=
+  fi
+else
+  ac_cpp_err=yes
+fi
+if test -z "$ac_cpp_err"; then
+  # Broken: success on invalid input.
+continue
+else
+  echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+  # Passes both tests.
+ac_preproc_ok=:
+break
+fi
+rm -f conftest.err conftest.$ac_ext
+
+done
+# Because of `break', _AC_PREPROC_IFELSE's cleaning code was skipped.
+rm -f conftest.err conftest.$ac_ext
+if $ac_preproc_ok; then
+  :
+else
+  { { echo "$as_me:$LINENO: error: C preprocessor \"$CPP\" fails sanity check
+See \`config.log' for more details." >&5
+echo "$as_me: error: C preprocessor \"$CPP\" fails sanity check
+See \`config.log' for more details." >&2;}
+   { (exit 1); exit 1; }; }
+fi
+
+ac_ext=c
+ac_cpp='$CPP $CPPFLAGS'
+ac_compile='$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >&5'
+ac_link='$CC -o conftest$ac_exeext $CFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS >&5'
+ac_compiler_gnu=$ac_cv_c_compiler_gnu
+
+
+echo "$as_me:$LINENO: checking for egrep" >&5
+echo $ECHO_N "checking for egrep... $ECHO_C" >&6
+if test "${ac_cv_prog_egrep+set}" = set; then
+  echo $ECHO_N "(cached) $ECHO_C" >&6
+else
+  if echo a | (grep -E '(a|b)') >/dev/null 2>&1
+    then ac_cv_prog_egrep='grep -E'
+    else ac_cv_prog_egrep='egrep'
+    fi
+fi
+echo "$as_me:$LINENO: result: $ac_cv_prog_egrep" >&5
+echo "${ECHO_T}$ac_cv_prog_egrep" >&6
+ EGREP=$ac_cv_prog_egrep
+
+
+
+echo "$as_me:$LINENO: checking for AIX" >&5
+echo $ECHO_N "checking for AIX... $ECHO_C" >&6
+cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+#ifdef _AIX
+  yes
+#endif
+
+_ACEOF
+if (eval "$ac_cpp conftest.$ac_ext") 2>&5 |
+  $EGREP "yes" >/dev/null 2>&1; then
+  echo "$as_me:$LINENO: result: yes" >&5
+echo "${ECHO_T}yes" >&6
+cat >>confdefs.h <<\_ACEOF
+#define _ALL_SOURCE 1
+_ACEOF
+
+else
+  echo "$as_me:$LINENO: result: no" >&5
+echo "${ECHO_T}no" >&6
+fi
+rm -f conftest*
+
+
+echo "$as_me:$LINENO: checking for ANSI C header files" >&5
+echo $ECHO_N "checking for ANSI C header files... $ECHO_C" >&6
+if test "${ac_cv_header_stdc+set}" = set; then