aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorPeter Wemm <peter@FreeBSD.org>1997-05-15 22:46:24 +0000
committerPeter Wemm <peter@FreeBSD.org>1997-05-15 22:46:24 +0000
commit4a59246031483629d4bbbb326c510f30e82ba86b (patch)
tree3b2f0092fa216d9f61059ba94b7f10b5bacf9496
parent18576028af9c8455e19c9f51d94b87e08d1e6bd7 (diff)
downloadsrc-4a59246031483629d4bbbb326c510f30e82ba86b.tar.gz
src-4a59246031483629d4bbbb326c510f30e82ba86b.zip
Import of cvs-1.9.9-970515 onto vendor branch.
Obtained from: cyclic.com
Notes
Notes: svn path=/vendor/cvs/dist/; revision=25839
-rw-r--r--contrib/cvs/BUGS222
-rw-r--r--contrib/cvs/ChangeLog853
-rw-r--r--contrib/cvs/DEVEL-CVS54
-rw-r--r--contrib/cvs/FAQ7
-rw-r--r--contrib/cvs/HACKING104
-rw-r--r--contrib/cvs/INSTALL143
-rw-r--r--contrib/cvs/MINOR-BUGS71
-rw-r--r--contrib/cvs/Makefile.in63
-rw-r--r--contrib/cvs/NEWS135
-rw-r--r--contrib/cvs/PROJECTS3
-rw-r--r--contrib/cvs/README118
-rw-r--r--contrib/cvs/README.VMS159
-rw-r--r--contrib/cvs/TESTS136
-rw-r--r--contrib/cvs/TODO171
-rw-r--r--contrib/cvs/acconfig.h6
-rw-r--r--contrib/cvs/config.h.in46
-rwxr-xr-xcontrib/cvs/configure1028
-rw-r--r--contrib/cvs/configure.in179
-rw-r--r--contrib/cvs/contrib/ChangeLog118
-rw-r--r--contrib/cvs/contrib/Makefile.in25
-rw-r--r--contrib/cvs/contrib/README53
-rw-r--r--contrib/cvs/contrib/ccvs-rsh.pl97
-rw-r--r--contrib/cvs/contrib/cln_hist.pl1
-rw-r--r--contrib/cvs/contrib/commit_prep.pl1
-rw-r--r--contrib/cvs/contrib/cvs2vendor.sh142
-rw-r--r--contrib/cvs/contrib/cvs_acls.pl2
-rw-r--r--contrib/cvs/contrib/cvscheck.man1
-rw-r--r--contrib/cvs/contrib/cvscheck.sh1
-rw-r--r--contrib/cvs/contrib/cvshelp.man1
-rw-r--r--contrib/cvs/contrib/descend.man1
-rw-r--r--contrib/cvs/contrib/descend.sh1
-rw-r--r--contrib/cvs/contrib/listen2.c65
-rw-r--r--contrib/cvs/contrib/listen2.mak161
-rw-r--r--contrib/cvs/contrib/log.pl2
-rw-r--r--contrib/cvs/contrib/log_accum.pl27
-rw-r--r--contrib/cvs/contrib/mfpipe.pl3
-rw-r--r--contrib/cvs/contrib/rcs-to-cvs.sh5
-rw-r--r--contrib/cvs/contrib/rcs2log.sh29
-rw-r--r--contrib/cvs/contrib/rcs2sccs.sh2
-rw-r--r--contrib/cvs/contrib/sccs2rcs.csh2
-rw-r--r--contrib/cvs/cvs-format.el22
-rw-r--r--contrib/cvs/doc/ChangeLog1296
-rw-r--r--contrib/cvs/doc/DIFFUTILS-2.7-BUG263
-rw-r--r--contrib/cvs/doc/Makefile.in22
-rw-r--r--contrib/cvs/doc/RCSFILES165
-rw-r--r--contrib/cvs/doc/cvs.texinfo6125
-rw-r--r--contrib/cvs/doc/cvsclient.texi1008
-rw-r--r--contrib/cvs/lib/ChangeLog131
-rw-r--r--contrib/cvs/lib/Makefile.in15
-rw-r--r--contrib/cvs/lib/argmatch.c6
-rw-r--r--contrib/cvs/lib/fnmatch.c7
-rw-r--r--contrib/cvs/lib/fnmatch.h7
-rw-r--r--contrib/cvs/lib/getdate.y23
-rw-r--r--contrib/cvs/lib/getline.c6
-rw-r--r--contrib/cvs/lib/getopt.c6
-rw-r--r--contrib/cvs/lib/getopt.h8
-rw-r--r--contrib/cvs/lib/getopt1.c6
-rw-r--r--contrib/cvs/lib/getwd.c8
-rw-r--r--contrib/cvs/lib/hostname.c6
-rw-r--r--contrib/cvs/lib/md5.c120
-rw-r--r--contrib/cvs/lib/md5.h18
-rw-r--r--contrib/cvs/lib/mkdir.c6
-rw-r--r--contrib/cvs/lib/regex.c694
-rw-r--r--contrib/cvs/lib/regex.h14
-rw-r--r--contrib/cvs/lib/rename.c6
-rw-r--r--contrib/cvs/lib/sighandle.c8
-rw-r--r--contrib/cvs/lib/strdup.c6
-rw-r--r--contrib/cvs/lib/strerror.c7
-rw-r--r--contrib/cvs/lib/stripslash.c6
-rw-r--r--contrib/cvs/lib/system.h71
-rw-r--r--contrib/cvs/lib/vasprintf.c28
-rw-r--r--contrib/cvs/lib/wait.h19
-rw-r--r--contrib/cvs/lib/waitpid.c4
-rw-r--r--contrib/cvs/lib/xgetwd.c6
-rw-r--r--contrib/cvs/lib/yesno.c6
-rw-r--r--contrib/cvs/man/ChangeLog48
-rw-r--r--contrib/cvs/man/Makefile.in11
-rw-r--r--contrib/cvs/man/cvs.154
-rw-r--r--contrib/cvs/man/cvsbug.826
-rw-r--r--contrib/cvs/src/ChangeLog2084
-rw-r--r--contrib/cvs/src/ChangeLog-964434
-rw-r--r--contrib/cvs/src/Makefile.in38
-rw-r--r--contrib/cvs/src/add.c324
-rw-r--r--contrib/cvs/src/admin.c30
-rw-r--r--contrib/cvs/src/buffer.c1294
-rw-r--r--contrib/cvs/src/buffer.h142
-rw-r--r--contrib/cvs/src/checkin.c91
-rw-r--r--contrib/cvs/src/checkout.c469
-rw-r--r--contrib/cvs/src/classify.c107
-rw-r--r--contrib/cvs/src/client.c3028
-rw-r--r--contrib/cvs/src/client.h78
-rw-r--r--contrib/cvs/src/commit.c1136
-rw-r--r--contrib/cvs/src/create_adm.c29
-rw-r--r--contrib/cvs/src/cvs.h476
-rwxr-xr-xcontrib/cvs/src/cvsbug.sh16
-rw-r--r--contrib/cvs/src/cvsrc.c41
-rw-r--r--contrib/cvs/src/diff.c622
-rw-r--r--contrib/cvs/src/edit.c141
-rw-r--r--contrib/cvs/src/edit.h6
-rw-r--r--contrib/cvs/src/entries.c427
-rw-r--r--contrib/cvs/src/error.c127
-rw-r--r--contrib/cvs/src/error.h22
-rw-r--r--contrib/cvs/src/expand_path.c112
-rw-r--r--contrib/cvs/src/fileattr.c95
-rw-r--r--contrib/cvs/src/fileattr.h30
-rw-r--r--contrib/cvs/src/filesubr.c316
-rw-r--r--contrib/cvs/src/find_names.c154
-rw-r--r--contrib/cvs/src/hash.c101
-rw-r--r--contrib/cvs/src/hash.h4
-rw-r--r--contrib/cvs/src/history.c186
-rw-r--r--contrib/cvs/src/ignore.c127
-rw-r--r--contrib/cvs/src/import.c294
-rw-r--r--contrib/cvs/src/lock.c497
-rw-r--r--contrib/cvs/src/log.c1368
-rw-r--r--contrib/cvs/src/login.c595
-rw-r--r--contrib/cvs/src/logmsg.c514
-rw-r--r--contrib/cvs/src/main.c999
-rw-r--r--contrib/cvs/src/mkmodules.c235
-rw-r--r--contrib/cvs/src/modules.c315
-rw-r--r--contrib/cvs/src/myndbm.c25
-rw-r--r--contrib/cvs/src/myndbm.h2
-rw-r--r--contrib/cvs/src/no_diff.c120
-rw-r--r--contrib/cvs/src/options.h.in227
-rw-r--r--contrib/cvs/src/parseinfo.c34
-rw-r--r--contrib/cvs/src/patch.c211
-rw-r--r--contrib/cvs/src/rcs.c2798
-rw-r--r--contrib/cvs/src/rcs.h38
-rw-r--r--contrib/cvs/src/rcscmds.c170
-rw-r--r--contrib/cvs/src/recurse.c431
-rw-r--r--contrib/cvs/src/release.c333
-rw-r--r--contrib/cvs/src/remove.c84
-rw-r--r--contrib/cvs/src/repos.c117
-rw-r--r--contrib/cvs/src/root.c356
-rw-r--r--contrib/cvs/src/rtag.c127
-rw-r--r--contrib/cvs/src/run.c76
-rwxr-xr-xcontrib/cvs/src/sanity.sh4924
-rw-r--r--contrib/cvs/src/server.c4288
-rw-r--r--contrib/cvs/src/server.h50
-rw-r--r--contrib/cvs/src/status.c163
-rw-r--r--contrib/cvs/src/subr.c168
-rw-r--r--contrib/cvs/src/tag.c241
-rw-r--r--contrib/cvs/src/update.c1443
-rw-r--r--contrib/cvs/src/update.h7
-rw-r--r--contrib/cvs/src/vers_ts.c163
-rw-r--r--contrib/cvs/src/version.c2
-rw-r--r--contrib/cvs/src/watch.c62
-rw-r--r--contrib/cvs/src/watch.h6
-rw-r--r--contrib/cvs/src/wrapper.c214
-rw-r--r--contrib/cvs/src/zlib.c429
-rw-r--r--contrib/cvs/tools/ChangeLog13
-rw-r--r--contrib/cvs/tools/Makefile.in9
-rw-r--r--contrib/cvs/tools/pcl-cvs/ChangeLog26
-rw-r--r--contrib/cvs/tools/pcl-cvs/ChangeLog.woods383
-rw-r--r--contrib/cvs/tools/pcl-cvs/Makefile.in6
-rw-r--r--contrib/cvs/tools/pcl-cvs/ToDo44
-rw-r--r--contrib/cvs/tools/pcl-cvs/pcl-cvs.el51
156 files changed, 40510 insertions, 12961 deletions
diff --git a/contrib/cvs/BUGS b/contrib/cvs/BUGS
index fc6af32f227f..2a1c8602a74c 100644
--- a/contrib/cvs/BUGS
+++ b/contrib/cvs/BUGS
@@ -1,15 +1,50 @@
-To report bugs send mail to bug-cvs@prep.ai.mit.edu, or run the "cvsbug"
-program and fill out the template:
+See the README file for information on how to report bugs (and what
+will happen to your bug reports if you do).
- $ cvsbug
+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 README). There
+are some other reported bugs in MINOR-BUGS; the difference, at least
+in theory, is that those bugs are less serious.
-The "cvsbug" program is installed in the same location as the "cvs"
-program. If your installation failed, you may need to run "cvsbug"
-directly out of the "src" directory as "src/cvsbug.sh". This is also
-the procedure for submitting suggested changes to CVS--note that all
-submitted changes may be distributed under the terms of the GNU Public
-License, so if you don't like this, don't submit them.
+* 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.
+
+
+* Some people have reported seeing the message "dying gasps from %s
+unexpected" (where %s is the name of your server) when using
+client/server CVS. One person reported that this had to do with using
+pserver and trying to run a program not in the PATH (which is set up
+by inetd, I think) from one of the *info scripts. But noone has
+carefully tracked this down (is it caused by something in the server
+writing to stdout or stderr when it shouldn't? But then wouldn't the
+"dying gasps" message be preceded by "warning: unrecognized response
+`%s' from cvs server"?).
+
+
+* "make remotecheck" sometimes fails on test 187a3 with
+ cvs server: in directory .:
+ cvs [server aborted]: *PANIC* administration files missing
+This does not happen every time. (-kingdon, Nov 96, Red Hat linux 3.0.3).
+
+
+* 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.
+
+
+* 'cvs admin' dumped core when files were missing from working directory
+ (and from the repository)?
* `cvs checkout -d nested/dir/path <module>' just doesn't work. The
@@ -17,9 +52,23 @@ License, so if you don't like this, don't submit them.
however.
-* CVS leaves .#mumble files around when a conflict occurs. (Note:
- this is intentional and is documented in doc/cvs.texinfo. Of course
- whether it is a good idea is a separate question).
+* The following bug was reported against CVS 1.9:
+
+ Create a module named test with a file named test in it.
+
+ cactus:sfavor> cvs get test
+ cvs checkout: Updating test
+ U test/test
+ cactus:sfavor> cd test
+ cactus:sfavor> cvs get test
+ cvs checkout: cannot chdir to test: Not a directory
+ cvs checkout: ignoring module test
+ Exit 1
+ cactus:sfavor> cvs update
+ cvs update: Updating .
+ rcs.c:2139: failed assertion `rev == NULL || isdigit (*rev)'
+ Abort (core dumped)
+ Exit 134
* pcl-cvs doesn't like it when you try to check in a file which isn't
@@ -27,6 +76,36 @@ License, so if you don't like this, don't submit them.
what pcl-cvs is looking for.
+* From: billr@mpd.tandem.com (Bill Robertson)
+ Subject: Problem with rtag and the -D option
+ Date: Fri, 17 Mar 1995 10:53:29 -0600 (CST)
+
+ I have been trying to use the -D option to specify a date for tagging, but
+ rtag does not recognize the -D option. It is documented to do so and I've
+ tested the use of -D with cvs update and cvs diff and it works fine there.
+
+* Defining RELATIVE_REPOS is said to not work with client/server CVS.
+
+* 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?
+
+
* From: Roland McGrath <roland@gnu.ai.mit.edu>
To: Cyclic CVS Hackers <info-cvs@prep.ai.mit.edu>
Subject: weird bug
@@ -119,125 +198,6 @@ License, so if you don't like this, don't submit them.
ls: cvs-serv28978/cvs-serv28978/arpa/cvs-serv28978/assert/cvs-serv28978/bare/cvs-serv28978/conf/cvs-serv28978/crypt/cvs-serv28978/csu/cvs-serv28978/ctype/cvs-serv28978/dirent/cvs-serv28978/elf/cvs-serv28978/gnu/cvs-serv28978/gnulib/cvs-serv28978/grp/cvs-serv28978/hurd/cvs-serv28978/hurd/hurd/cvs-serv28978/inet/cvs-serv28978/inet/arpa/cvs-serv28978/inet/netinet[...]/cvs-serv28978/posix/cvs-serv28978/posix/glob/cvs-serv28978/posix/gnu/cvs-serv28978/posix/sys/cvs-serv28978/protocols/cvs-serv28978/pwd/cvs-serv28978/resolv/cvs-serv28978/resolv/arpa/cvs-serv28978/resolv/sys/cvs-serv28978/resource/cvs-serv28978/resource/sys/cvs-serv28978/rpc/cvs-serv28978/setjmp/cvs-serv28978/signal/cvs-serv28978/signal/sys/cvs-serv28978/socket/cvs-serv28978/socket: File name too long
cvs-serv28978/cvs-serv28978/arpa/cvs-serv28978/assert/cvs-serv28978/bare/cvs-serv28978/conf/cvs-serv28978/crypt/cvs-serv28978/csu/cvs-serv28978/ctype/cvs-serv28978/dirent/cvs-serv28978/elf/cvs-serv28978/gnu/cvs-serv28978/gnulib/cvs-serv28978/grp/cvs-serv28978/hurd/cvs-serv28978/hurd/hurd/cvs-serv28978/inet/cvs-serv28978/inet/arpa/cvs-serv28978/inet/netinet[...]/cvs-serv28978/posix/glob/cvs-serv28978/posix/gnu/cvs-serv28978/posix/sys/cvs-serv28978/protocols/cvs-serv28978/pwd/cvs-serv28978/resolv/cvs-serv28978/resolv/arpa/cvs-serv28978/resolv/sys/cvs-serv28978/resource/cvs-serv28978/resource/sys/cvs-serv28978/rpc/cvs-serv28978/setjmp/cvs-serv28978/signal/cvs-serv28978/signal/sys/cvs-serv28978/socket/cvs-serv28978:
-
-* From: billr@mpd.tandem.com (Bill Robertson)
- Subject: Problem with rtag and the -D option
- Date: Fri, 17 Mar 1995 10:53:29 -0600 (CST)
-
- I have been trying to use the -D option to specify a date for tagging, but
- rtag does not recognize the -D option. It is documented to do so and I've
- tested the use of -D with cvs update and cvs diff and it works fine there.
-
-
-* We need some version numbers really badly. Are there some
- (and Charles Hannum is just not including them in his reports), or do
- we simply have no reliable way to distinguish between the various
- versions of rCVS people on the list are running?
-
- Now that I think of it, version numbers present a problem when
- people can update their sources anytime and rebuild. I think the
- solution is to increment a minor version number *every* time a bug is
- fixed, so we can identify uniquely what someone is running when they
- submit a report. This implies recording the version increments in the
- ChangeLog; that way we can just look to see where a particular version
- lies in relation to the flow of changing code.
-
- Should we be doing same with Guppy? I guess not -- it's only
- important when you have people who are updating directly from your
- development tree, which is the case with the remote-cvs folks.
-
- Thoughts?
-
-
-* (Charles Hannum <mycroft@ai.mit.edu>) has these bugs:
-
- I just tossed remote CVS at a fairly large source tree that I already
- had, and noticed a few problems:
-
- 1) server.c assumes that /usr/tmp is a valid default for the place to
- store files uploaded from the client. There are a number of systems
- that now use /var/tmp. These should probably be detected by autoconf.
-
- 2) The server deals rather ungracefully with the tmp directory
- becoming full.
-
- 3) There's some oddness with relative paths in Repository files that
- causes the directory prefix to be added twice; e.g. if I have CVSROOT
- set to `machine:/this/dir', and I try to update in a directory whose
- Repository file says `src/bin', the server looks in
- `/this/dir/machine:/this/dir/src/bin'.
-
-* From: "Charles M. Hannum" <mycroft@ai.mit.edu>
- To: jimb@duality.gnu.ai.mit.edu, roland@duality.gnu.ai.mit.edu
- Subject: Serious flaw in remote CVS
- Date: Wed, 22 Feb 1995 20:54:36 -0500
-
- I just found a major flaw in the current implementation. Because the
- sockets are not changed to non-blocking mode, write(2)s can hang. In
- some cases, this happens on both sides at the same time, with the
- socket buffers full in both directions. This causes a deadlock,
- because both processes are stuck in I/O wait and thus never drain
- their input queues.
-
- Until this is fixed, I can't use it. I'll look at the problem myself
- at some point, but I don't know when.
-
-
- From: "Charles M. Hannum" <mycroft@ai.mit.edu>
- To: info-cvs@prep.ai.mit.edu
- Cc: jimb@totoro.bio.indiana.edu
- Subject: Re: forwarded message from Charles M. Hannum
- Date: Wed, 22 Feb 1995 22:07:07 -0500
-
- FYI, this happened because the tmp directory on the server became
- full. Somehow the server started interpreting the files the client
- was sending as commands, and started spewing tons of errors.
- Apparently the errors are sent with blocking I/O, or something, and
- thus allowed the deadlock to happen.
-
-
-* From: "Charles M. Hannum" <mycroft@ai.mit.edu>
- To: info-cvs@prep.ai.mit.edu
- Subject: Regarding that relative path problem
- Date: Thu, 23 Feb 1995 02:41:51 -0500
-
- This is actually more serious. If you have `bar.com:/foo' as your CVS
- root directory, then:
-
- 1) When you check things out, the Repository files will contain
- `/foo/...' (i.e. without the machine name), which makes little sense.
-
- 2) If you instead have a relative path, when the Repository file is
- read, `bar.com:/foo' is prepended. This is sent to the server, but
- confuses it, because it's not expecting the machine name to be
- prepended.
-
- A slightly klugy fix would be to have the client prepend the machine
- name when writing a new Repository file, and strip it off before
- sending one to the server. This would be backward-compatible with the
- current arrangement.
-
-
-* 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?
-
-
* From: Roland McGrath <roland@gnu.ai.mit.edu>
To: Cyclic CVS Hackers <info-cvs@prep.ai.mit.edu>
Subject: bizarre failure mode
diff --git a/contrib/cvs/ChangeLog b/contrib/cvs/ChangeLog
index ad187ad5188c..6c4565b4e7e3 100644
--- a/contrib/cvs/ChangeLog
+++ b/contrib/cvs/ChangeLog
@@ -1,3 +1,847 @@
+Sun May 11 11:38:03 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * README.VMS: Remove information about "direct TCP". Noone has
+ been complaining about it being broken (the code bitrotted not long
+ after it was written), nor has anyone complained
+ that contrib/listener.c was omitted from the distribution (because
+ it wasn't mentioned in contrib/Makefile.in DISTFILES). If there
+ is a desire to resurrect such a feature, it should use port 2401
+ as now discussed in doc/cvsclient.texi.
+
+Thu May 8 12:14:40 1997 Larry Jones <larry.jones@sdrc.com>
+ and Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * INSTALL: Update MIPS/SGI Irix 6.2
+ * TESTS: Add note about TESTDIR and SGI Irix 6's XFS.
+
+Wed May 7 12:01:21 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * TODO: Fix keywords accidentally expanded in previous checkin.
+
+ * TODO: Add item #185, concerning keyword expansion and merges.
+
+Sun May 4 19:46:03 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * README: Replace section on reporting bugs with a reference to
+ the bug-reporting section in cvs.texinfo.
+
+Fri May 2 22:50:04 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * BUGS: Remove item about importing binary files; the bug is fixed.
+
+Sun Apr 27 19:54:34 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * INSTALL: Refer to doc/DIFFUTILS-2.7-BUG.
+
+ * INSTALL: Don't mention GREP; CVS no longer uses it.
+
+ * configure.in: Add comment about --bindir.
+
+Thu Apr 24 15:21:17 1997 Norbert Kiesel <nk@cosa.de>
+
+ * configure.in (AC_CHECK_FUNCS): added tempnam and mktemp
+ * config.h.in, configure: Regenerated with autoconf 2.10.
+
+21 Apr 1997 Jim Kingdon
+
+ * cvsnt.mak: Visual C++, as usual, wants to fiddle with this.
+ This time it would appear to be chiefly the dependencies.
+
+Mon Apr 21 01:06:31 1997 Ian Lance Taylor <ian@cygnus.com>
+
+ * NEWS: Document that the client no longer needs an external patch
+ program.
+
+Thu Apr 17 14:28:20 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * TODO: Combine items 150 and 181 since they are basically the same.
+
+Tue Apr 15 12:32:26 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * FAQ: The URL of yahoo's Configuration Management category has
+ changed. As it might change again, just cite their top-level page
+ rather than the entire URL.
+
+8 Apr 1997 Jim Kingdon
+
+ * cvsnt.mak: Add windows-NT/sockerror.c.
+
+Wed Mar 26 15:51:33 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * BUGS: Further note on import -kb bug.
+
+Tue Mar 25 17:51:32 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs-format.el: Add comment concerning c-label-offset.
+
+Wed Mar 19 14:06:40 1997 Jim Meyering <meyering@totoro.cyclic.com>
+
+ * configure.in (test for shadow passwords): Use AC_MSG_RESULT
+ rather than echo, so configure obeys --quiet.
+ Use yes and no in message rather than yup and nope.
+
+19 Mar 1997 Jim Kingdon
+
+ * cvsnt.mak: Now Visual C++ wants to add a bunch of dependencies
+ for the Release configuration as well as the Debug one. Why it
+ didn't do this before, I have no idea.
+
+13 Mar 1997 Jim Kingdon
+
+ * cvsnt.mak: Recent changes have added a number of getline.h
+ dependencies.
+
+Thu Mar 13 08:43:04 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * configure.in (AC_C_CROSS): Add comment about obsolescence
+ thereof.
+ * config.h.in, configure: Regenerated with autoconf 2.10.
+
+Thu Mar 13 05:50:29 1997 Philippe De Muyter <phdm@info.ucl.ac.be>
+
+ Here are the fixes I needed to make to cvs-1.9 to get it to
+ compile and successfully pass 'make check' on m68k-motorola-sysv.
+ * lib/getwd.c (getwd): Added declaration for getcwd().
+ * lib/wait.h (WIFSTOPPED et al.): Macro defined if not defined.
+ * lib/waitpid.c (waitpid): Use wait, not wait3, if !HAVE_WAIT3.
+ * src/admin.c (admin): Added declaration for getgrnam().
+ * src/server.c (fcntl.h): Do not include file twice. Already included
+ from system.h from cvs.h.
+ * src/sanity.sh (imported-f*): Renamed from imported-file*, that were
+ too long for sysv.
+ * configure.in (wait3): Added to AC_CHECK_FUNCS list.
+
+Wed Mar 12 14:32:50 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * BUGS: Add "failed assertion `rev == NULL || isdigit (*rev)'" bug.
+
+ * TODO: Remove item 135; this is solved by %v and %V in loginfo.
+
+ * configure.in (AC_CHECK_FUNCS): Don't check for setvbuf;
+ HAVE_SETVBUF is no longer used.
+ * config.h, configure: Regenerated with autoconf 2.10.
+
+ * TODO: Add item 184, concerning MD5-based password hash.
+ Remove item 14, concerning "pathname stripper". I think that was
+ a reference to the late unlamented strip_path.
+
+Sat Mar 8 21:22:54 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * INSTALL: NT 4.0 is client and local (like other NT 3.51 & Win95).
+
+Fri Mar 7 16:51:13 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * INSTALL: Just talked to a NT 4.0 user; add it to the list.
+
+Sun Mar 2 22:01:23 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * NEWS: Add item about "cvs admin" vs. "cvs admin .".
+
+ * TODO: Remove item #169. It doesn't really explain what an
+ "archive library" is or in general what the feature they discuss is
+ supposed to do--I mean, CVS _can_ be used to store .o's, if
+ that is what they are talking about.
+
+ * TODO: Add item #183, about greater documentation/visiblity for
+ Entries.Static and CVS/Tag.
+
+ * INSTALL (footnote 5): Add note about how /usr/tmp vs. /var/tmp
+ shouldn't be an issue anymore
+
+Thu Feb 20 13:53:19 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * INSTALL: Update Cray entry per mail from John Bowman
+ <bowman@ipp-garching.mpg.de>
+
+ * configure.in: Add comments about autoconf version.
+
+Mon Feb 17 09:55:35 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * configure: Regenerated.
+
+Sat Feb 15 15:37:39 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * configure.in (AC_OUTPUT): Add windows-NT/SCC/Makefile.
+
+Sun Dec 15 13:12:30 1996 Michael Douglass <mikedoug@texas.net>
+ and Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * NEWS: Mention "cvs logout".
+
+1997-02-12 Jim Kingdon
+
+ * cvsnt.mak: Visual C++ seems to want to make some cosmetic
+ changes (reordering *.obj files), perhaps prodded by "Save
+ All". I hope that putting in these changes will make it
+ happy...
+
+1997-02-11 Jim Kingdon <kingdon@cyclic.com>
+
+ * cvsnt.mak: Replace with version from Visual C++ 4.0. If someone
+ wants the 2.x one back, I suppose we can put them side by side,
+ but I won't be able to update the 2.x one any more as I won't be
+ having access to 2.x.
+
+Tue Feb 11 16:43:43 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * .cvsignore: Add cvsnt.mdp and cvsnt.ncb. They seem to be files
+ created by Visual C++ 4.x which were not created by Visual C++ 2.x.
+
+Tue Feb 4 11:42:30 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * INSTALL: OS/2 port is client only.
+
+ * Rename devel-cvs (which had only been in the repository, not the
+ distribution) to DEVEL-CVS. Add "Charter for the devel-cvs
+ mailing list:" heading, "CVS Development Policies" title, and
+ one-sentence introduction (editorial changes, not run by
+ devel-cvs). Revise paragraph concerning membership in the list to
+ reflect policy change to make read-only membership different from
+ the ability to send to the list (the new wording was approved by
+ devel-cvs, as was the rename and including it in the
+ distribution).
+ * Makefile.in (DISTFILES): Add DEVEL-CVS.
+ * HACKING: Add "Mailing lists" section.
+
+Tue Jan 28 10:41:05 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * configure.in: Remove AC_CHECK_SIZEOF; no longer needed with
+ lib/md5.c changes.
+ * acconfig.h: Add HAVE_CONNECT. This is needed so that autoheader
+ 2.10 works; I think this has been broken since 2 Dec 1996.
+ * config.h.in: Regenerated with autoheader 2.10.
+ * configure: Regenerated with autoconf 2.10.
+
+ * HACKING: Revise criterion for whether something goes in NEWS
+ again (now "user-visible change worth mentioning"--the language
+ from the GNU coding standards).
+
+Mon Jan 27 23:05:24 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * HACKING: Criterion for whether something goes in NEWS is not
+ whether it is user-visible; it is whether it is a bugfix or a
+ feature.
+
+Tue Jan 21 10:21:53 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * INSTALL: Warn people against pre-5.x RCS; describe how to find
+ out what version of RCS you have.
+
+Wed Jan 8 14:50:47 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * Makefile.in, NEWS, README, TODO, configure.in: Remove CVSid; we
+ decided to get rid of these some time ago.
+
+Wed Jan 8 00:17:13 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * README (Credits): Refer to NEWS not ChangeLog; the ChangeLog in
+ question got renamed a bit but ended up as the bottom of the NEWS
+ file. Eliminate use of first person in a few places where it is
+ unclear who it refers to. Explicitly say that the lists
+ of contributors are not comprehensive.
+
+Thu Jan 2 12:59:45 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * README, Makefile.in: Remove paragraph about writing to the Free
+ Software Foundation at 675 Massachusetts Avenue. (1) They are no
+ longer at that address; (2) the Free Software Foundation are not
+ the ones to write to concerning CVS licensing. bug-cvs would be a
+ more appropriate choice; (3) there is probably little need for
+ this paragraph anyway.
+
+Thu Jan 2 09:46:37 1997 Karl Fogel <kfogel@ynu38.ynu.edu.cn>
+
+ * NEWS: mention read-only repository access feature.
+
+Wed Jan 1 18:47:08 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.spec: Don't include ChangeLog and ChangeLog.zoo in %doc.
+ There is no point in including them without src/ChangeLog,
+ src/ChangeLog-96, etc., but more to the point they really belong
+ in the source distribution rather than a binary distribution anyway.
+
+Mon Dec 30 16:55:54 1996 Abe Feldman <feldman@harvey.cyclic.com>
+
+ * NEWS: Add entry for changes to checkout command (creating CVS
+ directory at top of working directory)
+
+Tue Dec 17 13:13:30 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * NEWS: Add entry for verifymsg.
+
+Tue Dec 10 19:22:20 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs-format.el: Revise comments to explain how to use it and
+ general minor tidying of comments.
+
+Mon Dec 2 13:05:44 1996 Ian Lance Taylor <ian@cygnus.com>
+
+ * configure.in: Don't call AC_CHECK_FUNCS(connect) a second time,
+ because the value will have been cached; instead, check whether
+ the library was found with connect defined.
+ * configure: Rebuild with autoconf 2.12.
+
+Sat Nov 30 23:04:52 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * BUGS: Add note about mysterious failure in test 187a3.
+
+Fri Nov 29 10:19:50 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * configure.in (AC_CHECK_FUNCS): Also check for readlink.
+ * config.h.in: Regenerated using autoheader 2.10.
+
+Fri Nov 22 16:30:27 1996 Brendan Kehoe <brendan@cygnus.com>
+
+ * configure.in: Check for -lsocket, etc., before checking for
+ Kerberos libraries.
+ * configure: Rebuild.
+
+1996-11-19 Jim Kingdon
+
+ * cvsnt.mak: Remove strippath.c.
+
+Sun Nov 3 21:54:18 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * README: Move detailed information on compatibility to
+ the manual; simply point to it here.
+
+Thu Oct 31 07:20:45 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * BUGS: Add note about cvs import of binary files on non-unix.
+
+Tue Oct 29 13:59:14 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * BUGS: Add note about "dying gasps" message.
+
+Sat Oct 26 16:17:09 1996 Jim Blandy <jimb@totoro.cyclic.com>
+
+ * configure.in (AC_CHECK_FUNCS): Check for tzset.
+
+Fri Oct 25 10:27:08 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * NEWS: Mention new loginfo features.
+
+Thu Oct 24 08:21:48 1996 Lars.Henriksen@netman.dk
+
+ * INSTALL: Update to "DEC Alpha running OSF/1 version 3.2 (1.9)"
+
+Tue Oct 22 10:34:21 1996 Noel Cragg <noel@gargle.rain.org>
+
+ * configure.in: don't check for the existence of the /etc/security
+ directory, because it's possible to have PAM installed without
+ using shadow passwords.
+ * configure: regenerated.
+
+Sat Oct 19 18:34:29 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * README: Say that the remote protocol is not interoperable before
+ CVS 1.5.
+
+Sat Oct 19 13:06:53 1996 Mark H. Wilkinson <mhw@minster.york.ac.uk>
+ and Jim Kingdon <kingdon@cyclic.com>
+
+ * configure.in, INSTALL: New options for configure to enable or
+ disable client and server code, overriding configure's defaults.
+ * confiugre: Regenerated.
+
+Sat Oct 19 13:06:53 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * INSTALL: Add note about what to do if you got a binary
+ distribution of CVS. Add VAX/VMS entry.
+
+Thu Oct 17 15:38:03 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * NEWS, README: Reinstate 30 Sep 96 changes concerning US letter
+ vs. A4 paper.
+
+Wed Oct 16 16:59:57 1996 Jim Blandy <jimb@totoro.cyclic.com>
+
+ * configure.in: Simplify code to check for crypt. Check for
+ -lcrypt first, and then check for the crypt function. The old
+ code did slightly funky things with cache variables, which JimK's
+ last change disturbed. Let's just keep it simple.
+ * configure: Rebuilt.
+
+Wed Oct 16 15:01:59 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * configure.in: Don't call unset. It isn't portable to Ultrix,
+ but perhaps more to the point, seems like we should be using the
+ cached values (there was no comment explaining why we should
+ ignore the cached values, and none of the CVS developers were
+ able to provide an explanation when I asked).
+ * configure: Regenerated.
+
+ * NEWS: Add item regarding export and "cvs history".
+
+Tue Oct 15 07:40:42 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * TESTS: Mention the fact that expr is only for the tests, not for
+ CVS itself. At least one person was unclear on this.
+
+Mon Oct 14 12:13:03 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * HACKING: Add "Submitting patches (strategy)" section and
+ sentence about test cases. These changes have been run by
+ devel-cvs and there was no objection.
+
+Sat Oct 12 19:43:56 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * README.VMS: Add notes about some build problems on VAX/VMS.
+
+Thu Oct 10 09:20:25 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * BUGS: Remove item about & in modules file and client/server; the
+ bug is fixed.
+
+ * README.VMS: Rewrite sections about wildcard expansion and
+ calling editors to suggest technical approaches and to make it
+ clear that fixes will only happen if someone gets around to them.
+
+Sat Oct 5 15:01:22 1996 Jim Blandy <jimb@totoro.cyclic.com>
+
+ * Version 1.9 released.
+
+Tue Oct 1 14:32:44 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * NEWS, README: Revert changes regarding -D, -g, and A4. They
+ are for new features which are not appropriate at this stage of
+ the release process.
+
+Mon Sep 30 14:51:36 1996 Greg A. Woods <woods@most.weird.com>
+
+ * INSTALL (sun3): 1.8.86+ builds and runs make check.
+
+ * NEWS: describe -D and -g; DIFFBIN and GREPBIN
+
+ * MINOR-BUGS: yet another couple of annoyances...
+
+Mon Sep 30 08:33:51 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * BUGS: Mention "cvs add -m" client/server bug.
+
+ * NEWS: Document change from A4 to US letter. It may seem minor,
+ but it affects a *lot* of people.
+
+ * README: Revise discussion of US letter vs. A4 to reflect recent
+ change to cvs.texinfo.
+
+Sun Sep 29 16:32:47 1996 Greg A. Woods <woods@most.weird.com>
+
+ * MINOR-BUGS: describe a minor annoyance or two
+
+ * BUGS: describe a couple of new bugs
+
+Sun Sep 29 14:09:49 1996 Noel Cragg <noel@gargle.rain.org>
+
+ * configure.in: check for shadow password files as well as for
+ getspnam. Some systems (like Linux) have getspnam in the C
+ library, but aren't necessarily using shadow passwords.
+ * configure, config.h.in: Regenerate.
+
+Fri Sep 27 16:49:53 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * Makefile.in (TSUBDIRS): Remove comment about order of
+ directories mattering. That was only for an old set of hacks,
+ since gone, which tried to combine several tag files into one
+ (before emacs could use several tag files at once).
+
+Wed Sep 25 10:35:06 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * NEWS: Add note about "cvs log -d" date formats changing. See
+ comment I added to cvs.texinfo for more whining about this situation.
+
+ * BUGS: Remove item about ~/.cvsignore on NT; it is fixed.
+
+Wed Sep 25 10:22:00 1996 Larry Jones <larry.jones@sdrc.com>
+
+ * configure.in: Add hack for ISC crypt (the version in the posix C
+ library doesn't work -- why am I not surprised). Add check for
+ libsec.a for shadow password functions.
+
+ * Makefile.in: Make zlib along with lib in the check targets.
+
+Wed Sep 25 08:34:01 1996 Jim Blandy <jimb@floss.cyclic.com>
+
+ Fix from Mark A. Solinski <markso@mcs.com>:
+ * cvsnt.mak: The debug configuration adds the zlib directory to
+ the include path but it is missing from the release configuration.
+ Add it to the "ADD CPP" and "CPP_PROJ" lines.
+
+Tue Sep 24 11:32:20 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * INSTALL: Add VMS entry. Clarify what "tested" means.
+
+ * README: Replace section about what CVS is with the blurb from
+ cvs.spec (which is also the paragraph we use in the release
+ announcements).
+ Change location of pcl-cvs from contrib/pcl-cvs to tools/pcl-cvs.
+
+ * BUGS: Remove item about version numbers; we now have version
+ numbers. Remove item about server using /usr/tmp; this has been
+ changed. Remove item about deadlocks between server and client
+ and file contents being interpreted as commands; I believe this
+ refers to the case which was fixed by Ian's 7 Aug 96 change to
+ receive_partial_file. Remove item about server temp directory
+ becoming full; I'm not sure all bugs related to that have been
+ fixed, but I think the ones mentioned have been. Remove item
+ about .# files; this is a documented behavior. Refer to
+ platform-specific documentation. Add bug with & in modules file
+ and client/server CVS. Move bug about weird use of long file
+ names to end; the bug report is so long people won't want to read
+ past it. Refer to README concerning reporting bugs. Add
+ introduction. Reword some bug descriptions. Add bug concerning
+ ~/.cvsignore on NT.
+ * MINOR-BUGS: Add introduction. Reword some bug descriptions.
+ Remove item about "premature end of file"--we've improved that
+ error message as much as we can figure out how. Remove item about
+ filenames getting truncated (with rcs2log?)--I think this is a fixed
+ bug although I couldn't quickly find a ChangeLog entry for the fix.
+
+Tue Sep 17 12:46:37 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * .cvsignore: Add cvs-*.spec.
+
+Mon Sep 16 17:42:30 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * TODO: In 180, mention issue of network being down. Add item
+ 182, about inclusiveness of "cvs log -r foo -r bar".
+
+ * HACKING: Also mention arbitrary limits and reentrancy.
+ User-visible changes should be documented in cvs.texinfo as well
+ as NEWS.
+
+Thu Sep 12 16:06:33 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * README.VMS: Put authorship info at end. Add disclaimer. Say
+ that patch is mandatory not optional. Don't mention gzip; we
+ don't require it any more. Remove section on filename case; the
+ bugs described there are fixed. Miscellaneous tweaks and updates.
+
+Wed Sep 11 11:08:39 1996 Jim Blandy <jimb@totoro.cyclic.com>
+
+ * configure.in (AC_OUTPUT): Don't forget to create vms/Makefile.
+
+Tue Sep 10 19:55:07 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * Makefile.in (DISTFILES): Add build.com and README.VMS.
+ (SUBDIRS): Add vms.
+ * build.com: Also recurse into zlib directory.
+
+ * NEWS: Mention Win95.
+
+Fri Sep 6 11:43:26 1996 Ian Lance Taylor <ian@cygnus.com>
+
+ * configure.in: Add AC_ARG_ENABLE for encryption.
+ * acconfig.h: Add ENCRYPTION.
+ * configure, config.h.in: Regenerate.
+ * NEWS: Modify the entry on encryption to mention that you must
+ configure with --enable-encryption.
+ * INSTALL: Mention the --with-krb4 and --enable-encryption
+ configure options.
+
+Thu Sep 5 11:30:45 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * NEWS: Revise access method item to mention both :ext: and
+ :server:.
+
+ * README.VMS: Change bug reporting address to bug-cvs. In
+ discussing filenames, don't mention a hypothetical behavior
+ involving folding to lowercase (I'm not sure what is meant, and it
+ doesn't sound right to me) and do mention that things might be
+ different now (as a result of recent changes to case sensitivity
+ code).
+
+Wed Sep 4 1996 Jim Kingdon <kingdon@cyclic.com>
+
+ * cvsnt.mak: Add windows-NT/ChangeLog.
+
+Wed Sep 4 13:55:11 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * Makefile.in (DISTFILES): Add cvs.spec.
+
+Mon Aug 26 15:30:13 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * TODO: Add item suggesting "cvs message" command.
+
+Tue Aug 20 12:22:53 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * configure.in (AC_C_INLINE): Removed; see src/ChangeLog.
+ * config.h.in, configure: Regenerated.
+ * os2/config.h, windows-NT/config.h: Remove #define of inline.
+
+ * configure.in (AC_C_CHAR_UNSIGNED): Removed; it is not used
+ anywhere.
+ * config.h.in, configure: Regenerated.
+ * os2/config.h, vms/config.h, windows-NT/config.h: Likewise,
+ remove __CHAR_UNSIGNED__.
+
+Fri Aug 16 13:37:19 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.spec (%description): Replace description with one that
+ resembles the release announcements we have been sending out. The
+ previous one was out of date and not really focused on describing
+ what CVS does.
+ (%build): Don't define SERVER_FLOWCONTROL; if we are ready to make
+ this is the default it should be for all kinds of builds, not just
+ those via RPM.
+
+Fri Aug 16 16:09:59 1996 Norbert Kiesel <nk@col.sw-ley.de>
+
+ * cvs.spec: new file. This is a template for a RPM specification
+ file (which is used by 'make spec').
+
+ * Makefile.in (installdirs-local): new (empty) target
+ (all install uninstall installdirs): add installdirs to list of
+ targets which are done for all subdirs
+ (spec): new target to create a rpm specification file (which can
+ be used to create RPM source and binary packages)
+ (dist): depend on spec (which now also creates .fname)
+
+Wed Aug 14 13:59:11 1996 Norbert Kiesel <nk@col.sw-ley.de>
+
+ * configure.in (AC_REPLACE_FUNCS): add getspnam for reading shadow
+ password entries
+ * configure: regenerated
+ * config.h.in: regenerated
+
+Mon Aug 12 14:15:31 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * Makefile.in (config.status): When running config.status
+ --recheck, preserve the value of CFLAGS.
+
+Fri Aug 9 14:11:31 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * TESTS: Also mention dejagnu advantages.
+
+Thu Aug 8 16:00:55 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * TESTS (ABOUT STDOUT AND STDERR): New section.
+ (ABOUT TEST FRAMEWORKS): Add sed/cmp/diff (a la C News) as an option.
+
+ * NEWS: Change entry regarding "cvs log" not invoking "rlog" so
+ that it emphasizes user-visible behaviors.
+
+Tue Aug 6 17:01:23 1996 Ian Lance Taylor <ian@cygnus.com>
+
+ * TODO: Remove item #167 (cvs log doesn't understand symbolic
+ branch names). It works now.
+
+ * NEWS: Mention that "cvs log" no longer invokes "rlog".
+
+Wed Jul 31 16:06:03 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * HACKING: Mention rule about _ vs - in file names.
+
+Wed Jul 24 19:10:38 1996 Ian Lance Taylor <ian@cygnus.com>
+
+ * NEWS: Mention that Kerberos encryption is now supported.
+
+Mon Jul 22 23:48:39 1996 Ian Lance Taylor <ian@cygnus.com>
+
+ * NEWS: Mention that the commit message has changed slightly when
+ committing changes on a branch.
+
+Fri Jul 19 16:10:04 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * TESTS: Say that GNU expr is part of sh-utils.
+
+Thu Jul 18 18:16:33 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * NEWS: Mention -k wrappers option.
+
+ * TESTS: In list of what we would like in a test framework, only
+ mention portable once, and other wording cleanups.
+
+Mon Jul 15 1996 Jim Kingdon <kingdon@cyclic.com>
+
+ * cvsnt.mak: Add src/ChangeLog (lets us edit it from within
+ the integrated development environment).
+
+Sun Jul 14 1996 Jim Kingdon <kingdon@cyclic.com>
+
+ * cvsnt.mak: Add src/zlib.c. Add zlib group containing the .c
+ files in zlib. Add /I "zlib" compiler options.
+
+Sun Jul 14 10:26:21 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * NEWS: Expand zlib item to emphasize user-visible (and
+ CVS-installer-visible) consequences.
+
+Sat Jul 13 21:11:50 1996 Ian Lance Taylor <ian@cygnus.com>
+
+ * NEWS: Mention that -z now uses zlib.
+
+Fri Jul 12 18:54:21 1996 Ian Lance Taylor <ian@cygnus.com>
+
+ * Makefile.in (USOURCE_SUBDIRS): Add zlib.
+ * configure.in (AC_OUTPUT): Add zlib/Makefile.
+ * configure: Regenerate.
+
+ * zlib/*: Import zlib 1.0.3. Remove zlib/Makefile. Modify
+ zlib/Makefile.in for use with CVS.
+
+Fri Jul 12 1996 Jim Kingdon <kingdon@cyclic.com>
+
+ * cvsnt.mak: Add src/buffer.c
+
+Wed Jul 10 18:44:58 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * NEWS: Say that rlog is deprecated.
+
+Tue Jul 9 14:37:41 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * PROJECTS: Refer to comment in rcscmds.c regarding RCS library.
+
+ * HACKING: Expand comments on portability.
+
+Sun Jul 7 23:21:02 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * configure.in (AC_REPLACE_FUNCS): Remove memmove; it was used by
+ a very old version of the CVS server for nefarious purposes and it
+ has been long gone.
+ * configure: Regenerated.
+
+Tue Jul 2 22:36:31 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * TESTS: Add discussion of test frameworks.
+
+Fri Jun 28 20:27:56 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * NEWS: Describe "cvs diff -q" removal and new diff options.
+
+Thu Jun 13 17:29:30 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * TODO: Remove item #67 about having cvs import create CVS
+ directories; I don't think it is wise to have cvs import mess with
+ the directory it is working in at all. Remove item #69 about
+ having import edit modules--in many cases there is no need for an
+ entry in modules. Remove item #76 about running on top of SCCS;
+ we are clearly not evolving in that direction. Remove item #91
+ about documenting how to import sources from SCCS or RCS; this is
+ now documented in cvs.texinfo. Remove item #129 about "U CFTS/";
+ without more information it is impossible to know what behavior is
+ being discussed. Remove item #157 concerning module names in cvs
+ release; cvs release takes a directory name, not a module name.
+ Remove item #159 about checking access times; this is as likely to
+ be an annoyance as a help, and people who are into that can just
+ look at the result from "cvs update" (directly or with a script).
+ Remove item #164 concerning variables in *info files; it is done.
+ Remove item #35 (it just says "cvs admin" is cheesy, which isn't
+ specific enough to be useful). Rewrite #39 to be specific about
+ what would be nice in having branches track each other. Remove
+ item #46--I'm not sure what it means and if it means that one
+ should check in with "cci" or some such instead of "cvs ci" then
+ that is an installation hassle and a minimal convenience. Add
+ item #180.
+
+ * config.h.in: Regenerated.
+
+Thu Jun 13 1996 Ian Lance Taylor <ian@cygnus.com>
+ and Jim Kingdon <kingdon@cyclic.com>
+
+ * configure.in: Put -L${krb_libdir} in LDFLAGS temporarily when
+ looking for -ldes.
+ * configure: Regenerated.
+
+Mon Jun 10 13:13:35 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * NEWS: Mention NT local.
+
+Fri Jun 7 18:02:36 1996 Ian Lance Taylor <ian@cygnus.com>
+ and Jim Kingdon <kingdon@cyclic.com>
+
+ * NEWS: Mention new annotate options.
+
+Thu Jun 6 14:08:31 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * lib/savecwd.c: Revert CVS_* patch. The include files where
+ CVS_* is defined were not included, and the code in question was
+ inside HAVE_FCHDIR which isn't defined on the Mac anyway.
+
+ * src/filesubr.c: Revert CVS_* patch in this one file. The mac
+ port should have its own copy of filesubr.c instead.
+
+Wed Jun 05 10:03:10 1996 Mike Ladwig <mike@twinpeaks.prc.com>
+
+ * lib/{system.h,savecwd.c}, src/{add.c,checkout.c,client.c,
+ commit.c,create_adm.c,diff.c,edit.c,entries.c,fileattr.c,
+ filesubr.c,find_names.c,history.c,ignore.c,import.c,lock.c,
+ login.c,logmsg.c,mkmodules.c,modules.c,myndbm.c,no_diff.c,
+ parseinfo.c,patch.c,rcs.c,recurse.c,release.c,remove.c,root.c,
+ rtag.c,server.c,tag.c,update.c,vers_ts.c,wrapper.c}:
+ Under non-UNIX operating systems (MS-DOS, WinNT, MacOS), many
+ filesystem calls take only one argument; permission is handled
+ very differently on those systems than in UNIX. On MacOS,
+ the naming scheme for volumes and subdirectories is quite
+ different. This patch leaves hooks in the form of CVS_ACCESS,
+ CVS_CHDIR, CVS_CREAT, CVS_FOPEN, CVS_MKDIR, CVS_OPEN, CVS_OPENDIR,
+ CVS_RENAME, CVS_RMDIR, CVS_STAT, and CVS_UNLINK to accomodate
+ these differences.
+
+Thu Jun 6 11:11:53 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * NEWS: Say "changes from 1.7 to 1.8" not "changes since 1.7".
+
+Wed Jun 5 1996 Jim Kingdon <kingdon@cyclic.com>
+
+ * cvsnt.mak: Visual C++ 2.1 seems to want to reformat the line
+ breaks. No substantive changes, I think.
+
+Thu May 30 15:35:57 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * Makefile.in (DISTFILES): add TESTS.
+
+Tue May 28 13:10:42 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * src/server.c: Add comment regarding out-of-order bug.
+ * TESTS: Explain out-of-order bug.
+
+ * INSTALL: Remove $CVSId$. More strongly encourage people to skip
+ the tests if they don't have the time to look at the results.
+ Move most of the discussion of tests to new file TESTS, and add
+ some information on interpreting check.log output.
+ * README: In brief summary of install, don't spell out details of
+ "make check" or "cvs init" steps.
+
+Sun May 26 17:59:46 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * NEWS: Change "up-to-date" to "not locally modified"; the file
+ need not match the head revision it only need match some revision.
+
+Sun May 26 17:02:49 1996 Norbert Kiesel <nk@col.sw-ley.de>
+
+ * NEWS: document new option "-c" for tag
+
+Thu May 23 21:49:33 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * INSTALL: Remove footnote 10. The only kind of change suitable
+ for listing here is fairly easy portability stuff.
+
+Fri May 17 11:49:11 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * NEWS: Refer to cvs.texinfo and say "filesystem" not "fs".
+
+Thu May 16 17:13:56 1996 Noel Cragg <noel@gargle.rain.org>
+
+ * NEWS: Mention all access methods.
+
+Wed May 15 23:38:15 1996 Noel Cragg <noel@gargle.rain.org>
+
+ * NEWS: add info about access methods and document behavior change
+ for "cvs login."
+
+Mon May 13 10:37:09 1996 Greg A. Woods <woods@most.weird.com>
+
+ * INSTALL: updated for Sun-3 SunOS 4.1.1_U1 (1.8.2)
+
+Fri May 10 09:39:49 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * NEWS: Document that -d overrides CVS/Root.
+
+Mon May 6 06:00:10 1996 Benjamin J. Lee <benjamin@cyclic.com>
+
+ * Version 1.8.1
+
Sun May 5 17:38:21 1996 Benjamin J. Lee <benjamin@cyclic.com>
Integrated changes submitted by Ian Taylor <ian@cygnus.com>
@@ -46,6 +890,15 @@ Wed May 1 15:38:56 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
* NEWS: Remove item about reserving all-uppercase tag names.
+Wed May 01 00:18:01 1996 noel <noel@BOAT_ANCHOR>
+
+ * cvsnt.mak: remove all of those unnecessary libraries! We only
+ need advapi32.lib and wsock32.lib.
+
+Wed Apr 24 16:48:35 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * NEWS: Document that -d overrides CVS/Root.
+
Fri Apr 19 11:22:35 1996 Benjamin J. Lee <benjamin@cyclic.com>
* Version 1.7.86
diff --git a/contrib/cvs/DEVEL-CVS b/contrib/cvs/DEVEL-CVS
new file mode 100644
index 000000000000..defbba510324
--- /dev/null
+++ b/contrib/cvs/DEVEL-CVS
@@ -0,0 +1,54 @@
+ 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 <devel-cvs@cyclic.com> 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 (checkout-only access is available primarily
+via snapshots, for technical reasons) 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, an account will be created.
diff --git a/contrib/cvs/FAQ b/contrib/cvs/FAQ
index 450fa32f57d1..c7fcdd78bec2 100644
--- a/contrib/cvs/FAQ
+++ b/contrib/cvs/FAQ
@@ -7,8 +7,5 @@ questions like "what is the latest version of CVS?" and "what about GUIs
for CVS?", see the CVS web site,
http://www.loria.fr/~molli/cvs-index.html. There are many web sites on
Configuration Management packages (of which CVS is an example); for
-example see
-
-http://www.yahoo.com/Computers_and_Internet/Software/Software_Engineering/Configuration_Management/index.html
-
-or http://www.iac.honeywell.com/Pub/Tech/CM/index.html.
+example see the "Configuration Management" category at http://www.yahoo.com/
+or see http://www.iac.honeywell.com/Pub/Tech/CM/index.html.
diff --git a/contrib/cvs/HACKING b/contrib/cvs/HACKING
index ac4cdd194be3..89f7399e0e08 100644
--- a/contrib/cvs/HACKING
+++ b/contrib/cvs/HACKING
@@ -43,11 +43,17 @@ the person checking in such a patch should reindent it.
* Portability
-If it is in ANSI C and it is in SunOS4 (using /bin/cc), generally it
-is OK to use it without ifdefs (for example, assert() and void * as
-long as you add more casts to and from void * than ANSI requires. But
-not function prototypes). Such constructs are generally portable
-enough, including to NT, OS/2, VMS, etc.
+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.
+
+The current consequence of that general rule seems to be that if it
+is in ANSI C and it is in SunOS4 (using /bin/cc), generally it is OK
+to use it without ifdefs (for example, assert() and void * as long as
+you add more casts to and from void * than ANSI requires. But not
+function prototypes). Such constructs are generally portable enough,
+including to NT, OS/2, VMS, etc.
* Run-time behaviors
@@ -58,6 +64,22 @@ 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.
+We realize that CVS contains many arbitrary limits (such as PATH_MAX).
+Do not do this in new code; we are trying to *fix* those arbitrary
+limits. In particular, it should be possible to pass very long
+arguments (e.g. from a WWW cgi script) to CVS without having it
+overrun any buffers (which might create a security hole in the WWW
+example).
+
+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 from a
+Parse_Info caller to its callproc, you need a static variable. But
+use a single pointer so that when Parse_Info is fixed to pass along a
+void * argument, then the code can easily use that argument.
+
* Coding standards in general
Generally speaking the GNU coding standards are mostly used by CVS
@@ -65,7 +87,44 @@ Generally speaking the GNU coding standards are mostly used by CVS
and perhaps an exception or two we haven't mentioned). This is the
file standards.text at the GNU FTP sites.
-* Submitting patches
+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).
+
+* Submitting 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.
+
+However, if there is reason to think that a change would significantly
+inconvenience any significant body of CVS users, or would be
+controversial for other reasons, then the design should be re-thought.
+Go back to the requirements (writing documentation might help, if you
+write the documentation to explain why one would use the feature not
+just what the feature does). Think about whether there is a behavior
+which works in both your situation and the other situations. Make a
+list of the issues (for example, submit a comment or documentation
+change). Ask your coworkers, a newsgroup, or a mailing list, and see
+what other people think. Distribute some experimental patches outside
+the "official" CVS and see what people think. By this process, the
+intention is that once-controversial changes can be refined to the
+point where they are relatively uncontroversial before they are
+actually checked in to the "official" CVS. Features like zlib,
+encryption, and others have benefitted from this process in the past
+by being mentioned in the documentation and/or discussed, before an
+implementation was checked in.
+
+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.
+
+* Submitting patches (tactics)
Please include a ChangeLog entry (see the GNU coding standards for
information on writing one) with patches. Include a description of
@@ -74,7 +133,11 @@ the code are appropriate for this, but not always)--patches should not
be checked in unless there is some reason for them, and the
description may be helpful if there is a better way to solve the
problem. In addition to the ChangeLog entry, there should be a change
-to the NEWS file in the case of a new feature.
+to the NEWS file and cvs.texinfo, if the change is a user-visible
+change worth mentioning.
+
+It is nice to have a test case (see TESTS), especially for fixes which
+involve subtle behaviors or twisted sections of the code.
If you solve several unrelated problems, submit a separate
patch for each one. Patches should be tested before submission. Use
@@ -100,3 +163,30 @@ 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:
+
+ devel-cvs. 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.
+ commit-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 devel-cvs, commit-cvs, or test-results, send
+a message to "majordomo@cyclic.com" whose body consists of
+"subscribe <list>", where <list> is devel-cvs, commit-cvs or
+test-results.
+
+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@prep.ai.mit.edu.
+
+Other CVS discussions take place on the info-cvs mailing list
+(send mail to info-cvs-request@prep.ai.mit.edu to subscribe) or on
+the newsgroup comp.software.config-mgmt.
diff --git a/contrib/cvs/INSTALL b/contrib/cvs/INSTALL
index 4907134c6c53..56328345c867 100644
--- a/contrib/cvs/INSTALL
+++ b/contrib/cvs/INSTALL
@@ -1,45 +1,52 @@
-#ident "$CVSid$"
-
First, read the README file. If you're still happy...
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@prep.ai.mit.edu (doing so in the form of a diff
-to this file is encouraged).
+to this file 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.4.90)
+ 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.7+obvious patch)
+ DEC Alpha running OSF/1 version 3.2 (1.9)
+ DEC Alpha running VMS 6.2 (1.8.85 client-only)
+Cray:
+ J90 (CVS 970215 snapshot)
+ T3E (CVS 970215 snapshot)
HPPA:
HP 9000/710 running HP-UX 8.07A using gcc (about 1.4A2)
- HP 9000/715 running HP-UX 9.01 (1.6)
+ HPPA running HP-UX 9 (1.8)
HPPA running HP-UX 10.01 (1.7)
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)
- NextSTEP 3.3 (1.6.86)
+ HPPA 9000/735 running HP-UX A.09.05 (1.8.87)
+ NextSTEP 3.3 (1.7)
i386 family:
Solaris 2.4 using gcc (about 1.4A2)
UnixWare v1.1.1 using gcc (about 1.4A2)
- ISC 4.0.1 (1.5.94)
- Linux (kernel 1.2.x) (1.7.1)
+ Unixware 2.1 (1.8.86)
+ ISC 4.0.1 (1.8.87)
+ Linux (kernel 1.2.x) (1.8.86)
BSDI 2.0 (1.4.93) (footnote 5)
- FreeBSD 2.0.5, i486, gcc (1.5.95)
- NextSTEP 3.3 (1.6.86)
- NeXTSTEP 3.3 (1.7), (footnote 10)
- SCO Unix 3.2.4.2 (1.4.93) (footnote 4)
- SCO OpenServer 5.0.0, "CC='cc -b elf' configure"
+ 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 (1.8.86)
Lynx 2.3.0 080695 (1.6.86) (footnote 9)
- Windows NT 3.51 (1.7.87 client-only)
+ Windows NT 3.51 (1.8.86 client; 1.8.3 local)
+ Windows NT 4.0 (1.9 client and local)
+ Windows 95 (1.8.86 client and local)
QNX 4 (1.7 + obvious patches)
- OS/2 Version 3 using IBM C/C++ Tools 2.01 (1.7.86 with patches)
+ OS/2 Version 3 using IBM C/C++ Tools 2.01 (1.8.86 + patches, client)
m68k:
- Sun 3 running SunOS 4.1.1_U1 w/ bundled K&R /usr/5bin/cc (1.6)
- NextSTEP 3.3 (1.6.86)
- NeXTSTEP 3.3 (1.7), (footnote 10)
+ 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)
m88k:
Data General AViiON running dgux 5.4R2.10 (1.5)
@@ -47,23 +54,26 @@ m88k:
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.6.86)
+ DECstation running Ultrix 4.3 (1.8.85)
SGI running Irix 4.0.5H using gcc and cc (about 1.4A2) (footnote 2)
- SGI running Irix 5.3 (1.7)
- SGI running Irix-6 (about 1.4.90) (footnote 3)
+ SGI running Irix 5.3 using gcc 2.7.2 (1.8.87)
+ SGI running Irix-6.2 (1.9.8)
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.7.87)
+ IBM RS/6000 running AIX 3.2.5 (1.8)
IBM RS/6000 running AIX 4.1 using gcc and cc (about 1.4A2) (footnote 1)
Lynx 2.3.1 120495 (1.6.86) (footnote 9)
SPARC:
- Sun SPARC running SunOS 4.1.x (1.6.86)
+ Sun SPARC running SunOS 4.1.x (1.8.87)
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 (2.5 beta?) (1.6.4)
- NextSTEP 3.3 (1.6.86)
- NeXTSTEP 3.3 (1.7), (footnote 10)
+ Sun SPARC running Solaris 2.5 (1.8.87)
+ NextSTEP 3.3 (1.7)
+ Sun SparcClassing running Linux 2.0.17, gcc 2.7.2 (1.8.87)
+VAX:
+ VAX running VMS 6.2 (1.9+patches, client-only)
+ (see README.VMS for information on necessary hacks).
(footnote 1)
AIX 4.1 systems fail to run "configure" due to bugs in their
@@ -76,14 +86,13 @@ SPARC:
workaround this bug by linking with "-lmalloc" if necessary.
(about 1.4A2).
-(footnote 3)
- There are some warnings about pointer casts which can safely be
- ignored. (about 1.4.90).
-
(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 5) Change /usr/tmp to /var/tmp in src/server.c (2 places) (1.4.93).
+ (This should no longer be needed; CVS doesn't have /usr/tmp in
+ src/server.c any more. Has anyone tried a more recent version
+ on BSDI? If so, please report it so we can update this file).
(footnote 6) Build in ucb universe with COFF compiler tools. Put
/usr/local/bin first in PATH while doing a configure, make
@@ -108,15 +117,11 @@ SPARC:
So after running configure I had to undef HAVE_DIRENT_H and
define HAVE_SYS_DIR_H.
-(footnote 10) Ralf E. Stranzenbach <ralf@reswi.ruhr.de>
- I've made some modifications to "filesubr.c" to deal with NFS
- mounted directories (and those funny .nfs* files). This patch
- should be used whenever the programmers "sandbox" is located on
- a NFS mounted device --- at least on NeXTSTEP.
-
-------------------------------------------------------------------------------
-Installation under Unix:
+Installation under Unix (if you got a binary distribution from
+somewhere, install it according to procedure for that binary
+distribution, then skip to step 5):
1) Run "configure":
@@ -131,18 +136,35 @@ Installation under Unix:
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 using server or local CVS, RCS needs to be installed in
the user's PATH (or a path you have configured in src/options.h,
or a path specified with the -b option). If you don't have RCS,
you will need to get it from GNU as well. It is best to get the
version 5.7 (or later) version of RCS, available from
- prep.ai.mit.edu in the file pub/gnu/rcs-5.7.tar.gz.
+ prep.ai.mit.edu in the file pub/gnu/rcs-5.7.tar.gz. If you do not
+ have RCS version 5.x (for example, if you are using the old RCS
+ shipped with some versions of HPUX), CVS will probably fail to work
+ entirely. To find out what version of RCS you have, invoke "co -V".
+ If it fails to print a version number, it is an old version.
If you want version control of files with binary data, make sure
that the RCS configure script finds GNU diff 1.15 or later and
notices that diff supports the -a option. CVS itself is much less
picky about which version of diff it uses, and you shouldn't need
- to worry about that.
+ to worry about that. If you are using GNU diff 2.6 or 2.7, you may
+ want to know about a (subtle) bug described in doc/DIFFUTILS-2.7-BUG.
NOTE: The configure program will cache the results of the previous
configure execution. If you need to re-run configure from scratch, you
@@ -152,6 +174,16 @@ Installation under Unix:
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.
+
Try './configure --help' for further information on its usage.
NOTE ON CVS's USE OF NDBM:
@@ -190,7 +222,7 @@ Installation under Unix:
END OF NOTE FOR NDBM GUNK.
2) Edit src/options.h. Appropriate things to look at may be the
- invocation locations of programs like DIFF and GREP.
+ invocation locations of programs like DIFF.
Also glance at the default values for the environment variables
that CVS uses, in particular, the RCSBIN variable, which holds the
path to where the RCS programs live on your system.
@@ -209,27 +241,14 @@ Installation under Unix:
3a) Run the regression tests (optional).
You may also wish to validate the correctness of the new binary by
- running the regression 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
-
- WARNING: This test can take quite a while to run, esp. if your
- disks are slow or over-loaded.
-
- If you receive any un-expected output from the regression tests,
- it may indicate a bug in CVS (or might just indicate a problem
- running the tests). If you choose to submit a bug report,
- 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 and ability to provide one), etc. The check.log file is the
- first place to look.
+ 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:
diff --git a/contrib/cvs/MINOR-BUGS b/contrib/cvs/MINOR-BUGS
index 7b857193f86b..ba6fb1821111 100644
--- a/contrib/cvs/MINOR-BUGS
+++ b/contrib/cvs/MINOR-BUGS
@@ -1,26 +1,37 @@
-Low-priority bugs go here. We don't have many yet -- everything is
-high-priority at the moment. :-)
-
-
-* From: Jeff Johnson <jbj@brewster.JBJ.ORG>
- To: cyclic-cvs@cyclic.com
- Subject: Named_Root assumes . on server
- Date: Wed, 17 May 1995 11:04:53 -0400 (EDT)
-
- Problem:
- On server, Name_Root() attempts (aggressively) to set CVSADM_Root.
- If ~/CVS/Root exists (wrto rsh login), then CVSADM_Root will be
- initialized from that file. The sanity check between the root
- repository and the invocation will fail if the two values are not
- coincidentally the same.
-
- Workaround:
- There's a zillion ways to fix this bugture/featurelet. My current
- workaround is to remove ~/CVS/Root on the server. I shall attempt
- a better fix as soon as I can determine what appears politically
- correct. IMHO, the CVS/Root stuff (and getenv("CVSROOT") also) is
- a bit fragile and tedious in an rcmd() driven CCVS environment.
-
+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:
@@ -34,18 +45,8 @@ high-priority at the moment. :-)
...
I claim that CVS dirs should be ignored.
-
-
-* I sometimes get this message:
-
- Could not look up address for your host. Permission denied.
- cvs [update aborted]: premature end of file from server
-
- The client's response should be cleaned up.
-
-* In the gb-grep module, update-ChangeLog (and therefore, I assume,
- rcs2log) truncates file names --- I get entries for things called
- ring/lenstring.h instead of lenstring/lenstring.h.
+ (I don't *think* this always happens; is "-I !" getting picked up somewhere
+ something like that? -kingdon, Sep 96)
* 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
diff --git a/contrib/cvs/Makefile.in b/contrib/cvs/Makefile.in
index 636a0d70307e..bbf197d65ab8 100644
--- a/contrib/cvs/Makefile.in
+++ b/contrib/cvs/Makefile.in
@@ -11,12 +11,6 @@
# 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., 675 Mass Ave, Cambridge, MA 02139, USA.
-
-# $CVSid: @(#)Makefile.in 1.30 94/10/22 $
-
SHELL = /bin/sh
#### Start of system configuration section. ####
@@ -90,33 +84,35 @@ FLAGS_TO_PASS = \
DISTFILES = \
COPYING COPYING.LIB INSTALL README TODO PROJECTS \
- BUGS MINOR-BUGS FAQ HACKING \
+ BUGS MINOR-BUGS FAQ HACKING DEVEL-CVS TESTS \
+ README.VMS build.com \
ChangeLog NEWS ChangeLog.zoo \
configure configure.in stamp-h.in config.h.in Makefile.in acconfig.h \
cvs-format.el mkinstalldirs install-sh \
cvsnt.mak \
- .cvsignore
+ .cvsignore cvs.spec
### Subdirectories to run make in for the primary targets.
# Unix source subdirs, where we'll want to run lint and etags:
-USOURCE_SUBDIRS = lib src
+USOURCE_SUBDIRS = lib zlib src
# All other subdirs:
-SUBDIRS = ${USOURCE_SUBDIRS} man doc contrib tools windows-NT os2 macintosh
-# Only make TAGS/tags files in these directories, in this order
-# [Why in this order? If we didn't have to stick to this order, we
-# could make "TSUBDIRS = ${USOURCE_SUBDIRS}". -Karl]
+SUBDIRS = ${USOURCE_SUBDIRS} man doc contrib tools \
+ windows-NT os2 macintosh vms
+# Only make TAGS/tags files in these directories.
TSUBDIRS= src lib
# Set default target.
all:
-.PHONY: all install uninstall
-all install uninstall: config.h Makefile all-local
+.PHONY: all install uninstall installdirs
+all install uninstall installdirs: config.h Makefile all-local
@for subdir in $(SUBDIRS); do \
echo "making $@ in $$subdir"; \
( cd $$subdir && $(MAKE) $(FLAGS_TO_PASS) $@ ) || exit 1; \
done
+installdirs: installdirs-local
+
install: all install-local install-info
.PHONY: all-local
@@ -130,6 +126,10 @@ info dvi clean-info install-info:
install-local: all-local
@: nothing to do locally
+.PHONY: installdirs-local
+installdirs-local: all-local
+ @: nothing to do locally
+
.PHONY: tags
tags:
@for dir in $(TSUBDIRS); do echo making $@ in $$dir; cd $$dir && $(MAKE) $(FLAGS_TO_PASS) $@ || exit 1; cd ..; done
@@ -187,16 +187,19 @@ saber:
.PHONY: check
check:
cd lib ; $(MAKE) $(FLAGS_TO_PASS)
+ cd zlib ; $(MAKE) $(FLAGS_TO_PASS)
cd src ; $(MAKE) $(FLAGS_TO_PASS) check
.PHONY: remotecheck
remotecheck:
cd lib ; $(MAKE) $(FLAGS_TO_PASS)
+ cd zlib ; $(MAKE) $(FLAGS_TO_PASS)
cd src ; $(MAKE) $(FLAGS_TO_PASS) remotecheck
.PHONY: installcheck
installcheck:
cd lib ; $(MAKE) $(FLAGS_TO_PASS)
+ cd zlib ; $(MAKE) $(FLAGS_TO_PASS)
cd src ; $(MAKE) $(FLAGS_TO_PASS) installcheck
.PHONY: lint
@@ -207,12 +210,7 @@ lint:
GZIP=gzip --best
GZIP_EXT=.gz
TAR_VERBOSE=
-dist:
- echo > .fname \
- cvs-`sed < $(srcdir)/src/version.c \
- -e '/version_string/!d' \
- -e 's/[^0-9.]*\([0-9.]*\).*/\1/' \
- -e q`
+dist: spec
rm -rf `cat .fname`
${MAKE} dist-dir DISTDIR="`cat .fname`"
for dir in ${SUBDIRS}; do \
@@ -222,7 +220,7 @@ dist:
); \
done
tar chf${TAR_VERBOSE} - `cat .fname` | ${GZIP} > "`cat .fname`.tar${GZIP_EXT}"
- rm -rf `cat .fname` .fname
+ rm -rf `cat .fname` .fname .version
.PHONY: dist-dir
dist-dir:
@@ -231,12 +229,31 @@ dist-dir:
ln $(srcdir)/$${i} ${DISTDIR}; \
done
+.PHONY: spec
+spec:
+ rm -f .version .fname
+ sed < $(srcdir)/src/version.c \
+ -e '/version_string/!d' \
+ -e 's/[^0-9.]*\([0-9.]*\).*/\1/' \
+ -e q > .version
+ echo > .fname cvs-`cat .version`
+ rm -f `cat .fname`.spec
+ sed < $(top_srcdir)/cvs.spec \
+ -e 's/@VERSION@/'`cat .version`'/' \
+ > `cat .fname`.spec
+
+
# For the justification of the following Makefile rules, see node
# `Automatic Remaking' in GNU Autoconf documentation.
Makefile: Makefile.in config.status
CONFIG_FILES=$@ CONFIG_HEADERS= ./config.status
+
+# Use @CFLAGS@ not $(CFLAGS) because it would be confusing for "make CFLAGS="
+# to sometimes (i.e., if configure is modified) change the configured CFLAGS,
+# and sometimes not.
config.status: configure
- ./config.status --recheck
+ CFLAGS="@CFLAGS@" ./config.status --recheck
+
# The rules to run autoconf and autoheader are commented out. This is because
# when the user unpacks a tarfile, configure.in might end up newer than
# configure, but the user might not have (and does not need to have) autoconf
diff --git a/contrib/cvs/NEWS b/contrib/cvs/NEWS
index 81d82acf4dcb..46c78f7b7a31 100644
--- a/contrib/cvs/NEWS
+++ b/contrib/cvs/NEWS
@@ -1,4 +1,135 @@
-Changes since 1.7:
+Changes since 1.9:
+
+* 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. Note that the security cautions in
+cvs.texinfo ("Password authentication security"), and the requirement
+that read-only users be able to create locks and write the history
+file, both apply.
+
+* The "checkout" 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.
+
+* 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
@@ -903,5 +1034,3 @@ Mon Nov 19 23:15:11 1990 Brian Berliner (berliner at prisma.com)
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.
-
-$CVSid: @(#)ChangeLog 1.35 94/10/22 $
diff --git a/contrib/cvs/PROJECTS b/contrib/cvs/PROJECTS
index de765760631e..4e20f8b883af 100644
--- a/contrib/cvs/PROJECTS
+++ b/contrib/cvs/PROJECTS
@@ -51,9 +51,10 @@ are actually more appropriate for this list.
CVS parses RCS files in order to determine if work needs to be done,
and then RCS parses the files again when it is performing the work.
This would be much faster if CVS could do whatever is necessary
- by itself.
+ by itself. (see comment at start of rcscmds.c for a few notes on this).
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/README b/contrib/cvs/README
index 5c4c9b6436f8..977ddcb480e7 100644
--- a/contrib/cvs/README
+++ b/contrib/cvs/README
@@ -1,5 +1,3 @@
-$CVSid: @(#)README 1.32 94/10/22 $
-
CVS Kit
Copyright (c) 1993-1994 Brian Berliner
@@ -17,37 +15,22 @@ $CVSid: @(#)README 1.32 94/10/22 $
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., 675 Mass Ave, Cambridge, MA 02139, USA.
-
-------------------------------------------------------------------------------
Welcome to CVS!
-Bug reports are accepted, however note that someone may or may not
-feel like taking care of your bug report. Support contracts are
-available from Cyclic Software (http://www.cyclic.com or
-info@cyclic.com).
-
-To report bugs send mail to bug-cvs@prep.ai.mit.edu, or run the "cvsbug"
-program and fill out the template:
+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).
- $ cvsbug
-
-The "cvsbug" program is installed in the same location as the "cvs"
-program. If your installation failed, you may need to run "cvsbug"
-directly out of the "src" directory as "src/cvsbug.sh". This is also
-the procedure for submitting suggested changes to CVS (see the file
-HACKING for more details). Note that all submitted changes may be
-distributed under the terms of the GNU Public License, so if you don't
-like this, don't submit them.
+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 write
-to the above address and let us know! Free software only works if we
-all help out.
+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
@@ -61,24 +44,19 @@ Thanks for your support!
-------------------------------------------------------------------------------
-CVS is a freely available collection of programs that provide for software
-release and revision control functions in a UNIX environment. It is
-designed to work on top of the RCS distribution, V4 and later. CVS does
-understand how to parse older RCS formats, but cannot do any of the fancier
-features (like vendor branch support) without RCS branch support.
-
-Short blurb from the manual page (larger blurb is included there):
- cvs is a front end to the rcs(1) revision control system
- which extends the notion of revision control from a collec-
- tion of files in a single directory to a hierarchical col-
- lection of directories consisting of revision controlled
- files. These directories and files can be combined together
- to form a software release. cvs provides the functions
- necessary to manage these software releases and to control
- the concurrent editing of source files among multiple
- software developers.
-
-And a whole lot more. See the doc/cvs.texinfo file for more information.
+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.
-------------------------------------------------------------------------------
@@ -86,23 +64,10 @@ Notes to people upgrading from a previous release of CVS:
See the NEWS file for a description of features new in this version.
-The repository format is compatible going back to CVS 1.3. But see
-the "Watches compatibility" section of doc/cvs.texinfo if you have
-copies of CVS 1.6 or older and you want to use the optional developer
-communication features.
-
-The working directory format is compatible going back to CVS 1.5. It
-did change between CVS 1.3 and CVS 1.5. If you run CVS 1.5 or newer
-on a working directory checked out with CVS 1.3, CVS will convert it,
-but to go back to CVS 1.3 you need to check out a new working
-directory with CVS 1.3.
-
-The remote protocol is interoperable going back to CVS 1.5. Using a
-client or server older than 1.5 is deprecated and may fail to work at
-some point in the future (1.5 was the first official release with the
-remote protocol, but some older versions might still be floating
-around). In many cases you need to upgrade both the client and the
-server to take advantage of new features and bugfixes, however.
+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.
-------------------------------------------------------------------------------
@@ -112,15 +77,18 @@ Please read the INSTALL file for installation instructions. Brief summary:
$ ./configure
$ make
- $ make check # optional, long-running, step
+ (run the regression tests if desired)
$ make install
- $ cvsinit
+ (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 A4 paper; if you want US letter size, you need to remove the line
-@afourpaper from cvs.texinfo and re-generate cvs.ps using TeX.
+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.
-------------------------------------------------------------------------------
@@ -159,7 +127,7 @@ 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 ChangeLog file.
+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
@@ -179,9 +147,9 @@ 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. We should all thank him for saving us from
-my poor use of our language!
+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,
@@ -190,13 +158,17 @@ and non-POSIX/non-BSD systems.
Jim Kingdon and others at Cygnus Support <info@cygnus.com> wrote the
remote repository access code.
-In addition to the above contributors, the following Beta testers deserve
-special mention for their support. If I have left off your name, I
-apologize. Just write to me and let me know!
+There have been many, many contributions not listed here. Consult the
+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 elsewhere in this file).
Mark D. Baushke <mdb@cisco.com>
Per Cederqvist <ceder@signum.se>
- J.T. Conklin (jtc@cygnus.com>
+ J.T. Conklin <jtc@cygnus.com>
Vince DeMarco <vdemarco@fdcsrvr.cs.mci.com>
Paul Eggert <eggert@twinsun.com>
Lal George <george@research.att.com>
@@ -219,4 +191,4 @@ apologize. Just write to me and let me know!
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 contrib/pcl-cvs.
+contributed GNU Emacs CVS-mode in tools/pcl-cvs.
diff --git a/contrib/cvs/README.VMS b/contrib/cvs/README.VMS
new file mode 100644
index 000000000000..b32ed8f995b6
--- /dev/null
+++ b/contrib/cvs/README.VMS
@@ -0,0 +1,159 @@
+ CVS port to VMS
+
+DISCLAIMER: This port must be considered experimental. Although
+previous versions have been in use at one large site since about
+October, 1995, and the port is believed to be quite usable, various
+VMS-specific quirks are known and the port cannot be considered as
+mature as the ports to, say, Windows NT or unix. As always, future
+progress of this port will depend on volunteer and customer interest.
+
+This port is of the CVS client only. Or in other words, the port
+implements the full set of CVS commands, but cannot access
+repositories located on the local machine. The repository must live
+on another machine (a Unix box) which runs a complete port of CVS.
+
+Most (all?) work to date has been done on OpenVMS/AXP 6.2. Other VMS
+variants might work too.
+
+You will also need GNU patch installed on your system. Here's a list
+of ftp servers which have VMS GNU resources, taken from
+
+ ftp://prep.ai.mit.edu/pub/gnu/vms.README
+
+ mvb.saic.com
+ wuarchive.wustl.edu
+ ftp.wku.edu
+ ftp.spc.edu
+ ftp.stacken.kth.se
+
+Please send bug reports to bug-cvs@prep.ai.mit.edu.
+
+As of CVS 1.5.something, this port passed most of the tests in
+[.src]sanity.sh. I say "most" because some tests to not apply to the
+CVS client. The tests were run by hand because the VMS POSIX shell
+was incapable of running the script. The tests that sanity.sh
+provides are not conclusive but at least provides some assurance that
+the client is usable.
+
+To compile, you will need DEC C (CC), DEC UCX, and of course DCL
+installed on your machine. Just type "@build" in the top level
+directory. This will build the sources in each subdirectory, and link
+the executable [.src]cvs.exe
+
+Copy the executable to an appropriate directory, and define the symbol "CVS"
+in a .COM file which everyone running CVS will need to run. Here's an example
+of what needs to be done.
+
+$ CVS :== $YOUR_DEVICE:[YOUR.DIRECTORY.CVS]CVS.EXE
+
+Accessing a remote repository can happen in several ways.
+
+1. pserver
+2. rsh - privileged (default)
+3. rsh - unprivileged (on VMS side)
+
+Here's how to do each of the above:
+
+-------------------------------------------------------------------------------
+1. pserver. This is the preferred way. It works just as it is
+documented in the CVS manual (see the README file in the CVS
+distribution for more information on the manual).
+
+-------------------------------------------------------------------------------
+2. Using CVS internal rsh support (privileged)
+
+VMS's RSH is unusable for CVS's purposes (that is, the one in UCX.
+Don't know about Multinet). However, there is code within CVS to
+emulate RSH for purposes of contacting a CVS server "in the usual way"
+via rshd. Unfortunately, this requires the VMS CVS client to be
+installed with OPER privilege, by your system administrator.
+
+RSH uses privileged ports and trusted software/hosts to determine
+which user on the client side is trying to connect. Part of this
+security is due to the fact that on VMS or UNIX, a non privileged
+process is not permitted to bind a socket to a privileged port.
+
+If rshd receives a connection on a non-privileged port, the connection is
+immediately aborted. Only connections arriving from a privileged port will
+be authenticated and served. The CVS client will therefore need privileges
+under VMS to produce such a connection.
+
+*** Please note that no careful examination has been done of the security
+ implications of installing CVS with the OPER privilege. If some hole
+ exists, then by doing so, you will enable users who are already on
+ your system to gain unauthorized privileges ***
+
+-------------------------------------------------------------------------------
+3. Using CVS internal rsh support (non-privileged)
+
+There is a workaround, but this is one case where I think the cure is worse
+than the disease. If you patch an rshd to not care that the RSH originating
+port is "non-privileged", the CVS VMS client will allow you to define the
+logical CVS_RCMD_PORT to the port number where this patched rshd will be
+listening. I leave the talk of patching rshd to the gentle reader and his/her
+friendly system administrator.
+
+If I put an entry in my /etc/services file:
+
+cvs_rcmd 4381/tcp cvs_rcmd
+
+And add a line to /etc/inetd.conf, then restart inetd via "kill -1"
+
+cvs_rcmd stream tcp nowait root /usr/sbin/tcpd /usr/local/sbin/cvs_rcmd
+
+On the VMS side, you will have to do this:
+
+$ define CVS_RCMD_PORT 4381
+
+Then run CVS in the "usual way".
+
+Note that the patched rshd will need to be invoked via inetd as root, so it can
+authenticate and _become_ the intended user, the same as the regular rshd.
+
+***Please note that you will be installing a security hole by doing this.***
+
+Please also note that this security hole is no larger than allowing a
+Macintosh, PC (OS/2, NT, etc.) to have it's hostname in any .rhosts file,
+as any user can create a privileged socket without authentication, under these
+environments. In fact, existing ports of CVS to these environment use this
+to their advantage.
+
+-------------------------------------------------------------------------------
+Wildcard expansion is not yet implemented (i.e. CVS COMMIT *.c won't
+work.) I think that expand_wild should be calling lib$findfile
+(util.c in gzip is said to provide an example), but noone has gotten
+around to implementing this.
+
+Log messages must be entered on the command line using -m or -F. You
+can use -e or define the logical EDITOR to cause CVS to try other
+editors (TPU.EXE or any other editor which wants DCL command parsing
+will not work) if you want to test what's available on your system. I
+haven't tested this, but if you install vi or emacs, chances are it
+will probably work. Just make sure the .EXE files are in a directory
+listed in VAXC$PATH (is this a typo for DCL$PATH? Also, will a
+logical name work?). If someone gets around to implementing it, we
+should probably be using the callable editors (e.g. TPU$TPU), although
+of course we also need interface(s) which are not locked into any
+particular editors.
+
+----------------------------------------
+
+Notes regarding compiling on VAX/VMS 6.2 (not Alpha) (These are items
+which hopefully will have cleaner solutions in the future, but here is
+how to get around them for now):
+
+* Need to compile lib/getdate.c with vaxc instead of decc to avoid a
+compiler bugcheck. Therefore one must add SYS$LIBRARY:VAXCRTL/LIBRARY
+to the link.
+
+* In src/ignore.c, change lstat to stat. In vms/filesubr.c, change
+"#ifdef S_ISLNK" to "#if 0".
+
+* Ignore the warnings in vms/vmsmunch.c; the system include file
+declares something as an int when it should be void *. Not *our*
+fault!
+
+Credits:
+
+Initial VMS port by Benjamin J. Lee <benjamin@cyclic.com>, Cyclic
+Software, October 1, 1995 (Update March 1, 1996).
diff --git a/contrib/cvs/TESTS b/contrib/cvs/TESTS
new file mode 100644
index 000000000000..39a38a9292ee
--- /dev/null
+++ b/contrib/cvs/TESTS
@@ -0,0 +1,136 @@
+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
+
+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. In particular, using SGI's Irix 6, the tests
+will fail if TESTDIR is an XFS filesystem (which /tmp often is);
+you'll want to set TESTDIR to a non-XFS filesystem.
+
+You will probably need GNU expr, which is part of the GNU sh-utils
+package (this is just for running the tests; CVS itself doesn't use
+expr).
+
+If there is some unexpected output, that is a failure which can be
+somewhat hard to track down. Finding out which test is producing the
+output is not always easy. The newer tests (that is, ones using
+dotest*) will not have this problem, but there are many old tests
+which have not been converted.
+
+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.
+
+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?>
diff --git a/contrib/cvs/TODO b/contrib/cvs/TODO
index ef9306c3687e..7a9a8166c9db 100644
--- a/contrib/cvs/TODO
+++ b/contrib/cvs/TODO
@@ -1,38 +1,26 @@
-$CVSid: @(#)TODO 1.26 94/09/21 $
-
-14. Pathname stripper, for checkout, as well as for writing the
- Repository file.
- [[ I have a simple one, but need to make sure to call it at all the
- appropriate points ]]
- (I'm not sure what this means -kingdon, Jun 1995).
-
22. Catch signals for cleanup when "add"ing files.
24. Insist on a log message.
- (This should be configurable via commitinfo or some new config file
- -kingdon, Jun 1995).
+ (If done, this should be configurable via commitinfo or some new
+ config file -kingdon, Jun 1995).
30. Add "patch" program option to the modules database.
31. Think hard about ^C recovery.
-35. Add "admin" command as an interface to "rcs".
- [[ a cheesy version is there, but it should be re-done ]]
-
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 allowing parallel source trees that can easily track
- each other.
- [[ sort of solved with the automagic branch support, but I want more ]]
+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.
-45. Consider enhancing the "patch" and "tag" command support in the module
- database -- they seem hard to use since these commands deal directly
- with the RCS ,v files.
-
-46. Perhaps checkout/checkin/tag/patch commands should be imbedded in the
- file system directly, using special known command names?
+45. Consider enhancing the "rdiff" and "tag" (rtag??) command support in
+ the module database -- they seem hard to use since these commands
+ deal directly with the RCS ,v files.
49. cvs xxx commands should be able to deal with files in other
directories. I want to do a cvs add foo/bar.c.
@@ -63,22 +51,12 @@ $CVSid: @(#)TODO 1.26 94/09/21 $
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.
-67. cvs import should populate the vendor sources with CVS.adm files so
- that one could use the vendor sources directly without having the check
- them out.
-
-69. Consider enhacing import to add a module automatically to the module
- database. Perhaps with a new option, or perhaps with an editor.
-
72. Consider re-design of the module -o, -i, -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.
-76. Consider adding a layer of abstraction so that CVS can work with both
- RCS and SCCS files. Larry says this should be #ifdef'ed.
-
79. Might be nice to have some sort of interface to TFS and tagged
revisions.
@@ -91,9 +69,6 @@ $CVSid: @(#)TODO 1.26 94/09/21 $
85. Add revision controlled symbolic links to CVS using one of the tag
fields in the RCS file.
-91. Better document the format of the source repository and how one might
- convert their current SCCS or RCS files into CVS format.
-
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
@@ -156,10 +131,15 @@ $CVSid: @(#)TODO 1.26 94/09/21 $
(why? What is wrong with piping stdout to "tee"? -kingdon, Jun 1995)
119. Consider an option to have import checkout the RCS or SCCS files
- if necessary.
+ if necessary. (this is if someone want to import something which is
+ in RCS or SCCS without preserving the history, but making 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.
+ 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.
@@ -179,13 +159,6 @@ $CVSid: @(#)TODO 1.26 94/09/21 $
128. When I tag a file, the message tells me that I'm tagging a directory.
-129. Something strange seems to have happened here. When I check this out,
- the update lines (U CFTS/...) seem to report a bogus leading CFTS
- (e.g. U CFTS/Medusa_TS/...) when the later files are checked out.
-
- The directory structure doesn't seem to be botched, just the
- messages. I don't recall seeing this before.
-
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.
@@ -197,11 +170,8 @@ $CVSid: @(#)TODO 1.26 94/09/21 $
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.
-
-135. The email CVS sends with each checkin, should include the version
- number of each file it is checking in.
- [[ Sort of solved by contrib/log.pl, which does a good job of this ]]
+ 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
@@ -252,6 +222,10 @@ $CVSid: @(#)TODO 1.26 94/09/21 $
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. On Sun, 2 Feb 92 22:01:38 EST, rouilj@dl5000.bc.edu (John P. Rouillard)
said:
@@ -271,15 +245,30 @@ $CVSid: @(#)TODO 1.26 94/09/21 $
A new command seems appropriate for this. The state can be saved in the
CVS directory. I.e.,
-
- % cvs msg foo.c
+
+ % 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.
+ 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)
+ -kingdon, June 1996)
+
+ 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).
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
@@ -311,10 +300,6 @@ $CVSid: @(#)TODO 1.26 94/09/21 $
the various flags that are now available, or if somebody has a lot of
files to put into a module.
-157. The "cvs release" command does not understand about module names with
- the same flexibility that the "checkout" and "rdiff" commands do.
- It should, though, since it's confusing right now.
-
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
@@ -322,13 +307,6 @@ $CVSid: @(#)TODO 1.26 94/09/21 $
should catch this (typically unusual) case and issue an appropriate
diagnostic and die.
-159. On "update", when a merge is done, CVS should remember that your file
- was merged into and should keep reminding you of this fact until you
- actually look at the file (change its access time). Once you do this,
- it should go back to being a normal, unmodified file. This way, after
- a big update, you can run update again to see which files just got
- merged and may need attention.
-
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
@@ -343,11 +321,6 @@ $CVSid: @(#)TODO 1.26 94/09/21 $
tag (like "Mon", "Tue", ...) all the time and still have it tag the
real main-line code.
-164. The *info files should allow multiple ocurrences of $CVSROOT and/or
- other cvs variables. They probably should *not* expand environment
- variables, as their behavior probably should not depend on who is
- running CVS.
-
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.
@@ -359,22 +332,6 @@ $CVSid: @(#)TODO 1.26 94/09/21 $
- What all the tags mean in an "import" command
- Tags are important; revision numbers are not
-167. "cvs log" doesn't understand about CVS magic branch numbers. As such,
- the command:
-
- cvs log -r1.63.2
- cvs log -rC2
-
- where "C2" is a magic branch that resolves to 1.63.2 do not print the
- same things. Sigh.
-
-169. We are using CVS as the configuration control for a software reuse library.
- What we do is do system calls passing the needed arguments. In the next
- release, it would be nice to see an option to put cvs .o files into a
- archive library with an API. This enhancement would go nicely with the
- notion of being able to integrate tools into a large software engineering
- environment.
-
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
@@ -421,3 +378,45 @@ $CVSid: @(#)TODO 1.26 94/09/21 $
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 -rbar" doesn't
+cut it, because it is inclusive on the bar end. I'm not sure that is
+ever a useful or logical behavior ("cvs diff -r foo -r bar" is not
+similarly inclusive), but is compatibility an issue?
+
+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).
diff --git a/contrib/cvs/acconfig.h b/contrib/cvs/acconfig.h
index 551a8aa6524d..8bbda6ff3b2e 100644
--- a/contrib/cvs/acconfig.h
+++ b/contrib/cvs/acconfig.h
@@ -10,3 +10,9 @@
/* Define if you want to use the password authenticated server. */
#undef AUTH_SERVER_SUPPORT
+
+/* Define if you want encryption support. */
+#undef ENCRYPTION
+
+/* Define if you have the connect function. */
+#undef HAVE_CONNECT
diff --git a/contrib/cvs/config.h.in b/contrib/cvs/config.h.in
index 91819366096c..c731d6d3a7db 100644
--- a/contrib/cvs/config.h.in
+++ b/contrib/cvs/config.h.in
@@ -7,11 +7,6 @@
#undef _ALL_SOURCE
#endif
-/* Define if type char is unsigned and you are not using gcc. */
-#ifndef __CHAR_UNSIGNED__
-#undef __CHAR_UNSIGNED__
-#endif
-
/* Define to empty if the keyword does not work. */
#undef const
@@ -27,9 +22,6 @@
/* Define if utime(file, NULL) sets file's timestamp to the present. */
#undef HAVE_UTIME_NULL
-/* Define as __inline if that's what the C compiler calls it. */
-#undef inline
-
/* Define if on MINIX. */
#undef _MINIX
@@ -77,15 +69,15 @@
/* Define if you want to use the password authenticated server. */
#undef AUTH_SERVER_SUPPORT
-/* The number of bytes in a int. */
-#undef SIZEOF_INT
-
-/* The number of bytes in a long. */
-#undef SIZEOF_LONG
+/* Define if you want encryption support. */
+#undef ENCRYPTION
/* Define if you have the connect function. */
#undef HAVE_CONNECT
+/* Define if you have the crypt function. */
+#undef HAVE_CRYPT
+
/* Define if you have the fchdir function. */
#undef HAVE_FCHDIR
@@ -104,17 +96,26 @@
/* Define if you have the getpagesize function. */
#undef HAVE_GETPAGESIZE
+/* Define if you have the getspnam function. */
+#undef HAVE_GETSPNAM
+
+/* Define if you have the initgroups function. */
+#undef HAVE_INITGROUPS
+
/* Define if you have the krb_get_err_text function. */
#undef HAVE_KRB_GET_ERR_TEXT
/* Define if you have the mkfifo function. */
#undef HAVE_MKFIFO
+/* Define if you have the mktemp function. */
+#undef HAVE_MKTEMP
+
/* Define if you have the putenv function. */
#undef HAVE_PUTENV
-/* Define if you have the setvbuf function. */
-#undef HAVE_SETVBUF
+/* Define if you have the readlink function. */
+#undef HAVE_READLINK
/* Define if you have the sigaction function. */
#undef HAVE_SIGACTION
@@ -131,15 +132,24 @@
/* Define if you have the sigvec function. */
#undef HAVE_SIGVEC
+/* Define if you have the tempnam function. */
+#undef HAVE_TEMPNAM
+
/* Define if you have the timezone function. */
#undef HAVE_TIMEZONE
+/* Define if you have the tzset function. */
+#undef HAVE_TZSET
+
/* Define if you have the vfork function. */
#undef HAVE_VFORK
/* Define if you have the vprintf function. */
#undef HAVE_VPRINTF
+/* Define if you have the wait3 function. */
+#undef HAVE_WAIT3
+
/* Define if you have the <direct.h> header file. */
#undef HAVE_DIRECT_H
@@ -197,6 +207,9 @@
/* Define if you have the <utime.h> header file. */
#undef HAVE_UTIME_H
+/* Define if you have the crypt library (-lcrypt). */
+#undef HAVE_LIBCRYPT
+
/* Define if you have the inet library (-linet). */
#undef HAVE_LIBINET
@@ -206,5 +219,8 @@
/* Define if you have the nsl_s library (-lnsl_s). */
#undef HAVE_LIBNSL_S
+/* Define if you have the sec library (-lsec). */
+#undef HAVE_LIBSEC
+
/* Define if you have the socket library (-lsocket). */
#undef HAVE_LIBSOCKET
diff --git a/contrib/cvs/configure b/contrib/cvs/configure
index 3025eefa4ea6..d35580fd3b2b 100755
--- a/contrib/cvs/configure
+++ b/contrib/cvs/configure
@@ -1,7 +1,7 @@
#! /bin/sh
# Guess values for system-dependent variables and create Makefiles.
-# Generated automatically using autoconf version 2.9
+# Generated automatically using autoconf version 2.10
# Copyright (C) 1992, 93, 94, 95, 96 Free Software Foundation, Inc.
#
# This configure script is free software; the Free Software Foundation
@@ -13,6 +13,14 @@ ac_default_prefix=/usr/local
# Any additions from configure.in:
ac_help="$ac_help
--with-krb4=value set default \$(KRB4) from value"
+ac_help="$ac_help
+ --enable-encryption enable encryption support"
+ac_help="$ac_help
+ --enable-client include code for running as a remote client (default)
+ --disable-client don't include remote client code"
+ac_help="$ac_help
+ --enable-server include code for running as a server (default)
+ --disable-server don't include server code"
# Initialize some variables set by options.
# The variables have the same names as the options, with
@@ -332,7 +340,7 @@ EOF
verbose=yes ;;
-version | --version | --versio | --versi | --vers)
- echo "configure generated by autoconf version 2.9"
+ echo "configure generated by autoconf version 2.10"
exit 0 ;;
-with-* | --with-*)
@@ -602,7 +610,7 @@ else
yes;
#endif
EOF
-if { ac_try='${CC-cc} -E conftest.c'; { (eval echo configure:606: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }; } | egrep yes >/dev/null 2>&1; then
+if { ac_try='${CC-cc} -E conftest.c'; { (eval echo configure:614: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }; } | egrep yes >/dev/null 2>&1; then
ac_cv_prog_gcc=yes
else
ac_cv_prog_gcc=no
@@ -655,13 +663,13 @@ else
# On the NeXT, cc -E runs the code through the compiler's parser,
# not just through cpp.
cat > conftest.$ac_ext <<EOF
-#line 659 "configure"
+#line 667 "configure"
#include "confdefs.h"
#include <assert.h>
Syntax Error
EOF
ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out"
-{ (eval echo configure:665: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }
+{ (eval echo configure:673: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }
ac_err=`grep -v '^ *+' conftest.out`
if test -z "$ac_err"; then
:
@@ -670,13 +678,13 @@ else
rm -rf conftest*
CPP="${CC-cc} -E -traditional-cpp"
cat > conftest.$ac_ext <<EOF
-#line 674 "configure"
+#line 682 "configure"
#include "confdefs.h"
#include <assert.h>
Syntax Error
EOF
ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out"
-{ (eval echo configure:680: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }
+{ (eval echo configure:688: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }
ac_err=`grep -v '^ *+' conftest.out`
if test -z "$ac_err"; then
:
@@ -698,7 +706,7 @@ echo "$ac_t""$CPP" 1>&6
echo $ac_n "checking for AIX""... $ac_c" 1>&6
cat > conftest.$ac_ext <<EOF
-#line 702 "configure"
+#line 710 "configure"
#include "confdefs.h"
#ifdef _AIX
yes
@@ -725,12 +733,12 @@ if eval "test \"`echo '$''{'ac_cv_header_$ac_safe'+set}'`\" = set"; then
echo $ac_n "(cached) $ac_c" 1>&6
else
cat > conftest.$ac_ext <<EOF
-#line 729 "configure"
+#line 737 "configure"
#include "confdefs.h"
#include <minix/config.h>
EOF
ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out"
-{ (eval echo configure:734: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }
+{ (eval echo configure:742: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }
ac_err=`grep -v '^ *+' conftest.out`
if test -z "$ac_err"; then
rm -rf conftest*
@@ -787,6 +795,7 @@ fi
if test "$ISC" = yes; then
CFLAGS="$CFLAGS -D_SYSV3"
+LIBS="-lcrypt $LIBS"
fi
if test "x$prefix" = xNONE; then
@@ -836,11 +845,11 @@ else
ac_cv_c_cross=yes
else
cat > conftest.$ac_ext <<EOF
-#line 840 "configure"
+#line 849 "configure"
#include "confdefs.h"
main(){return(0);}
EOF
-{ (eval echo configure:844: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }
+{ (eval echo configure:853: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }
if test -s conftest && (./conftest; exit) 2>/dev/null; then
ac_cv_c_cross=no
else
@@ -859,7 +868,7 @@ if eval "test \"`echo '$''{'ac_cv_c_const'+set}'`\" = set"; then
echo $ac_n "(cached) $ac_c" 1>&6
else
cat > conftest.$ac_ext <<EOF
-#line 863 "configure"
+#line 872 "configure"
#include "confdefs.h"
int main() { return 0; }
@@ -909,7 +918,7 @@ ccp = (char const *const *) p;
; return 0; }
EOF
-if { (eval echo configure:913: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then
+if { (eval echo configure:922: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then
rm -rf conftest*
ac_cv_c_const=yes
else
@@ -928,102 +937,6 @@ EOF
fi
-echo $ac_n "checking whether char is unsigned""... $ac_c" 1>&6
-if eval "test \"`echo '$''{'ac_cv_c_char_unsigned'+set}'`\" = set"; then
- echo $ac_n "(cached) $ac_c" 1>&6
-else
- if test "$GCC" = yes; then
- # GCC predefines this symbol on systems where it applies.
-cat > conftest.$ac_ext <<EOF
-#line 939 "configure"
-#include "confdefs.h"
-#ifdef __CHAR_UNSIGNED__
- yes
-#endif
-
-EOF
-if (eval "$ac_cpp conftest.$ac_ext") 2>&5 |
- egrep "yes" >/dev/null 2>&1; then
- rm -rf conftest*
- ac_cv_c_char_unsigned=yes
-else
- rm -rf conftest*
- ac_cv_c_char_unsigned=no
-fi
-rm -f conftest*
-
-else
-if test "$cross_compiling" = yes; then
- { echo "configure: error: can not run test program while cross compiling" 1>&2; exit 1; }
-else
-cat > conftest.$ac_ext <<EOF
-#line 961 "configure"
-#include "confdefs.h"
-/* volatile prevents gcc2 from optimizing the test away on sparcs. */
-#if !defined(__STDC__) || __STDC__ != 1
-#define volatile
-#endif
-main() {
- volatile char c = 255; exit(c < 0);
-}
-EOF
-{ (eval echo configure:971: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }
-if test -s conftest && (./conftest; exit) 2>/dev/null; then
- ac_cv_c_char_unsigned=yes
-else
- ac_cv_c_char_unsigned=no
-fi
-fi
-rm -fr conftest*
-fi
-fi
-
-echo "$ac_t""$ac_cv_c_char_unsigned" 1>&6
-if test $ac_cv_c_char_unsigned = yes && test "$GCC" != yes; then
- cat >> confdefs.h <<\EOF
-#define __CHAR_UNSIGNED__ 1
-EOF
-
-fi
-
-echo $ac_n "checking for inline""... $ac_c" 1>&6
-if eval "test \"`echo '$''{'ac_cv_c_inline'+set}'`\" = set"; then
- echo $ac_n "(cached) $ac_c" 1>&6
-else
- ac_cv_c_inline=no
-for ac_kw in inline __inline__ __inline; do
- cat > conftest.$ac_ext <<EOF
-#line 997 "configure"
-#include "confdefs.h"
-
-int main() { return 0; }
-int t() {
-} $ac_kw foo() {
-; return 0; }
-EOF
-if { (eval echo configure:1005: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then
- rm -rf conftest*
- ac_cv_c_inline=$ac_kw; break
-fi
-rm -f conftest*
-
-done
-
-fi
-
-echo "$ac_t""$ac_cv_c_inline" 1>&6
-case "$ac_cv_c_inline" in
- inline | yes) ;;
- no) cat >> confdefs.h <<\EOF
-#define inline
-EOF
- ;;
- *) cat >> confdefs.h <<EOF
-#define inline $ac_cv_c_inline
-EOF
- ;;
-esac
-
ac_aux_dir=
for ac_dir in $srcdir $srcdir/.. $srcdir/../..; do
@@ -1286,7 +1199,7 @@ if eval "test \"`echo '$''{'ac_cv_header_stdc'+set}'`\" = set"; then
echo $ac_n "(cached) $ac_c" 1>&6
else
cat > conftest.$ac_ext <<EOF
-#line 1290 "configure"
+#line 1203 "configure"
#include "confdefs.h"
#include <stdlib.h>
#include <stdarg.h>
@@ -1294,7 +1207,7 @@ else
#include <float.h>
EOF
ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out"
-{ (eval echo configure:1298: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }
+{ (eval echo configure:1211: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }
ac_err=`grep -v '^ *+' conftest.out`
if test -z "$ac_err"; then
rm -rf conftest*
@@ -1309,7 +1222,7 @@ rm -f conftest*
if test $ac_cv_header_stdc = yes; then
# SunOS 4.x string.h does not declare mem*, contrary to ANSI.
cat > conftest.$ac_ext <<EOF
-#line 1313 "configure"
+#line 1226 "configure"
#include "confdefs.h"
#include <string.h>
EOF
@@ -1327,7 +1240,7 @@ fi
if test $ac_cv_header_stdc = yes; then
# ISC 2.0.2 stdlib.h does not declare free, contrary to ANSI.
cat > conftest.$ac_ext <<EOF
-#line 1331 "configure"
+#line 1244 "configure"
#include "confdefs.h"
#include <stdlib.h>
EOF
@@ -1348,7 +1261,7 @@ if test "$cross_compiling" = yes; then
:
else
cat > conftest.$ac_ext <<EOF
-#line 1352 "configure"
+#line 1265 "configure"
#include "confdefs.h"
#include <ctype.h>
#define ISLOWER(c) ('a' <= (c) && (c) <= 'z')
@@ -1359,7 +1272,7 @@ if (XOR (islower (i), ISLOWER (i)) || toupper (i) != TOUPPER (i)) exit(2);
exit (0); }
EOF
-{ (eval echo configure:1363: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }
+{ (eval echo configure:1276: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }
if test -s conftest && (./conftest; exit) 2>/dev/null; then
:
else
@@ -1388,12 +1301,12 @@ if eval "test \"`echo '$''{'ac_cv_header_$ac_safe'+set}'`\" = set"; then
echo $ac_n "(cached) $ac_c" 1>&6
else
cat > conftest.$ac_ext <<EOF
-#line 1392 "configure"
+#line 1305 "configure"
#include "confdefs.h"
#include <$ac_hdr>
EOF
ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out"
-{ (eval echo configure:1397: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }
+{ (eval echo configure:1310: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }
ac_err=`grep -v '^ *+' conftest.out`
if test -z "$ac_err"; then
rm -rf conftest*
@@ -1422,7 +1335,7 @@ if eval "test \"`echo '$''{'ac_cv_header_sys_wait_h'+set}'`\" = set"; then
echo $ac_n "(cached) $ac_c" 1>&6
else
cat > conftest.$ac_ext <<EOF
-#line 1426 "configure"
+#line 1339 "configure"
#include "confdefs.h"
#include <sys/types.h>
#include <sys/wait.h>
@@ -1439,7 +1352,7 @@ wait (&s);
s = WIFEXITED (s) ? WEXITSTATUS (s) : 1;
; return 0; }
EOF
-if { (eval echo configure:1443: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then
+if { (eval echo configure:1356: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then
rm -rf conftest*
ac_cv_header_sys_wait_h=yes
else
@@ -1463,7 +1376,7 @@ if eval "test \"`echo '$''{'ac_cv_header_stat_broken'+set}'`\" = set"; then
echo $ac_n "(cached) $ac_c" 1>&6
else
cat > conftest.$ac_ext <<EOF
-#line 1467 "configure"
+#line 1380 "configure"
#include "confdefs.h"
#include <sys/types.h>
#include <sys/stat.h>
@@ -1518,7 +1431,7 @@ if eval "test \"`echo '$''{'ac_cv_header_time'+set}'`\" = set"; then
echo $ac_n "(cached) $ac_c" 1>&6
else
cat > conftest.$ac_ext <<EOF
-#line 1522 "configure"
+#line 1435 "configure"
#include "confdefs.h"
#include <sys/types.h>
#include <sys/time.h>
@@ -1528,7 +1441,7 @@ int t() {
struct tm *tp;
; return 0; }
EOF
-if { (eval echo configure:1532: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then
+if { (eval echo configure:1445: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then
rm -rf conftest*
ac_cv_header_time=yes
else
@@ -1556,7 +1469,7 @@ if eval "test \"`echo '$''{'ac_cv_header_dirent_$ac_safe'+set}'`\" = set"; then
echo $ac_n "(cached) $ac_c" 1>&6
else
cat > conftest.$ac_ext <<EOF
-#line 1560 "configure"
+#line 1473 "configure"
#include "confdefs.h"
#include <sys/types.h>
#include <$ac_hdr>
@@ -1565,7 +1478,7 @@ int t() {
DIR *dirp = 0;
; return 0; }
EOF
-if { (eval echo configure:1569: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then
+if { (eval echo configure:1482: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then
rm -rf conftest*
eval "ac_cv_header_dirent_$ac_safe=yes"
else
@@ -1589,16 +1502,18 @@ done
# Two versions of opendir et al. are in -ldir and -lx on SCO Xenix.
if test $ac_header_dirent = dirent.h; then
echo $ac_n "checking for -ldir""... $ac_c" 1>&6
-ac_lib_var=`echo dir_opendir | tr '.-/+' '___p'`
+ac_lib_var=`echo dir'_'opendir | tr './+\055' '__p_'`
if eval "test \"`echo '$''{'ac_cv_lib_$ac_lib_var'+set}'`\" = set"; then
echo $ac_n "(cached) $ac_c" 1>&6
else
ac_save_LIBS="$LIBS"
LIBS="-ldir $LIBS"
cat > conftest.$ac_ext <<EOF
-#line 1600 "configure"
+#line 1513 "configure"
#include "confdefs.h"
/* Override any gcc2 internal prototype to avoid an error. */
+/* We use char because int might match the return type of a gcc2
+ builtin and then its argument prototype would still apply. */
char opendir();
int main() { return 0; }
@@ -1606,7 +1521,7 @@ int t() {
opendir()
; return 0; }
EOF
-if { (eval echo configure:1610: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
+if { (eval echo configure:1525: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
rm -rf conftest*
eval "ac_cv_lib_$ac_lib_var=yes"
else
@@ -1626,16 +1541,18 @@ fi
else
echo $ac_n "checking for -lx""... $ac_c" 1>&6
-ac_lib_var=`echo x_opendir | tr '.-/+' '___p'`
+ac_lib_var=`echo x'_'opendir | tr './+\055' '__p_'`
if eval "test \"`echo '$''{'ac_cv_lib_$ac_lib_var'+set}'`\" = set"; then
echo $ac_n "(cached) $ac_c" 1>&6
else
ac_save_LIBS="$LIBS"
LIBS="-lx $LIBS"
cat > conftest.$ac_ext <<EOF
-#line 1637 "configure"
+#line 1552 "configure"
#include "confdefs.h"
/* Override any gcc2 internal prototype to avoid an error. */
+/* We use char because int might match the return type of a gcc2
+ builtin and then its argument prototype would still apply. */
char opendir();
int main() { return 0; }
@@ -1643,7 +1560,7 @@ int t() {
opendir()
; return 0; }
EOF
-if { (eval echo configure:1647: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
+if { (eval echo configure:1564: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
rm -rf conftest*
eval "ac_cv_lib_$ac_lib_var=yes"
else
@@ -1668,7 +1585,7 @@ if eval "test \"`echo '$''{'ac_cv_type_signal'+set}'`\" = set"; then
echo $ac_n "(cached) $ac_c" 1>&6
else
cat > conftest.$ac_ext <<EOF
-#line 1672 "configure"
+#line 1589 "configure"
#include "confdefs.h"
#include <sys/types.h>
#include <signal.h>
@@ -1686,7 +1603,7 @@ int t() {
int i;
; return 0; }
EOF
-if { (eval echo configure:1690: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then
+if { (eval echo configure:1607: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then
rm -rf conftest*
ac_cv_type_signal=void
else
@@ -1708,7 +1625,7 @@ if eval "test \"`echo '$''{'ac_cv_type_uid_t'+set}'`\" = set"; then
echo $ac_n "(cached) $ac_c" 1>&6
else
cat > conftest.$ac_ext <<EOF
-#line 1712 "configure"
+#line 1629 "configure"
#include "confdefs.h"
#include <sys/types.h>
EOF
@@ -1741,7 +1658,7 @@ if eval "test \"`echo '$''{'ac_cv_type_mode_t'+set}'`\" = set"; then
echo $ac_n "(cached) $ac_c" 1>&6
else
cat > conftest.$ac_ext <<EOF
-#line 1745 "configure"
+#line 1662 "configure"
#include "confdefs.h"
#include <sys/types.h>
#if STDC_HEADERS
@@ -1772,7 +1689,7 @@ if eval "test \"`echo '$''{'ac_cv_type_size_t'+set}'`\" = set"; then
echo $ac_n "(cached) $ac_c" 1>&6
else
cat > conftest.$ac_ext <<EOF
-#line 1776 "configure"
+#line 1693 "configure"
#include "confdefs.h"
#include <sys/types.h>
#if STDC_HEADERS
@@ -1803,7 +1720,7 @@ if eval "test \"`echo '$''{'ac_cv_type_pid_t'+set}'`\" = set"; then
echo $ac_n "(cached) $ac_c" 1>&6
else
cat > conftest.$ac_ext <<EOF
-#line 1807 "configure"
+#line 1724 "configure"
#include "confdefs.h"
#include <sys/types.h>
#if STDC_HEADERS
@@ -1829,19 +1746,21 @@ EOF
fi
-for ac_func in getwd mkdir rename strdup strstr dup2 strerror valloc waitpid memmove vasprintf strtoul
+for ac_func in getwd mkdir rename strdup strstr dup2 strerror valloc waitpid vasprintf strtoul
do
echo $ac_n "checking for $ac_func""... $ac_c" 1>&6
if eval "test \"`echo '$''{'ac_cv_func_$ac_func'+set}'`\" = set"; then
echo $ac_n "(cached) $ac_c" 1>&6
else
cat > conftest.$ac_ext <<EOF
-#line 1840 "configure"
+#line 1757 "configure"
#include "confdefs.h"
/* System header to define __stub macros and hopefully few prototypes,
which can conflict with char $ac_func(); below. */
#include <assert.h>
/* Override any gcc2 internal prototype to avoid an error. */
+/* We use char because int might match the return type of a gcc2
+ builtin and then its argument prototype would still apply. */
char $ac_func();
int main() { return 0; }
@@ -1858,7 +1777,7 @@ $ac_func();
; return 0; }
EOF
-if { (eval echo configure:1862: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
+if { (eval echo configure:1781: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
rm -rf conftest*
eval "ac_cv_func_$ac_func=yes"
else
@@ -1878,19 +1797,123 @@ fi
done
-for ac_func in fchmod fsync ftime mkfifo putenv setvbuf vfork vprintf ftruncate timezone getpagesize initgroups fchdir sigaction sigprocmask sigvec sigsetmask sigblock
+for ac_func in fchmod fsync ftime mkfifo mktemp putenv vfork vprintf ftruncate timezone getpagesize initgroups fchdir sigaction sigprocmask sigvec sigsetmask sigblock tempnam tzset readlink wait3
+do
+echo $ac_n "checking for $ac_func""... $ac_c" 1>&6
+if eval "test \"`echo '$''{'ac_cv_func_$ac_func'+set}'`\" = set"; then
+ echo $ac_n "(cached) $ac_c" 1>&6
+else
+ cat > conftest.$ac_ext <<EOF
+#line 1808 "configure"
+#include "confdefs.h"
+/* System header to define __stub macros and hopefully few prototypes,
+ which can conflict with char $ac_func(); below. */
+#include <assert.h>
+/* Override any gcc2 internal prototype to avoid an error. */
+/* We use char because int might match the return type of a gcc2
+ builtin and then its argument prototype would still apply. */
+char $ac_func();
+
+int main() { return 0; }
+int t() {
+
+/* The GNU C library defines this for functions which it implements
+ to always fail with ENOSYS. Some functions are actually named
+ something starting with __ and the normal name is an alias. */
+#if defined (__stub_$ac_func) || defined (__stub___$ac_func)
+choke me
+#else
+$ac_func();
+#endif
+
+; return 0; }
+EOF
+if { (eval echo configure:1832: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
+ rm -rf conftest*
+ eval "ac_cv_func_$ac_func=yes"
+else
+ rm -rf conftest*
+ eval "ac_cv_func_$ac_func=no"
+fi
+rm -f conftest*
+
+fi
+if eval "test \"`echo '$ac_cv_func_'$ac_func`\" = yes"; then
+ echo "$ac_t""yes" 1>&6
+ ac_tr_func=HAVE_`echo $ac_func | tr 'abcdefghijklmnopqrstuvwxyz' 'ABCDEFGHIJKLMNOPQRSTUVWXYZ'`
+ cat >> confdefs.h <<EOF
+#define $ac_tr_func 1
+EOF
+
+else
+ echo "$ac_t""no" 1>&6
+fi
+done
+
+
+echo $ac_n "checking for evidence of shadow passwords""... $ac_c" 1>&6
+if test -f /etc/shadow \
+ || test -f /etc/security/passwd.adjunct ; then
+ found="yes"
+ echo $ac_n "checking for -lsec""... $ac_c" 1>&6
+ac_lib_var=`echo sec'_'getspnam | tr './+\055' '__p_'`
+if eval "test \"`echo '$''{'ac_cv_lib_$ac_lib_var'+set}'`\" = set"; then
+ echo $ac_n "(cached) $ac_c" 1>&6
+else
+ ac_save_LIBS="$LIBS"
+LIBS="-lsec $LIBS"
+cat > conftest.$ac_ext <<EOF
+#line 1867 "configure"
+#include "confdefs.h"
+/* Override any gcc2 internal prototype to avoid an error. */
+/* We use char because int might match the return type of a gcc2
+ builtin and then its argument prototype would still apply. */
+char getspnam();
+
+int main() { return 0; }
+int t() {
+getspnam()
+; return 0; }
+EOF
+if { (eval echo configure:1879: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
+ rm -rf conftest*
+ eval "ac_cv_lib_$ac_lib_var=yes"
+else
+ rm -rf conftest*
+ eval "ac_cv_lib_$ac_lib_var=no"
+fi
+rm -f conftest*
+LIBS="$ac_save_LIBS"
+
+fi
+if eval "test \"`echo '$ac_cv_lib_'$ac_lib_var`\" = yes"; then
+ echo "$ac_t""yes" 1>&6
+ ac_tr_lib=HAVE_LIB`echo sec | tr 'abcdefghijklmnopqrstuvwxyz' 'ABCDEFGHIJKLMNOPQRSTUVWXYZ'`
+ cat >> confdefs.h <<EOF
+#define $ac_tr_lib 1
+EOF
+
+ LIBS="-lsec $LIBS"
+
+else
+ echo "$ac_t""no" 1>&6
+fi
+
+ for ac_func in getspnam
do
echo $ac_n "checking for $ac_func""... $ac_c" 1>&6
if eval "test \"`echo '$''{'ac_cv_func_$ac_func'+set}'`\" = set"; then
echo $ac_n "(cached) $ac_c" 1>&6
else
cat > conftest.$ac_ext <<EOF
-#line 1889 "configure"
+#line 1910 "configure"
#include "confdefs.h"
/* System header to define __stub macros and hopefully few prototypes,
which can conflict with char $ac_func(); below. */
#include <assert.h>
/* Override any gcc2 internal prototype to avoid an error. */
+/* We use char because int might match the return type of a gcc2
+ builtin and then its argument prototype would still apply. */
char $ac_func();
int main() { return 0; }
@@ -1907,7 +1930,7 @@ $ac_func();
; return 0; }
EOF
-if { (eval echo configure:1911: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
+if { (eval echo configure:1934: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
rm -rf conftest*
eval "ac_cv_func_$ac_func=yes"
else
@@ -1929,17 +1952,24 @@ else
fi
done
+else
+ found="no"
+fi
+echo "$ac_t""$found" 1>&6
+
echo $ac_n "checking for re_exec""... $ac_c" 1>&6
if eval "test \"`echo '$''{'ac_cv_func_re_exec'+set}'`\" = set"; then
echo $ac_n "(cached) $ac_c" 1>&6
else
cat > conftest.$ac_ext <<EOF
-#line 1938 "configure"
+#line 1966 "configure"
#include "confdefs.h"
/* System header to define __stub macros and hopefully few prototypes,
which can conflict with char re_exec(); below. */
#include <assert.h>
/* Override any gcc2 internal prototype to avoid an error. */
+/* We use char because int might match the return type of a gcc2
+ builtin and then its argument prototype would still apply. */
char re_exec();
int main() { return 0; }
@@ -1956,7 +1986,7 @@ re_exec();
; return 0; }
EOF
-if { (eval echo configure:1960: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
+if { (eval echo configure:1990: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
rm -rf conftest*
eval "ac_cv_func_re_exec=yes"
else
@@ -1984,7 +2014,7 @@ if test "$cross_compiling" = yes; then
ac_cv_func_utime_null=no
else
cat > conftest.$ac_ext <<EOF
-#line 1988 "configure"
+#line 2018 "configure"
#include "confdefs.h"
#include <sys/types.h>
#include <sys/stat.h>
@@ -1995,7 +2025,7 @@ exit(!(stat ("conftestdata", &s) == 0 && utime("conftestdata", (long *)0) == 0
&& t.st_mtime - s.st_mtime < 120));
}
EOF
-{ (eval echo configure:1999: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }
+{ (eval echo configure:2029: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }
if test -s conftest && (./conftest; exit) 2>/dev/null; then
ac_cv_func_utime_null=yes
else
@@ -2059,7 +2089,7 @@ else
ccvs_cv_sys_working_fnmatch=no
else
cat > conftest.$ac_ext <<EOF
-#line 2063 "configure"
+#line 2093 "configure"
#include "confdefs.h"
#include <fnmatch.h>
@@ -2071,7 +2101,7 @@ main ()
? 0 : 1);
}
EOF
-{ (eval echo configure:2075: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }
+{ (eval echo configure:2105: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }
if test -s conftest && (./conftest; exit) 2>/dev/null; then
ccvs_cv_sys_working_fnmatch=yes
else
@@ -2086,323 +2116,24 @@ if test $ccvs_cv_sys_working_fnmatch = no; then
fi
echo "$ac_t""$ccvs_cv_sys_working_fnmatch" 1>&6
-KRB4=/usr/kerberos
-
-# Check whether --with-krb4 or --without-krb4 was given.
-if test "${with_krb4+set}" = set; then
- withval="$with_krb4"
- KRB4=$withval
-fi
-echo "default place for krb4 is $KRB4"
-
-
-echo $ac_n "checking size of long""... $ac_c" 1>&6
-if eval "test \"`echo '$''{'ac_cv_sizeof_long'+set}'`\" = set"; then
- echo $ac_n "(cached) $ac_c" 1>&6
-else
- if test "$cross_compiling" = yes; then
- { echo "configure: error: can not run test program while cross compiling" 1>&2; exit 1; }
-else
-cat > conftest.$ac_ext <<EOF
-#line 2108 "configure"
-#include "confdefs.h"
-#include <stdio.h>
-main()
-{
- FILE *f=fopen("conftestval", "w");
- if (!f) exit(1);
- fprintf(f, "%d\n", sizeof(long));
- exit(0);
-}
-EOF
-{ (eval echo configure:2119: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }
-if test -s conftest && (./conftest; exit) 2>/dev/null; then
- ac_cv_sizeof_long=`cat conftestval`
-else
- ac_cv_sizeof_long=0
-fi
-fi
-rm -fr conftest*
-fi
-echo "$ac_t""$ac_cv_sizeof_long" 1>&6
-cat >> confdefs.h <<EOF
-#define SIZEOF_LONG $ac_cv_sizeof_long
-EOF
-
-
-echo $ac_n "checking size of int""... $ac_c" 1>&6
-if eval "test \"`echo '$''{'ac_cv_sizeof_int'+set}'`\" = set"; then
- echo $ac_n "(cached) $ac_c" 1>&6
-else
- if test "$cross_compiling" = yes; then
- { echo "configure: error: can not run test program while cross compiling" 1>&2; exit 1; }
-else
-cat > conftest.$ac_ext <<EOF
-#line 2142 "configure"
-#include "confdefs.h"
-#include <stdio.h>
-main()
-{
- FILE *f=fopen("conftestval", "w");
- if (!f) exit(1);
- fprintf(f, "%d\n", sizeof(int));
- exit(0);
-}
-EOF
-{ (eval echo configure:2153: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }
-if test -s conftest && (./conftest; exit) 2>/dev/null; then
- ac_cv_sizeof_int=`cat conftestval`
-else
- ac_cv_sizeof_int=0
-fi
-fi
-rm -fr conftest*
-fi
-echo "$ac_t""$ac_cv_sizeof_int" 1>&6
-cat >> confdefs.h <<EOF
-#define SIZEOF_INT $ac_cv_sizeof_int
-EOF
-
-
-
-krb_h=
-echo $ac_n "checking for krb.h""... $ac_c" 1>&6
-cat > conftest.$ac_ext <<EOF
-#line 2172 "configure"
-#include "confdefs.h"
-#include <krb.h>
-int main() { return 0; }
-int t() {
-int i;
-; return 0; }
-EOF
-if { (eval echo configure:2180: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
- rm -rf conftest*
- krb_h=yes krb_incdir=
-else
- rm -rf conftest*
- if test "$cross_compiling" != yes && test -r $KRB4/include/krb.h; then
- hold_cflags=$CFLAGS
- CFLAGS="$CFLAGS -I$KRB4/include"
- cat > conftest.$ac_ext <<EOF
-#line 2189 "configure"
-#include "confdefs.h"
-#include <krb.h>
-int main() { return 0; }
-int t() {
-int i;
-; return 0; }
-EOF
-if { (eval echo configure:2197: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
- rm -rf conftest*
- krb_h=yes krb_incdir=$KRB4/include
-fi
-rm -f conftest*
-
- CFLAGS=$hold_cflags
- fi
-fi
-rm -f conftest*
-
-if test -z "$krb_h"; then
- cat > conftest.$ac_ext <<EOF
-#line 2210 "configure"
-#include "confdefs.h"
-#include <krb.h>
-int main() { return 0; }
-int t() {
-int i;
-; return 0; }
-EOF
-if { (eval echo configure:2218: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
- rm -rf conftest*
- krb_h=yes krb_incdir=
-else
- rm -rf conftest*
- if test "$cross_compiling" != yes && test -r $KRB4/include/kerberosIV/krb.h; then
- hold_cflags=$CFLAGS
- CFLAGS="$CFLAGS -I$KRB4/include/kerberosIV"
- cat > conftest.$ac_ext <<EOF
-#line 2227 "configure"
-#include "confdefs.h"
-#include <krb.h>
-int main() { return 0; }
-int t() {
-int i;
-; return 0; }
-EOF
-if { (eval echo configure:2235: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
- rm -rf conftest*
- krb_h=yes krb_incdir=$KRB4/include/kerberosIV
-fi
-rm -f conftest*
-
- CFLAGS=$hold_cflags
- fi
-fi
-rm -f conftest*
-
-fi
-echo "$ac_t""$krb_h" 1>&6
-
-if test -n "$krb_h"; then
- krb_lib=
- echo $ac_n "checking for -lkrb""... $ac_c" 1>&6
-ac_lib_var=`echo krb_printf | tr '.-/+' '___p'`
-if eval "test \"`echo '$''{'ac_cv_lib_$ac_lib_var'+set}'`\" = set"; then
- echo $ac_n "(cached) $ac_c" 1>&6
-else
- ac_save_LIBS="$LIBS"
-LIBS="-lkrb $LIBS"
-cat > conftest.$ac_ext <<EOF
-#line 2259 "configure"
-#include "confdefs.h"
-/* Override any gcc2 internal prototype to avoid an error. */
-char printf();
-
-int main() { return 0; }
-int t() {
-printf()
-; return 0; }
-EOF
-if { (eval echo configure:2269: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
- rm -rf conftest*
- eval "ac_cv_lib_$ac_lib_var=yes"
-else
- rm -rf conftest*
- eval "ac_cv_lib_$ac_lib_var=no"
-fi
-rm -f conftest*
-LIBS="$ac_save_LIBS"
-
-fi
-if eval "test \"`echo '$ac_cv_lib_'$ac_lib_var`\" = yes"; then
- echo "$ac_t""yes" 1>&6
- krb_lib=yes krb_libdir=
-else
- echo "$ac_t""no" 1>&6
-if test "$cross_compiling" != yes && test -r $KRB4/lib/libkrb.a; then
- krb_lib=yes krb_libdir=$KRB4/lib
- fi
-fi
-
- if test -n "$krb_lib"; then
- cat >> confdefs.h <<\EOF
-#define HAVE_KERBEROS 1
-EOF
-
- test -n "${krb_libdir}" && LIBS="${LIBS} -L${krb_libdir}"
- LIBS="${LIBS} -lkrb"
- echo $ac_n "checking for -ldes""... $ac_c" 1>&6
-ac_lib_var=`echo des_printf | tr '.-/+' '___p'`
-if eval "test \"`echo '$''{'ac_cv_lib_$ac_lib_var'+set}'`\" = set"; then
- echo $ac_n "(cached) $ac_c" 1>&6
-else
- ac_save_LIBS="$LIBS"
-LIBS="-ldes $LIBS"
-cat > conftest.$ac_ext <<EOF
-#line 2305 "configure"
-#include "confdefs.h"
-/* Override any gcc2 internal prototype to avoid an error. */
-char printf();
-
-int main() { return 0; }
-int t() {
-printf()
-; return 0; }
-EOF
-if { (eval echo configure:2315: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
- rm -rf conftest*
- eval "ac_cv_lib_$ac_lib_var=yes"
-else
- rm -rf conftest*
- eval "ac_cv_lib_$ac_lib_var=no"
-fi
-rm -f conftest*
-LIBS="$ac_save_LIBS"
-
-fi
-if eval "test \"`echo '$ac_cv_lib_'$ac_lib_var`\" = yes"; then
- echo "$ac_t""yes" 1>&6
- LIBS="${LIBS} -ldes"
-else
- echo "$ac_t""no" 1>&6
-fi
-
- if test -n "$krb_incdir"; then
- includeopt="${includeopt} -I$krb_incdir"
-
- fi
- fi
-fi
-for ac_func in krb_get_err_text
-do
-echo $ac_n "checking for $ac_func""... $ac_c" 1>&6
-if eval "test \"`echo '$''{'ac_cv_func_$ac_func'+set}'`\" = set"; then
- echo $ac_n "(cached) $ac_c" 1>&6
-else
- cat > conftest.$ac_ext <<EOF
-#line 2346 "configure"
-#include "confdefs.h"
-/* System header to define __stub macros and hopefully few prototypes,
- which can conflict with char $ac_func(); below. */
-#include <assert.h>
-/* Override any gcc2 internal prototype to avoid an error. */
-char $ac_func();
-
-int main() { return 0; }
-int t() {
-
-/* The GNU C library defines this for functions which it implements
- to always fail with ENOSYS. Some functions are actually named
- something starting with __ and the normal name is an alias. */
-#if defined (__stub_$ac_func) || defined (__stub___$ac_func)
-choke me
-#else
-$ac_func();
-#endif
-
-; return 0; }
-EOF
-if { (eval echo configure:2368: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
- rm -rf conftest*
- eval "ac_cv_func_$ac_func=yes"
-else
- rm -rf conftest*
- eval "ac_cv_func_$ac_func=no"
-fi
-rm -f conftest*
-
-fi
-if eval "test \"`echo '$ac_cv_func_'$ac_func`\" = yes"; then
- echo "$ac_t""yes" 1>&6
- ac_tr_func=HAVE_`echo $ac_func | tr 'abcdefghijklmnopqrstuvwxyz' 'ABCDEFGHIJKLMNOPQRSTUVWXYZ'`
- cat >> confdefs.h <<EOF
-#define $ac_tr_func 1
-EOF
-
-else
- echo "$ac_t""no" 1>&6
-fi
-done
-
# If we can't find connect, try looking in -lsocket, -lnsl, and -linet.
# The Irix 5 libc.so has connect and gethostbyname, but Irix 5 also has
# libsocket.so which has a bad implementation of gethostbyname (it
# only looks in /etc/hosts), so we only look for -lsocket if we need
# it.
-unset ac_cv_func_connect
echo $ac_n "checking for connect""... $ac_c" 1>&6
if eval "test \"`echo '$''{'ac_cv_func_connect'+set}'`\" = set"; then
echo $ac_n "(cached) $ac_c" 1>&6
else
cat > conftest.$ac_ext <<EOF
-#line 2401 "configure"
+#line 2130 "configure"
#include "confdefs.h"
/* System header to define __stub macros and hopefully few prototypes,
which can conflict with char connect(); below. */
#include <assert.h>
/* Override any gcc2 internal prototype to avoid an error. */
+/* We use char because int might match the return type of a gcc2
+ builtin and then its argument prototype would still apply. */
char connect();
int main() { return 0; }
@@ -2419,7 +2150,7 @@ connect();
; return 0; }
EOF
-if { (eval echo configure:2423: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
+if { (eval echo configure:2154: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
rm -rf conftest*
eval "ac_cv_func_connect=yes"
else
@@ -2437,16 +2168,18 @@ else
case "$LIBS" in
*-lnsl*) ;;
*) echo $ac_n "checking for -lnsl_s""... $ac_c" 1>&6
-ac_lib_var=`echo nsl_s_printf | tr '.-/+' '___p'`
+ac_lib_var=`echo nsl_s'_'printf | tr './+\055' '__p_'`
if eval "test \"`echo '$''{'ac_cv_lib_$ac_lib_var'+set}'`\" = set"; then
echo $ac_n "(cached) $ac_c" 1>&6
else
ac_save_LIBS="$LIBS"
LIBS="-lnsl_s $LIBS"
cat > conftest.$ac_ext <<EOF
-#line 2448 "configure"
+#line 2179 "configure"
#include "confdefs.h"
/* Override any gcc2 internal prototype to avoid an error. */
+/* We use char because int might match the return type of a gcc2
+ builtin and then its argument prototype would still apply. */
char printf();
int main() { return 0; }
@@ -2454,7 +2187,7 @@ int t() {
printf()
; return 0; }
EOF
-if { (eval echo configure:2458: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
+if { (eval echo configure:2191: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
rm -rf conftest*
eval "ac_cv_lib_$ac_lib_var=yes"
else
@@ -2482,16 +2215,18 @@ esac
case "$LIBS" in
*-lnsl*) ;;
*) echo $ac_n "checking for -lnsl""... $ac_c" 1>&6
-ac_lib_var=`echo nsl_printf | tr '.-/+' '___p'`
+ac_lib_var=`echo nsl'_'printf | tr './+\055' '__p_'`
if eval "test \"`echo '$''{'ac_cv_lib_$ac_lib_var'+set}'`\" = set"; then
echo $ac_n "(cached) $ac_c" 1>&6
else
ac_save_LIBS="$LIBS"
LIBS="-lnsl $LIBS"
cat > conftest.$ac_ext <<EOF
-#line 2493 "configure"
+#line 2226 "configure"
#include "confdefs.h"
/* Override any gcc2 internal prototype to avoid an error. */
+/* We use char because int might match the return type of a gcc2
+ builtin and then its argument prototype would still apply. */
char printf();
int main() { return 0; }
@@ -2499,7 +2234,7 @@ int t() {
printf()
; return 0; }
EOF
-if { (eval echo configure:2503: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
+if { (eval echo configure:2238: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
rm -rf conftest*
eval "ac_cv_lib_$ac_lib_var=yes"
else
@@ -2527,16 +2262,18 @@ esac
case "$LIBS" in
*-lsocket*) ;;
*) echo $ac_n "checking for -lsocket""... $ac_c" 1>&6
-ac_lib_var=`echo socket_connect | tr '.-/+' '___p'`
+ac_lib_var=`echo socket'_'connect | tr './+\055' '__p_'`
if eval "test \"`echo '$''{'ac_cv_lib_$ac_lib_var'+set}'`\" = set"; then
echo $ac_n "(cached) $ac_c" 1>&6
else
ac_save_LIBS="$LIBS"
LIBS="-lsocket $LIBS"
cat > conftest.$ac_ext <<EOF
-#line 2538 "configure"
+#line 2273 "configure"
#include "confdefs.h"
/* Override any gcc2 internal prototype to avoid an error. */
+/* We use char because int might match the return type of a gcc2
+ builtin and then its argument prototype would still apply. */
char connect();
int main() { return 0; }
@@ -2544,7 +2281,7 @@ int t() {
connect()
; return 0; }
EOF
-if { (eval echo configure:2548: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
+if { (eval echo configure:2285: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
rm -rf conftest*
eval "ac_cv_lib_$ac_lib_var=yes"
else
@@ -2572,16 +2309,18 @@ esac
case "$LIBS" in
*-linet*) ;;
*) echo $ac_n "checking for -linet""... $ac_c" 1>&6
-ac_lib_var=`echo inet_connect | tr '.-/+' '___p'`
+ac_lib_var=`echo inet'_'connect | tr './+\055' '__p_'`
if eval "test \"`echo '$''{'ac_cv_lib_$ac_lib_var'+set}'`\" = set"; then
echo $ac_n "(cached) $ac_c" 1>&6
else
ac_save_LIBS="$LIBS"
LIBS="-linet $LIBS"
cat > conftest.$ac_ext <<EOF
-#line 2583 "configure"
+#line 2320 "configure"
#include "confdefs.h"
/* Override any gcc2 internal prototype to avoid an error. */
+/* We use char because int might match the return type of a gcc2
+ builtin and then its argument prototype would still apply. */
char connect();
int main() { return 0; }
@@ -2589,7 +2328,7 @@ int t() {
connect()
; return 0; }
EOF
-if { (eval echo configure:2593: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
+if { (eval echo configure:2332: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
rm -rf conftest*
eval "ac_cv_lib_$ac_lib_var=yes"
else
@@ -2614,20 +2353,221 @@ else
fi
;;
esac
-unset ac_cv_func_connect
-for ac_func in connect
+if test "$ac_cv_lib_socket_connect" = "yes" || test "$ac_cv_lib_inet_connect" = "yes"; then
+ ac_cv_func_connect=yes
+ cat >> confdefs.h <<\EOF
+#define HAVE_CONNECT 1
+EOF
+
+fi
+fi
+
+
+KRB4=/usr/kerberos
+
+# Check whether --with-krb4 or --without-krb4 was given.
+if test "${with_krb4+set}" = set; then
+ withval="$with_krb4"
+ KRB4=$withval
+fi
+echo "default place for krb4 is $KRB4"
+
+
+krb_h=
+echo $ac_n "checking for krb.h""... $ac_c" 1>&6
+cat > conftest.$ac_ext <<EOF
+#line 2380 "configure"
+#include "confdefs.h"
+#include <krb.h>
+int main() { return 0; }
+int t() {
+int i;
+; return 0; }
+EOF
+if { (eval echo configure:2388: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
+ rm -rf conftest*
+ krb_h=yes krb_incdir=
+else
+ rm -rf conftest*
+ if test "$cross_compiling" != yes && test -r $KRB4/include/krb.h; then
+ hold_cflags=$CFLAGS
+ CFLAGS="$CFLAGS -I$KRB4/include"
+ cat > conftest.$ac_ext <<EOF
+#line 2397 "configure"
+#include "confdefs.h"
+#include <krb.h>
+int main() { return 0; }
+int t() {
+int i;
+; return 0; }
+EOF
+if { (eval echo configure:2405: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
+ rm -rf conftest*
+ krb_h=yes krb_incdir=$KRB4/include
+fi
+rm -f conftest*
+
+ CFLAGS=$hold_cflags
+ fi
+fi
+rm -f conftest*
+
+if test -z "$krb_h"; then
+ cat > conftest.$ac_ext <<EOF
+#line 2418 "configure"
+#include "confdefs.h"
+#include <krb.h>
+int main() { return 0; }
+int t() {
+int i;
+; return 0; }
+EOF
+if { (eval echo configure:2426: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
+ rm -rf conftest*
+ krb_h=yes krb_incdir=
+else
+ rm -rf conftest*
+ if test "$cross_compiling" != yes && test -r $KRB4/include/kerberosIV/krb.h; then
+ hold_cflags=$CFLAGS
+ CFLAGS="$CFLAGS -I$KRB4/include/kerberosIV"
+ cat > conftest.$ac_ext <<EOF
+#line 2435 "configure"
+#include "confdefs.h"
+#include <krb.h>
+int main() { return 0; }
+int t() {
+int i;
+; return 0; }
+EOF
+if { (eval echo configure:2443: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
+ rm -rf conftest*
+ krb_h=yes krb_incdir=$KRB4/include/kerberosIV
+fi
+rm -f conftest*
+
+ CFLAGS=$hold_cflags
+ fi
+fi
+rm -f conftest*
+
+fi
+echo "$ac_t""$krb_h" 1>&6
+
+if test -n "$krb_h"; then
+ krb_lib=
+ echo $ac_n "checking for -lkrb""... $ac_c" 1>&6
+ac_lib_var=`echo krb'_'printf | tr './+\055' '__p_'`
+if eval "test \"`echo '$''{'ac_cv_lib_$ac_lib_var'+set}'`\" = set"; then
+ echo $ac_n "(cached) $ac_c" 1>&6
+else
+ ac_save_LIBS="$LIBS"
+LIBS="-lkrb $LIBS"
+cat > conftest.$ac_ext <<EOF
+#line 2467 "configure"
+#include "confdefs.h"
+/* Override any gcc2 internal prototype to avoid an error. */
+/* We use char because int might match the return type of a gcc2
+ builtin and then its argument prototype would still apply. */
+char printf();
+
+int main() { return 0; }
+int t() {
+printf()
+; return 0; }
+EOF
+if { (eval echo configure:2479: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
+ rm -rf conftest*
+ eval "ac_cv_lib_$ac_lib_var=yes"
+else
+ rm -rf conftest*
+ eval "ac_cv_lib_$ac_lib_var=no"
+fi
+rm -f conftest*
+LIBS="$ac_save_LIBS"
+
+fi
+if eval "test \"`echo '$ac_cv_lib_'$ac_lib_var`\" = yes"; then
+ echo "$ac_t""yes" 1>&6
+ krb_lib=yes krb_libdir=
+else
+ echo "$ac_t""no" 1>&6
+if test "$cross_compiling" != yes && test -r $KRB4/lib/libkrb.a; then
+ krb_lib=yes krb_libdir=$KRB4/lib
+ fi
+fi
+
+ if test -n "$krb_lib"; then
+ cat >> confdefs.h <<\EOF
+#define HAVE_KERBEROS 1
+EOF
+
+ test -n "${krb_libdir}" && LIBS="${LIBS} -L${krb_libdir}"
+ LIBS="${LIBS} -lkrb"
+ # Put -L${krb_libdir} in LDFLAGS temporarily so that it appears before
+ # -ldes in the command line. Don't do it permanently so that we honor
+ # the user's setting for LDFLAGS
+ hold_ldflags=$LDFLAGS
+ test -n "${krb_libdir}" && LDFLAGS="$LDFLAGS -L${krb_libdir}"
+ echo $ac_n "checking for -ldes""... $ac_c" 1>&6
+ac_lib_var=`echo des'_'printf | tr './+\055' '__p_'`
+if eval "test \"`echo '$''{'ac_cv_lib_$ac_lib_var'+set}'`\" = set"; then
+ echo $ac_n "(cached) $ac_c" 1>&6
+else
+ ac_save_LIBS="$LIBS"
+LIBS="-ldes $LIBS"
+cat > conftest.$ac_ext <<EOF
+#line 2520 "configure"
+#include "confdefs.h"
+/* Override any gcc2 internal prototype to avoid an error. */
+/* We use char because int might match the return type of a gcc2
+ builtin and then its argument prototype would still apply. */
+char printf();
+
+int main() { return 0; }
+int t() {
+printf()
+; return 0; }
+EOF
+if { (eval echo configure:2532: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
+ rm -rf conftest*
+ eval "ac_cv_lib_$ac_lib_var=yes"
+else
+ rm -rf conftest*
+ eval "ac_cv_lib_$ac_lib_var=no"
+fi
+rm -f conftest*
+LIBS="$ac_save_LIBS"
+
+fi
+if eval "test \"`echo '$ac_cv_lib_'$ac_lib_var`\" = yes"; then
+ echo "$ac_t""yes" 1>&6
+ LIBS="${LIBS} -ldes"
+else
+ echo "$ac_t""no" 1>&6
+fi
+
+ LDFLAGS=$hold_ldflags
+ if test -n "$krb_incdir"; then
+ includeopt="${includeopt} -I$krb_incdir"
+
+ fi
+ fi
+fi
+for ac_func in krb_get_err_text
do
echo $ac_n "checking for $ac_func""... $ac_c" 1>&6
if eval "test \"`echo '$''{'ac_cv_func_$ac_func'+set}'`\" = set"; then
echo $ac_n "(cached) $ac_c" 1>&6
else
cat > conftest.$ac_ext <<EOF
-#line 2626 "configure"
+#line 2564 "configure"
#include "confdefs.h"
/* System header to define __stub macros and hopefully few prototypes,
which can conflict with char $ac_func(); below. */
#include <assert.h>
/* Override any gcc2 internal prototype to avoid an error. */
+/* We use char because int might match the return type of a gcc2
+ builtin and then its argument prototype would still apply. */
char $ac_func();
int main() { return 0; }
@@ -2644,7 +2584,7 @@ $ac_func();
; return 0; }
EOF
-if { (eval echo configure:2648: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
+if { (eval echo configure:2588: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
rm -rf conftest*
eval "ac_cv_func_$ac_func=yes"
else
@@ -2666,20 +2606,39 @@ else
fi
done
+
+# Check whether --enable-encryption or --disable-encryption was given.
+if test "${enable_encryption+set}" = set; then
+ enableval="$enable_encryption"
+ case "${enableval}" in
+ yes) encryption=true ;;
+ no) encryption=false ;;
+ *) { echo "configure: error: bad value ${enableval} for encryption option" 1>&2; exit 1; } ;;
+ esac
+else
+ encryption=false
fi
+if test "$encryption" = "true"; then
+ cat >> confdefs.h <<\EOF
+#define ENCRYPTION 1
+EOF
+
+fi
echo $ac_n "checking for gethostname""... $ac_c" 1>&6
if eval "test \"`echo '$''{'ac_cv_func_gethostname'+set}'`\" = set"; then
echo $ac_n "(cached) $ac_c" 1>&6
else
cat > conftest.$ac_ext <<EOF
-#line 2678 "configure"
+#line 2635 "configure"
#include "confdefs.h"
/* System header to define __stub macros and hopefully few prototypes,
which can conflict with char gethostname(); below. */
#include <assert.h>
/* Override any gcc2 internal prototype to avoid an error. */
+/* We use char because int might match the return type of a gcc2
+ builtin and then its argument prototype would still apply. */
char gethostname();
int main() { return 0; }
@@ -2696,7 +2655,7 @@ gethostname();
; return 0; }
EOF
-if { (eval echo configure:2700: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
+if { (eval echo configure:2659: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
rm -rf conftest*
eval "ac_cv_func_gethostname=yes"
else
@@ -2715,73 +2674,69 @@ LIBOBJS="$LIBOBJS hostname.o"
fi
-# If we have connect(), we want the full client & server arrangement.
-if test "$ac_cv_func_connect" = yes; then
-cat >> confdefs.h <<\EOF
+# Check for options requesting client and server feature. If none are
+# given and we have connect(), we want the full client & server arrangement.
+# Check whether --enable-client or --disable-client was given.
+if test "${enable_client+set}" = set; then
+ enableval="$enable_client"
+ if test "$enable_client" = yes; then
+ cat >> confdefs.h <<\EOF
+#define CLIENT_SUPPORT 1
+EOF
+
+fi
+else
+ if test "$ac_cv_func_connect" = yes; then
+ cat >> confdefs.h <<\EOF
#define CLIENT_SUPPORT 1
EOF
-cat >> confdefs.h <<\EOF
+fi
+fi
+
+# Check whether --enable-server or --disable-server was given.
+if test "${enable_server+set}" = set; then
+ enableval="$enable_server"
+ if test "$enable_server" = yes; then
+ cat >> confdefs.h <<\EOF
#define SERVER_SUPPORT 1
EOF
-# Define AUTH_SERVER_SUPPORT only if we could locate the crypt() function
-unset ac_cv_func_crypt
-echo $ac_n "checking for crypt""... $ac_c" 1>&6
-if eval "test \"`echo '$''{'ac_cv_func_crypt'+set}'`\" = set"; then
- echo $ac_n "(cached) $ac_c" 1>&6
+fi
else
- cat > conftest.$ac_ext <<EOF
-#line 2736 "configure"
-#include "confdefs.h"
-/* System header to define __stub macros and hopefully few prototypes,
- which can conflict with char crypt(); below. */
-#include <assert.h>
-/* Override any gcc2 internal prototype to avoid an error. */
-char crypt();
+ if test "$ac_cv_func_connect" = yes; then
+ cat >> confdefs.h <<\EOF
+#define SERVER_SUPPORT 1
+EOF
-int main() { return 0; }
-int t() {
+ enable_server=yes
+fi
+fi
-/* The GNU C library defines this for functions which it implements
- to always fail with ENOSYS. Some functions are actually named
- something starting with __ and the normal name is an alias. */
-#if defined (__stub_crypt) || defined (__stub___crypt)
-choke me
-#else
-crypt();
-#endif
-; return 0; }
-EOF
-if { (eval echo configure:2758: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
- rm -rf conftest*
- eval "ac_cv_func_crypt=yes"
-else
- rm -rf conftest*
- eval "ac_cv_func_crypt=no"
-fi
-rm -f conftest*
+### The auth server needs to be able to check passwords against passwd
+### file entries, so we only #define AUTH_SERVER_SUPPORT if we can
+### find the crypt function.
+###
+### We used to test for crypt in libc first, and only add -lcrypt if
+### we couldn't find it, but that interacts badly with the cache
+### variables, the 'unset' command isn't portable, and I'm not sure
+### there's any harm in just testing for -lcrypt first.
-fi
-if eval "test \"`echo '$ac_cv_func_'crypt`\" = yes"; then
- echo "$ac_t""yes" 1>&6
- :
-else
- echo "$ac_t""no" 1>&6
-case "$LIBS" in
-*-lcrypt*) ;;
-*) echo $ac_n "checking for -lcrypt""... $ac_c" 1>&6
-ac_lib_var=`echo crypt_crypt | tr '.-/+' '___p'`
+if test "$enable_server" = yes; then
+echo $ac_n "checking for -lcrypt""... $ac_c" 1>&6
+ac_lib_var=`echo crypt'_'crypt | tr './+\055' '__p_'`
if eval "test \"`echo '$''{'ac_cv_lib_$ac_lib_var'+set}'`\" = set"; then
echo $ac_n "(cached) $ac_c" 1>&6
else
ac_save_LIBS="$LIBS"
LIBS="-lcrypt $LIBS"
cat > conftest.$ac_ext <<EOF
-#line 2783 "configure"
+#line 2736 "configure"
#include "confdefs.h"
/* Override any gcc2 internal prototype to avoid an error. */
+/* We use char because int might match the return type of a gcc2
+ builtin and then its argument prototype would still apply. */
char crypt();
int main() { return 0; }
@@ -2789,7 +2744,7 @@ int t() {
crypt()
; return 0; }
EOF
-if { (eval echo configure:2793: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
+if { (eval echo configure:2748: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
rm -rf conftest*
eval "ac_cv_lib_$ac_lib_var=yes"
else
@@ -2812,9 +2767,7 @@ EOF
else
echo "$ac_t""no" 1>&6
fi
- ;;
-esac
-unset ac_cv_func_crypt
+
for ac_func in crypt
do
echo $ac_n "checking for $ac_func""... $ac_c" 1>&6
@@ -2822,12 +2775,14 @@ if eval "test \"`echo '$''{'ac_cv_func_$ac_func'+set}'`\" = set"; then
echo $ac_n "(cached) $ac_c" 1>&6
else
cat > conftest.$ac_ext <<EOF
-#line 2826 "configure"
+#line 2779 "configure"
#include "confdefs.h"
/* System header to define __stub macros and hopefully few prototypes,
which can conflict with char $ac_func(); below. */
#include <assert.h>
/* Override any gcc2 internal prototype to avoid an error. */
+/* We use char because int might match the return type of a gcc2
+ builtin and then its argument prototype would still apply. */
char $ac_func();
int main() { return 0; }
@@ -2844,7 +2799,7 @@ $ac_func();
; return 0; }
EOF
-if { (eval echo configure:2848: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
+if { (eval echo configure:2803: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
rm -rf conftest*
eval "ac_cv_func_$ac_func=yes"
else
@@ -2866,15 +2821,14 @@ else
fi
done
-fi
- if test "$ac_cv_func_crypt" = yes; then
+if test "$ac_cv_func_crypt" = yes; then
cat >> confdefs.h <<\EOF
#define AUTH_SERVER_SUPPORT 1
EOF
- fi
fi
+fi # enable_server
test -f src/options.h && (
echo "configure: warning: saving ./src/options.h in ./src/options.h-SAVED" 1>&2
@@ -2959,7 +2913,7 @@ do
echo "running \${CONFIG_SHELL-/bin/sh} $0 $ac_configure_args --no-create --no-recursion"
exec \${CONFIG_SHELL-/bin/sh} $0 $ac_configure_args --no-create --no-recursion ;;
-version | --version | --versio | --versi | --vers | --ver | --ve | --v)
- echo "$CONFIG_STATUS generated by autoconf version 2.9"
+ echo "$CONFIG_STATUS generated by autoconf version 2.10"
exit 0 ;;
-help | --help | --hel | --he | --h)
echo "\$ac_cs_usage"; exit 0 ;;
@@ -2970,10 +2924,12 @@ done
ac_given_srcdir=$srcdir
ac_given_INSTALL="$INSTALL"
-trap 'rm -fr `echo "Makefile lib/Makefile src/Makefile doc/Makefile \
+trap 'rm -fr `echo "Makefile lib/Makefile src/Makefile zlib/Makefile doc/Makefile \
man/Makefile tools/Makefile tools/pcl-cvs/Makefile \
contrib/Makefile contrib/elib/Makefile \
- windows-NT/Makefile os2/Makefile macintosh/Makefile stamp-h config.h src/options.h" | sed "s/:[^ ]*//g"` conftest*; exit 1' 1 2 15
+ windows-NT/Makefile windows-NT/SCC/Makefile \
+ os2/Makefile macintosh/Makefile vms/Makefile \
+ stamp-h config.h src/options.h" | sed "s/:[^ ]*//g"` conftest*; exit 1' 1 2 15
EOF
cat >> $CONFIG_STATUS <<EOF
@@ -3021,10 +2977,12 @@ CEOF
EOF
cat >> $CONFIG_STATUS <<EOF
-CONFIG_FILES=\${CONFIG_FILES-"Makefile lib/Makefile src/Makefile doc/Makefile \
+CONFIG_FILES=\${CONFIG_FILES-"Makefile lib/Makefile src/Makefile zlib/Makefile doc/Makefile \
man/Makefile tools/Makefile tools/pcl-cvs/Makefile \
contrib/Makefile contrib/elib/Makefile \
- windows-NT/Makefile os2/Makefile macintosh/Makefile stamp-h"}
+ windows-NT/Makefile windows-NT/SCC/Makefile \
+ os2/Makefile macintosh/Makefile vms/Makefile \
+ stamp-h"}
EOF
cat >> $CONFIG_STATUS <<\EOF
for ac_file in .. $CONFIG_FILES; do if test "x$ac_file" != x..; then
@@ -3171,6 +3129,12 @@ cat >> $CONFIG_STATUS <<\EOF
echo "$ac_file is unchanged"
rm -f conftest.h
else
+ # Remove last slash and all that follows it. Not all systems have dirname.
+ ac_dir=`echo $ac_file|sed 's%/[^/][^/]*$%%'`
+ if test "$ac_dir" != "$ac_file" && test "$ac_dir" != .; then
+ # The file is in a subdirectory.
+ test ! -d "$ac_dir" && mkdir "$ac_dir"
+ fi
rm -f $ac_file
mv conftest.h $ac_file
fi
diff --git a/contrib/cvs/configure.in b/contrib/cvs/configure.in
index 554a401fa6a5..87f4b7d24a51 100644
--- a/contrib/cvs/configure.in
+++ b/contrib/cvs/configure.in
@@ -1,7 +1,17 @@
dnl configure.in for cvs
-dnl "$CVSid$"
AC_INIT(src/cvs.h)
+dnl
AC_PREREQ(2.4)dnl Required Autoconf version.
+dnl Do not use autoconf 2.12; it produces a configure script which produces
+dnl a "internal 2K buffer" error on HPUX when run with /bin/sh.
+dnl autoconf 2.10 seems like a good choice.
+dnl
+dnl It is possible that we should just change the above required version
+dnl to 2.10; it seems like everyone is using 2.10 anyway, and there is
+dnl at least some sentiment that we should be using a version which has
+dnl --bindir (and correspondingly, using @bindir@ and friends in our
+dnl Makefile.in files. I'm not sure exactly what version of autoconf
+dnl introduced --bindir but I know 2.10 has it.
AC_CONFIG_HEADER(config.h src/options.h)
AC_PROG_CC
@@ -11,15 +21,17 @@ AC_MINIX
AC_ISC_POSIX
if test "$ISC" = yes; then
CFLAGS="$CFLAGS -D_SYSV3"
+LIBS="-lcrypt $LIBS"
fi
AC_PREFIX_PROGRAM(cvs)
+dnl FIXME: AC_C_CROSS is considered obsolete by autoconf 2.12, and is
+dnl pretty ugly to start with. But it isn't obvious to me how we should
+dnl be handling the uses of cross_compiling below.
AC_C_CROSS
AC_C_CONST
-AC_C_CHAR_UNSIGNED
-AC_C_INLINE
AC_PROG_INSTALL
AC_PROG_RANLIB
@@ -49,8 +61,29 @@ AC_TYPE_UID_T
AC_TYPE_MODE_T
AC_TYPE_SIZE_T
AC_TYPE_PID_T
-AC_REPLACE_FUNCS(getwd mkdir rename strdup strstr dup2 strerror valloc waitpid memmove vasprintf strtoul)
-AC_CHECK_FUNCS(fchmod fsync ftime mkfifo putenv setvbuf vfork vprintf ftruncate timezone getpagesize initgroups fchdir sigaction sigprocmask sigvec sigsetmask sigblock)
+AC_REPLACE_FUNCS(getwd mkdir rename strdup strstr dup2 strerror valloc waitpid vasprintf strtoul)
+AC_CHECK_FUNCS(fchmod fsync ftime mkfifo mktemp putenv vfork vprintf ftruncate timezone getpagesize initgroups fchdir sigaction sigprocmask sigvec sigsetmask sigblock tempnam tzset readlink wait3)
+
+dnl
+dnl Look for shadow password files before we go ahead and set getspnam.
+dnl On some systems (Linux), the C library has getspnam but shadow
+dnl passwords might not be in use.
+dnl
+dnl We used to check for the existence of the /etc/security directory
+dnl here, but that's incorrect, since it's possible to have PAM installed
+dnl without using shadow passwords.
+dnl
+AC_MSG_CHECKING([for evidence of shadow passwords])
+if test -f /etc/shadow \
+ || test -f /etc/security/passwd.adjunct ; then
+ found="yes"
+ AC_CHECK_LIB(sec, getspnam)
+ AC_CHECK_FUNCS(getspnam)
+else
+ found="no"
+fi
+AC_MSG_RESULT([$found])
+
AC_CHECK_FUNC(re_exec, :, LIBOBJS="$LIBOBJS regex.o")
AC_FUNC_UTIME_NULL
AC_SYS_LONG_FILE_NAMES
@@ -74,6 +107,35 @@ if test $ccvs_cv_sys_working_fnmatch = no; then
fi
AC_MSG_RESULT($ccvs_cv_sys_working_fnmatch)
+# If we can't find connect, try looking in -lsocket, -lnsl, and -linet.
+# The Irix 5 libc.so has connect and gethostbyname, but Irix 5 also has
+# libsocket.so which has a bad implementation of gethostbyname (it
+# only looks in /etc/hosts), so we only look for -lsocket if we need
+# it.
+AC_CHECK_FUNC(connect, :,
+[case "$LIBS" in
+*-lnsl*) ;;
+*) AC_CHECK_LIB(nsl_s, printf) ;;
+esac
+case "$LIBS" in
+*-lnsl*) ;;
+*) AC_CHECK_LIB(nsl, printf) ;;
+esac
+case "$LIBS" in
+*-lsocket*) ;;
+*) AC_CHECK_LIB(socket, connect) ;;
+esac
+case "$LIBS" in
+*-linet*) ;;
+*) AC_CHECK_LIB(inet, connect) ;;
+esac
+dnl We can't just call AC_CHECK_FUNCS(connect) here, because the value
+dnl has been cached.
+if test "$ac_cv_lib_socket_connect" = "yes" || test "$ac_cv_lib_inet_connect" = "yes"; then
+ ac_cv_func_connect=yes
+ AC_DEFINE(HAVE_CONNECT)
+fi])
+
dnl
dnl set $(KRB4) from --with-krb4=value -- WITH_KRB4
dnl
@@ -87,9 +149,6 @@ echo "default place for krb4 is $KRB4"
AC_SUBST(KRB4)])dnl
WITH_KRB4
-AC_CHECK_SIZEOF(long)
-AC_CHECK_SIZEOF(int)
-
krb_h=
AC_MSG_CHECKING([for krb.h])
AC_TRY_LINK([#include <krb.h>],[int i;],
@@ -124,7 +183,13 @@ if test -n "$krb_h"; then
AC_DEFINE(HAVE_KERBEROS)
test -n "${krb_libdir}" && LIBS="${LIBS} -L${krb_libdir}"
LIBS="${LIBS} -lkrb"
+ # Put -L${krb_libdir} in LDFLAGS temporarily so that it appears before
+ # -ldes in the command line. Don't do it permanently so that we honor
+ # the user's setting for LDFLAGS
+ hold_ldflags=$LDFLAGS
+ test -n "${krb_libdir}" && LDFLAGS="$LDFLAGS -L${krb_libdir}"
AC_CHECK_LIB(des,printf,[LIBS="${LIBS} -ldes"])
+ LDFLAGS=$hold_ldflags
if test -n "$krb_incdir"; then
includeopt="${includeopt} -I$krb_incdir"
AC_SUBST(includeopt)
@@ -132,51 +197,63 @@ if test -n "$krb_h"; then
fi
fi
AC_CHECK_FUNCS(krb_get_err_text)
-# If we can't find connect, try looking in -lsocket, -lnsl, and -linet.
-# The Irix 5 libc.so has connect and gethostbyname, but Irix 5 also has
-# libsocket.so which has a bad implementation of gethostbyname (it
-# only looks in /etc/hosts), so we only look for -lsocket if we need
-# it.
-unset ac_cv_func_connect
-AC_CHECK_FUNC(connect, :,
-[case "$LIBS" in
-*-lnsl*) ;;
-*) AC_CHECK_LIB(nsl_s, printf) ;;
-esac
-case "$LIBS" in
-*-lnsl*) ;;
-*) AC_CHECK_LIB(nsl, printf) ;;
-esac
-case "$LIBS" in
-*-lsocket*) ;;
-*) AC_CHECK_LIB(socket, connect) ;;
-esac
-case "$LIBS" in
-*-linet*) ;;
-*) AC_CHECK_LIB(inet, connect) ;;
-esac
-unset ac_cv_func_connect
-AC_CHECK_FUNCS(connect)])
+
+dnl
+dnl Use --with-encryption to turn on encryption support
+dnl
+AC_ARG_ENABLE(encryption,
+ [ --enable-encryption enable encryption support],
+ [case "${enableval}" in
+ yes) encryption=true ;;
+ no) encryption=false ;;
+ *) AC_MSG_ERROR(bad value ${enableval} for encryption option) ;;
+ esac],
+ [encryption=false])
+if test "$encryption" = "true"; then
+ AC_DEFINE(ENCRYPTION)
+fi
AC_CHECK_FUNC(gethostname, :, LIBOBJS="$LIBOBJS hostname.o")
-# If we have connect(), we want the full client & server arrangement.
-if test "$ac_cv_func_connect" = yes; then
-AC_DEFINE(CLIENT_SUPPORT)
-AC_DEFINE(SERVER_SUPPORT)
-# Define AUTH_SERVER_SUPPORT only if we could locate the crypt() function
-unset ac_cv_func_crypt
-AC_CHECK_FUNC(crypt, :,
-[case "$LIBS" in
-*-lcrypt*) ;;
-*) AC_CHECK_LIB(crypt, crypt) ;;
-esac
-unset ac_cv_func_crypt
-AC_CHECK_FUNCS(crypt)])
- if test "$ac_cv_func_crypt" = yes; then
+# Check for options requesting client and server feature. If none are
+# given and we have connect(), we want the full client & server arrangement.
+AC_ARG_ENABLE(client,
+[ --enable-client include code for running as a remote client (default)
+ --disable-client don't include remote client code],
+[if test "$enable_client" = yes; then
+ AC_DEFINE(CLIENT_SUPPORT)
+fi],
+[if test "$ac_cv_func_connect" = yes; then
+ AC_DEFINE(CLIENT_SUPPORT)
+fi])
+AC_ARG_ENABLE(server,
+[ --enable-server include code for running as a server (default)
+ --disable-server don't include server code],
+[if test "$enable_server" = yes; then
+ AC_DEFINE(SERVER_SUPPORT)
+fi],
+[if test "$ac_cv_func_connect" = yes; then
+ AC_DEFINE(SERVER_SUPPORT)
+ enable_server=yes
+fi])
+
+### The auth server needs to be able to check passwords against passwd
+### file entries, so we only #define AUTH_SERVER_SUPPORT if we can
+### find the crypt function.
+###
+### We used to test for crypt in libc first, and only add -lcrypt if
+### we couldn't find it, but that interacts badly with the cache
+### variables, the 'unset' command isn't portable, and I'm not sure
+### there's any harm in just testing for -lcrypt first.
+
+if test "$enable_server" = yes; then
+AC_CHECK_LIB(crypt, crypt)
+AC_CHECK_FUNCS(crypt)
+
+if test "$ac_cv_func_crypt" = yes; then
AC_DEFINE(AUTH_SERVER_SUPPORT)
- fi
fi
+fi # enable_server
test -f src/options.h && (
AC_MSG_WARN(saving ./src/options.h in ./src/options.h-SAVED)
@@ -185,7 +262,9 @@ test -f src/options.h && (
cp ./src/options.h ./src/options.h-SAVED
)
-AC_OUTPUT(Makefile lib/Makefile src/Makefile doc/Makefile \
+AC_OUTPUT(Makefile lib/Makefile src/Makefile zlib/Makefile doc/Makefile \
man/Makefile tools/Makefile tools/pcl-cvs/Makefile \
contrib/Makefile contrib/elib/Makefile \
- windows-NT/Makefile os2/Makefile macintosh/Makefile stamp-h)
+ windows-NT/Makefile windows-NT/SCC/Makefile \
+ os2/Makefile macintosh/Makefile vms/Makefile \
+ stamp-h)
diff --git a/contrib/cvs/contrib/ChangeLog b/contrib/cvs/contrib/ChangeLog
index 80db5b857f34..3fbee6196a2c 100644
--- a/contrib/cvs/contrib/ChangeLog
+++ b/contrib/cvs/contrib/ChangeLog
@@ -1,3 +1,121 @@
+Mon May 12 11:59:23 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * listener.c: Removed; see ../ChangeLog for rationale.
+
+10 May 1997 Jim Kingdon
+
+ * listen2.c, listen2.mak: New files.
+ * Makefile.in (DISTFILES): Add them.
+ * .cvsignore: Add Debug.
+
+Thu Feb 20 22:43:45 1997 David J MacKenzie <djm@va.pubnix.com>
+
+ * rcs-to-cvs.sh: Put temporary files in /var/tmp or /usr/tmp
+ whichever one exists. Just call "vi" not "/usr/ucb/vi".
+
+Mon Feb 17 08:51:37 1997 Greg A. Woods <woods@most.weird.com>
+
+ * .cvsignore: added 'cvs2vendor' target from Feb. 12 changes.
+
+ * log_accum.pl (build_header): added "Repository:" to the report
+ header to show the first argument supplied to the script by CVS.
+ [[this value seems spuriously to be wrong when client is used]]
+ ($hostdomain): correct order of initialization from the Feb. 12
+ changes.
+ ($modulename): add more commentary about using '-M' to to get a
+ meaningful string here.
+ Tweak a few other comments from the Feb. 12 changes.
+
+Wed Feb 12 10:27:48 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cln_hist.pl, commit_prep.pl, cvs2vendor.sh, cvs_acls.pl,
+ cvscheck.man, cvscheck.sh, cvshelp.man, descend.man, descend.sh,
+ log_accum.pl, mfpipe.pl, rcs-to-cvs.sh, rcs2log.sh, rcs2sccs.sh,
+ sccs2rcs.csh: Remove $Id; we decided to get rid of these some
+ time ago.
+
+Wed Feb 12 00:24:33 1997 Greg A. Woods <woods@most.weird.com>
+
+ * cvs2vendor.sh: new script.
+ * README: noted new cvs2vendor script.
+ * Makefile.in (DISTFILES): added cvs2vendor.sh.
+ (CONTRIB_PROGS): added cvs2vendor.
+
+ * log_accum.pl (show_wd): new variable, initialized to 0.
+ - set $show_wd if '-w' option found while parsing @ARGV.
+ - don't add 'In directory' line to report header unless $show_wd
+ is set.
+ (domainname): prepend a leading '.' if none there so that
+ concatenation with $hostname works (those with a FQDN hostname
+ *and* a domainname still lose).
+ (mail_notification): don't set a "From:" header -- the mailer will.
+
+Wed Jan 8 14:48:58 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * Makefile.in, README, log.pl: Remove CVSid; we decided to get rid
+ of these some time ago.
+
+Thu Jan 2 13:30:56 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * Makefile.in: Remove "675" paragraph; see ../ChangeLog for rationale.
+
+Thu Oct 17 18:28:25 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * patch-2.1-.new-fix: Removed; it was not in DISTFILES so it never
+ made it into distributions. It also isn't clear what it has to do
+ with CVS. It is available from
+ ftp://ftp.weird.com/pub/patch-2.1-.new-fix
+ * README: Remove entry for patch-2.1-.new-fix.
+
+Wed Oct 16 10:22:44 1996 Jim Blandy <jimb@totoro.cyclic.com>
+
+ * rcs2log.sh: Change date output format to something CVS 1.9
+ accepts. I think this breaks the Sep 29 change, but I don't have
+ a copy of CVS 1.5 handy, so I can't find a format that works with
+ both, and I think it's more important that it work with the
+ version it's distributed with.
+
+Sat Oct 12 21:18:19 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * README: Don't mention pcl-cvs; it isn't here any more.
+
+Sun Sep 29 19:45:19 1996 Greg A. Woods <woods@most.weird.com>
+
+ * README: add entry for patch-2.1-.new-fix.
+
+ * README: re-write the top section a bit.
+
+ * patch-2.1-.new-fix: re-generated using fixed "cvs patch" command.
+
+ * patch-2.1-.new-fix: new file.
+
+Sun Sep 29 14:25:28 1996 Dave Love <d.love@dl.ac.uk>
+
+ * rcs2log.sh (month_data): Make default date format acceptable to
+ CVS post v1.8 as well as earlier CVSs and RCS.
+ Message-Id: <199609291546.QAA25531@mserv1.dl.ac.uk>
+ To: bug-gnu-emacs@prep.ai.mit.edu
+
+Thu Aug 29 11:58:03 1996 Jim Blandy <jimb@totoro.cyclic.com>
+
+ * rcs2log: Update FSF address.
+
+ * rcs2log: Be more aggressive about finding the author's full
+ name; try nismatch and ypmatch.
+
+ * rcs2log: If the hostname appears not to be fully qualified, see
+ if domainname provides any useful information.
+
+Fri Aug 16 16:02:36 1996 Norbert Kiesel <nk@col.sw-ley.de>
+
+ * Makefile.in (installdirs): support this target
+
+Mon May 6 13:04:57 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * Makefile.in (install): Don't tell user to run cvsinit. It isn't
+ called cvsinit anymore, and it isn't necessary (repositories are,
+ and need to be, compatible between cvs versions).
+
Sun Apr 14 11:30:36 1996 Karl Fogel <kfogel@floss.red-bean.com>
* Removed pcl-cvs/ subdir; see tools/ subdir in the top-level from
diff --git a/contrib/cvs/contrib/Makefile.in b/contrib/cvs/contrib/Makefile.in
index a29dec02b5fe..2a6e9a267401 100644
--- a/contrib/cvs/contrib/Makefile.in
+++ b/contrib/cvs/contrib/Makefile.in
@@ -12,12 +12,6 @@
# 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., 675 Mass Ave, Cambridge, MA 02139, USA.
-
-# $CVSid: @(#)Makefile.in 1.6 94/10/22 $
-
SHELL = /bin/sh
srcdir = @srcdir@
@@ -47,10 +41,11 @@ INSTALL_PROGRAM = @INSTALL_PROGRAM@
DISTFILES = \
ChangeLog README .cvsignore intro.doc \
- Makefile.in clmerge.pl cln_hist.pl commit_prep.pl cvs_acls.pl \
- cvscheck.sh cvscheck.man cvshelp.man descend.sh descend.man \
- dirfns.shar log.pl log_accum.pl mfpipe.pl rcs-to-cvs.sh rcs2log.sh \
- rcslock.pl sccs2rcs.csh rcs2sccs.sh
+ Makefile.in clmerge.pl cln_hist.pl commit_prep.pl cvs2vendor.sh \
+ cvs_acls.pl cvscheck.sh cvscheck.man cvshelp.man descend.sh \
+ descend.man dirfns.shar log.pl log_accum.pl mfpipe.pl rcs-to-cvs.sh \
+ rcs2log.sh rcslock.pl sccs2rcs.csh rcs2sccs.sh \
+ listen2.c listen2.mak
# files installed in $(libdir)/cvs/contrib
#
@@ -59,8 +54,8 @@ CONTRIB_FILES = README intro.doc cvscheck.man
# things we actually build and install....
#
PROGS = rcs2log
-CONTRIB_PROGS = clmerge cln_hist commit_prep cvs_acls cvscheck log log_accum \
- mfpipe rcs-to-cvs rcs2log rcslock sccs2rcs
+CONTRIB_PROGS = clmerge cln_hist commit_prep cvs2vendor cvs_acls cvscheck \
+ log log_accum mfpipe rcs-to-cvs rcs2log rcslock sccs2rcs
.SUFFIXES: .pl .sh .csh
@@ -84,7 +79,7 @@ CONTRIB_PROGS = clmerge cln_hist commit_prep cvs_acls cvscheck log log_accum \
all: Makefile $(PROGS) $(CONTRIB_PROGS)
.PHONY: all
-install: all $(libdir)/cvs/contrib
+install: all installdirs
for f in $(CONTRIB_FILES) ; do\
$(INSTALL_DATA) $(srcdir)/$$f $(libdir)/cvs/contrib/$$f; \
done
@@ -94,11 +89,11 @@ install: all $(libdir)/cvs/contrib
for f in $(PROGS) ; do\
$(INSTALL_PROGRAM) $$f $(bindir)/$$f; \
done
- @echo "You might consider running 'cvsinit' to upgrade your repository(s)...."
.PHONY: install
-$(libdir)/cvs/contrib:
+installdirs:
$(top_srcdir)/mkinstalldirs $(libdir)/cvs/contrib
+.PHONY: installdirs
tags:
.PHONY: tags
diff --git a/contrib/cvs/contrib/README b/contrib/cvs/contrib/README
index d453f8d56169..900b0c75f749 100644
--- a/contrib/cvs/contrib/README
+++ b/contrib/cvs/contrib/README
@@ -1,27 +1,31 @@
-$CVSid: @(#)README 1.12 94/09/25 $
+This "contrib" directory is a place holder for code/scripts sent to me
+by contributors around the world. This README file will be kept
+up-to-date from release to release. BUT, we must point out that these
+contributions are really, REALLY UNSUPPORTED. In fact, we probably
+don't even know what some of them really do. We certainly do not
+guarantee to have tried them, or ported them to work with this CVS
+distribution. If you have questions, your best bet is to contact the
+original author, but you should not necessarily expect a reply, since
+the author may not be available at the address given.
-This "contrib" directory is a place holder for code/scripts sent to
-me by contributors around the world. This README file will be kept
-up-to-date from release to release. BUT, I must point out that these
-contributions are really, REALLY UNSUPPORTED. In fact, I probably
-don't even know what they do. Nor do I guarantee to have tried them,
-or ported them to work with this CVS distribution. If you have questions,
-you might contact the author, but you should not necessarily expect
-a reply. USE AT YOUR OWN RISK -- and all that stuff.
+USE AT YOUR OWN RISK -- and all that stuff.
-"Unsupported" also means that noone has volunteered to accept and
-check in changes to this directory. So submissions for new scripts to
-add here are unlikely to be accepted. Suggested changes to the
-existing scripts here conceivably might, but that isn't clear either.
-The exception is pcl-cvs; that is more actively maintained (see
-pcl-cvs/README). If you have some software that works with CVS that
-you wish to offer it is suggested that you make it available by FTP or
-HTTP and then announce it on the info-cvs mailing list. There is also
-a web page of software related to CVS at
-http://www.loria.fr/~molli/cvs-index.html which would presumably be
-willing to list your software.
+"Unsupported" also means that no one has volunteered to accept and check
+in changes to this directory. So submissions for new scripts to add
+here are unlikely to be accepted. Suggested changes to the existing
+scripts here conceivably might, but that isn't clear either, unless of
+course they come from the original author of the script.
-Contents of this directory:
+If you have some software that works with CVS that you wish to offer it
+is suggested that you make it available by FTP or HTTP and then announce
+it on the info-cvs mailing list.
+
+There is a web page of software related to CVS at the following URL which
+would presumably be willing to list your software.
+
+ http://www.loria.fr/~molli/cvs-index.html
+
+An attempt at a table of Contents for this directory:
README This file.
log A perl script suitable for including in your
@@ -29,9 +33,6 @@ Contents of this directory:
changes. Includes the RCS revision of the change
as part of the log.
Contributed by Kevin Samborn <samborn@sunrise.com>.
- pcl-cvs A directory that contains GNU Emacs lisp code which
- implements a CVS-mode for emacs.
- Contributed by Per Cederqvist <ceder@lysator.liu.se>.
commit_prep A perl script, to be combined with log_accum.pl, to
log_accum provide for a way to combine the individual log
messages of a multi-directory "commit" into a
@@ -104,3 +105,7 @@ Contents of this directory:
by hostname, then runs a subprocess whose input/output
is redirected through the port.
Contributed by Benjamin J. Lee <benjamin@cyclic.com>
+ cvs2vendor A shell script to move changes from a repository
+ that was started without a vendor branch to one
+ that has a vendor branch.
+ Contributed by Greg A. Woods <woods@planix.com>
diff --git a/contrib/cvs/contrib/ccvs-rsh.pl b/contrib/cvs/contrib/ccvs-rsh.pl
new file mode 100644
index 000000000000..8cfc6743ba3b
--- /dev/null
+++ b/contrib/cvs/contrib/ccvs-rsh.pl
@@ -0,0 +1,97 @@
+#!/usr/bin/perl
+
+# The version of the remote shell program on some Linuxes, at least,
+# misuses GNU getopt in such a way that it plucks arguments to rsh
+# that look like command-line switches from anywhere in rsh's
+# arguments. This is the Wrong Thing to do, and causes older versions
+# of CCVS to break.
+
+# In addition, if we live behind a firewall and have to construct a
+# "pipeline" of rshes through different machines in order to get to
+# the outside world, each rshd along the way undoes the hard work CCVS
+# does to put the command to be executed at the far end into a single
+# argument. Sigh.
+
+# This script is a very minimal wrapper to rsh which makes sure that
+# the commands to be executed remotely are packed into a single
+# argument before we call exec(). It works on the idea of a "proxy
+# chain", which is a set of machines you go through to get to the CCVS
+# server machine.
+
+# Each host you go through before you reach the CCVS server machine
+# should have a copy of this script somewhere (preferably accessible
+# directly from your PATH envariable). In addition, each host you go
+# through before you reach the firewall should have the CVS_PROXY_HOST
+# envariable set to the next machine in the chain, and CVS_PROXY_USER
+# set if necessary.
+
+# This really isn't as complex as it sounds. Honest.
+
+# Bryan O'Sullivan <bos@serpentine.com> April 1995
+
+$usage = "usage: ccvs-rsh hostname [-l username] command [...]\n";
+
+if ($#ARGV < 1) {
+ print STDERR $usage;
+ exit 1;
+}
+
+# Try to pick a sane version of the remote shell command to run. This
+# only understands BSD and Linux machines; if your remote shell is
+# called "remsh" under some System V (e.g. HP-SUX), you should edit
+# the line manually to suit yourself.
+
+$rsh = (-x "/usr/ucb/rsh") ? "/usr/ucb/rsh" : "/usr/bin/rsh";
+
+# If you are not rshing directly to the CCVS server machine, make the
+# following variable point at ccvs-rsh on the next machine in the
+# proxy chain. If it's accessible through the PATH envariable, you
+# can just set this to "ccvs-rsh".
+
+$ccvs_rsh = "ccvs-rsh";
+
+# There shouldn't be any user-serviceable parts beyond this point.
+
+$host = $ARGV[0];
+
+if ($ARGV[1] eq "-l") {
+ if ($#ARGV < 3) {
+ print STDERR $usage;
+ exit 1;
+ }
+ $user = $ARGV[2];
+ $cbase = 3;
+} else {
+ $cbase = 1;
+}
+
+# You might think you shoul be able to do something like
+# $command = join(' ', $ARGV[$cbase..$#ARGV]);
+# to achieve the effect of the following block of code, but it doesn't
+# work under Perl 4 on Linux, at least. Sigh.
+
+$command = $ARGV[$cbase];
+for ($cbase++; $cbase <= $#ARGV; $cbase++) {
+ $command .= " " . $ARGV[$cbase];
+}
+
+if (defined $ENV{"CVS_PROXY_HOST"}) {
+ $command = (defined $user)
+ ? "$ccvs_rsh $host -l $user $command"
+ : "$ccvs_rsh $host $command";
+
+ if (defined $ENV{"CVS_PROXY_USER"}) {
+ exec ($rsh, $ENV{"CVS_PROXY_HOST"}, "-l", $ENV{"CVS_PROXY_USER"},
+ $command);
+ } else {
+ exec ($rsh, $ENV{"CVS_PROXY_HOST"}, $command);
+ }
+} elsif (defined $user) {
+ exec ($rsh, $host, "-l", $user, $command);
+} else {
+ if (defined $ENV{"CVS_PROXY_USER"}) {
+ exec ($rsh, $host, "-l", $ENV{"CVS_PROXY_USER"}, $command);
+ } else {
+ exec ($rsh, $host, $command);
+ }
+}
diff --git a/contrib/cvs/contrib/cln_hist.pl b/contrib/cvs/contrib/cln_hist.pl
index ff49d0a3e9c7..19a0b815b783 100644
--- a/contrib/cvs/contrib/cln_hist.pl
+++ b/contrib/cvs/contrib/cln_hist.pl
@@ -1,7 +1,6 @@
#! xPERL_PATHx
# -*-Perl-*-
#
-# $Id: cln_hist.pl,v 1.2 1995/07/10 02:01:26 kfogel Exp $
# Contributed by David G. Grubbs <dgg@ksr.com>
#
# Clean up the history file. 10 Record types: MAR OFT WUCG
diff --git a/contrib/cvs/contrib/commit_prep.pl b/contrib/cvs/contrib/commit_prep.pl
index 5272c0430ad3..bf0ce92f22f4 100644
--- a/contrib/cvs/contrib/commit_prep.pl
+++ b/contrib/cvs/contrib/commit_prep.pl
@@ -1,7 +1,6 @@
#! xPERL_PATHx
# -*-Perl-*-
#
-#ident "@(#)cvs/contrib:$Name: $:$Id: commit_prep.pl,v 1.2 1995/07/10 02:01:29 kfogel Exp $"
#
# Perl filter to handle pre-commit checking of files. This program
# records the last directory where commits will be taking place for
diff --git a/contrib/cvs/contrib/cvs2vendor.sh b/contrib/cvs/contrib/cvs2vendor.sh
new file mode 100644
index 000000000000..234f4d95e5d7
--- /dev/null
+++ b/contrib/cvs/contrib/cvs2vendor.sh
@@ -0,0 +1,142 @@
+#! /bin/sh
+#
+# cvs2vendor - move revsisions from files in A to files in B
+#
+# The primary reason for this script is to move deltas from a
+# non-vendor branched repository onto a fresh vendor branched one,
+# skipping the initial checkin in assumption that it is the same in
+# both repositories. This way you can take a project that was moved
+# into CVS without the benefit of the vendor branch and for all
+# intents and purposes add the vendor branch underneath the existing
+# deltas.
+#
+# This script is also a decent example of repository maintenance using
+# raw RCS commands (if I do say so myself! ;-).
+#
+# Tags are preserved.
+#
+# The timestamp of the initial vendor branch revision will be adjusted
+# to be the same as the 1.1 revision of each source file.
+#
+# Extra branches in the source directory will cause breakage.
+#
+# Intermediate files are created in the current working directory
+# where this script is started.
+#
+# Written by Greg A. Woods <woods@planix.com>, based on rcs2sccs
+# (retains some of the rlog parsing from it).
+#
+# The copyright is in the Public Domain.
+#
+
+if [ $# -ne 2 ]; then
+ echo USAGE: $0 srcdir dstdir
+ exit 2
+fi
+tsrcdir=$1
+tdstdir=$2
+
+revfile=/tmp/cvs2vendor_$$_rev
+rm -f $revfile
+
+commentfile=/tmp/cvs2vendor_$$_comment
+rm -f $commentfile
+
+srcdirs=`cd $tsrcdir && find . -type d -print | sed 's~^\.[/]*~~'`
+
+# the "" is a trick to get $tsrcdir itself without resorting to '.'
+for ldir in "" $srcdirs; do
+
+ srcdir=$tsrcdir/$ldir
+ dstdir=$tdstdir/$ldir
+
+ # Loop over every RCS file in srcdir
+ #
+ for vfile in $srcdir/*,v; do
+ # get rid of the ",v" at the end of the name
+ file=`echo $vfile | sed -e 's/,v$//'`
+ bfile=`basename $file`
+
+ if [ ! -d $dstdir ]; then
+ echo "making locally added directory $dstdir"
+ mkdir -p $dstdir
+ fi
+ if [ ! -f $dstdir/$bfile,v ]; then
+ echo "copying locally added file $dstdir/$bfile ..."
+ cp $vfile $dstdir
+ continue;
+ fi
+
+ # work on each rev of that file in ascending order
+ rlog $file | grep "^revision [0-9][0-9]*\." | awk '{print $2}' | sed -e 's/\./ /g' | sort -n -u +0 +1 +2 +3 +4 +5 +6 +7 +8 | sed -e 's/ /./g' > $revfile
+
+ for rev in `cat $revfile`; do
+
+ case "$rev" in
+ 1.1)
+ newdate=`rlog -r$rev $file | grep "^date: " | awk '{printf("%s.%s\n",$2,$3); exit}' | sed -e 's~/~.~g' -e 's/:/./g' -e 's/;//' -e 's/^19//'`
+ olddate=`rlog -r1.1.1.1 $dstdir/$bfile | grep "^date: " | awk '{printf("%s.%s\n",$2,$3); exit}' | sed -e 's~/~.~g' -e 's/:/./g' -e 's/;//' -e 's/^19//'`
+ sed "s/$olddate/$newdate/" < $dstdir/$bfile,v > $dstdir/$bfile.x
+ mv -f $dstdir/$bfile.x $dstdir/$bfile,v
+ chmod -w $dstdir/$bfile,v
+ symname=`rlog -h $file | sed -e '1,/^symbolic names:/d' -e 's/[ ]*//g' | awk -F: '$2 == "'"$rev"'" {printf("-n%s:1.1.1.1\n",$1)}'`
+ if [ -n "$symname" ]; then
+ echo "tagging $file with $symname ..."
+ rcs $symname $dstdir/$bfile,v
+ if [ $? != 0 ]; then
+ echo ERROR - rcs $symname $dstdir/$bfile,v
+ exit 1
+ fi
+ fi
+ continue # skip first rev....
+ ;;
+ esac
+
+ # get a lock on the destination local branch tip revision
+ co -r1 -l $dstdir/$bfile
+ if [ $? != 0 ]; then
+ echo ERROR - co -r1 -l $dstdir/$bfile
+ exit 1
+ fi
+ rm -f $dstdir/$bfile
+
+ # get file into current dir and get stats
+ date=`rlog -r$rev $file | grep "^date: " | awk '{printf("%s %s\n",$2,$3); exit}' | sed -e 's/;//'`
+ author=`rlog -r$rev $file | grep "^date: " | awk '{print $5; exit}' | sed -e 's/;//'`
+
+ symname=`rlog -h $file | sed -e '1,/^symbolic names:/d' -e 's/[ ]*//g' | awk -F: '$2 == "'"$rev"'" {printf("-n%s\n",$1)}'`
+
+ rlog -r$rev $file | sed -e '/^branches: /d' -e '1,/^date: /d' -e '/^===========/d' | awk '{if ((total += length($0) + 1) < 510) print $0}' > $commentfile
+
+ echo "==> file $file, rev=$rev, date=$date, author=$author $symname"
+
+ co -p -r$rev $file > $bfile
+ if [ $? != 0 ]; then
+ echo ERROR - co -p -r$rev $file
+ exit 1
+ fi
+
+ # check file into vendor repository...
+ ci -f -m"`cat $commentfile`" -d"$date" $symname -w"$author" $bfile $dstdir/$bfile,v
+ if [ $? != 0 ]; then
+ echo ERROR - ci -f -m"`cat $commentfile`" -d"$date" $symname -w"$author" $bfile $dstdir/$bfile,v
+ exit 1
+ fi
+ rm -f $bfile
+
+ # set the default branch to the trunk...
+ # XXX really only need to do this once....
+ rcs -b1 $dstdir/$bfile
+ if [ $? != 0 ]; then
+ echo ERROR - rcs -b1 $dstdir/$bfile
+ exit 1
+ fi
+ done
+ done
+done
+
+echo cleaning up...
+rm -f $commentfile
+echo " Conversion Completed Successfully"
+
+exit 0
diff --git a/contrib/cvs/contrib/cvs_acls.pl b/contrib/cvs/contrib/cvs_acls.pl
index bcb544d46f5d..c1d64e948770 100644
--- a/contrib/cvs/contrib/cvs_acls.pl
+++ b/contrib/cvs/contrib/cvs_acls.pl
@@ -1,8 +1,6 @@
#! xPERL_PATHx
# -*-Perl-*-
#
-# $Id: cvs_acls.pl,v 1.2 1995/07/10 02:01:33 kfogel Exp $
-#
# Access control lists for CVS. dgg@ksr.com (David G. Grubbs)
#
# CVS "commitinfo" for matching repository names, running the program it finds
diff --git a/contrib/cvs/contrib/cvscheck.man b/contrib/cvs/contrib/cvscheck.man
index 61a064aeeaf7..2b90b49a14cb 100644
--- a/contrib/cvs/contrib/cvscheck.man
+++ b/contrib/cvs/contrib/cvscheck.man
@@ -1,4 +1,3 @@
-.\" $Id: cvscheck.man,v 1.1.1.3 1995/08/28 16:20:24 jimb Exp $
.\" Contributed by Lowell Skoog <fluke!lowell@uunet.uu.net>
.TH CVSCHECK LOCAL "4 March 1991" FLUKE
.SH NAME
diff --git a/contrib/cvs/contrib/cvscheck.sh b/contrib/cvs/contrib/cvscheck.sh
index 96dba6e1f87e..f711b430e0f3 100644
--- a/contrib/cvs/contrib/cvscheck.sh
+++ b/contrib/cvs/contrib/cvscheck.sh
@@ -1,5 +1,4 @@
#! /bin/sh
-# $Id: cvscheck.sh,v 1.1 1995/07/10 02:26:29 kfogel Exp $
#
# cvscheck - identify files added, changed, or removed
# in CVS working directory
diff --git a/contrib/cvs/contrib/cvshelp.man b/contrib/cvs/contrib/cvshelp.man
index 2cfae1f2bb8c..b166af69528b 100644
--- a/contrib/cvs/contrib/cvshelp.man
+++ b/contrib/cvs/contrib/cvshelp.man
@@ -1,4 +1,3 @@
-.\" $Id: cvshelp.man,v 1.1.1.3 1995/08/28 16:20:28 jimb Exp $
.\" Contributed by Lowell Skoog <fluke!lowell@uunet.uu.net>
.\" Full space in nroff; half space in troff
.de SP
diff --git a/contrib/cvs/contrib/descend.man b/contrib/cvs/contrib/descend.man
index 5ac46f499d25..0434ca8b43c4 100644
--- a/contrib/cvs/contrib/descend.man
+++ b/contrib/cvs/contrib/descend.man
@@ -1,4 +1,3 @@
-.\" $Id: descend.man,v 1.1.1.3 1995/08/28 16:20:31 jimb Exp $
.TH DESCEND 1 "31 March 1992"
.SH NAME
descend \- walk directory tree and execute a command at each node
diff --git a/contrib/cvs/contrib/descend.sh b/contrib/cvs/contrib/descend.sh
index e6a788079416..039a7a3d3ee4 100644
--- a/contrib/cvs/contrib/descend.sh
+++ b/contrib/cvs/contrib/descend.sh
@@ -1,5 +1,4 @@
#! /bin/sh
-# $Id: descend.sh,v 1.1 1995/07/10 02:26:32 kfogel Exp $
#
# descend - walk down a directory tree and execute a command at each node
diff --git a/contrib/cvs/contrib/listen2.c b/contrib/cvs/contrib/listen2.c
new file mode 100644
index 000000000000..09226bda88e6
--- /dev/null
+++ b/contrib/cvs/contrib/listen2.c
@@ -0,0 +1,65 @@
+/* This will develop into the inted-like program which
+ we may want to use for a server on Win95/NT. Right now
+ it is just a test program ("telnet foo 2401" and you'll
+ get a message). */
+
+#include <winsock.h>
+#include <stdio.h>
+
+int
+main ()
+{
+ struct sockaddr_in sa;
+ SOCKET t;
+ SOCKET s;
+ WSADATA data;
+
+ if (WSAStartup (MAKEWORD (1, 1), &data))
+ {
+ fprintf (stderr, "cvs: unable to initialize winsock\n");
+ exit (1);
+ }
+
+ t = socket (PF_INET, SOCK_STREAM, 0);
+ if (t == INVALID_SOCKET)
+ {
+ printf ("Error in socket(): %d\n", WSAGetLastError ());
+ exit (1);
+ }
+ sa.sin_family = AF_INET;
+ sa.sin_addr.s_addr = INADDR_ANY;
+ sa.sin_port = htons (2401);
+ if (bind (t, (struct sockaddr *) &sa, sizeof (sa)) != 0)
+ {
+ printf ("Cannot bind(): %d\n", WSAGetLastError ());
+ exit (1);
+ }
+ if (listen (t, 1) != 0)
+ {
+ printf ("Cannot listen(): %d\n", WSAGetLastError ());
+ exit (1);
+ }
+ while (1)
+ {
+ int sasize = sizeof (sa);
+ s = accept (t, (struct sockaddr *) &sa, &sasize);
+ if (s == INVALID_SOCKET)
+ {
+ printf ("Cannot accept(): %d\n", WSAGetLastError ());
+ exit (1);
+ }
+ if (send (s, "hello, world\n", 13, 0) == SOCKET_ERROR)
+ {
+ /* Note that we do not detect the case in which we sent
+ less than the requested number of bytes. */
+ printf ("Cannot send(): %d\n", WSAGetLastError ());
+ exit (1);
+ }
+ if (closesocket (s) != 0)
+ {
+ printf ("Cannot closesocket(): %d\n", WSAGetLastError ());
+ exit (1);
+ }
+ }
+ return 0;
+}
diff --git a/contrib/cvs/contrib/listen2.mak b/contrib/cvs/contrib/listen2.mak
new file mode 100644
index 000000000000..a72fd08779ed
--- /dev/null
+++ b/contrib/cvs/contrib/listen2.mak
@@ -0,0 +1,161 @@
+# Microsoft Developer Studio Generated NMAKE File, Format Version 40001
+# ** DO NOT EDIT **
+
+# TARGTYPE "Win32 (x86) Console Application" 0x0103
+
+!IF "$(CFG)" == ""
+CFG=listen2 - Win32 Debug
+!MESSAGE No configuration specified. Defaulting to listen2 - Win32 Debug.
+!ENDIF
+
+!IF "$(CFG)" != "listen2 - Win32 Release" && "$(CFG)" !=\
+ "listen2 - Win32 Debug"
+!MESSAGE Invalid configuration "$(CFG)" specified.
+!MESSAGE You can specify a configuration when running NMAKE on this makefile
+!MESSAGE by defining the macro CFG on the command line. For example:
+!MESSAGE
+!MESSAGE NMAKE /f "listen2.mak" CFG="listen2 - Win32 Debug"
+!MESSAGE
+!MESSAGE Possible choices for configuration are:
+!MESSAGE
+!MESSAGE "listen2 - Win32 Release" (based on "Win32 (x86) Console Application")
+!MESSAGE "listen2 - Win32 Debug" (based on "Win32 (x86) Console Application")
+!MESSAGE
+!ERROR An invalid configuration is specified.
+!ENDIF
+
+!IF "$(OS)" == "Windows_NT"
+NULL=
+!ELSE
+NULL=nul
+!ENDIF
+################################################################################
+# Begin Project
+RSC=rc.exe
+CPP=cl.exe
+
+!IF "$(CFG)" == "listen2 - Win32 Release"
+
+# PROP BASE Use_MFC 0
+# PROP BASE Use_Debug_Libraries 0
+# PROP BASE Output_Dir "Release"
+# PROP BASE Intermediate_Dir "Release"
+# PROP BASE Target_Dir ""
+# PROP Use_MFC 0
+# PROP Use_Debug_Libraries 0
+# PROP Output_Dir "Release"
+# PROP Intermediate_Dir "Release"
+# PROP Target_Dir ""
+OUTDIR=.\Release
+INTDIR=.\Release
+
+ALL :
+
+CLEAN :
+ -@erase
+
+"$(OUTDIR)" :
+ if not exist "$(OUTDIR)/$(NULL)" mkdir "$(OUTDIR)"
+
+# ADD BASE CPP /nologo /W3 /GX /O2 /D "WIN32" /D "NDEBUG" /D "_CONSOLE" /YX /c
+# ADD CPP /nologo /W3 /GX /O2 /D "WIN32" /D "NDEBUG" /D "_CONSOLE" /YX /c
+CPP_PROJ=/nologo /ML /W3 /GX /O2 /D "WIN32" /D "NDEBUG" /D "_CONSOLE"\
+ /Fp"$(INTDIR)/listen2.pch" /YX /Fo"$(INTDIR)/" /c
+CPP_OBJS=.\Release/
+CPP_SBRS=
+# ADD BASE RSC /l 0x409 /d "NDEBUG"
+# ADD RSC /l 0x409 /d "NDEBUG"
+BSC32=bscmake.exe
+# ADD BASE BSC32 /nologo
+# ADD BSC32 /nologo
+BSC32_FLAGS=/nologo /o"$(OUTDIR)/listen2.bsc"
+BSC32_SBRS=
+LINK32=link.exe
+# ADD BASE LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib /nologo /subsystem:console /machine:I386
+# ADD LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib /nologo /subsystem:console /machine:I386
+LINK32_FLAGS=kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib\
+ advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib /nologo\
+ /subsystem:console /incremental:no /pdb:"$(OUTDIR)/listen2.pdb" /machine:I386\
+ /out:"$(OUTDIR)/listen2.exe"
+LINK32_OBJS=
+
+!ELSEIF "$(CFG)" == "listen2 - Win32 Debug"
+
+# PROP BASE Use_MFC 0
+# PROP BASE Use_Debug_Libraries 1
+# PROP BASE Output_Dir "Debug"
+# PROP BASE Intermediate_Dir "Debug"
+# PROP BASE Target_Dir ""
+# PROP Use_MFC 0
+# PROP Use_Debug_Libraries 1
+# PROP Output_Dir "Debug"
+# PROP Intermediate_Dir "Debug"
+# PROP Target_Dir ""
+OUTDIR=.\Debug
+INTDIR=.\Debug
+
+ALL :
+
+CLEAN :
+ -@erase
+
+"$(OUTDIR)" :
+ if not exist "$(OUTDIR)/$(NULL)" mkdir "$(OUTDIR)"
+
+# ADD BASE CPP /nologo /W3 /Gm /GX /Zi /Od /D "WIN32" /D "_DEBUG" /D "_CONSOLE" /YX /c
+# ADD CPP /nologo /W3 /Gm /GX /Zi /Od /D "WIN32" /D "_DEBUG" /D "_CONSOLE" /YX /c
+CPP_PROJ=/nologo /MLd /W3 /Gm /GX /Zi /Od /D "WIN32" /D "_DEBUG" /D "_CONSOLE"\
+ /Fp"$(INTDIR)/listen2.pch" /YX /Fo"$(INTDIR)/" /Fd"$(INTDIR)/" /c
+CPP_OBJS=.\Debug/
+CPP_SBRS=
+# ADD BASE RSC /l 0x409 /d "_DEBUG"
+# ADD RSC /l 0x409 /d "_DEBUG"
+BSC32=bscmake.exe
+# ADD BASE BSC32 /nologo
+# ADD BSC32 /nologo
+BSC32_FLAGS=/nologo /o"$(OUTDIR)/listen2.bsc"
+BSC32_SBRS=
+LINK32=link.exe
+# ADD BASE LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib /nologo /subsystem:console /debug /machine:I386
+# ADD LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib /nologo /subsystem:console /debug /machine:I386
+LINK32_FLAGS=kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib\
+ advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib /nologo\
+ /subsystem:console /incremental:yes /pdb:"$(OUTDIR)/listen2.pdb" /debug\
+ /machine:I386 /out:"$(OUTDIR)/listen2.exe"
+LINK32_OBJS=
+
+!ENDIF
+
+.c{$(CPP_OBJS)}.obj:
+ $(CPP) $(CPP_PROJ) $<
+
+.cpp{$(CPP_OBJS)}.obj:
+ $(CPP) $(CPP_PROJ) $<
+
+.cxx{$(CPP_OBJS)}.obj:
+ $(CPP) $(CPP_PROJ) $<
+
+.c{$(CPP_SBRS)}.sbr:
+ $(CPP) $(CPP_PROJ) $<
+
+.cpp{$(CPP_SBRS)}.sbr:
+ $(CPP) $(CPP_PROJ) $<
+
+.cxx{$(CPP_SBRS)}.sbr:
+ $(CPP) $(CPP_PROJ) $<
+
+################################################################################
+# Begin Target
+
+# Name "listen2 - Win32 Release"
+# Name "listen2 - Win32 Debug"
+
+!IF "$(CFG)" == "listen2 - Win32 Release"
+
+!ELSEIF "$(CFG)" == "listen2 - Win32 Debug"
+
+!ENDIF
+
+# End Target
+# End Project
+################################################################################
diff --git a/contrib/cvs/contrib/log.pl b/contrib/cvs/contrib/log.pl
index 5e3bf4883776..e4fb9b1d3fbc 100644
--- a/contrib/cvs/contrib/log.pl
+++ b/contrib/cvs/contrib/log.pl
@@ -1,8 +1,6 @@
#! xPERL_PATHx
# -*-Perl-*-
#
-#ident "$CVSid$"
-#
# XXX: FIXME: handle multiple '-f logfile' arguments
#
# XXX -- I HATE Perl! This *will* be re-written in shell/awk/sed soon!
diff --git a/contrib/cvs/contrib/log_accum.pl b/contrib/cvs/contrib/log_accum.pl
index d5c678303421..d299fa62b53d 100644
--- a/contrib/cvs/contrib/log_accum.pl
+++ b/contrib/cvs/contrib/log_accum.pl
@@ -1,8 +1,6 @@
#! xPERL_PATHx
# -*-Perl-*-
#
-#ident "@(#)ccvs/contrib:$Name: $:$Id: log_accum.pl,v 1.4 1996/03/06 15:27:09 woods Exp $"
-#
# Perl filter to handle the log messages from the checkin of files in
# a directory. This script will group the lists of files by log
# message, and mail a single consolidated log message at the end of
@@ -22,6 +20,7 @@
# -M modulename - set module name to "modulename"
# -f logfile - write commit messages to logfile too
# -s - *don't* run "cvs status -v" for each file
+# -w - show working directory with log message
#
# Configurable options
@@ -173,9 +172,10 @@ sub read_logfile {
sub build_header {
local($header);
local($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime(time);
- $header = sprintf("CVSROOT:\t%s\nModule name:\t%s\nChanges by:\t%s@%s\t%02d/%02d/%02d %02d:%02d:%02d",
+ $header = sprintf("CVSROOT:\t%s\nModule name:\t%s\nRepository:\t%s\nChanges by:\t%s@%s\t%02d/%02d/%02d %02d:%02d:%02d",
$cvsroot,
$modulename,
+ $dir,
$login, $hostdomain,
$year%100, $mon+1, $mday,
$hour, $min, $sec);
@@ -228,7 +228,6 @@ sub mail_notification {
print MAIL "Date: " . $rfc822date . "\n";
print MAIL "Subject: CVS Update: " . $modulename . "\n";
print MAIL "To: " . $mailto . "\n";
- print MAIL "From: " . $login . "@" . $hostdomain . "\n";
print MAIL "Reply-To: " . $replyto . "\n";
print MAIL "\n";
print MAIL join("\n", @text), "\n";
@@ -255,9 +254,13 @@ $state = $STATE_NONE;
$login = getlogin || (getpwuid($<))[0] || "nobody";
chop($hostname = `hostname`);
chop($domainname = `domainname`);
+if ($domainname !~ '^\..*') {
+ $domainname = '.' . $domainname;
+}
$hostdomain = $hostname . $domainname;
$cvsroot = $ENV{'CVSROOT'};
-$do_status = 1;
+$do_status = 1; # moderately useful
+$show_wd = 0; # useless in client/server
$modulename = "";
# parse command line arguments (file list is seen as one arg)
@@ -284,6 +287,8 @@ while (@ARGV) {
$modulename = shift @ARGV;
} elsif ($arg eq '-s') {
$do_status = 0;
+ } elsif ($arg eq '-w') {
+ $show_wd = 1;
} elsif ($arg eq '-f') {
($commitlog) && die("Too many '-f' args\n");
$commitlog = shift @ARGV;
@@ -303,10 +308,14 @@ if ($replyto eq '') {
#
@path = split('/', $files[0]);
-# XXX there are some ugly assumptions in here about module names and
+# XXX There are some ugly assumptions in here about module names and
# XXX directories relative to the $CVSROOT location -- really should
# XXX read $CVSROOT/CVSROOT/modules, but that's not so easy to do, since
# XXX we have to parse it backwards.
+# XXX
+# XXX Fortunately it's relatively easy for the user to specify the
+# XXX module name as appropriate with a '-M' via the directory
+# XXX matching in loginfo.
#
if ($modulename eq "") {
$modulename = $path[0]; # I.e. the module name == top-level dir
@@ -384,8 +393,10 @@ while (<STDIN>) {
chop; # Drop the newline
if (/^In directory/) {
- push(@log_lines, $_);
- push(@log_lines, "");
+ if ($show_wd) { # useless in client/server mode
+ push(@log_lines, $_);
+ push(@log_lines, "");
+ }
next;
}
diff --git a/contrib/cvs/contrib/mfpipe.pl b/contrib/cvs/contrib/mfpipe.pl
index bae7a7243079..c74d71564908 100644
--- a/contrib/cvs/contrib/mfpipe.pl
+++ b/contrib/cvs/contrib/mfpipe.pl
@@ -12,9 +12,6 @@
# Especially if they regularly beat on the same directory. Anyway if you
# think anyone would be interested here it is.
#
-# $Id: mfpipe.pl,v 1.2 1995/07/10 02:01:57 kfogel Exp $
-#
-#
# File: mfpipe
#
# Author: John Clyne
diff --git a/contrib/cvs/contrib/rcs-to-cvs.sh b/contrib/cvs/contrib/rcs-to-cvs.sh
index 3af83d708ca4..66a62a9da5e1 100644
--- a/contrib/cvs/contrib/rcs-to-cvs.sh
+++ b/contrib/cvs/contrib/rcs-to-cvs.sh
@@ -1,6 +1,5 @@
#! /bin/sh
#
-# $Id: rcs-to-cvs.sh,v 1.2 1995/07/15 03:40:34 jimb Exp $
# Based on the CVS 1.0 checkin csh script.
# Contributed by Per Cederqvist <ceder@signum.se>.
# Rewritten in sh by David MacKenzie <djm@cygnus.com>.
@@ -33,7 +32,7 @@
usage="Usage: rcs-to-cvs [-v] [-m message] [-f message_file] repository"
vbose=0
message=""
-message_file=/usr/tmp/checkin.$$
+if [ -d /var/tmp ]; then message_file=/var/tmp/checkin.$$; else message_file=/usr/tmp/checkin.$$; fi
got_one=0
if [ $# -lt 1 ]; then
@@ -79,7 +78,7 @@ fi
if [ $got_one -eq 0 ]; then
echo "Please Edit this file to contain the RCS log information" >$message_file
echo "to be associated with this directory (please remove these lines)">>$message_file
- ${EDITOR-/usr/ucb/vi} $message_file
+ ${EDITOR-vi} $message_file
got_one=1
fi
diff --git a/contrib/cvs/contrib/rcs2log.sh b/contrib/cvs/contrib/rcs2log.sh
index ccea907ea37b..554856695666 100644
--- a/contrib/cvs/contrib/rcs2log.sh
+++ b/contrib/cvs/contrib/rcs2log.sh
@@ -12,8 +12,6 @@
# Author: Paul Eggert <eggert@twinsun.com>
-# $Id: rcs2log.sh,v 1.2 1995/07/28 19:48:45 eggert Exp $
-
# Copyright 1992, 1993, 1994, 1995 Free Software Foundation, Inc.
# This program is free software; you can redistribute it and/or modify
@@ -27,8 +25,9 @@
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
-# along with this program; see the file COPYING. If not, write to
-# the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.
+# along with this program; see the file COPYING. If not, write to the
+# Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+# Boston, MA 02111-1307, USA.
tab=' '
nl='
@@ -122,7 +121,7 @@ month_data='
# log the revisions checked in since the first ChangeLog entry.
case $rlog_options in
'')
- date=1970
+ date=1970-01-01
if test -s ChangeLog
then
# Add 1 to seconds to avoid duplicating most recent log.
@@ -158,8 +157,7 @@ case $rlog_options in
}
}
}
- # Output comma instead of space to avoid CVS 1.5 bug.
- printf "%d/%02d/%02d,%02d:%02d:%02d\n", year,i+1,dd,hh,mm,ss
+ printf "%02d/%02d/%d %02d:%02d:%02d\n", i+1,dd,year,hh,mm,ss
exit
}
'
@@ -364,7 +362,13 @@ EOF
'
initialize_fullname=`
- (cat /etc/passwd; ypmatch $authors passwd) 2>/dev/null |
+ (
+ cat /etc/passwd
+ for author in $authors
+ do nismatch $author passwd.org_dir
+ done
+ ypmatch $authors passwd
+ ) 2>/dev/null |
$AWK -F: "$awkscript"
`$initialize_fullname
esac
@@ -414,6 +418,15 @@ case $hostname in
echo >&2 "$0: cannot deduce hostname"
exit 1
}
+
+ case $hostname in
+ *.*) ;;
+ *)
+ domainname=`(domainname) 2>/dev/null` &&
+ case $domainname in
+ *.*) hostname=$hostname.$domainname
+ esac
+ esac
esac
diff --git a/contrib/cvs/contrib/rcs2sccs.sh b/contrib/cvs/contrib/rcs2sccs.sh
index af701384e4b6..b089dfef065a 100644
--- a/contrib/cvs/contrib/rcs2sccs.sh
+++ b/contrib/cvs/contrib/rcs2sccs.sh
@@ -1,8 +1,6 @@
#! /bin/sh
#
#
-# OrigId: rcs2sccs,v 1.12 90/10/04 20:52:23 kenc Exp Locker: kenc
-# $Id: rcs2sccs.sh,v 1.1 1995/07/10 02:26:45 kfogel Exp $
############################################################
# Error checking
diff --git a/contrib/cvs/contrib/sccs2rcs.csh b/contrib/cvs/contrib/sccs2rcs.csh
index 0f31893d3b24..a1dea01b19e7 100644
--- a/contrib/cvs/contrib/sccs2rcs.csh
+++ b/contrib/cvs/contrib/sccs2rcs.csh
@@ -42,8 +42,6 @@
# ...!harvard!cg-atla!viewlog!kenstir
#
# Various hacks made by Brian Berliner before inclusion in CVS contrib area.
-#
-# $Id: sccs2rcs.csh,v 1.1 1995/07/10 02:26:48 kfogel Exp $
#we'll assume the user set up the path correctly
diff --git a/contrib/cvs/cvs-format.el b/contrib/cvs/cvs-format.el
index cdbd8423ce2a..06dcc62fdd40 100644
--- a/contrib/cvs/cvs-format.el
+++ b/contrib/cvs/cvs-format.el
@@ -1,11 +1,17 @@
;; -*- lisp-interaction -*-
;; -*- emacs-lisp -*-
;;
+;; Set emacs up for editing code using CVS indentation conventions.
+;; See HACKING for more on what those conventions are.
+;; To use, put in your .emacs:
+;; (load "c-mode")
+;; (load "cvs-format.el")
+;; You need to load c-mode first or else when c-mode autoloads it will
+;; clobber the settings from cvs-format.el. Using c-mode-hook perhaps would
+;; be a cleaner way to handle that. Or see below about (set-c-style "BSD").
;;
-;; originally from...
-;; Rich's personal .emacs file. feel free to copy.
-;;
-;; Last Mod Wed Feb 5 16:11:47 PST 1992, by rich@cygnus.com
+;; Credits: Originally from the personal .emacs file of Rich Pixley,
+;; then rich@cygnus.com, circa 1992. He sez "feel free to copy."
;;
;;
@@ -75,7 +81,13 @@
;;`c-label-offset'
;; Extra indentation for line that is a label, or case or default.
-
+;; This doesn't quite do the right thing for CVS switches, which use the
+;; switch (foo)
+;; {
+;; case 0:
+;; break;
+;; style. But if one manually aligns the first case, then the rest
+;; should work OK.
(setq c-label-offset -4)
;;;; eof
diff --git a/contrib/cvs/doc/ChangeLog b/contrib/cvs/doc/ChangeLog
index 01efb1a2ef79..1ef10f4784bd 100644
--- a/contrib/cvs/doc/ChangeLog
+++ b/contrib/cvs/doc/ChangeLog
@@ -1,3 +1,1299 @@
+Wed May 14 12:16:19 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (Binary files): Add text and comment about
+ automatically detecting binary files.
+
+Mon May 12 11:55:07 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvsclient.texi (Connection and Authentication): Add item about
+ future expansion.
+
+Thu May 8 11:08:34 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (Update imports): Add comment about wdiff
+ vs. fsf/wdiff in example.
+
+Wed May 7 13:52:47 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (checkout): Add comment about need for example
+ regarding what the "module" argument means.
+
+Tue May 6 18:02:27 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (History browsing): Add comment about looking at old
+ revisions.
+
+Tue May 06 15:05:00 1997 Larry Jones <larry.jones@sdrc.com>
+
+ * cvs.texinfo: More additions/corrections for -R due to recent
+ changes.
+
+Mon Dec 16 15:18:00 1996 Larry Jones <larry.jones@sdrc.com>
+
+ * cvs.texinfo: Added/corrected documentation for -R. (Minor edits
+ by Jim Kingdon to reflect recent changes in cvs.texinfo)
+
+Sun May 4 14:38:35 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (Compatibility): Add comment about "D" lines in
+ Entries.
+
+ * cvs.texinfo (CVS commands, diff): Change "run diffs" to "show
+ differences"; the former is jargon.
+ (CVS commands): Don't refer to "rlog" in describing what log does.
+
+ * Makefile.in (cvsclient.dvi cvsclient.aux): Run texi2dvi rather
+ than (poorly) emulating it ourself.
+
+ Fix overfull and underfull hboxes:
+ * cvs.texinfo (What is CVS?): Add words "the newsgroup" before
+ "comp.sources.unix".
+ (Credits): Put list of people in @display.
+ (Repository files): Put /usr/local/cvsroot in @example.
+ (Connecting via rsh): Change "anklet" to "toe" in example.
+ (Kerberos authenticated, Password authentication client, Password
+ authentication server): Change "brickyard" to "yard" in example.
+ (Read-only access): Use @example and refer to files with a shorter
+ pathname.
+ (Server temporary directory): Use @example for pathname.
+ (Watches Compatibility): Add phony line break.
+ (Revision numbers): Remove revision 1.2.2.2 and tighten up the
+ spacing for "the main trunk".
+ (Tags, Creating a branch): Change /usr/local/cvsroot to /u/cvsroot.
+ (Merging more than once): Tighten up spacing for "the main trunk".
+ (Recursive behavior): Put long command in @example.
+ (First import): Remove word "called".
+ (Common options): Put long URL in @example.
+ (loginfo example): Use fewer hyphens in example.
+ (Variables): Put long command name in @example.
+ (Copying): Add line break.
+ (Administrative files): Remove "the" from title.
+ (Copying): Change "@unnumberedsec" to two "@heading"s.
+ * cvsclient.texi (Requests): Change /home/kingdon/zwork/cvsroot to
+ /u/cvsroot.
+ (Example): Add word "file".
+ (Example): Change line breaks in example log message.
+ (Example): Change /home/kingdon/testing/cvsroot to /u/cvsroot.
+
+ * cvs.texinfo (Credits): Don't refer to appendix A and B, they
+ have been renumbered. Reword so that it works whether the text in
+ question has since been rewritten or not.
+
+ * cvs.texinfo (BUGS): Rewrite to reflect the many different ways
+ that one might want to handle bugs. Move information on Signum
+ and Cyclic from Preface to here. Remove information on known
+ deficiencies in the manual (some of them I'm not sure were really
+ things in need of improvement; others were too general to be
+ useful). For the most part FIXME comments are probably better for
+ this. Remove "Linkoping, October 1993, Per Cederqvist"--many
+ parts of the manual are now from other people, dates, and places.
+ (What is CVS): For the most part, just refer to BUGS concerning
+ bug-cvs. Also tell people how to subscribe to bug-cvs.
+ (Credits): Say that list is not comprehensive and refer to
+ ChangeLog.
+
+Sat May 3 10:51:58 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (rcsinfo): Add comment about checkoutlist and
+ related topics.
+
+ * cvs.texinfo (Server temporary directory): New node.
+
+ * cvs.texinfo (Backing up): New node.
+
+ * cvs.texinfo (Repository): Be more explicit about the repository
+ and the working directory not being subdirectories of each other.
+
+Mon Apr 28 11:12:56 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (Removing files): Use "*.c" not "?.c" in example;
+ the former should be good for both unix and DOS-like operating
+ systems. Document -f option. Refer to Invoking CVS for a full
+ list of options. Add a few comments.
+
+ * cvs.texinfo (Invoking CVS): For checkout and update, call them
+ "sticky options" not "sticky kopts".
+
+ * cvs.texinfo (Editing files): Add additional comments on get
+ vs. checkout.
+
+Sun Apr 27 16:17:06 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (commit): Only document the current flags (where -f
+ is force and -F file gets the message from a log file). We had
+ partly made this change on 9 Feb 1997, but some places got missed.
+
+ * RCSFILES: Add discussion of the common concern regarding
+ applying deltas to get to a branch head.
+
+ * DIFFUTILS-2.7-BUG: New file.
+
+ * cvs.texinfo (File status): Refer to "Invoking CVS", not
+ "status", for status options. Add paragraph about how "cvs -n -q
+ update" is another way to display file status.
+ (update examples): Removed; it had contained the "cvs -n -q
+ update" material.
+ (Invoking CVS): xref to "File status" and "Tags", not "status" and
+ "status options".
+ (status, status options): Removed.
+ (update options, checkout options): xref to "Invoking CVS"
+ not "status".
+
+ * cvsclient.texi (Requests): Clarify how long-lived Sticky and
+ Static-directory are.
+
+ * cvs.texinfo: Add @finalout.
+
+ * cvs.texinfo (Error messages): Add "cannot change permissions on
+ temporary directory" message.
+
+Wed Apr 23 12:53:45 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvsclient.texi (Requests): Document "add" in much more detail.
+
+Wed Apr 23 00:38:17 1997 Ian Lance Taylor <ian@cygnus.com>
+
+ * cvsclient.texi (Requests): Correct small typo (`a' for `as').
+
+Tue Apr 22 14:23:32 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvsclient.texi (Protocol Notes): Expand ideas on multisite
+ features somewhat. Add items about the network turnarounds for
+ pserver authentication and for protocol negotiation.
+
+Mon Apr 21 08:54:48 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (Working directory storage): Describe what to do
+ with Entries.Log in more detail.
+
+ * cvsclient.texi (Responses): Say "CVS 1.9 and earlier" rather
+ than "pre version 1.10". The latter increases confusion by
+ referring to a version which doesn't exist yet.
+
+Mon Apr 21 01:02:53 1997 Ian Lance Taylor <ian@cygnus.com>
+
+ * cvsclient.texi (Responses): Document Rcs-diff. Indicate that
+ Patched is now deprecated in favor of Rcs-diff.
+
+Sun Apr 20 23:42:03 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (Working directory storage): Add note about format
+ of timestamp and the "Result of merge" concept.
+
+Sat Apr 19 13:42:33 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvsclient.texi (Responses): It is OK for Copy-file to implement
+ a rename instead of a copy.
+
+Fri Apr 18 12:05:48 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (Assigning revisions): Say that -r implies -f.
+
+Thu Apr 17 16:34:14 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (From other version control systems): Add comment
+ about CMZ and PATCHY.
+
+Wed Apr 16 12:35:25 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvsclient.texi (Responses): Add paragraph describing how
+ Copy-file relates to Merged.
+ (Responses): Add paragraph about how it is the server which
+ worries about not clobbering the user's file.
+
+Tue Apr 15 00:57:31 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * RCSFILES: Add notes on keyword expansion.
+
+ * cvs.texinfo (Rename by copying): Comment out seemingly erroneous
+ text regarding the revision number that the new file starts with.
+
+Mon Apr 14 12:37:35 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvsclient.texi (Requests): Clients should try to send
+ notifications right away.
+
+ * cvsclient.texi (Requests): For Notify request, clarify a few
+ future expansion situations. Specify the format of the time.
+
+ * cvsclient.texi (Requests): Clarify that arguments to co, rdiff,
+ and rtag are module names (and how that differs from file/directory
+ names).
+
+ * cvsclient.texi (Responses): Say that servers need to create
+ directories one at a time.
+
+Sat Apr 12 09:32:58 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (Committing your changes): Say that editor default
+ is notepad (not vi) for Windows NT/95. Be more clear about what
+ "cvs commit" does. Add paragraph about timestamps.
+ (Environment variables, Global options, editinfo):
+ Add xrefs to that node.
+
+Thu Apr 10 15:48:39 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (Error messages): Add "could not patch; will refetch".
+
+Wed Apr 9 15:21:11 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (Working directory storage): New node.
+
+ * cvs.texinfo (Error messages): Add comment about "cvs co ." on
+ NT.
+
+Tue Apr 8 14:44:26 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (Error messages): Add diff3 usage message.
+
+Sun Apr 6 19:03:01 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (Removing files): Add comment about undoing a "cvs
+ remove".
+
+ * cvsclient.texi (Requests): Explicitly mention the idea of
+ deferring "Notify" requests.
+
+Tue Apr 1 07:51:38 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvsclient.texi (Responses): Add paragraph about directory
+ creation and empty directories.
+
+ * cvs.texinfo (Binary files): Add comment about binary files and
+ merges.
+
+ * cvsclient.texi (Requests): Add discussion of when to send
+ Is-modified.
+
+ * cvsclient.texi (Requests): Sending Is-modified is enough to
+ prevent the file from being considered "lost".
+
+Sun Mar 30 00:31:47 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvsclient.texi (Requests): Add Is-modified request. Clarify
+ order of Entry relative to Unchanged or Is-modified (might as well
+ specify the same thing vis-a-vis Modified while we are at it).
+
+Sat Mar 29 12:32:40 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvsclient.texi: Change "newline" to "linefeed". Most of the
+ document already reads "linefeed" and that is what is intended.
+ (File transmissions): New node, moved here from Requests.
+ (Goals, Filenames, File transmissions, new node Strings): Add
+ discussion of character sets and what we expect from the transport
+ protocol we run on.
+
+ * cvsclient.texi (Requests): Add paragraph about each Directory
+ request specifying a new local-directory and repository.
+
+ * cvsclient.texi (Requests): Add paragraph about renaming
+ local-directory in Directory request. Use "local-directory"
+ consistently instead of "working directory", for clarity.
+
+Fri Mar 28 13:59:59 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvsclient.texi (Requests): Make it clear that there is no
+ guarantee that one will get Clear-sticky instead of another
+ response. Also clarify that clients will tend to store the
+ repository in a long-term way.
+
+ * cvsclient.texi (Requests): Further clarify Directory example.
+
+ * cvsclient.texi (Requests): Add example and further explanation
+ of what expand-modules is for.
+
+ * cvsclient.texi (Requests): Add example, hopefully making it
+ clearer what REPOSITORY and LOCAL-DIRECTORY mean to Directory.
+
+ * cvs.texinfo (Attic): New node.
+ (rtag options): Adjust discussion of -a accordingly.
+ (Repository files): Adjust accordingly.
+
+Thu Mar 27 09:57:05 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (Error messages): Give exact wording of broken pipe
+ error message.
+
+ * cvs.texinfo (history database): Add comment about various
+ problems with the history file.
+
+ * cvs.texinfo (Common options): The ISO8601 web page we had
+ mentioned in a comment is no more. Replace it with a new one.
+
+ * cvs.texinfo (Common options): "cvs history" also outputs dates.
+
+Wed Mar 26 10:54:21 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (Common options): "cvs editors" also outputs dates.
+
+ * cvs.texinfo (Outside): Fix paragraph which said that revision
+ numbers start at 1.0. First of all, it is 1.1. Second of all, it
+ is sometimes 2.1, 3.1, etc. Third of all, the xref should be to
+ Assigning revisions not commit options.
+
+ * cvs.texinfo (Outside): Comment out sentence which incorrectly
+ stated that "cvs add" can operate on "foo/bar.c".
+
+Tue Mar 25 22:21:29 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (Error messages): New node.
+ (Magic branch numbers): Move from Troubleshooting to Revisions and
+ branches. The former placement never made any sense to me.
+ (Revision numbers): Remove "Main trunk (intro)" index entry now
+ that this node is right next to the other "main trunk" index
+ entry.
+ (BUGS): Very briefly mention reporting bugs in CVS.
+
+ * cvs.texinfo (Compatibility): Add comment about "Nfoo" in CVS/Tag.
+
+Mon Mar 24 13:50:24 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (Creating a branch): Add comment about -r in branch
+ example.
+
+ * cvsclient.texi (Responses): Discuss meaning of tagspec and
+ future expansion in Set-sticky. The behavior described is the one
+ which CVS has always implemented.
+
+Fri Mar 21 14:19:05 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvsclient.texi (Requests): Revise meaning of "Case" per change
+ to CVS.
+
+Tue Mar 18 15:50:47 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ The following reorganization hopefully presents numeric revisions
+ in a slightly more coherent fashion. The only new material is the
+ paragraph about assigning revisions for added files.
+ * cvs.texinfo (A sample session): Bring in a sentence from Basic
+ concepts node, defining a repository.
+ (Revisions and branches): Renamed from Branches (it has always
+ covered non-branch tags too). Bring in nodes "Revision numbers" and
+ "Versions revisions releases" from Basic concepts, the former in
+ particular was way too detailed for an intro section.
+ (A sample session): Add comment about how we need an introduction
+ and what might go into one. Also bring in the paragraph from
+ Basic concepts introducing modules, but comment it out.
+ (Viewing differences): Add comment about
+ (Basic concepts): Removed; its content has been farmed out as
+ described above, and as the comment said, it was fundamentally
+ flawed.
+ (Assigning revisions): New node. Incorporates the "New major
+ release number" subsubsec which was in "commit examples". Add
+ paragraph concerning how CVS assigns revisions on added files.
+ (commit options): Refer to that node under -r.
+ (Invoking CVS): Add comment about text for -r.
+
+Tue Mar 18 13:04:30 1997 Jim Meyering <meyering@totoro.cyclic.com>
+
+ * Makefile.in: (install-info): Depend on installdirs.
+
+Sun Mar 16 12:37:12 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (File permissions): CVSUMASK now works for RCS
+ files; but it is (still) awkward for client/server CVS.
+
+Sat Mar 15 17:41:12 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (Magic branch numbers): Add comment about where this
+ should go.
+
+Thu Mar 13 09:11:36 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (Credits): Fix grammatical mistake ("manual about"
+ -> "manual is about"). Reported by Philippe De Muyter.
+
+Sun Mar 9 09:06:40 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (File permissions): Add comment about val-tags and
+ CVSUMASK.
+
+Sun Mar 2 12:33:26 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (From scratch): Add comment about creating
+ directories with add rather than import.
+
+ * cvs.texinfo (Creating a repository): Add comment about how this
+ somewhat duplicates Server requirements.
+
+ * cvs.texinfo (Connecting via rsh): Add comment about rsh
+ vs. remsh. Also wording fix ("incorrect" -> "inapplicable").
+
+ * cvs.texinfo (Outside): Add comment about renames and annotate.
+
+ * cvs.texinfo (Server requirements): New node.
+
+Thu Feb 27 15:20:49 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (Multiple developers): Reword section on "cvs admin
+ -l". As nearly as I can tell based on when it came up on info-cvs
+ and other contexts, people who are into reserved checkouts
+ generally find that cvs admin -l is OK. Add a bunch more notes
+ (inside @ignore) about reserved checkout implementation ideas.
+
+Sun Feb 23 16:12:03 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (Common options): Add various additional comments
+ about date formats.
+
+ * RCSFILES: Remove diff for Id and explain it in words instead.
+ The previous values for Id had been clobbered by keyword expansion
+ on the RCSFILES file itself.
+
+Sat Feb 22 14:16:28 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * Makefile.in (DISTFILES): Fix typo (missing backslash).
+
+Fri Feb 21 23:08:38 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * RCSFILES: New file.
+ * Makefile.in (DISTFILES): Add RCSFILES.
+
+20 Feb 1997 Lenny Foner <foner@media.mit.edu>
+
+ * cvs.texinfo (Checklist): Fix typo ("keword" -> "keyword").
+
+Thu Feb 20 21:57:05 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (Keeping a checked out copy): Add "web" to index.
+
+Wed Feb 12 18:44:16 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (Password authentication client, Invoking CVS):
+ Document "cvs logout" command.
+
+Tue Feb 11 20:42:45 1997 Ian Lance Taylor <ian@cygnus.com>
+
+ * cvs.texinfo (commit options): Document that the -f option to
+ commit disables recursion.
+
+Sun Feb 9 13:58:59 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (diff options): Document all the options we pass
+ through to diff. Remove paragraph about -D sometimes meaning
+ --ifdef since that is no longer true.
+
+ * cvs.texinfo (Multiple developers): Add lengthy comment about
+ reserved checkout design issues.
+
+ * cvs.texinfo (Wrappers): Add paragraph about timestamps.
+
+ * cvs.texinfo (commit options): Don't try to document what CVS 1.3
+ does with -f and how recent versions differ: 1.3 is pretty old
+ anyway, we generally only try to document the current version, and
+ the way it was described here was pretty confusing.
+ (Environment variables): Likewise for CVSEDITOR.
+
+ * cvs.texinfo (import output): Add index entries for symbolic
+ links. Add brief mention of whether behavior should be
+ different. Add comments on other symbolic link issues.
+
+Wed Feb 5 13:02:37 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (Concurrency): Add comment about commit/commit
+ atomicity.
+
+Mon Feb 3 10:55:41 1997 joel boutros <nihilis@moral.addiction.com>
+
+ * cvs.texinfo (Connecting via rsh): Fix typo (programs -> problems).
+
+Fri Jan 31 12:18:47 1997 Ian Lance Taylor <ian@cygnus.com>
+
+ * cvsclient.texi (Connection and Authentication): Correct typo
+ (``sent'' for ``send''), and rewrite sentence for clarity.
+
+Fri Jan 24 10:31:57 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (File status): Change "Unresolved Conflict" to "File
+ had conflicts on merge" per change to CVS.
+
+Sun Jan 19 16:21:17 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (admin): Add comments about "group" and "compiled in
+ value". At least one info-cvs poster was confused by this.
+
+Thu Jan 16 17:54:51 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (Wrappers): It is just -t/-f which doesn't work
+ client/server. -k *does* (well, except for the problem with
+ import noted in BUGS). -m I don't know and I doubt anyone cares.
+
+Mon Jan 13 15:41:02 1997 Karl Fogel <kfogel@ynu38.ynu.edu.cn>
+
+ * cvs.texinfo (Read-only access): rephrase to imply that there may
+ be other administrative files, besides history and locks, which
+ read-only users can also affect (in the future, for example, the
+ `passwd' file).
+
+Wed Jan 8 14:50:47 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * Makefile.in: Remove CVSid; we decided to get rid
+ of these some time ago.
+
+Wed Jan 8 09:08:36 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvsclient.texi (Connection and Authentication): Document
+ restriction that cvs root sent in the cvs protocol and in the
+ pserver authentication protocol must be identical.
+
+Thu Jan 2 13:30:56 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * Makefile.in, cvs.texinfo: Remove "675" paragraph;
+ see ../ChangeLog for rationale.
+
+Thu Jan 2 09:34:51 1997 Karl Fogel <kfogel@ynu38.ynu.edu.cn>
+
+ * cvs.texinfo (Read-only access): new node.
+ (Repository): new menu item for above new node.
+ (Password authentication server): document the user-aliasing
+ feature. Why was this undocumented before?
+
+Wed Jan 1 18:12:11 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (Conflicts example): Use @asis in example to prevent
+ starting a line with a conflict marker. This means that when
+ maintaining the file with CVS itself, CVS will not think there is
+ a conflict merely because of the conflict marker in the example.
+ IMHO, this is totally bogus and CVS needs a better way of figuring
+ out whether a conflict is resolved (see comments elsewhere in this
+ node), but until then.... Credit to Fred Fish for reporting the
+ problem.
+
+ * cvs.texinfo (cvsignore): Add paragraph about how .cvsignore
+ files in the sources being imported by "cvs import" override
+ "-I !". Credit goes to Fred Fish for pointing out this problem.
+
+Thu Dec 19 12:36:46 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (Credits): Update Roland Pesch email address per his
+ request.
+
+Tue Dec 17 12:57:56 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (verifymsg): In example, remove text "and reedit if
+ necessary"; it was copied from editinfo and doesn't apply here.
+ Fix syntax of if statement; remove unnecessary attempt at loop;
+ don't use -n with echo. Add @appendixsec at start of node.
+ Add note about how verifymsg cannot change log message.
+ (editinfo): In paragraph saying editinfo is obsolete, fix various
+ typos and formatting glitches. Mention -e as well as EDITOR.
+ (editinfo): In saying that editinfo doesn't get consulted with -m,
+ -F or client/server, recommend verifymsg. Remove comment which
+ says, in effect, "we need a feature like verifymsg".
+ (editinfo example): Change "verifymsg" back to "editinfo" here;
+ the example is of editinfo not verifymsg.
+
+Tue Dec 17 12:45:32 1996 Abe Feldman <feldman@cyclic.com>
+
+ * cvs.texinfo (verifymsg): New node.
+ various places: Say that editinfo is obsolete, or refer to
+ verifymsg instead of editinfo
+
+Wed Dec 11 08:55:26 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (Compatibility): Add comment about 1.3 and file death.
+
+ * cvs.texinfo (update output, release output): Document "P" as
+ well as "U".
+
+Tue Dec 10 16:23:40 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (Builds): Change "make" to "implement" and "build";
+ in this context "make" is ambiguous.
+ (Builds): Add new URL of mk web page.
+
+Mon Dec 9 11:03:37 1996 Jim Blandy <jimb@floss.cyclic.com>
+
+ * cvs.texinfo (Password authentication client, Environment
+ variables): Remove mention of CVS_PASSWORD.
+
+Sun Dec 8 22:38:34 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (Repository files): Mention differences between RCS
+ files in RCS and in CVS.
+ (Tags): Tag names must start with a letter.
+
+Fri Dec 6 09:08:18 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (syntax): Expand discussion of regular expression
+ syntax.
+
+Fri Nov 29 09:06:41 1996 fnf@ninemoons.com (Fred Fish)
+ and Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo, cvsclient.texi: Make sure @ref and friends are
+ followed by "," or "." as described in the texinfo manual. This
+ is a dubious practice as texi2html and texinfo.tex don't require
+ it, and makeinfo could insert them as needed, but since makeinfo
+ doesn't do that yet, cope.
+
+ * cvs.texinfo (From files): Suggest "diff -r" rather than "ls -R"
+ as the way to see that the sources seem to have been imported
+ correctly.
+ (Common options): -k is also available with import.
+ (admin options): Fix typo ("interrested" -> "interested").
+
+Mon Nov 25 10:03:56 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (Common options): Add comments about two digit
+ years, year 2000, and ambiguous/nonexistent dates.
+
+Sun Nov 24 17:27:24 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (First import): Don't say what the wdiff program we
+ are using as an example does--that is confusing. Also don't show
+ untarring it--people might be familiar with cpio, ZIP, VMS BACKUP,
+ etc., instead of tar.
+
+ * cvs.texinfo (Adding files): Update comment about "cvs add -m".
+
+ * cvs.texinfo (Common options): Remove -H; -H is not a command
+ option.
+ (Global options): Also list --help and --version. Don't say that
+ -H gives a list of commands; it doesn't any more (directly).
+
+ * cvs.texinfo: Add comment pointing to paper size web page.
+
+ * cvs.texinfo (Common options): Rewrite section on date formats.
+ Executive summary is that RFC822 and ISO8601 are now preferred.
+
+Wed Nov 20 08:39:45 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (Getting Notified): Add paragraph clarifying that
+ watches happen per user, not per working directory.
+
+Tue Nov 19 09:39:08 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (Tags): Suggest that future special tag names might
+ start with ".". Fix typo.
+
+ * cvs.texinfo (Removing directories): -P is also available with
+ export.
+ (Moving directories): Rewrite first paragraph; now says that you
+ must use -P for the directory to disappear from working
+ directories. Thanks to Martin Lorentzon
+ <Martin.Lorentzson@emw.ericsson.se> for reporting this bug.
+ (various): Where we mention -P, point to Removing directories
+ node.
+
+Sat Nov 16 18:03:22 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvsclient.texi (Example): Rewrite to actually be based on a real
+ live example (and therefore reflect the way the protocol currently
+ works). Add comment about formatting of the document itself.
+
+Thu Nov 14 10:22:58 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvsclient.texi (Introduction): Use @ref, not @xref, after "see".
+ (Goals): Rewrite items about locking, about uploading in big
+ chunks, and about atomicity to be focused more on the protocol
+ than the current implementation.
+ (Notes): Remove this node. The attempt to describe the basic
+ model has pretty much been replaced by the Introduction.
+ The material about how to start the client is incomplete and
+ better left to cvs.texinfo. And the item about the lack of
+ SERVER_FLOWCONTROL is obsolete now that SERVER_FLOWCONTROL is the
+ default.
+ (Protocol Notes): Add comment about multisite features.
+ (Requirements): Use @code for requests and responses.
+
+ * cvs.texinfo (Remote repositories): Add a few sentences defining
+ "client" and "server"; before we had been using the terms without
+ defining them.
+
+ * cvs.texinfo (What is CVS?): Add paragraph about reporting bugs.
+ Reword and expand comp.software.config-mgmt description (and add
+ comments about other newsgroup facts). Point people at GNU list
+ of FTP sites rather than directly at prep.ai.mit.edu.
+
+Wed Nov 6 09:45:08 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (Tracking sources): Add comment regarding added and
+ removed files.
+
+Tue Nov 5 14:00:31 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo: Rename node "Invoking CVS" to "CVS commands".
+ Rewrite the intro and comments to reflect addition of the new
+ Invoking CVS.
+ (Invoking CVS): New node, a quick summary of each command.
+ (annotate): Don't list the options; refer to Invoking CVS and
+ Common options instead.
+
+Sun Nov 3 21:22:42 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (Compatibility): New node, moved from ../README.
+
+ * cvs.texinfo (Common options): Add comment about how tar manual
+ contains documentation for getdate date formats.
+
+Fri Nov 1 14:00:31 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (commit examples): Rewrite "New major release
+ number" section to tighten up the wording, better motivate the
+ discussion, and replace the term "rcs revision number" with
+ "numeric revision".
+
+Fri Oct 25 07:49:21 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (loginfo): Don't say "a la printf"; the syntax is
+ only vaguely similar to printf.
+
+ * cvs.texinfo (loginfo): To get just the repository name, suggest
+ %{} instead of % "standing alone"; the latter is now an error.
+
+Tue Oct 22 13:08:54 1996 Noel Cragg <noel@gargle.rain.org>
+
+ * cvs.texinfo (loginfo): add information on the new loginfo format
+ string specification.
+
+Mon Oct 21 17:33:44 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (Builds): New node.
+ (What is CVS?): Refer to it.
+
+Sat Oct 19 14:32:21 1996 Jim Meyering <meyering@asic.sc.ti.com>
+ and Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (Choosing a model): Wording/grammar fix.
+
+Sat Oct 19 14:32:21 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvsclient.texi (Obsolete): New node.
+ (Requests): Remove Repository and Lost and adjust Directory,
+ UseUnchanged, and other places accordingly.
+ (Required): Directory and Unchanged are now required.
+
+ * cvs.texinfo (Removing files): Don't talk about modules; they are
+ not relevant in this context.
+ (Removing directories): New node.
+ (Common options): Refer to it instead of duplicating information.
+
+Fri Oct 18 11:05:06 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (First import, import): Add paragraph about the fact
+ that import doesn't modify the directory which it imports from.
+
+ * cvs.texinfo (Creating a repository): Add paragraph about
+ resource requirements.
+
+ * cvs.texinfo (Copying): Replace empty node with a copy of the GPL.
+
+Thu Oct 17 12:10:55 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (Adding files): Revise comment to more accurately
+ reflect the functioning/nonfunctioning status of cvs add -m.
+
+ * cvs.texinfo (Reverting local changes): New node, somewhat based
+ on the version of this node from 30 Sep 96 change.
+ (admin options): Refer to it.
+
+ * cvs.texinfo: Reinstate 30 Sep 96 change from A4 to US letter.
+
+ * cvs.texinfo (Concurrency): When telling people how to clean up
+ locks, tell them to make sure the locks are owned by the person
+ who has the stale locks.
+ (update output, release output): Remove text about how CVS doesn't
+ print "? foo" for directories; CVS has since been changed (see
+ conflicts-130 in sanity.sh).
+
+Wed Oct 16 15:01:42 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (history options): Mention new option -x E.
+
+Mon Oct 14 15:21:25 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (Tags): Add paragraph on choosing a convention for
+ naming tags.
+
+Thu Oct 10 16:05:26 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (modules): Describe what & does.
+
+Mon Oct 7 17:20:11 1996 Ian Lance Taylor <ian@cygnus.com>
+
+ * cvs.texinfo (Removing files): Correct apparent cut and paste
+ error: refer to the removed file, not the added file.
+
+Tue Oct 1 14:15:33 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo: Revert all recent changes (the last unscathed one
+ is the CVSUMASK one from Sunday). For the most part said changes
+ are for new features which are not appropriate at this stage of
+ the release process. None of the changes being reverted need to
+ go into 1.9, that is for sure.
+
+Mon Sep 30 18:17:34 1996 Greg A. Woods <woods@most.weird.com>
+
+ * cvs.texinfo (Credits): add comment asking if we should update.
+ Add more detail about printing Letter on A4.
+ Add some comments about internal comments.
+ (From files): describe "cvs import -b 1" for importing existing
+ projects onto the main branch.
+ (First import): add a couple of helpful hints about naming vendor
+ and release tags, etc., and regularize the examples with this.
+ (Tracking sources): noted some reasons why you might use vendor
+ branches with "cvs import".
+ (Update imports): mention using "update" in place of "checkout" if
+ you have an existing working directory.
+ (Binary files in imports): add sub-menu separator comment.
+ (Tracking sources): new menu entry "Reverting to vendor release".
+ (Reverting to vendor release): new node to describe reverting
+ local changes and optionally using patch(1) to move local changes
+ forward.
+ (Global options): describe -D and -g, as well as DIFFBIN and
+ GREPBIN.
+ (export examples): add one.
+ (import options): describe the effect of '-b 1'.
+
+Mon Sep 30 08:09:53 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo: Adjust comments concerning A4 vs. US letter,
+ referring to ../README.
+
+ * cvs.texinfo (Common options): Add comment about dates which CVS
+ uses in output.
+
+Sun Sep 29 11:14:16 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (Keyword list): Don't mention Name twice.
+
+ * cvs.texinfo (File permissions): Expand CVSUMASK stuff a bit.
+ (Setting a watch, Environment variables, Global options): Update
+ index entries for "read-only files, and ...".
+
+ * cvsclient.texi (Requests): State that Gzip-stream is preferred
+ to gzip-file-contents. Cite RFC1952/1951 rather than just "gzip".
+ Say that RFC1950/1951 compression is also known as "zlib".
+
+Sat Sep 28 09:31:45 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (Repository): Move all information about the
+ internal structure of the repository to User modules node. Rename
+ it to "Repository storage" ("User modules" wasn't particularly
+ clear). Mention CVSUMASK. Much clarification and
+ reorganization.
+ (Basic concepts): Remove material which duplicates what is now in
+ Repository. Rewrite paragraph introducing modules.
+
+ * cvs.texinfo (Starting a new project): In discussing difficulty
+ in renaming files, don't refer to "cvs 1.x"--there is no
+ non-vaporous "cvs 2.x". Reword to reflect that part of the reason
+ to avoid renames (where possible) is not because of CVS at all, and
+ to try to give a general impression of how bad CVS issues involved in
+ renaming are.
+
+Fri Sep 27 04:23:44 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (Adding files): Talk about directories, not modules,
+ since that is what is meant. Suggest using -kb option to add
+ rather than running cvs admin after the fact and xref to Binary
+ files not admin examples. Incorporate information which had been
+ in "add" node (there was a lot of duplication). Don't document
+ use of "add" on a directory to take the place of "cvs update -d";
+ the latter is simpler and more logical.
+ (add, add options, add examples): Removed.
+ (release output, release options): Update xrefs accordingly.
+ (Adding files, Removing files): Mention the fact that adds and
+ removes are branch-specific.
+ (Merging adds and removals): New node.
+
+ * cvs.texinfo (Concurrency): When mentioning RCS locks, use the
+ term reserved checkouts and xref to the place where we discuss
+ them in more depth.
+
+Thu Sep 26 08:26:01 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (log): Add comments about timezones.
+ (log, Common options): Add index entries for timezone and zone, time.
+
+Wed Sep 25 11:05:30 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (log options): Add xref to where we describe the
+ date formats that -d accepts.
+ (Common options): Don't refer to date formats accepted by co(1);
+ CVS's rules have never been the same. Add long whiny comment
+ about what a mess date formats are.
+
+Tue Sep 24 11:49:02 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (From other version control systems): The RCS file
+ must not be locked when you copy it to the CVS repository.
+
+ * cvs.texinfo (Editing files): Also discuss how to revert in the
+ non-watch case. Add some index entries.
+
+ * cvs.texinfo (update output): Add comment about how we *should*
+ be handling .# files. Mention fact that it is different under
+ VMS. Add .# to index.
+
+Fri Sep 20 13:08:33 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (Multiple developers): Revise text on reserved
+ versus unreserved checkouts extensively. Move index entries for
+ "reserved checkouts" and "RCS-style locking" to here. Add
+ cross-reference to cvs admin -l. Add new section "Choosing a
+ model".
+ (Editing files): Add note about use of the word "checkout".
+
+Tue Sep 17 00:54:57 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (Defining the module): Don't suggest "cvs co
+ modules"; that depends on a "modules" module being defined which
+ is not the default which is created by "cvs init". Instead
+ suggest "cvs co CVSROOT/modules" which should always work.
+
+Tue Sep 17 00:43:49 1996 VaX#n8 <vax@linkdead.paranoia.com>
+ and Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (Rename by copying): Suggest "cvs tag -d" on the file
+ "new", not on everything. Also don't suggest deleting branch tags.
+
+Tue Sep 17 00:34:39 1996 David A. Swierczek <swierczekd@med.ge.com>
+
+ * Makefile.in (install-info): Note whether files are in srcdir and
+ deal with it rather than cd'ing into srcdir.
+
+Mon Sep 16 23:33:36 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (Wrappers): Add comment about using wrappers to
+ compress files in the repository.
+
+ * cvs.texinfo (modules): Add comments about how we should be
+ documenting how -i and friends operate in client/server CVS.
+
+ * cvs.texinfo (File permissions): Describe the need for write
+ permissions for locks and val-tags.
+
+ * cvs.texinfo (commitinfo): Add comment about using commitinfo to
+ enforce who has access.
+
+Wed Jul 24 17:01:41 1996 Larry Jones <larry.jones@sdrc.com>
+ and Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (checkout): Refer to "update output" node.
+ (import): Add new import output node.
+ (release): Correct release output menu entry (used to be
+ release options instead).
+ (update output): Say this is output from checkout as well as
+ update.
+
+Mon Sep 16 16:18:38 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (Common options): Clarify that CVS uses MM/DD/YY dates.
+
+ * cvs.texinfo (Common options): Add comment about what HEAD means.
+
+Mon Sep 16 10:52:04 1996 Norbert Kiesel <nk@col.sw-ley.de>
+
+ * cvs.texinfo (Global options): Document global '-T' option.
+
+Sat Sep 14 10:46:58 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (Keeping a checked out copy): New node.
+
+Fri Sep 13 23:55:42 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (Magic branch numbers): Delete song and dance about
+ how cvs log can't cope with magic branches because rlog doesn't
+ know about them; cvs log no longer calls rlog. Delete item about
+ how you can't specify a symbolic branch to cvs log; that is fixed.
+
+Wed Sep 11 22:48:21 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (Password authentication server): Add comments
+ regarding port numbers and troubleshooting.
+
+Tue Sep 10 10:36:00 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (What is CVS?): Reword text regarding info-cvs,
+ to avoid overfull hbox.
+
+ * cvs.texinfo (Binary files): Add comment about further issues
+ with recovering from failure to use -kb.
+
+ * cvs.texinfo (Conflicts example): Describe the "feature" by which
+ CVS won't check in files with conflicts.
+ (File status): Expand and revise to document all the possible
+ statuses from cvs status. Also document "Working revision" and
+ "Repository revision". Refer to other sections for other aspects
+ of cvs status.
+ (status options): Refer to other sections as appropriate.
+ (update output): Refer user to Conflicts example node. Add
+ comment regarding purging of .# files.
+
+Fri Sep 6 11:47:14 1996 Ian Lance Taylor <ian@cygnus.com>
+
+ * cvs.texinfo (Kerberos authenticated): Mention need for
+ --enable-encryption option in order to use encryption.
+ (Global options): Likewise, in description of -x option.
+
+Thu Sep 5 14:31:42 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (Connecting via rsh): Discuss :ext:, :server:, and
+ CVS_RSH.
+ (Remote repositories): Mention what default is if no access method
+ is specified.
+ (Environment variables): Don't discuss CVS_RSH at length here;
+ rely on reference to "Connecting via rsh" node.
+
+Mon Aug 26 15:39:18 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvsclient.texi (Protocol Notes): When talking about having the
+ client know the original contents of files, suggest cvs edit as a
+ solution.
+
+Thu Aug 22 10:44:40 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (Keyword list): Document Name keyword.
+
+ * cvs.texinfo (Tags): Revise comment regarding legal tag names.
+
+Mon Aug 12 14:58:54 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (Password authentication security): Add comment
+ about how some of this is not pserver-specific.
+
+Tue Aug 6 16:48:53 1996 Ian Lance Taylor <ian@cygnus.com>
+
+ * cvs.texinfo (log, log options): Update for changes to cvs log
+ now that it no longer invokes rlog.
+
+Thu Jul 25 10:10:16 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvsclient.texi (Requests): Fix typo (Kerberos-request ->
+ Kerberos-encrypt).
+
+Wed Jul 24 18:53:13 1996 Ian Lance Taylor <ian@cygnus.com>
+
+ * cvs.texinfo (Kerberos authenticated): Change the note that the
+ Kerberos connection is not encrypted.
+ (Global options): Add documentation for -x.
+ * cvsclient.texi (Protocol Notes): Remove enhancement note about
+ Kerberos encryption.
+ (Requests): Add documentation for Kerberos-encrypt request.
+
+Thu Jul 18 18:27:40 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (Creating a repository): Mention need to be able to
+ create lock files in the repository.
+
+ * cvsclient.texi (Responses): In F response, make at least a
+ minimal attempt to define "flush".
+
+ * cvs.texinfo (Wrappers): Document -k.
+ (From files, Binary files in imports): Say that imports can deal
+ with binary files and refer to Wrappers node for details.
+ (Binary files): Likewise for imports and adds.
+
+Sat Jul 13 18:29:10 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (Binary files): Add paragraph concerning the fact
+ that the keyword expansion mode is not versioned, and why this is
+ a problem.
+
+Fri Jul 12 18:55:06 1996 Ian Lance Taylor <ian@cygnus.com>
+
+ * cvsclient.texi (Requests): Document Gzip-stream.
+
+Thu Jul 11 21:51:45 1996 Ian Lance Taylor <ian@cygnus.com>
+
+ * cvsclient.texi (Responses): Document new "F" response.
+
+Wed Jul 10 18:46:39 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (log): Don't document "rlog"; it is deprecated.
+
+Sat Jul 6 22:07:45 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (Environment variables): Document more temp
+ directory nonsense, this time with "patch".
+
+Fri Jul 5 23:27:40 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvsclient.texi (Responses): Add comment regarding "/." ending.
+
+Fri Sep 13 10:52:09 1996 Greg A. Woods <woods@clapton.seachange.com>
+
+ * cvs.texinfo: don't force afourpaper -- Letter prints much better
+ on A4 than the other way around, believe you me!
+ (rdiff options): describe -k and new -K.
+ (RCS keywords): add description of $Name.
+ (Using keywords): add description of #ident and example of using
+ $Name.
+ - also fixed cross references to Substitution modes in various
+ places.
+ (import options): mention that -b 1 imports to the trunk.
+
+Tue Jul 2 22:40:39 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (Sticky tags): Update to reflect change in
+ "resurrected" message.
+
+Fri Jun 28 10:48:33 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (Connecting via rsh): Add comment about what we
+ might be saying about troubleshooting.
+
+Sun Jun 23 10:07:45 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (Password authentication security): Add comment
+ regarding anoncvs as practised by OpenBSD.
+
+Wed Jun 19 15:41:11 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (Administrative files): Add xref to Intro
+ administrative files.
+ (Intro administrative files): Add comment suggesting future
+ reorganizations of this material.
+ (syntax): Add comment regarding this node.
+ (Getting Notified): Actually document the notify file. It hadn't
+ really been documented to speak of.
+ (editinfo,loginfo,rcsfino,cvsignore): Make the index entries
+ follow the standard "foo (admin file)" format.
+
+Fri Jun 14 18:14:32 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (editinfo): Discuss the way editinfo falls down in
+ the face of -m or -F options to commit, or remote CVS.
+
+Thu Jun 13 15:08:27 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (Watches): Add comment discussing the
+ fact that using cvs edit instead of chmod is not enforced.
+
+ * cvs.texinfo (Setting up): Add index entry for "init (subcommand)".
+ (Creating a repository): Move contents of node Setting up here...
+ (Setting up): ...and remove this node.
+ (Creating a repository): Don't refer to the INSTALL file (it just
+ refers back to us!).
+
+ * cvsclient.texi (Responses): Document the fact that the server
+ should send data only when the client is expecting responses.
+
+Wed Jun 12 16:04:48 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvsclient.texi (Entries Lines): Add comment regarding specifying
+ the meaning of "any other" data, in the conflict field.
+ (Example): Make it clear that using a separate connection for each
+ command is not required by the protocol. Add some comments
+ regarding ways in which the example is out of date or wrong.
+
+Fri Jun 7 18:02:36 1996 Ian Lance Taylor <ian@cygnus.com>
+ and Jim Kingdon <kingdon@cyclic.com>
+
+ * cvs.texinfo (annotate): Document new -r, -D, and -f options.
+
+Fri Jun 7 16:59:47 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (Invoking CVS): Add comment describing why only some
+ commands are listed here.
+ (Structure, Environment variables): Don't describe CVS as a
+ front-end to RCS.
+
+Tue Jun 4 21:19:42 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvsclient.texi (Responses): Document Created and Update-existing.
+
+Mon Jun 3 17:01:02 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvsclient.texi (Responses): Clarify "diff -c" versus "diff -u"
+ format in Patched response. Don't specify how the client must
+ implement its patch-applying functionality.
+
+Sun May 26 17:12:24 1996 Norbert Kiesel <nk@col.sw-ley.de>
+
+ * cvs.texinfo (tag options) Document option "-c".
+
+Thu May 23 21:11:56 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (Credits): Rewrite section on FAQ to reflect the
+ fact that FAQ is no longer maintained.
+ (What is CVS?): Mention comp.software.config-mgmt as well as
+ info-cvs. Mention the fact that info-cvs-request can be slow in
+ responding.
+ (What is CVS?): Rather than say that cvs is not a configuration
+ mangement system, say specifically what it lacks (change control,
+ etc.). I added process control (which was sorely lacking from the
+ list of configuration management functionality), and deleted some
+ functions such as tape construction which are not provided by the
+ well-known configuration management systems.
+
+ * cvs.texinfo (checkout options): Add comment regarding
+ subdirectories (lack of clarity pointed out by ian@cygnus.com).
+ Add comment about that infernal "short as possible" wording.
+
+ * cvs.texinfo (Global options): Fix error ("diff" -> "log")
+ (reported by ian@cygnus.com).
+ Remove footnote "Yes, this really should be fixed, and it's being
+ worked on"--it isn't clear what "this" is, and I doubt anyone is
+ working on it.
+
+Tue May 21 17:22:18 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvsclient.texi (Requests): Clarify Directory with "." as local
+ directory, and that filename for Questionable cannot contain "/".
+
+Mon May 20 13:15:25 1996 Greg A. Woods <woods@most.weird.com>
+
+ * cvs.texinfo (rdiff): description from main.c:cmd_usage
+ (rtag): description from main.c:cmd_usage
+ (status): description from main.c:cmd_usage
+ (tag): description from main.c:cmd_usage
+ [all for the sake of consistency]
+
+Fri May 17 11:42:46 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo: Add index entries for :local:, etc.
+ (Password authentication server): Revert erroneous change
+ regarding the format of CVSROOT/passwd file.
+
+Thu May 16 17:06:46 1996 Noel Cragg <noel@gargle.rain.org>
+
+ * cvsclient.texi (Notes): Removed paragraphs about various server
+ invocations which are now described in full in node "Connection
+ and Authentication."
+ (Requests): Include a note that "gzip-file-contents" doesn't
+ follow the upper/lowercase convention and that unknown reqests
+ always elicit a response, regardless of capitalization.
+
+ * cvs.texinfo (Kerberos authenticated): Removed bogus version
+ number.
+ (Repository): explain the ":local:" access method.
+
+Wed May 15 23:43:04 1996 Noel Cragg <noel@gargle.rain.org>
+
+ * cvsclient.texi (Goals): mention access methods.
+ (Requests): add note about convention: requests starting with a
+ captial letter don't have any expected response. Made sure each
+ request has a "Response expected" note.
+
+ * cvs.texinfo (Remote repositories): add info about access
+ methods; fix pserver info.
+
+Tue May 14 08:56:41 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (Environment variables): Try to document somewhat
+ more accurately where we put temporary files.
+
+ * cvs.texinfo (From files): Say directory tree instead of module
+ where that is what we mean. Use @var{wdir} and @var{rdir} in the
+ example instead of using @var{dir} for two different things.
+ (From files): Say directory tree instead of module
+ where that is what we mean.
+ (Binary files): When using cvs admin -kb, one needs an extra
+ commit step on non-unix systems.
+ (Binary files in imports): New node.
+ (Wrappers): Add comment regarding indent example.
+ (Top): Don't refer to modules when that is not what we mean.
+
+Fri May 10 09:39:49 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.texinfo (Sticky tags): Explain what sticky dates and
+ non-branch sticky tags are good for.
+
+ * cvs.texinfo (Repository): Document that -d overrides CVS/Root.
+
Wed May 1 15:38:26 1996 Jim Kingdon <kingdon@harvey.cyclic.com>
* cvs.texinfo (Tags): Document un-revision of all-uppercase tag
diff --git a/contrib/cvs/doc/DIFFUTILS-2.7-BUG b/contrib/cvs/doc/DIFFUTILS-2.7-BUG
new file mode 100644
index 000000000000..f258ee7f6aae
--- /dev/null
+++ b/contrib/cvs/doc/DIFFUTILS-2.7-BUG
@@ -0,0 +1,263 @@
+The enclosed two messages describe a bug in GNU diff 2.6 and 2.7 which
+may cause CVS to perform an erroneous merge. You may wish to use GNU
+diff 2.5 or apply the patch supplied by Loren James Rittle below. It
+would be nice to add this to the CVS testsuite, but I haven't done so
+because probably a lot of people who would like to run the testsuite
+are using the buggy diff.
+
+From: friedman@splode.com (Noah Friedman)
+To: bug-gnu-utils@prep.ai.mit.edu
+Cc: info-cvs@prep.ai.mit.edu
+Subject: diffutils 2.7 -- diff3 merge bug
+Date: Tue, 29 Oct 96 17:02:54 CST
+
+I believe a change first introduced in GNU diff 2.6 causes diff3 sometimes
+to produce incorrect merges.
+
+Since this is a not a bug in CVS itself but can cause commits to CVS
+repositories to be incorrect, am warning info-cvs@prep.ai.mit.edu as
+well as reporting the bug to bug-gnu-utils@prep.ai.mit.edu.
+
+I am including a simple test case as well as some sample outputs from
+different versions of `diff' and `diff3' in the enclosed shar archive.
+In addition, the file DESCRIPTION in that archive describes the problem
+more fully.
+
+If anyone has any advice for how to fix or to work around this bug, I would
+appreciate it. Using diff 2.5 seems like the most immediately obvious
+solution, but I don't know if it will introduce other problems.
+I do not understand the algorithms used by GNU diff well enough to suggest
+any patches.
+
+Unshar and enjoy. ;-)
+
+begin 666 merge-testcase.shar.gz
+M'XL(",&,=C("`VUE<F=E+71E<W1C87-E+G-H87(`[5Q[;]M&$O_[^"FF;E#9
+M@41)?C!GYX&V;MPS<$F+V+FZP.&:%;F26)-<E;NTHC[NL]_,+%^29;USUP-L
+M&)9$[CQW]C?#W;$^_ZS="Y.V'CJ?P_4PU("_`O101A&(U!^&=Q+V1ZD*,E\&
+MT)O`MV_?XVV19B:,-!R[W0.72!7(CR85O@$SE-`/(ZFAGZH8/Q)'RZD)6B"_
+M$`<IT"J6<''Y]]=-2&6L[B2RD7<RG2!%,H">[*M4,K</A8X-B,)$@N@IXH6W
+M$C"3$0[00^;40%60RQL12%`)=$]/O5:WTSH\A:YW=G(,YU?79,*+?AK*(!;)
+MEWH4J4"ZOHI?D157*DM]"4&82M^H=`)CH>%#.]-I.U*^B-HZ]=N#)&L'8;_/
+M#FC',AW(EI':^$++7('7'T-MR`CKAW&(SGR:*/,4K0+4/1VGH3&H?9;@?131
+M\AOD>#V2?MA'W2P;G@_R-?@J,2),]!E>C60R,$.(47&P/XF(R7DM_LE?9MXN
+M^T%R_#DZ]:"5CO-?F+:M7;QI3=!-VE(\ZQRM0A'CM%D"[_1X%0(5!3*U%,<G
+MAPLHWHA;25[FL8?=PV<+QG[S^NK\W>7WUY??O<U9=Q;92Y-\Z)Y87>I&>R>K
+MD)'-=:I5A'ESA!T_6X'LOK"3%52LYH?N!ZM,:2%P'FFW>[1HJJ[>OWGSU;L?
+M,;2-ROPAM$0,W<,C_#TY/3V%)T]<>_U5.Y!W[23#17/XZHNN$_:!>,!GT.K7
+M";[XPE['JP7M<P8%!WC5_,277O)?1T9:3E\_PX_2'ZK\!1H_?/7N[>7;;\\`
+M5RI"DD8$H#5LPAC?BWBD78!SE>@09P@&TO`*%TG0*#CLX0HU(HKH.L'D/S^P
+MI$83$46;-.QE!C$T3/CF!08MO$<,"4THM>NZ>X4^_=!)XQE;"P,9%U[6?Q:O
+MTNFQ+^N^#*`Q`UZE]ZP_/D(+_%0*MK/"Q!DB'![?XMU[W,B.0AP:TUBH9Z.<
+MS9N])]T]^.PEOFGY>W-4TK?A:$0J+39\GU`!1(0&!!-,3C@#^J!1Q$'%+D];
+M*S`T./2`[-4XBPW=_M=-N]V`%R^@<?6WK][]]/J[BP:\6L%.I]V&KS-C5.+^
+M+.Z$<^.,A'\K!A)2C"85NV(TBD(?_:Z2YW@WC$<J-<5-2CON4[H^RGHX#/Q(
+M8`JQ#)W?G!N`]E.XI$A,3"A0/.9S>Q<3$28.C.H!QN!^IPF=`XI?^%6F"N\%
+M>),^#F4X&!J7.,%3^%%E$&<X,9C_L"1(,'XQ8D44(A5ZS`Q50-D<2X213*-)
+M[3;G[MQ0RZQ-+[G:N4K[!W2-U4;'9L@#+Y%U?.$G$YI(GJM(I?`2^-7M1>BM
+MY_E]7%BB%\G@^OZX02HFS^ML+C")XEUZ<0/9%UED^!++`_C#^<,I)A(G^4D%
+M%1:I.H>GW9-##U/D"E,,X`\Q0T/'\Y:/__WW,B(M[&"1T%\2C7V!X<W0PWKZ
+M*DO,R[T/8Q]:/KQ8)O(#@0TO-T[Y\A?8>U+QV;,:%:BVD-59'D\B`DUSCOR:
+MX&=I*M&S?*7.F#!A5?RBE/80?"W"$Z+;)9RP'CM$$\MO2S`IC'S$DI6Q!#VU
+M#$YHR&J(4C);"BHWN1>Q<KB322@3?,#`<A[K@8SR*>!3#H2EA[FDJ+LX]UP/
+MET^@X6,3)DWKWF;=OP"O?\G".Q'1JC,J)Z*?OE*H7B+'E9.>3]]VR<NP/\7:
+MLBU&SG-UB(*0A%XF]B4GI;<Y>6TV^"FP$`U+)*Z&Q,\6(7&Y/E8#8CM\/1SF
+M=;PI#+/`"H6YYMX,A8G3+`@CNQV!,#^.;(+"3+A+&+::[!"'<X9;`G%IYR,2
+M_TFKND<`_D0`O+`4KM;%:@B<CU\/@NT2WA2#K<@*A'EK:C,09E:S*(S\MD/A
+M8F]K#?PM2':`O*7T[3&W8K49VM:M<KZYO+@XPB5%.U%'_"G_@"N=Z<Z<F[^T
+MGNSSN`-HO>:8G4[;,Q$TL[-YPWNO:'(ZR&*</,T8@8[32#E68/"&Q*MCB>$9
+M2"-38LJ[X[CX9.K+$7D!N;".#6U1%@.9/C-L(.",I/65F9*$ZW*$R,];P*3$
+MQ.X>WXET@J)&,@F(!@&`R,)DE!G>9'8=8EW?/20O6">@#P2T6D.,SE]5TJ(M
+M=/VRV\%+B_V`L9)F$KW!K*L=QII_Y[/N3K&>=GB=\S*(\;K=.1`S%0P+P:4:
+MN1*LE%&Z)J"48BHHX3WKM:"D8#(+(LAI.Q"I;7JO@2,UJAU`25V'[=%DBMMF
+M@#)CGF-/6J2AJ+!G-KCHL#Q*\TJ+S2=*&`]YT=.Z9KU(O_QX3#MAXJN4]DEI
+M^Q@+$4W#$\ATL2-<GAO!H>OA3%-=(%.L'E@!7V0:N?@JCD.DQ?KK_!]7R&JD
+M=$B;T9*O]6C=YW*:H!5<`BZ81)FP/R$YYQ,?ZP3G2O7-6-A`)ZQ`);&DBD$0
+M;E'-IZ&7#5J#)&NQ1E^.4)`K0A=ENS+(L+ASD+/)]ZVG>*`6?,JGHDB-<06*
+M9$">"7'Q8I4K42IO<S/:H:%-A[`-ZU["2#2CSP4ELWC[^H<KL(N.(5:8:J\<
+M"<Z*DG'/==WO16J04M"$6/\V2Z<BQJK,$!JB'VG_7G[$X,'1)$2+&"-.6T[V
+M7-&%]SI#4)X0X/*19P_?Z!@OR;2)GC%\/LE[_U-#(L+^U-TCQ9PWDUIDU".F
+M\@[-B/9E(M)0Y=9\90W.S_1X`!V%^G2@1U$PE/XM>@KMH8Q""6<DU8@P_@8X
+M+_7#%(5B4:TQ#P0RDC9(^UGBD],XP11!Q'%E)\C.&C$I0VI2\M02]0D*ID3-
+MZ8B4&*'?*8H$^G5(]59=#@:(C$<<K<3*BJU)I4.3K\D2R=%MHQ'O<FQ@`/(Q
+MKEWA$"C)DV=5I"/A/.KD7:@R'4U:UMB@4B$_8I[1OU%))UY7J@BW/@.KKT9E
+M`%:NL)K<DS"DA2(1Z%@ISAVT-*[+4^ZI1-><2:G-F<Q'9]UHC^;'!)R,6;6)
+MI56D3`/V$OG:S,Q],=Y!AEQ-W,EH4E<.'CCHXW!.\J<>GR=%0`%==B[L0V7?
+M(9EFF$H)=R@3'8(FE.T`/*B.:2=N$:'H&>?^22B;,>=<==HK/`)#-TMNZ8X(
+M$%AI*5C4I<=2F>(BCLO0P34TQVQOKMEV]G-0K`";1U2F.?=,\W+3[!HH)#S-
+M@X"`5N!LJ0$&:K[2PK3P`'"VEBFM)`I)AQZ_N:XCV/9MF-]*:R'F%YJ3/#ZM
+M$V1,_0)<81;^H6'&R2>EK"T)12LF%+EF+*E-8JH:XV":BDM&>RN1P:S@A\H_
+ML"Z$G2HL2`MGLNNI@R1Q"'G4.&'M65H!Q[$PB&^ZOF1Y3"ZO5-A94>$RQ5C5
+M[:(GSJ1C/BWH9G2F`,K"D?5H,\]6ER@O"N6==&*LORS2QP@(.NSE*:F,.4-)
+MTU+Q-#)O*S!@_?B>4]W#B,+E6#C.75[M'I[.J79G*Y6%!>_4X)5JWGHMM6;9
+M6Q=65;ZV!6.MTK?&:+;Z)6[;E;_SP&;U,G@.]0[*X7DZ;5\6S^6Z67G\@-G.
+MC>M6K4\M',&?-GR\=`X[S:-.T#UU7@#^;K5'1^3K;]+E5`_NTDW?7[A-9X>V
+M^763C3JB^\URJ;;J[,=E8I=OU7F=><CRT"0O1)BY1"LAS;SP7!-QY@FO/7-W
+MUCW)GL/OWN-WQ]L-_M1JH/7AIR+>(?K4--H=^-29;H<]TS:O`SU+MY^<KM?L
+M_M7GO_DB6WPX7(U9>C(QPV[1Z02U7;Z")0<B^8"E<NN,%@E]!-T_!>C.1/=*
+MF%NG60MR:XMR0\2MB:Z=EYQL"KBUO>39,Y.3G>"MMU6]YWV2>L_[)/6>M[MZ
+MSUM:[WF/]=[_!?1T.P]"C[=)O>=M7.]YV]=[WH[K/>^_4.]YV]1[WJ>H][Q/
+M4>]Y.ZOWO&7UGK=EO7=X^C^O]^SB?02_3<'O?U(O;X>UZY=YWJ9EGK=UF><]
+M4.8=/]L09Q>4><<[VM:;W>%?_]EZAL,.'[!G==O=4_8]SML]:L]QP6,WXY^]
+MKWR5,O!PP1/HO$E?Z3'T'N%:SZ*SH;OA`^FL$O6R\&3#I](9GO=+PY/=E(;;
+M8I;WR3#+^V28Y>T6L[Q'S'K\7YC'5NP5@-[;%.B]K8#>VPW0>PN`?OW_F7F`
+MY\[_>R;_1_<U@#VGV`&0%[*W!^Z2TV9`73/)N;E(57P&<[YV`_;?*C&$B_S.
+M@7.MSA;W)3KG_ADNFKYJ^7?W;UYEO9^E;\ZF6G>>T09!U;(I28#S3HZB28O$
+MS5'+^08!_@RN,]F$PU/XSC?\92+\-2)'9]UC:'6\3@?VSZ^N#YP+'S7Z=UL:
+MOQUCD+>1NZ[V+O"QE1R8MP-JN_IIYP*?9LOV$VI+LDUZMK\+@:/HL<J_+J!H
+M=,F;1'-SRAY%QZ8*(IEM:N)6F:LPX3:CX@M>J$52D!^(/W69AD;+J,^-CSXF
+M(]NL-]V)ZBSN1$4T&HN4^QD?FAYJPBR:3XE96C;`DR;$<86.U)B$1EE@TX/&
+M+![)6AMFK;^5VRJUX`&V.]1^)XU3]D^536T$9!^XD913R0?;N%\T86&BBA1%
+M/W\92_YE-B[U'XD@"*F>:%8=4/66&J87IOPFG4!J/PU[>0-4WD[KQ(2D_2RR
+MS7N7U&DY48GDUD-\BT+NJ$F,LN-0C<E/_?`C=0_CN[%*;Y$]I40[O=Q3>8G7
+MLRAPL.+!R:%J!2<8,^-[;;_+P79VX8*6,07CK:TI8D6A%\<R(`JL.52/&R\=
+MK:+,6DGQ<0F!2AH&;A-4!D$M-+:7K0S:O$<N-P_CCR@XY%!+=+@IFAE%-,!@
+M,D-4(M/5UPNQ?CR),E'98,C?%I0-,)2-0_X8V28R<M;[Q$X)M9@E/ZL)VOB\
+M=;`\8YX<S<F8=<A:F"'+@2MEQ`)(U\R`A9`JX]GO5UDKY>5,9E,<<5J2XS!E
+-&.@X_P&I*Y$W($H``"'+
+`
+end
+
+Date: Wed, 30 Oct 96 14:54:13 CST
+From: Loren James Rittle <rittle@comm.mot.com>
+To: friedman@splode.com
+Cc: bug-gnu-utils@prep.ai.mit.edu, info-cvs@prep.ai.mit.edu
+Subject: Re: diffutils 2.7 -- diff3 merge bug
+
+Noah,
+
+I have seen the problem you discuss in your e-mail, however I fail to
+see how this situation is as critical as might be implied since it can
+never arise without at least some user involvement (an update that
+caused a merge is never automatically followed by a commit --- the
+user has a chance to inspect the merged file). However, I will agree
+that I don't always look very closely at non-conflicted merges before
+checking them back in.
+
+You didn't give the exact CVS commands used to create a lossage,
+but I added the following to your Makefile, to help me see the problem
+in a CVS usage context:
+
+t-older: testcase-older
+ cp testcase-older t-older
+
+t-yours: testcase-yours
+ cp testcase-yours t-yours
+
+t-mine: testcase-mine
+ cp testcase-mine t-mine
+
+# Assume cvs-1.9
+cvs-test: t-older t-yours t-mine
+ rm -rf /tmp/cvs-test-root x x2
+ cvs -d /tmp/cvs-test-root init
+ mkdir x
+ cp t-older x/testcase
+ cd x; cvs -d /tmp/cvs-test-root import -m '' x X X1
+ rm -rf x
+ cvs -d /tmp/cvs-test-root co x
+ cvs -d /tmp/cvs-test-root co -d x2 x
+ cp t-yours x/testcase
+ cp t-mine x2/testcase
+ cd x; cvs ci -m ''
+ -cd x2; cvs ci -m ''
+ cd x2; cvs update
+ cat x2/testcase # at this point, user may commit blindly
+
+It looks like whomever added shift_boundaries() in analyze.c, which
+seems to be the source of the diff3 induced mischief, already provided
+a means to disable the boundary shifting optimization (at least with
+a recompile).
+
+Here is the patch I applied to diff to disable this (currently)
+overaggressive optimization:
+
+[ rittle@supra ]; diff -c analyze.c-old analyze.c
+*** analyze.c-old Wed Oct 30 14:10:27 1996
+--- analyze.c Wed Oct 30 13:48:57 1996
+***************
+*** 616,622 ****
+ but usually it is cleaner to consider the following identical line
+ to be the "change". */
+
+! int inhibit;
+
+ static void
+ shift_boundaries (filevec)
+--- 616,622 ----
+ but usually it is cleaner to consider the following identical line
+ to be the "change". */
+
+! int inhibit = 1;
+
+ static void
+ shift_boundaries (filevec)
+
+Now, diff-2.7 with the above patch produces:
+
+[ rittle@supra ]; make diff-mine-yours 'DIFF=/usr/src/diffutils-2.7/diff'
+/usr/src/diffutils-2.7/diff -a --horizon-lines=11 -- testcase-mine testcase-yours; true
+16,18c16,18
+< // _titleColor = Color.black;
+< // _disabledTitleColor = Color.gray;
+< // _titleFont = Font.defaultFont ();
+---
+> _titleColor = Color.black;
+> _disabledTitleColor = Color.gray;
+> _titleFont = Font.defaultFont ();
+20,30d19
+<
+< /* Convenience constructor for instantiating a Button with
+< * bounds x, y, width, and height. Equivalent to
+< * foo = new Button ();
+< * foo.init (x, y, width, height);
+< */
+< public Button (int x, int y, int width, int height)
+< {
+< this ();
+< init (x, y, width, height);
+< }
+
+Whereas, stock diff-2.7 produces:
+
+[ rittle@supra ]; make diff-mine-yours
+diff -a --horizon-lines=11 -- testcase-mine testcase-yours; true
+16,29c16,18
+< // _titleColor = Color.black;
+< // _disabledTitleColor = Color.gray;
+< // _titleFont = Font.defaultFont ();
+< }
+<
+< /* Convenience constructor for instantiating a Button with
+< * bounds x, y, width, and height. Equivalent to
+< * foo = new Button ();
+< * foo.init (x, y, width, height);
+< */
+< public Button (int x, int y, int width, int height)
+< {
+< this ();
+< init (x, y, width, height);
+---
+> _titleColor = Color.black;
+> _disabledTitleColor = Color.gray;
+> _titleFont = Font.defaultFont ();
+
+A better solution might be to disable the boundary shifting code
+unless explicitly turned on via command line argument. That way
+programs, like diff3, expecting unoptimized diff regions will work
+correctly, yet users can get smaller diffs, if desired. The problem
+is that diff3 doesn't properly track changes once they have been
+optimized.
+
+BTW, I never did like the look of the `optimized diff regions', so I
+consider this a good change for other reasons... :-)
+
+Enjoy!
+
+Regards,
+Loren
+--
+Loren J. Rittle (rittle@comm.mot.com) PGP KeyIDs: 1024/B98B3249 2048/ADCE34A5
+Systems Technology Research (IL02/2240) FP1024:6810D8AB3029874DD7065BC52067EAFD
+Motorola, Inc. FP2048:FDC0292446937F2A240BC07D42763672
+(847) 576-7794 Call for verification of fingerprints.
diff --git a/contrib/cvs/doc/Makefile.in b/contrib/cvs/doc/Makefile.in
index 11c70519a3b0..29eb565d46ac 100644
--- a/contrib/cvs/doc/Makefile.in
+++ b/contrib/cvs/doc/Makefile.in
@@ -12,12 +12,6 @@
# 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., 675 Mass Ave, Cambridge, MA 02139, USA.
-
-# $CVSid: @(#)Makefile.in 1.8 94/10/22 $
-
SHELL = /bin/sh
srcdir = @srcdir@
@@ -34,6 +28,7 @@ INSTALL_DATA = @INSTALL_DATA@
DISTFILES = \
.cvsignore ChangeLog ChangeLog.fsf Makefile.in \
+ RCSFILES \
cvs-paper.ms cvs-paper.ps \
cvs.texinfo \
cvsclient.texi
@@ -99,10 +94,12 @@ cvsclient.txt: cvsclient.texi CVSvn.texi
# it, and builds it in a seperate build dir, then *.info* are in srcdir.
# If the user builds *.info (e.g. after editing *.texi), then *.info* are
# in the build dir.
-install-info: info
- test -f cvs.info || cd $(srcdir); \
- for i in *.info* ; do \
- $(INSTALL_DATA) $$i $(infodir)/$$i ; \
+# (Note: don't solve this problem with "cd"; INSTALL_DATA might be a
+# relative path to install-sh).
+install-info: info installdirs
+ if test -f cvs.info ; then docdir=.; else docdir=$(srcdir);fi; \
+ for i in $$docdir/*.info* ; do \
+ $(INSTALL_DATA) $$i $(infodir)/`basename $$i` ; \
done
installdirs:
@@ -130,10 +127,7 @@ cvsclient.dvi cvsclient.aux: cvsclient.texi CVSvn.texi
ln -s $(srcdir)/CVSvn.texi . || \
ln $(srcdir)/CVSvn.texi . || \
cp $(srcdir)/CVSvn.texi . ; else true; fi
- $(SET_TEXINPUTS) $(TEX) cvsclient.texi
- $(SET_TEXINPUTS) $(TEX) cvsclient.texi
- $(TEXINDEX) cvsclient.??
- $(SET_TEXINPUTS) $(TEX) cvsclient.texi
+ $(TEXI2DVI) $(srcdir)/cvsclient.texi
rm -f cvsclient.?? cvsclient.log cvsclient.toc cvsclient.??s
cvs.ps: cvs.dvi
diff --git a/contrib/cvs/doc/RCSFILES b/contrib/cvs/doc/RCSFILES
new file mode 100644
index 000000000000..41d131bbcfce
--- /dev/null
+++ b/contrib/cvs/doc/RCSFILES
@@ -0,0 +1,165 @@
+It would be nice for the RCS file format (which is implemented by a
+great many tools, both free and non-free, both by calling GNU RCS and
+by reimplementing access to RCS files) were documented in some
+standard separate from any one tool. But as far as I know no such
+standard exists. Hence this file.
+
+The place to start is the rcsfile.5 manpage in the GNU RCS 5.7
+distribution. Then look at the diff at the end of this file (which
+contains a few fixes and clarifications to that manpage).
+
+If you are interested in MKS RCS, src/ci.c in GNU RCS 5.7 has a
+comment about their date format. However, as far as we know there
+isn't really any document describing MKS's changes to the RCS file
+format.
+
+The rcsfile.5 manpage does not document what goes in the "text" field
+for each revision. The answer is that the head revision contains the
+contents of that revision and every other revision contain a bunch of
+edits to produce that revision ("a" and "d" lines). The GNU diff
+manual (the version I looked at was for GNU diff 2.4) documents this
+format somewhat (as the "RCS output format"), but the presentation is
+a bit confusing as it is all tangled up with the documentation of
+several other output formats. If you just want some source code to
+look at, the part of CVS which applies these is RCS_deltas in
+src/rcs.c.
+
+The first time I read rcsfile.5 I didn't really notice the part about
+the order of the revisions. This order _is_ important and CVS relies
+on it. It is documented but it would be clearer if the example in
+rcsfile.5 also showed the order of the revisions (and the "next" and
+"branch" fields and anything else where it would be useful to have an
+example of how a revision tree is represented in an RCS file).
+
+There is one case where CVS uses CVS-specific, non-compatible changes
+to the RCS file format, and this is magic branches. See cvs.texinfo
+for more information on them. CVS also sets the RCS state to "dead"
+to indicate that a file does not exist in a given revision (this is
+stored just as any other RCS state is).
+
+The rules regarding keyword expansion are not documented along with
+the rest of the RCS file format; they are documented in the co(1)
+manpage in the RCS 5.7 distribution. See also the "Keyword
+substitution" chapter of cvs.texinfo. The co(1) manpage refers to
+special behavior if the log prefix for the $Log keyword is /* or (*.
+RCS 5.7 produces a warning whenever it behaves that way, and current
+versions of CVS do not handle this case in a special way (CVS 1.9 and
+earlier invoke RCS to perform keyword expansion).
+
+Note that the "comment {string};" syntax from rcsfile.5 specifies a
+comment leader, which affects expansion of the $Log keyword for old
+versions of RCS. The comment leader is not used by RCS 5.7 or current
+versions of CVS.
+
+Both RCS 5.7 and current versions of CVS handle the $Log keyword in a
+different way if the log message starts with "checked in with -k by ".
+I don't think this behavior is documented anywhere.
+
+One common concern about the RCS file format is the fact that to get
+the head of a branch, one must apply deltas from the head of the trunk
+to the branchpoint, and then from the branchpoint to the head of the
+branch. While more detailed analyses might be worth doing, we will
+note:
+
+ * The performance bottleneck for CVS generally is figuring out which
+ files to operate on and that sort of thing, not applying deltas.
+
+ * Here is one quick test (probably not a very good test; a better test
+ would use a normally sized file (say 50-200K) instead of a small one):
+
+ I just did a quick test with a small file (on a Sun Ultra 1/170E
+ running Solaris 5.5.1), with 1000 revisions on the main branch and
+ 1000 revisions on branch that forked at the root (i.e., RCS revisions
+ 1.1, 1.2, ..., 1.1000, and branch revisions 1.1.1.1, 1.1.1.2, ...,
+ 1.1.1.1000). It took about 0.15 seconds real time to check in the
+ first revision, and about 0.6 seconds to check in and 0.3 seconds to
+ retrieve revision 1.1.1.1000 (the worst case).
+
+ * Any attempt to "fix" this problem should be careful not to interfere
+ with other features, such as lightweight creation of branches
+ (particularly using CVS magic branches).
+
+Diff follows:
+
+(Note that in the following diff the old value for the Id keyword was:
+ Id: rcsfile.5in,v 5.6 1995/06/05 08:28:35 eggert Exp
+and the new one was:
+ Id: rcsfile.5in,v 5.7 1996/12/09 17:31:44 eggert Exp
+but since this file itself might be subject to keyword expansion I
+haven't included a diff for that fact).
+
+===================================================================
+RCS file: RCS/rcsfile.5in,v
+retrieving revision 5.6
+retrieving revision 5.7
+diff -u -r5.6 -r5.7
+--- rcsfile.5in 1995/06/05 08:28:35 5.6
++++ rcsfile.5in 1996/12/09 17:31:44 5.7
+@@ -85,7 +85,8 @@
+ .LP
+ \f2sym\fP ::= {\f2digit\fP}* \f2idchar\fP {\f2idchar\fP | \f2digit\fP}*
+ .LP
+-\f2idchar\fP ::= any visible graphic character except \f2special\fP
++\f2idchar\fP ::= any visible graphic character,
++ except \f2digit\fP or \f2special\fP
+ .LP
+ \f2special\fP ::= \f3$\fP | \f3,\fP | \f3.\fP | \f3:\fP | \f3;\fP | \f3@\fP
+ .LP
+@@ -119,12 +120,23 @@
+ the minute (00\-59),
+ and
+ .I ss
+-the second (00\-60).
++the second (00\-59).
++If
+ .I Y
+-contains just the last two digits of the year
+-for years from 1900 through 1999,
+-and all the digits of years thereafter.
+-Dates use the Gregorian calendar; times use UTC.
++contains exactly two digits,
++they are the last two digits of a year from 1900 through 1999;
++otherwise,
++.I Y
++contains all the digits of the year.
++Dates use the Gregorian calendar.
++Times use UTC, except that for portability's sake leap seconds are not allowed;
++implementations that support leap seconds should output
++.B 59
++for
++.I ss
++during an inserted leap second, and should accept
++.B 59
++for a deleted leap second.
+ .PP
+ The
+ .I newphrase
+@@ -144,16 +156,23 @@
+ field in order of decreasing numbers.
+ The
+ .B head
+-field in the
+-.I admin
+-node points to the head of that sequence (i.e., contains
++field points to the head of that sequence (i.e., contains
+ the highest pair).
+ The
+ .B branch
+-node in the admin node indicates the default
++field indicates the default
+ branch (or revision) for most \*r operations.
+ If empty, the default
+ branch is the highest branch on the trunk.
++The
++.B symbols
++field associates symbolic names with revisions.
++For example, if the file contains
++.B "symbols rr:1.1;"
++then
++.B rr
++is a name for revision
++.BR 1.1 .
+ .PP
+ All
+ .I delta
+
diff --git a/contrib/cvs/doc/cvs.texinfo b/contrib/cvs/doc/cvs.texinfo
index 29bc5f350601..633098474ef7 100644
--- a/contrib/cvs/doc/cvs.texinfo
+++ b/contrib/cvs/doc/cvs.texinfo
@@ -16,11 +16,29 @@
@comment MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
@comment GNU General Public License for more details.
-@comment You should have received a copy of the GNU General Public License
-@comment along with CVS; see the file COPYING. If not, write to
-@comment the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.
+@c See ../README for A4 vs. US letter size.
+@c When we provided A4 postscript, and people tried to
+@c print it on US letter, the usual complaint was that the
+@c page numbers would get cut off.
+@c If one prints US letter on A4, reportedly there is
+@c some extra space at the top and/or bottom, and the side
+@c margins are a bit narrow, but no text is lost.
+@c
+@c See
+@c http://www.ft.uni-erlangen.de/~mskuhn/iso-paper.html
+@c for more on paper sizes. Insuring that margins are
+@c big enough to print on either A4 or US letter does
+@c indeed seem to be the usual approach (according to
+@c an internet draft by Jacob Palme).
+
+@c This document seems to get overfull hboxes with some
+@c frequency (probably because the tendency is to
+@c sanity-check it with "make info" and run TeX less
+@c often). The big ugly boxes just seem to add insult
+@c to injury, and I'm not aware of them helping to fix
+@c the overfull hboxes at all.
+@finalout
-@afourpaper
@setfilename cvs.info
@include CVSvn.texi
@settitle CVS---Concurrent Versions System
@@ -120,27 +138,36 @@ This info manual describes how to use and administer
@sc{cvs} version @value{CVSVN}.
@end ifinfo
+@c This menu is pretty long. Not sure how easily that
+@c can be fixed; seems like "Adding files", "Removing
+@c files", "Removing directories", "Moving files",
+@c and "Moving directories" all go together (into
+@c "Adding, removing, and renaming"?). Other than that
+@c no brilliant ideas for a fix...
@menu
* Preface:: About this manual
* What is CVS?:: What is CVS?
-* Basic concepts:: Basic concepts of revision management
* A sample session:: A tour of basic CVS usage
* Repository:: Where all your sources are stored
* Starting a new project:: Starting a project with CVS
* Multiple developers:: How CVS helps a group of developers
-* Branches:: Parallel development explained
+* Revisions and branches:: Numeric, symbolic, and branch revisions
* Merging:: How to move changes between branches
* Recursive behavior:: CVS descends directories
-* Adding files:: Adding files to a module
-* Removing files:: Removing files from a module
+* Adding files:: Adding files
+* Removing files:: Removing files
+* Removing directories:: Removing directories
* Tracking sources:: Tracking third-party sources
* Moving files:: Moving and renaming files
* Moving directories:: Moving and renaming directories
* History browsing:: Viewing the history of files in various ways
* Keyword substitution:: CVS can include the revision inside the file
* Binary files:: CVS can handle binary files
+* Builds:: Issues related to CVS and builds
+* Compatibility:: Upgrading CVS versions
* Revision management:: Policy questions for revision management
-* Invoking CVS:: Reference manual for CVS commands
+* CVS commands:: CVS commands share some things
+* Invoking CVS:: Quick reference to CVS commands
* Administrative files:: Reference manual for the Administrative files
* Environment variables:: All environment variables which affect CVS
* Troubleshooting:: Some tips when nothing works
@@ -187,34 +214,6 @@ every @sc{cvs} command is gathered together. There is also
an extensive index, and a lot of cross references.
@end itemize
-@cindex Signum Support
-@cindex Support, getting CVS support
-This manual was contributed by Signum Support AB in
-Sweden. Signum is yet another in the growing list of
-companies that support free software. You are free to
-copy both this manual and the @sc{cvs} program.
-@xref{Copying}, for the details. Signum Support offers
-@c -- Check this reference! It has been bogus in the past.
-support contracts and binary distribution for many
-programs, such as @sc{cvs}, @sc{gnu} Emacs, the
-@sc{gnu} C compiler and others. Write to us for
-more information.
-
-@example
-Signum Support AB
-Box 2044
-S-580 02 Linkoping
-Sweden
-
-Email: info@@signum.se
-Phone: +46 (0)13 - 21 46 00
-Fax: +46 (0)13 - 21 47 00
-@end example
-
-Another company selling support for @sc{cvs} is Cyclic
-Software, web: @code{http://www.cyclic.com/}, email:
-@code{info@@cyclic.com}.
-
@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@menu
* Checklist::
@@ -243,12 +242,12 @@ flag (release 1.15 and later are OK). You must also
configure both @sc{rcs} and @sc{cvs} to handle binary
files when you install them.
-Keword substitution can be a source of trouble with
+Keyword substitution can be a source of trouble with
binary files. @xref{Keyword substitution}, for
solutions.
@item The @code{admin} command
-Uncareful use of the @code{admin} command can cause
+Careless use of the @code{admin} command can cause
@sc{cvs} to cease working. @xref{admin}, before trying
to use it.
@end table
@@ -259,10 +258,10 @@ to use it.
@cindex Contributors (manual)
@cindex Credits (manual)
-Roland Pesch, Cygnus Support <@t{pesch@@cygnus.com}>
+Roland Pesch, then of Cygnus Support <@t{roland@@wrs.com}>
wrote the manual pages which were distributed with
-@sc{cvs} 1.3. Appendix A and B contain much text that
-was extracted from them. He also read an early draft
+@sc{cvs} 1.3. Much of their text was copied into this
+manual. He also read an early draft
of this manual and contributed many ideas and
corrections.
@@ -274,15 +273,16 @@ David G. Grubbs <@t{dgg@@think.com}>.
Some text has been extracted from the man pages for
@sc{rcs}.
-The @sc{cvs} @sc{faq} (@pxref{What is CVS?}) by David
-G. Grubbs has been used as a check-list to make sure
-that this manual is as complete as possible. (This
-manual does however not include all of the material in
-the @sc{faq}). The @sc{faq} contains a lot of useful
-information.
+The @sc{cvs} @sc{faq} by David G. Grubbs has provided
+useful material. The @sc{faq} is no longer maintained,
+however, and this manual is about the closest thing there
+is to a successor (with respect to documenting how to
+use @sc{cvs}, at least).
In addition, the following persons have helped by
telling me about mistakes I've made:
+
+@display
Roxanne Brunskill <@t{rbrunski@@datap.ca}>,
Kathy Dyer <@t{dyer@@phoenix.ocf.llnl.gov}>,
Karl Pingle <@t{pingle@@acuson.com}>,
@@ -290,52 +290,122 @@ Thomas A Peterson <@t{tap@@src.honeywell.com}>,
Inge Wallin <@t{ingwa@@signum.se}>,
Dirk Koschuetzki <@t{koschuet@@fmi.uni-passau.de}>
and Michael Brown <@t{brown@@wi.extrel.com}>.
+@end display
+
+The list of contributors here is not comprehensive; for a more
+complete list of who has contributed to this manual see
+the file @file{doc/ChangeLog} in the @sc{cvs} source
+distribution.
@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node BUGS
@unnumberedsec BUGS
-@cindex Bugs, known in this manual
-@cindex Known bugs in this manual
-This manual is known to have room for improvement.
-Here is a list of known deficiencies:
-
+@cindex Bugs in this manual or CVS
+Neither @sc{cvs} nor this manual is perfect, and they
+probably never will be. If you are having trouble
+using @sc{cvs}, or think you have found a bug, there
+are a number of things you can do about it. Note that
+if the manual is unclear, that can be considered a bug
+in the manual, so these problems are often worth doing
+something about as well as problems with @sc{cvs} itself.
+
+@cindex Reporting bugs
+@cindex Bugs, reporting
+@cindex Errors, reporting
@itemize @bullet
@item
-In the examples, the output from @sc{cvs} is sometimes
-displayed, sometimes not.
+If you want someone to help you and fix bugs that you
+report, there are companies which will do that for a
+fee. Two such companies are:
-@item
-The input that you are supposed to type in the examples
-should have a different font than the output from the
-computer.
+@cindex Signum Support
+@cindex Cyclic Software
+@cindex Support, getting CVS support
+@example
+Signum Support AB
+Box 2044
+S-580 02 Linkoping
+Sweden
+Email: info@@signum.se
+Phone: +46 (0)13 - 21 46 00
+Fax: +46 (0)13 - 21 47 00
+http://www.signum.se/
+
+Cyclic Software
+United States of America
+http://www.cyclic.com/
+info@@cyclic.com
+@end example
@item
-This manual should be clearer about what file
-permissions you should set up in the repository, and
-about setuid/setgid.
+If you got @sc{cvs} through a distributor, such as an
+operating system vendor or a vendor of freeware
+@sc{cd-rom}s, you may wish to see whether the
+distributor provides support. Often, they will provide
+no support or minimal support, but this may vary from
+distributor to distributor.
@item
-Some of the chapters are not yet complete. They are
-noted by comments in the @file{cvs.texinfo} file.
+If you have the skills and time to do so, you may wish
+to fix the bug yourself. If you wish to submit your
+fix for inclusion in future releases of @sc{cvs}, see
+the file @sc{hacking} in the @sc{cvs} source
+distribution. It contains much more information on the
+process of submitting fixes.
@item
-@cindex Reporting bugs (manual)
-@cindex Bugs, reporting (manual)
-@cindex Errors, reporting (manual)
-This list is not complete. If you notice any error,
-omission, or something that is unclear, please send
-mail to @t{bug-cvs@@prep.ai.mit.edu}.
-@end itemize
+There may be resources on the net which can help. Two
+good places to start are:
+
+@example
+http://www.cyclic.com
+ @r{particularly the Unsupported Resources page}
+http://www.loria.fr/~molli/cvs-index.html
+@end example
-I hope that you will find this manual useful, despite
-the above-mentioned shortcomings.
+If you are so inspired, increasing the information
+available on the net is likely to be appreciated. For
+example, before the standard @sc{cvs} distribution
+worked on Windows 95, there was a web page with some
+explanation and patches for running @sc{cvs} on Windows
+95, and various people helped out by mentioning this
+page on mailing lists or newsgroups when the subject
+came up.
-@flushright
+@item
+It is also possible to report bugs to @code{bug-cvs}.
+Note that someone may or may not want to do anything
+with your bug report---if you need a solution consider
+one of the options mentioned above. People probably do
+want to hear about bugs which are particularly severe
+in consequences and/or easy to fix, however. You can
+also increase your odds by being as clear as possible
+about the exact nature of the bug and any other
+relevant information. The way to report bugs is to
+send email to @code{bug-cvs@@prep.ai.mit.edu}. Note
+that submissions to @code{bug-cvs} may be distributed
+under the terms of the @sc{gnu} Public License, so if
+you don't like this, don't submit them. There is
+usually no justification for sending mail directly to
+one of the @sc{cvs} maintainers rather than to
+@code{bug-cvs}; those maintainers who want to hear
+about such bug reports read @code{bug-cvs}. Also note
+that sending a bug report to other mailing lists or
+newsgroups is @emph{not} a substitute for sending it to
+@code{bug-cvs}. It is fine to discuss @sc{cvs} bugs on
+whatever forum you prefer, but there are not
+necessarily any maintainers reading bug reports sent
+anywhere except @code{bug-cvs}.
+@end itemize
-Linkoping, October 1993
-Per Cederqvist
-@end flushright
+@cindex Known bugs in this manual or CVS
+People often ask if there is a list of known bugs or
+whether a particular bug is a known one. The file
+@sc{bugs} in the @sc{cvs} source distribution is one
+list of known bugs, but it doesn't necessarily try to
+be comprehensive. Perhaps there will never be a
+comprehensive, detailed list of known bugs.
@c ---------------------------------------------------------------------
@node What is CVS?
@@ -383,7 +453,8 @@ the work when each developer is done.
@cindex Credits (CVS program)
@cindex Contributors (CVS program)
@sc{cvs} started out as a bunch of shell scripts written by
-Dick Grune, posted to @code{comp.sources.unix} in the volume 6
+Dick Grune, posted to the newsgroup
+@code{comp.sources.unix} in the volume 6
release of December, 1986. While no actual code from
these shell scripts is present in the current version
of @sc{cvs} much of the @sc{cvs} conflict resolution algorithms
@@ -394,21 +465,56 @@ Jeff Polk later helped Brian with the design of the @sc{cvs}
module and vendor branch support.
@cindex Source, getting CVS source
-You can get @sc{cvs} via anonymous ftp from a number of
-sites, for instance @t{prep.ai.mit.edu} in
-@file{pub/gnu}.
+You can get @sc{cvs} via anonymous @sc{ftp} from a
+number of sites; for example see
+@example
+http://www.gnu.ai.mit.edu/order/ftp.html
+@end example
+for a list of the @sc{gnu} @sc{ftp} sites.
+@c We could also be pointing to other resources like
+@c the cyclic getting.html, Pascal Molli's page, etc.,
+@c and probably should, when someone gets around to
+@c figuring out which pages are stable enough that we
+@c should cite them, which ones are best to point
+@c people to (supported? binary? source? zero-cost?
+@c buying CD-ROMs? etc.), etc.
@cindex Mailing list
@cindex List, mailing list
-There is a mailing list for @sc{cvs} where bug reports
-can be sent, questions can be asked, an FAQ is posted,
-and discussion about future enhancements to @sc{cvs}
-take place. To submit a message to the list, write to
-<@t{info-cvs@@prep.ai.mit.edu}>. To subscribe or
-unsubscribe, write to
-<@t{info-cvs-request@@prep.ai.mit.edu}>. Please be
-specific about your email address.
-
+@cindex Newsgroups
+@c Be careful in editing this--it is worded so that
+@c the long -request address is in the middle of a
+@c line, thus avoiding overfull hboxes.
+There is a mailing list, known as @w{@code{info-cvs}},
+devoted to @sc{cvs}. To subscribe or
+unsubscribe
+@c could add "to the mailing list,"
+send a message to
+@c or "write to"
+@w{@code{info-cvs-request@@prep.ai.mit.edu}}. Please
+be specific about your email address. As of May 1996,
+subscription requests are handled by a busy human
+being, so you cannot expect to be added or removed
+immediately. If you prefer a usenet group, the right
+group is @code{comp.software.config-mgmt} which is for
+@sc{cvs} discussions (along with other configuration
+management systems). In the future, it might be
+possible to create a
+@code{comp.software.config-mgmt.cvs}, but probably only
+if there is sufficient @sc{cvs} traffic on
+@code{comp.software.config-mgmt}.
+@c Other random data is that past attempts to create a
+@c gnu.* group have failed (the relevant authorities
+@c say they'll do it, but don't), and that tale was very
+@c skeptical of comp.software.config-mgmt.cvs when the
+@c subject came up around 1995 or so (for one
+@c thing, because creating it would be a "reorg" which
+@c would need to take a more comprehensive look at the
+@c whole comp.software.config-mgmt.* hierarchy).
+
+You can also subscribe to the bug-cvs mailing list,
+described in more detail in @ref{BUGS}. To subscribe
+send mail to bug-cvs-request@@prep.ai.mit.edu.
@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@unnumberedsec CVS is not@dots{}
@@ -433,7 +539,7 @@ checked out working directories. If you write your
@file{Makefile}s or scripts in every directory so they
have to know the relative positions of everything else,
you wind up requiring the entire repository to be
-checked out. That's simply bad planning.
+checked out.
If you modularize your work, and construct a build
system that will share files (via links, mounts,
@@ -442,14 +548,22 @@ arrange your disk usage however you like.
But you have to remember that @emph{any} such system is
a lot of work to construct and maintain. @sc{cvs} does
-not address the issues involved. You must use your
-brain and a collection of other tools to provide a
-build scheme to match your plans.
+not address the issues involved.
Of course, you should place the tools created to
support such a build system (scripts, @file{Makefile}s,
etc) under @sc{cvs}.
+Figuring out what files need to be rebuilt when
+something changes is, again, something to be handled
+outside the scope of @sc{cvs}. One traditional
+approach is to use @code{make} for building, and use
+some automated tool for generating the dependencies which
+@code{make} uses.
+
+See @ref{Builds}, for more information on doing builds
+in conjunction with @sc{cvs}.
+
@item @sc{cvs} is not a substitute for management.
Your managers and project leaders are expected to talk
@@ -489,175 +603,64 @@ Acquire the habit of reading specs and talking to your
peers.
-@item @sc{cvs} is not a configuration management system.
-
-@sc{cvs} is a source control system. The phrase
-``configuration management'' is a marketing term, not
-an industry-recognized set of functions.
-
-A true ``configuration management system'' would contain
-elements of the following:
-
-@itemize @bullet
-@item Source control.
-@item Dependency tracking.
-@item Build systems (i.e. What to build and how to find
-things during a build. What is shared? What is local?)
-@item Bug tracking.
-@item Automated Testing procedures.
-@item Release Engineering documentation and procedures.
-@item Tape Construction.
-@item Customer Installation.
-@item A way for users to run different versions of the same
-software on the same host at the same time.
-@end itemize
-
-@sc{cvs} provides only the first.
+@item @sc{cvs} does not have change control
+
+Change control refers to a number of things. First of
+all it can mean @dfn{bug-tracking}, that is being able
+to keep a database of reported bugs and the status of
+each one (is it fixed? in what release? has the bug
+submitter agreed that it is fixed?). For interfacing
+@sc{cvs} to an external bug-tracking system, see the
+@file{rcsinfo} and @file{verifymsg} files
+(@pxref{Administrative files}).
+
+Another aspect of change control is keeping track of
+the fact that changes to several files were in fact
+changed together as one logical change. If you check
+in several files in a single @code{cvs commit}
+operation, @sc{cvs} then forgets that those files were
+checked in together, and the fact that they have the
+same log message is the only thing tying them
+together. Keeping a @sc{gnu} style @file{ChangeLog}
+can help somewhat.
+@c FIXME: should have an xref to a section which talks
+@c more about keeping ChangeLog's with CVS, but that
+@c section hasn't been written yet.
+
+Another aspect of change control, in some systems, is
+the ability to keep track of the status of each
+change. Some changes have been written by a developer,
+others have been reviewed by a second developer, and so
+on. Generally, the way to do this with @sc{cvs} is to
+generate a diff (using @code{cvs diff} or @code{diff})
+and email it to someone who can then apply it using the
+@code{patch} utility. This is very flexible, but
+depends on mechanisms outside @sc{cvs} to make sure
+nothing falls through the cracks.
+
+@item @sc{cvs} is not an automated testing program
+
+It should be possible to enforce mandatory use of a
+testsuite using the @code{commitinfo} file. I haven't
+heard a lot about projects trying to do that or whether
+there are subtle gotchas, however.
+
+@item @sc{cvs} does not have a builtin process model
+
+Some systems provide ways to ensure that changes or
+releases go through various steps, with various
+approvals as needed. Generally, one can accomplish
+this with @sc{cvs} but it might be a little more work.
+In some cases you'll want to use the @file{commitinfo},
+@file{loginfo}, @file{rcsinfo}, or @file{verifymsg}
+files, to require that certain steps be performed
+before cvs will allow a checkin. Also consider whether
+features such as branches and tags can be used to
+perform tasks such as doing work in a development tree
+and then merging certain changes over to a stable tree
+only once they have been proven.
@end table
-This section is taken from release 2.3 of the @sc{cvs}
-@sc{faq}.
-
-@c ---------------------------------------------------------------------
-@node Basic concepts
-@chapter Basic concepts
-@cindex Modules (intro)
-@cindex Repository (intro)
-
-@sc{cvs} stores all files in a centralized
-@dfn{repository}: a directory (such as
-@file{/usr/local/cvsroot} or
-@file{user@@remotehost:/usr/local/cvsroot}) which is
-populated with a hierarchy of files and directories.
-(@pxref{Remote repositories} for information about
-keeping the repository on a remote machine.)
-
-Normally, you never access any of the files in the
-repository directly. Instead, you use @sc{cvs}
-commands to get your own copy of the files, and then
-work on that copy. When you've finished a set of
-changes, you check (or @dfn{commit}) them back into the
-repository.
-
-The files in the repository are organized in
-@dfn{modules}. Each module is made up of one or more
-files, and can include files from several directories.
-A typical usage is to define one module per project.
-
-@menu
-* Revision numbers:: The meaning of a revision number
-* Versions revisions releases:: Terminology used in this manual
-@end menu
-
-@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-@node Revision numbers
-@section Revision numbers
-@cindex Revision numbers
-@cindex Revision tree
-@cindex Linear development
-@cindex Number, revision-
-@cindex Decimal revision number
-@cindex Main trunk (intro)
-@cindex Branch number
-@cindex Number, branch
-
-Each version of a file has a unique @dfn{revision
-number}. Revision numbers look like @samp{1.1},
-@samp{1.2}, @samp{1.3.2.2} or even @samp{1.3.2.2.4.5}.
-A revision number always has an even number of
-period-separated decimal integers. By default revision
-1.1 is the first revision of a file. Each successive
-revision is given a new number by increasing the
-rightmost number by one. The following figure displays
-a few revisions, with newer revisions to the right.
-
-@example
- +-----+ +-----+ +-----+ +-----+ +-----+
- ! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 !
- +-----+ +-----+ +-----+ +-----+ +-----+
-@end example
-
-@sc{cvs} is not limited to linear development. The
-@dfn{revision tree} can be split into @dfn{branches},
-where each branch is a self-maintained line of
-development. Changes made on one branch can easily be
-moved back to the main trunk.
-
-Each branch has a @dfn{branch number}, consisting of an
-odd number of period-separated decimal integers. The
-branch number is created by appending an integer to the
-revision number where the corresponding branch forked
-off. Having branch numbers allows more than one branch
-to be forked off from a certain revision.
-
-@need 3500
-All revisions on a branch have revision numbers formed
-by appending an ordinal number to the branch number.
-The following figure illustrates branching with an
-example.
-
-@example
-@group
- +-------------+
- Branch 1.2.2.3.2 -> ! 1.2.2.3.2.1 !
- / +-------------+
- /
- /
- +---------+ +---------+ +---------+ +---------+
-Branch 1.2.2 -> _! 1.2.2.1 !----! 1.2.2.2 !----! 1.2.2.3 !----! 1.2.2.4 !
- / +---------+ +---------+ +---------+ +---------+
- /
- /
-+-----+ +-----+ +-----+ +-----+ +-----+
-! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 ! <- The main trunk
-+-----+ +-----+ +-----+ +-----+ +-----+
- !
- !
- ! +---------+ +---------+ +---------+
-Branch 1.2.4 -> +---! 1.2.4.1 !----! 1.2.4.2 !----! 1.2.4.3 !
- +---------+ +---------+ +---------+
-
-@end group
-@end example
-
-@c -- However, at least for me the figure is not enough. I suggest more
-@c -- text to accompany it. "A picture is worth a thousand words", so you
-@c -- have to make sure the reader notices the couple of hundred words
-@c -- *you* had in mind more than the others!
-
-@c -- Why an even number of segments? This section implies that this is
-@c -- how the main trunk is distinguished from branch roots, but you never
-@c -- explicitly say that this is the purpose of the [by itself rather
-@c -- surprising] restriction to an even number of segments.
-
-The exact details of how the branch number is
-constructed is not something you normally need to be
-concerned about, but here is how it works: When
-@sc{cvs} creates a branch number it picks the first
-unused even integer, starting with 2. So when you want
-to create a branch from revision 6.4 it will be
-numbered 6.4.2. All branch numbers ending in a zero
-(such as 6.4.0) are used internally by @sc{cvs}
-(@pxref{Magic branch numbers}). The branch 1.1.1 has a
-special meaning. @xref{Tracking sources}.
-
-@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-@node Versions revisions releases
-@section Versions, revisions and releases
-@cindex Revisions, versions and releases
-@cindex Versions, revisions and releases
-@cindex Releases, revisions and versions
-
-A file can have several versions, as described above.
-Likewise, a software product can have several versions.
-A software product is often given a version number such
-as @samp{4.1.1}.
-
-Versions in the first sense are called @dfn{revisions}
-in this document, and versions in the second sense are
-called @dfn{releases}. To avoid confusion, the word
-@dfn{version} is almost never used in this document.
-
@c ---------------------------------------------------------------------
@node A sample session
@chapter A sample session
@@ -668,9 +671,39 @@ called @dfn{releases}. To avoid confusion, the word
@cindex tc, Trivial Compiler (example)
@cindex Trivial Compiler (example)
-This section describes a typical work-session using
-@sc{cvs}. It assumes that a repository is set up
-(@pxref{Repository}).
+@c I think an example is a pretty good way to start. But
+@c somewhere in here, maybe after the sample session,
+@c we need something which is kind of
+@c a "roadmap" which is more directed at sketching out
+@c the functionality of CVS and pointing people to
+@c various other parts of the manual. As it stands now
+@c people who read in order get dumped right into all
+@c manner of hair regarding remote repositories,
+@c creating a repository, etc.
+@c
+@c The following was in the old Basic concepts node. I don't
+@c know how good a job it does at introducing modules,
+@c or whether they need to be introduced so soon, but
+@c something of this sort might go into some
+@c introductory material somewhere.
+@ignore
+@cindex Modules (intro)
+The repository contains directories and files, in an
+arbitrary tree. The @dfn{modules} feature can be used
+to group together a set of directories or files into a
+single entity (@pxref{modules}). A typical usage is to
+define one module per project.
+@end ignore
+
+As a way of introducing @sc{cvs}, we'll go through a
+typical work-session using @sc{cvs}. The first thing
+to understand is that @sc{cvs} stores all files in a
+centralized @dfn{repository} (@pxref{Repository}); this
+section assumes that a repository is set up.
+@c I'm not sure that the sentence concerning the
+@c repository quite tells the user what they need to
+@c know at this point. Might need to expand on "centralized"
+@c slightly (maybe not here, maybe further down in the example?)
Suppose you are working on a simple compiler. The source
consists of a handful of C files and a @file{Makefile}.
@@ -707,7 +740,7 @@ the source files.
@example
$ cd tc
-$ ls tc
+$ ls
CVS Makefile backend.c driver.c frontend.c parser.c
@end example
@@ -718,7 +751,7 @@ any of the files in it.
You start your favorite editor, hack away at @file{backend.c}, and a couple
of hours later you have added an optimization pass to the compiler.
A note to @sc{rcs} and @sc{sccs} users: There is no need to lock the files that
-you want to edit. @xref{Multiple developers} for an explanation.
+you want to edit. @xref{Multiple developers}, for an explanation.
@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node Committing your changes
@@ -729,7 +762,10 @@ you want to edit. @xref{Multiple developers} for an explanation.
@cindex EDITOR, environment variable
When you have checked that the compiler is still compilable you decide
-to make a new version of @file{backend.c}.
+to make a new version of @file{backend.c}. This will
+store your new @file{backend.c} in the repository and
+make it available to anyone else who is using that same
+repository.
@example
$ cvs commit backend.c
@@ -744,8 +780,34 @@ The environment variable @code{$CVSEDITOR} determines
which editor is started. If @code{$CVSEDITOR} is not
set, then if the environment variable @code{$EDITOR} is
set, it will be used. If both @code{$CVSEDITOR} and
-@code{$EDITOR} are not set then the editor defaults to
-@code{vi}. If you want to avoid the overhead of
+@code{$EDITOR} are not set then there is a default
+which will vary with your operating system, for example
+@code{vi} for unix or @code{notepad} for Windows
+NT/95.
+
+@c This probably should go into some new node
+@c containing detailed info on the editor, rather than
+@c the intro. In fact, perhaps some of the stuff with
+@c CVSEDITOR and -m and so on should too.
+When @sc{cvs} starts the editor, it includes a list of
+files which are modified. For the @sc{cvs} client,
+this list is based on comparing the modification time
+of the file against the modification time that the file
+had when it was last gotten or updated. Therefore, if
+a file's modification time has changed but its contents
+have not, it will show up as modified. The simplest
+way to handle this is simply not to worry about it---if
+you proceed with the commit @sc{cvs} will detect that
+the contents are not modified and treat it as an
+unmodified file. The next @code{update} will clue
+@sc{cvs} in to the fact that the file is unmodified,
+and it will reset its stored timestamp so that the file
+will not show up in future editor sessions.
+@c FIXCVS: Might be nice if "commit" and other commands
+@c would reset that timestamp too, but currently commit
+@c doesn't.
+
+If you want to avoid
starting an editor you can specify the log message on
the command line using the @samp{-m} flag instead, like
this:
@@ -829,6 +891,7 @@ This command runs @code{diff} to compare the version of @file{driver.c}
that you checked out with your working copy. When you see the output
you remember that you added a command line option that enabled the
optimization pass. You check it in, and release the module.
+@c FIXME: we haven't yet defined the term "check in".
@example
$ cvs commit -m "Added an optimization pass" driver.c
@@ -846,52 +909,84 @@ Are you sure you want to release (and delete) module `tc': y
@c ---------------------------------------------------------------------
@node Repository
@chapter The Repository
+@cindex Repository (intro)
@cindex Repository, example
@cindex Layout of repository
@cindex Typical repository
-@cindex CVSROOT, environment variable
-@cindex .profile
-@cindex .cshrc
-@cindex .tcshrc
-@cindex .bashrc
-@cindex /usr/local/cvsroot
+@cindex /usr/local/cvsroot, as example repository
@cindex cvsroot
-Figure 3 below shows a typical setup of a repository.
-Only directories are shown below.
+The @sc{cvs} @dfn{repository} stores a complete copy of
+all the files and directories which are under version
+control.
-@example
-@t{/usr}
- |
- +--@t{local}
- | |
- | +--@t{cvsroot}
- | | |
- | | +--@t{CVSROOT}
- | (administrative files)
- |
- +--@t{gnu}
- | |
- | +--@t{diff}
- | | (source code to @sc{gnu} diff)
- | |
- | +--@t{rcs}
- | | (source code to @sc{rcs})
- | |
- | +--@t{cvs}
- | (source code to @sc{cvs})
- |
- +--@t{yoyodyne}
- |
- +--@t{tc}
- | |
- | +--@t{man}
- | |
- | +--@t{testing}
- |
- +--(other Yoyodyne software)
-@end example
+Normally, you never access any of the files in the
+repository directly. Instead, you use @sc{cvs}
+commands to get your own copy of the files into a
+@dfn{working directory}, and then
+work on that copy. When you've finished a set of
+changes, you check (or @dfn{commit}) them back into the
+repository. The repository then contains the changes
+which you have made, as well as recording exactly what
+you changed, when you changed it, and other such
+information. Note that the repository is not a
+subdirectory of the working directory, or vice versa;
+they should be in separate locations.
+@c Need some example, e.g. repository
+@c /usr/local/cvsroot; working directory
+@c /home/joe/sources. But this node is too long
+@c as it is; need a little reorganization...
+
+@cindex :local:
+@sc{Cvs} can access a repository by a variety of
+means. It might be on the local computer, or it might
+be on a computer across the room or across the world.
+To distinguish various ways to access a repository, the
+repository name can start with an @dfn{access method}.
+For example, the access method @code{:local:} means to
+access a repository directory, so the repository
+@code{:local:/usr/local/cvsroot} means that the
+repository is in @file{/usr/local/cvsroot} on the
+computer running @sc{cvs}. For information on other
+access methods, see @ref{Remote repositories}.
+
+@c Can se say this more concisely? Like by passing
+@c more of the buck to the Remote repositories node?
+If the access method is omitted, then if the repository
+does not contain @samp{:}, then @code{:local:} is
+assumed. If it does contain @samp{:} than either
+@code{:ext:} or @code{:server:} is assumed. For
+example, if you have a local repository in
+@file{/usr/local/cvsroot}, you can use
+@code{/usr/local/cvsroot} instead of
+@code{:local:/usr/local/cvsroot}. But if (under
+Windows NT, for example) your local repository is
+@file{c:\src\cvsroot}, then you must specify the access
+method, as in @code{:local:c:\src\cvsroot}.
+
+@c This might appear to go in Repository storage, but
+@c actually it is describing something which is quite
+@c user-visible, when you do a "cvs co CVSROOT". This
+@c isn't necessary the perfect place for that, though.
+The repository is split in two parts. @file{$CVSROOT/CVSROOT} contains
+administrative files for @sc{cvs}. The other directories contain the actual
+user-defined modules.
+
+@menu
+* Specifying a repository:: Telling CVS where your repository is
+* Repository storage:: The structure of the repository
+* Working directory storage:: The structure of working directories
+* Intro administrative files:: Defining modules
+* Multiple repositories:: Multiple repositories
+* Creating a repository:: Creating a repository
+* Backing up:: Backing up a repository
+* Remote repositories:: Accessing repositories on remote machines
+* Read-only access:: Granting read-only access to the repository
+* Server temporary directory:: The server creates temporary directories
+@end menu
+@node Specifying a repository
+@section Telling CVS where your repository is
There are a couple of different ways to tell @sc{cvs}
where to find the repository. You can name the
@@ -902,6 +997,11 @@ repository on the command line explicitly, with the
cvs -d /usr/local/cvsroot checkout yoyodyne/tc
@end example
+@cindex .profile, setting CVSROOT in
+@cindex .cshrc, setting CVSROOT in
+@cindex .tcshrc, setting CVSROOT in
+@cindex .bashrc, setting CVSROOT in
+@cindex CVSROOT, environment variable
Or you can set the @code{$CVSROOT} environment
variable to an absolute path to the root of the
repository, @file{/usr/local/cvsroot} in this example.
@@ -922,6 +1022,8 @@ CVSROOT=/usr/local/cvsroot
export CVSROOT
@end example
+@cindex Root file, in CVS directory
+@cindex CVS/Root file
A repository specified with @code{-d} will
override the @code{$CVSROOT} environment variable.
Once you've checked a working copy out from the
@@ -929,35 +1031,93 @@ repository, it will remember where its repository is
(the information is recorded in the
@file{CVS/Root} file in the working copy).
-The @code{-d} option and the @file{CVS/Root} file
-both override the @code{$CVSROOT} environment variable;
-however, @sc{CVS} will complain if the @file{-d}
-argument and the @file{CVS/Root} file disagree.
-
-There is nothing magical about the name
-@file{/usr/local/cvsroot}. You can choose to place the
-repository anywhere you like.
-@xref{Remote repositories} to learn how the repository can be on a
-different machine than your working copy of the sources.
+The @code{-d} option and the @file{CVS/Root} file both
+override the @code{$CVSROOT} environment variable. If
+@code{-d} option differs from @file{CVS/Root}, the
+former is used (and specifying @code{-d} will cause
+@file{CVS/Root} to be updated). Of course, for proper
+operation they should be two ways of referring to the
+same repository.
-The repository is split in two parts. @file{$CVSROOT/CVSROOT} contains
-administrative files for @sc{cvs}. The other directories contain the actual
-user-defined modules.
+@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
+@node Repository storage
+@section How data is stored in the repository
+@cindex Repository, how data is stored
+
+For most purposes it isn't important @emph{how}
+@sc{cvs} stores information in the repository. In
+fact, the format has changed in the past, and is likely
+to change in the future. Since in almost all cases one
+accesses the repository via @sc{cvs} commands; such
+changes need not be disruptive.
+
+However, in some cases it may be necessary to
+understand how @sc{cvs} stores data in the repository,
+for example you might need to track down @sc{cvs} locks
+(@pxref{Concurrency}) or you might need to deal with
+the file permissions appropriate for the repository.
@menu
-* User modules:: The structure of the repository
-* Intro administrative files:: Defining modules
-* Multiple repositories:: Multiple repositories
-* Creating a repository:: Creating a repository
-* Remote repositories:: Accessing repositories on remote machines
+* Repository files:: What files are stored in the repository
+* File permissions:: File permissions
+* Attic:: Some files are stored in the Attic
@end menu
-@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-@node User modules
-@section User modules
-@cindex User modules
-@cindex Repository, user parts
+@node Repository files
+@subsection Where files are stored within the repository
+
+The overall structure of the repository is a directory
+tree corresponding to the directories in the working
+directory. For example, supposing the repository is in
+
+@example
+/usr/local/cvsroot
+@end example
+
+@noindent
+here is a possible directory tree (showing only the
+directories):
+
+@example
+@t{/usr}
+ |
+ +--@t{local}
+ | |
+ | +--@t{cvsroot}
+ | | |
+ | | +--@t{CVSROOT}
+ | (administrative files)
+ |
+ +--@t{gnu}
+ | |
+ | +--@t{diff}
+ | | (source code to @sc{gnu} diff)
+ | |
+ | +--@t{rcs}
+ | | (source code to @sc{rcs})
+ | |
+ | +--@t{cvs}
+ | (source code to @sc{cvs})
+ |
+ +--@t{yoyodyne}
+ |
+ +--@t{tc}
+ | |
+ | +--@t{man}
+ | |
+ | +--@t{testing}
+ |
+ +--(other Yoyodyne software)
+@end example
+With the directories are @dfn{history files} for each file
+under version control. The name of the history file is
+the name of the corresponding file with @samp{,v}
+appended to the end. Here is what the repository for
+the @file{yoyodyne/tc} directory might look like:
+@c FIXME: Should also mention CVS (CVSREP)
+@c FIXME? Should we introduce Attic with an xref to
+@c Attic? Not sure whether that is a good idea or not.
@example
@code{$CVSROOT}
|
@@ -982,32 +1142,43 @@ user-defined modules.
@cindex History files
@cindex RCS history files
-@cindex RCS, CVS uses RCS
-The figure above shows the contents of the @samp{tc}
-module inside the repository. As you can see all file
-names end in @samp{,v}. The files are @dfn{history
-files}. They contain, among other things, enough
+@c The first sentence, about what history files
+@c contain, is kind of redundant with our intro to what the
+@c repository does in node Repository....
+The history files contain, among other things, enough
information to recreate any revision of the file, a log
of all commit messages and the user-name of the person
-who committed the revision. @sc{cvs} uses the
-facilities of @sc{rcs}, a simpler version control
-system, to maintain these files. For a full
+who committed the revision. The history files are
+known as @dfn{RCS files}, because the first program to
+store files in that format was a version control system
+known as @sc{rcs}. For a full
description of the file format, see the @code{man} page
-@cite{rcsfile(5)}.
-@c -- Use this format for all references to man pages,
-@c -- or use something better!
-
-@menu
-* File permissions:: File permissions
-@end menu
+@cite{rcsfile(5)}, distributed with @sc{rcs}. This
+file format has become very common---many systems other
+than @sc{cvs} or @sc{rcs} can at least import history
+files in this format.
+@c FIXME: Think about including documentation for this
+@c rather than citing it? In the long run, getting
+@c this to be a standard (not sure if we can cope with
+@c a standards process as formal as IEEE/ANSI/ISO/etc,
+@c though...) is the way to go, so maybe citing is
+@c better.
+
+The @sc{rcs} files used in @sc{cvs} differ in a few
+ways from the standard format. The biggest difference
+is magic branches; for more information see @ref{Magic
+branch numbers}. Also in @sc{cvs} the valid tag names
+are a subset of what @sc{rcs} accepts; for @sc{cvs}'s
+rules see @ref{Tags}.
@c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
@node File permissions
@subsection File permissions
-@c -- Move this to @node Setting up
+@c -- Move this to @node Creating a repository or similar
@cindex Security
@cindex File permissions
@cindex Group
+@cindex read-only files, in repository
All @samp{,v} files are created read-only, and you
should not change the permission of those files. The
directories inside the repository should be writable by
@@ -1017,15 +1188,62 @@ create a UNIX group (see group(5)) consisting of the
persons that are to edit the files in a project, and
set up the repository so that it is that group that
owns the directory.
+@c See also comment in commitinfo node regarding cases
+@c which are really awkward with unix groups.
This means that you can only control access to files on
a per-directory basis.
+Note that users must also have write access to check
+out files, because @sc{cvs} needs to create lock files
+(@pxref{Concurrency}).
+
+@c CVS seems to use CVSUMASK in picking permissions for
+@c val-tags, but maybe we should say more about this.
+@c Like val-tags gets created by someone who doesn't
+@c have CVSUMASK set right?
+Also note that users must have write access to the
+@file{CVSROOT/val-tags} file. @sc{Cvs} uses it to keep
+track of what tags are valid tag names (it is sometimes
+updated when tags are used, as well as when they are
+created, though).
+
+@cindex CVSUMASK
+@cindex umask, for repository files
@sc{cvs} tries to set up reasonable file permissions
for new directories that are added inside the tree, but
you must fix the permissions manually when a new
directory should have different permissions than its
-parent directory.
+parent directory. If you set the @code{CVSUMASK}
+environment variable that will control the file
+permissions which @sc{cvs} uses in creating directories
+and/or files in the repository. @code{CVSUMASK} does
+not affect the file permissions in the working
+directory; such files have the permissions which are
+typical for newly created files, except that sometimes
+@sc{cvs} creates them read-only (see the sections on
+watches, @ref{Setting a watch}; -r, @ref{Global
+options}; or CVSREAD, @ref{Environment variables}).
+
+Note that using the client/server @sc{cvs}
+(@pxref{Remote repositories}), there is no good way to
+set @code{CVSUMASK}; the setting on the client machine
+has no effect. If you are connecting with @code{rsh}, you
+can set @code{CVSUMASK} in @file{.bashrc} or @file{.cshrc}, as
+described in the documentation for your operating
+system. This behavior might change in future versions
+of @sc{cvs}; do not rely on the setting of
+@code{CVSUMASK} on the client having no effect.
+@c FIXME: need to explain what a umask is or cite
+@c someplace which does.
+@c FIXME: Need one place which discusses this
+@c read-only files thing. Why would one use -r or
+@c CVSREAD? Why would one use watches? How do they interact?
+@c FIXME: We need to state
+@c whether using CVSUMASK removes the need for manually
+@c fixing permissions (in fact, if we are going to mention
+@c manually fixing permission, we better document a lot
+@c better just what we mean by "fix").
@cindex setuid
@cindex setgid
@@ -1033,6 +1251,285 @@ Since @sc{cvs} was not written to be run setuid, it is
unsafe to try to run it setuid. You cannot use the
setuid features of @sc{rcs} together with @sc{cvs}.
+@node Attic
+@subsection The attic
+@cindex attic
+
+You will notice that sometimes @sc{cvs} stores an
+@sc{rcs} file in the @code{Attic}. For example, if the
+@sc{cvsroot} is @file{/usr/local/cvsroot} and we are
+talking about the file @file{backend.c} in the
+directory @file{yoyodyne/tc}, then the file normally
+would be in
+
+@example
+/usr/local/cvsroot/yoyodyne/tc/backend.c,v
+@end example
+
+but if it goes in the attic, it would be in
+
+@example
+/usr/local/cvsroot/yoyodyne/tc/Attic/backend.c,v
+@end example
+
+@cindex dead state
+instead. It should not matter from a user point of
+view whether a file is in the attic; @sc{cvs} keeps
+track of this and looks in the attic when it needs to.
+But in case you want to know, the rule is that the RCS
+file is stored in the attic if and only if the head
+revision on the trunk has state @code{dead}. A
+@code{dead} state means that file has been removed, or
+never added, for that revision. For example, if you
+add a file on a branch, it will have a trunk revision
+in @code{dead} state, and a branch revision in a
+non-@code{dead} state.
+@c Probably should have some more concrete examples
+@c here, or somewhere (not sure exactly how we should
+@c arrange the discussion of the dead state, versus
+@c discussion of the attic).
+
+@node Working directory storage
+@section How data is stored in the working directory
+
+While we are discussing @sc{cvs} internals which may
+become visible from time to time, we might as well talk
+about what @sc{cvs} puts in the @file{CVS} directories
+in the working directories. As with the repository,
+@sc{cvs} handles this information and one can usually
+access it via @sc{cvs} commands. But in some cases it
+may be useful to look at it, and other programs, such
+as the @code{jCVS} graphical user interface or the
+@code{VC} package for emacs, may need to look at it.
+Such programs should follow the recommendations in this
+section if they hope to be able to work with other
+programs which use those files, including future
+versions of the programs just mentioned and the
+command-line @sc{cvs} client.
+
+The @file{CVS} directory contains several files.
+Programs which are reading this directory should
+silently ignore files which are in the directory but
+which are not documented here, to allow for future
+expansion.
+
+@table @file
+@item Root
+This file contains the current @sc{cvs} root, as
+described in @ref{Specifying a repository}.
+
+@cindex Repository file, in CVS directory
+@cindex CVS/Repository file
+@item Repository
+This file contains the directory within the repository
+which the current directory corresponds with. For
+historical reasons it is an absolute pathname, although
+it would make more sense for it to be relative to the
+root. For example, after the command
+
+@example
+cvs -d :local:/usr/local/cvsroot checkout yoyodyne/tc
+@end example
+
+@file{Root} will contain
+
+@example
+:local:/usr/local/cvsroot
+@end example
+
+and @file{Repository} will contain
+
+@example
+/usr/local/cvsroot/yoydyne/tc
+@end example
+
+@cindex Entries file, in CVS directory
+@cindex CVS/Entries file
+@item Entries
+This file lists the files and directories in the
+working directory. It is a text file according to the
+conventions appropriate for the operating system in
+question.
+@c That seems like a lose, it makes it impossible (it
+@c would seem) to share a working directory via a
+@c networked file system between systems with diverse
+@c text file conventions. But it seems to be how CVS
+@c currently works.
+The first character of each line indicates what sort of
+line it is. If the character is unrecognized, programs
+reading the file should silently skip that line, to
+allow for future expansion.
+
+If the first character is @samp{/}, then the format is:
+
+@example
+/@var{name}/@var{revision}/@var{timestamp}[+@var{conflict}]/@var{options}/@var{tagdate}
+@end example
+
+where @samp{[} and @samp{]} are not part of the entry,
+but instead indicate that the @samp{+} and conflict
+marker are optional. @var{name} is the name of the
+file within the directory. @var{revision} is the
+revision that the file in the working derives from, or
+@samp{0} for an added file, or @samp{-} followed by a
+revision for a removed file. @var{timestamp} is the
+timestamp of the file at the time that @sc{cvs} created
+it; if the timestamp differs with the actual
+modification time of the file it means the file has
+been modified. It is in Universal Time (UT), stored in
+the format used by the ISO C asctime() function (for
+example, @samp{Sun Apr 7 01:29:26 1996}). One may
+write a string which is not in that format, for
+example, @samp{Result of merge}, to indicate that the
+file should always be considered to be modified. This
+is not a special case; to see whether a file is
+modified a program should take the timestamp of the file
+and simply do a string compare with @var{timestamp}.
+@var{conflict} indicates that there was
+a conflict; if it is the same as the actual
+modification time of the file it means that the user
+has obviously not resolved the conflict. @var{options}
+contains sticky options (for example @samp{-kb} for a
+binary file). @var{tagdate} contains @samp{T} followed
+by a tag name, or @samp{D} for a date, followed by a
+sticky tag or date. Note that if @var{timestamp}
+contains a pair of timestamps separated by a space,
+rather than a single timestamp, you are dealing with a
+version of @sc{cvs} earlier than @sc{cvs} 1.5 (not
+documented here).
+
+If the first character of a line in @file{Entries} is
+@samp{D}, then it indicates a subdirectory. @samp{D}
+on a line all by itself indicates that the program
+which wrote the @file{Entries} file does record
+subdirectories (therefore, if there is such a line and
+no other lines beginning with @samp{D}, one knows there
+are no subdirectories). Otherwise, the line looks
+like:
+
+@example
+D/@var{name}/@var{filler1}/@var{filler2}/@var{filler3}/@var{filler4}
+@end example
+
+where @var{name} is the name of the subdirectory, and
+all the @var{filler} fields should be silently ignored,
+for future expansion. Programs which modify
+@code{Entries} files should preserve these fields.
+
+@cindex Entries.Log file, in CVS directory
+@cindex CVS/Entries.Log file
+@item Entries.Log
+This file does not record any information beyond that
+in @file{Entries}, but it does provide a way to update
+the information without having to rewrite the entire
+@file{Entries} file, including the ability to preserve
+the information even if the program writing
+@file{Entries} and @file{Entries.Log} abruptly aborts.
+Programs which are reading the @file{Entries} file
+should also check for @file{Entries.Log}. If the latter
+exists, they should read @file{Entries} and then apply
+the changes mentioned in @file{Entries.Log}. After
+applying the changes, the recommended practice is to
+rewrite @file{Entries} and then delete @file{Entries.Log}.
+The format of a line in @file{Entries.Log} is a single
+character command followed by a space followed by a
+line in the format specified for a line in
+@file{Entries}. The single character command is
+@samp{A} to indicate that the entry is being added,
+@samp{R} to indicate that the entry is being removed,
+or any other character to indicate that the entire line
+in @file{Entries.Log} should be silently ignored (for
+future expansion). If the second character of the line
+in @file{Entries.Log} is not a space, then it was
+written by an older version of @sc{cvs} (not documented
+here).
+
+@cindex Entries.Backup file, in CVS directory
+@cindex CVS/Entries.Backup file
+@item Entries.Backup
+This is a temporary file. Recommended usage is to
+write a new entries file to @file{Entries.Backup}, and
+then to rename it (atomically, where possible) to @file{Entries}.
+
+@cindex Entries.Static file, in CVS directory
+@cindex CVS/Entries.Static file
+@item Entries.Static
+The only relevant thing about this file is whether it
+exists or not. If it exists, then it means that only
+part of a directory was gotten and @sc{cvs} will
+not create additional files in that directory. To
+clear it, use the @code{update} command with the
+@samp{-d} option, which will get the additional files
+and remove @file{Entries.Static}.
+
+@cindex Tag file, in CVS directory
+@cindex CVS/Tag file
+@cindex Sticky tags/dates, per-directory
+@cindex Per-directory sticky tags/dates
+@item Tag
+This file contains per-directory sticky tags or dates.
+The first character is @samp{T} for a branch tag,
+@samp{N} for a non-branch tag, or @samp{D} for a date,
+or another character to mean the file should be
+silently ignored, for future expansion. This character
+is followed by the tag or date. Note that
+per-directory sticky tags or dates are used for things
+like applying to files which are newly added; they
+might not be the same as the sticky tags or dates on
+individual files. For general information on sticky
+tags and dates, see @ref{Sticky tags}.
+@c FIXME: This needs to be much better documented,
+@c preferably not in the context of "working directory
+@c storage".
+@c FIXME: The Sticky tags node needs to discuss, or xref to
+@c someplace which discusses, per-directory sticky
+@c tags and the distinction with per-file sticky tags.
+
+@cindex Checkin.prog file, in CVS directory
+@cindex CVS/Checkin.prog file
+@cindex Update.prog file, in CVS directory
+@cindex CVS/Update.prog file
+@item Checkin.prog
+@itemx Update.prog
+These files store the programs specified by the
+@samp{-i} and @samp{-u} options in the modules file,
+respectively.
+
+@cindex Notify file, in CVS directory
+@cindex CVS/Notify file
+@item Notify
+This file stores notifications (for example, for
+@code{edit} or @code{unedit}) which have not yet been
+sent to the server. Its format is not yet documented
+here.
+
+@cindex Notify.tmp file, in CVS directory
+@cindex CVS/Notify.tmp file
+@item Notify.tmp
+This file is to @file{Notify} as @file{Entries.Backup}
+is to @file{Entries}. That is, to write @file{Notify},
+first write the new contents to @file{Notify.tmp} and
+then (atomically where possible), rename it to
+@file{Notify}.
+
+@cindex Base directory, in CVS directory
+@cindex CVS/Base directory
+@item Base
+If watches are in use, then an @code{edit} command
+stores the original copy of the file in the @file{Base}
+directory. This allows the @code{unedit} command to
+operate even if it is unable to communicate with the
+server.
+
+@cindex Template file, in CVS directory
+@cindex CVS/Template file
+@item Template
+This file contains the template specified by the
+@file{rcsinfo} file (@pxref{rcsinfo}). It is only used
+by the client; the non-client/server @sc{cvs} consults
+@file{rcsinfo} directly.
+@end table
+
@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node Intro administrative files
@section The administrative files
@@ -1041,6 +1538,15 @@ setuid features of @sc{rcs} together with @sc{cvs}.
@cindex CVSROOT, module name
@cindex Defining modules (intro)
+@c FIXME: this node should be reorganized into "general
+@c information about admin files" and put the "editing
+@c admin files" stuff up front rather than jumping into
+@c the details of modules right away. Then the
+@c Administrative files node can go away, the information
+@c on each admin file distributed to a place appropriate
+@c to its function, and this node can contain a table
+@c listing each file and a @ref to its detailed description.
+
The directory @file{$CVSROOT/CVSROOT} contains some @dfn{administrative
files}. @xref{Administrative files}, for a complete description.
You can use @sc{cvs} without any of these files, but
@@ -1062,10 +1568,11 @@ diff gnu/diff
tc yoyodyne/tc
@end example
-The @file{modules} file is line oriented. In its simplest form each
-line contains the name of the module, whitespace, and the directory
-where the module resides. The directory is a path relative to
-@code{$CVSROOT}. The last for lines in the example
+The @file{modules} file is line oriented. In its
+simplest form each line contains the name of the
+module, whitespace, and the directory where the module
+resides. The directory is a path relative to
+@code{$CVSROOT}. The last four lines in the example
above are examples of such lines.
@c FIXME: might want to introduce the concept of options in modules file
@@ -1076,6 +1583,7 @@ uses features that are not explained here.
@xref{modules}, for a full explanation of all the
available features.
+@c FIXME: subsection without node is bogus
@subsection Editing administrative files
@cindex Editing administrative files
@cindex Administrative files, editing them
@@ -1110,12 +1618,25 @@ without sharing any code. All you have to do to have
several repositories is to specify the appropriate
repository, using the @code{CVSROOT} environment
variable, the @samp{-d} option to @sc{cvs}, or (once
-you have checked out a working directories) by
-simply allowing @sc{cvs} to use the repository that was
-used to check out the working directory (@pxref{Repository}).
-
-Notwithstanding, it can be confusing to have two or
-more repositories.
+you have checked out a working directory) by simply
+allowing @sc{cvs} to use the repository that was used
+to check out the working directory
+(@pxref{Specifying a repository}).
+
+The big advantage of having multiple repositories is
+that they can reside on different servers. The big
+disadvantage is that you cannot have a single @sc{cvs}
+command recurse into directories which comes from
+different repositories. Generally speaking, if you are
+thinking of setting up several repositories on the same
+machine, you might want to consider using several
+directories within the same repository.
+@c FIXCVS: the thing about recursing into diverse roots
+@c would be nice to fix. But it gets hairy if they are
+@c on diverse servers--it isn't clear this is really
+@c all that useful.
+@c FIXME: Does the FAQ have more about this? I have a
+@c dim recollection, but I'm too lazy to check right now.
None of the examples in this manual show multiple
repositories.
@@ -1123,10 +1644,117 @@ repositories.
@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node Creating a repository
@section Creating a repository
-@c -- Well, how do you do?
-See the instructions in the @file{INSTALL} file in the
-@sc{cvs} distribution.
+@cindex Repository, setting up
+@cindex Creating a repository
+@cindex Setting up a repository
+
+To set up a @sc{cvs} repository, first choose the
+machine and disk on which you want to store the
+revision history of the source files. CPU and memory
+requirements are modest---a server with 32M of memory
+or even less can handle a fairly large source tree with
+a fair amount of activity. To estimate disk space
+requirements, if you are importing RCS files from
+another system, the size of those files is the
+approximate initial size of your repository, or if you
+are starting without any version history, a rule of
+thumb is to allow for the server approximately three
+times the size of the code to be under CVS for the
+repository (you will eventually outgrow this, but not
+for a while). On the machines on which the developers
+will be working, you'll want disk space for
+approximately one working directory for each developer
+(either the entire tree or a portion of it, depending
+on what each developer uses). Don't worry about CPU
+and memory requirements for the clients---any machine
+with enough capacity to run the operating system in
+question should have little trouble.
+@c Stuff about memory duplicates Server requirements
+@c to some extent. I'm not sure this is a bad thing,
+@c though (one is aimed at people who are looking into
+@c this carefully, the other is aimed at people who
+@c want a rule of thumb).
+
+The repository should be accessable
+(directly or via a networked file system) from all
+machines which want to use @sc{cvs} in server or local
+mode; the client machines need not have any access to
+it other than via the @sc{cvs} protocol. It is not
+possible to use @sc{cvs} to read from a repository
+which one only has read access to; @sc{cvs} needs to be
+able to create lock files (@pxref{Concurrency}).
+
+@cindex init (subcommand)
+To create a repository, run the @code{cvs init}
+command. It will set up an empty repository in the
+@sc{cvs} root specified in the usual way
+(@pxref{Repository}). For example,
+
+@example
+cvs -d /usr/local/cvsroot init
+@end example
+
+@code{cvs init} is careful to never overwrite any
+existing files in the repository, so no harm is done if
+you run @code{cvs init} on an already set-up
+repository.
+
+@code{cvs init} will enable history logging; if you
+don't want that, remove the history file after running
+@code{cvs init}. @xref{history file}.
+
+@node Backing up
+@section Backing up a repository
+@cindex Repository, backing up
+@cindex Backing up, repository
+
+There is nothing particularly magical about the files
+in the repository; for the most part it is possible to
+back them up just like any other files. However, there
+are a few issues to consider.
+
+The first is that to be paranoid, one should either not
+use @sc{cvs} during the backup, or have the backup
+program lock @sc{cvs} while doing the backup. To not
+use @sc{cvs}, you might forbid logins to machines which
+can access the repository, turn off your @sc{cvs}
+server, or similar mechanisms. The details would
+depend on your operating system and how you have
+@sc{cvs} set up. To lock @sc{cvs}, you would create
+@file{#cvs.rfl} locks in each repository directory.
+See @ref{Concurrency}, for more on @sc{cvs} locks.
+Having said all this, if you just back up without any
+of these precautions, the results are unlikely to be
+particularly dire. Restoring from backup, the
+repository might be in an inconsistent state, but this
+would not be particularly hard to fix manually.
+
+When you restore a repository from backup, assuming
+that changes in the repository were made after the time
+of the backup, working directories which were not
+affected by the failure may refer to revisions which no
+longer exist in the repository. Trying to run @sc{cvs}
+in such directories will typically produce an error
+message. One way to get those changes back into the
+repository is as follows:
+
+@itemize @bullet
+@item
+Get a new working directory.
+
+@item
+Copy the files from the working directory from before
+the failure over to the new working directory (do not
+copy the contents of the @file{CVS} directories, of
+course).
+
+@item
+Working in the new working directory, use commands such
+as @code{cvs update} and @code{cvs diff} to figure out
+what has changed, and then when you are ready, commit
+the changes into the repository.
+@end itemize
@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node Remote repositories
@@ -1134,25 +1762,103 @@ See the instructions in the @file{INSTALL} file in the
@cindex Repositories, remote
@cindex Remote repositories
@cindex Client/Server Operation
+@cindex server, CVS
Your working copy of the sources can be on a
-different machine than the repository. Generally,
-using a remote repository is just like using a local
-one, except that the format of the repository name is:
+different machine than the repository. Using @sc{cvs}
+in this manner is known as @dfn{client/server}
+operation. You run @sc{cvs} on a machine which can
+mount your working directory, known as the
+@dfn{client}, and tell it to communicate to a machine
+which can mount the repository, known as the
+@dfn{server}. Generally, using a remote
+repository is just like using a local one, except that
+the format of the repository name is:
@example
- user@@hostname:/path/to/repository
+:@var{method}:@var{user}@@@var{hostname}:/path/to/repository
@end example
The details of exactly what needs to be set up depend
on how you are connecting to the server.
+If @var{method} is not specified, and the repository
+name contains @samp{:}, then the default is @code{ext}
+or @code{server}, depending on your platform; both are
+described in @ref{Connecting via rsh}.
+@c Should we try to explain which platforms are which?
+@c Platforms like unix and VMS, which only allow
+@c privileged programs to bind to sockets <1024 lose on
+@c :server:
+@c Platforms like Mac and VMS, whose rsh program is
+@c unusable or nonexistent, lose on :ext:
+@c Platforms like OS/2 and NT probably could plausibly
+@c default either way (modulo -b troubles).
+
+@c FIXME: We need to have a better way of explaining
+@c what method to use. This presentation totally
+@c obscures the fact that :ext: and CVS_RSH is the way to
+@c use SSH, for example. Plus it incorrectly implies
+@c that you need an @code{rsh} binary on the client to use
+@c :server:.
@menu
+* Server requirements:: Memory and other resources for servers
* Connecting via rsh:: Using the @code{rsh} program to connect
* Password authenticated:: Direct connections using passwords
* Kerberos authenticated:: Direct connections with kerberos
@end menu
+@node Server requirements
+@subsection Server requirements
+
+The quick answer to what sort of machine is suitable as
+a server is that requirements are modest---a server
+with 32M of memory or even less can handle a fairly
+large source tree with a fair amount of activity.
+@c Say something about CPU speed too? I'm even less sure
+@c what to say on that subject...
+
+The real answer, of course, is more complicated. The
+@sc{cvs} server consists of two processes for each
+client that it is serving. Memory consumption on the
+child process should remain fairly small. Memory
+consumption on the parent process, particularly if the
+network connection to the client is slow, can be
+expected to grow to slightly more than the size of the
+sources in a single directory, or two megabytes,
+whichever is larger.
+@c "two megabytes" of course is SERVER_HI_WATER. But
+@c we don't mention that here because we are
+@c documenting the default configuration of CVS. If it
+@c is a "standard" thing to change that value, it
+@c should be some kind of run-time configuration.
+@c
+@c See cvsclient.texi for more on the design decision
+@c to not have locks in place while waiting for the
+@c client, which is what results in memory consumption
+@c as high as this.
+
+Multiplying the size of each @sc{cvs} server by the
+number of servers which you expect to have active at
+one time should give an idea of memory requirements for
+the server. For the most part, the memory consumed by
+the parent process probably can be swap space rather
+than physical memory.
+@c Has anyone verified that notion about swap space?
+@c I say it based pretty much on guessing that the
+@c ->text of the struct buffer_data only gets accessed
+@c in a first in, first out fashion, but I haven't
+@c looked very closely.
+
+Resource consumption for the client or the
+non-client/server @sc{cvs} is even more modest---any
+machine with enough capacity to run the operating system
+in question should have little trouble.
+@c Probably we could be saying more about this.
+@c I would guess for non-client/server CVS in an NFS
+@c environment the biggest issues is the network and
+@c the NFS server.
+
@node Connecting via rsh
@subsection Connecting with rsh
@@ -1163,19 +1869,19 @@ operations, so the remote user host needs to have a
user.
For example, suppose you are the user @file{mozart} on
-the local machine @file{anklet.grunge.com}, and the
-server machine is @file{chainsaw.brickyard.com}. On
+the local machine @file{toe.grunge.com}, and the
+server machine is @file{chainsaw.yard.com}. On
chainsaw, put the following line into the file
@file{.rhosts} in @file{bach}'s home directory:
@example
-anklet.grunge.com mozart
+toe.grunge.com mozart
@end example
Then test that @code{rsh} is working with
@example
-rsh -l bach chainsaw.brickyard.com echo $PATH
+rsh -l bach chainsaw.yard.com 'echo $PATH'
@end example
@cindex CVS_SERVER
@@ -1189,22 +1895,63 @@ or @file{.profile}. Alternately, you can set the
environment variable @code{CVS_SERVER} on the client
machine to the filename of the server you want to use,
for example @file{/usr/local/bin/cvs-1.6}.
+@c FIXME: there should be a way to specify the
+@c program in CVSROOT, not CVS_SERVER, so that one can use
+@c different ones for different roots. e.g. ":server;cvs=cvs-1.6:"
+@c instead of ":server:".
There is no need to edit @code{inetd.conf} or start a
@sc{cvs} server daemon.
+@cindex :server:
+@cindex :ext:
+There are two access methods that you use in CVSROOT
+for rsh. @code{:server:} specifies an internal rsh
+client, which is supported only by some CVS ports.
+@code{:ext:} specifies an external rsh program. By
+default this is @code{rsh} but you may set the
+@code{CVS_RSH} environment variable to invoke another
+program which can access the remote server (for
+example, @code{remsh} on HP-UX 9 because @code{rsh} is
+something different). It must be a program which can
+transmit data to and from the server without modifying
+it; for example the Windows NT @code{rsh} is not
+suitable since it by default translates between CRLF
+and LF. The OS/2 CVS port has a hack to pass @samp{-b}
+to @code{rsh} to get around this, but since this could
+potentially cause problems for programs other than the
+standard @code{rsh}, it may change in the future. If
+you set @code{CVS_RSH} to @code{SSH} or some other rsh
+replacement, the instructions in the rest of this
+section concerning @file{.rhosts} and so on are likely
+to be inapplicable; consult the documentation for your rsh
+replacement.
+@c FIXME: there should be a way to specify the
+@c program in CVSROOT, not CVS_RSH, so that one can use
+@c different ones for different roots. e.g. ":ext;rsh=remsh:"
+@c instead of ":ext:".
+@c See also the comment in src/client.c for rationale
+@c concerning "rsh" being the default and never
+@c "remsh".
+
Continuing our example, supposing you want to access
the module @file{foo} in the repository
@file{/usr/local/cvsroot/}, on machine
-@file{chainsaw.brickyard.com}, you are ready to go:
+@file{chainsaw.yard.com}, you are ready to go:
@example
-cvs -d bach@@chainsaw.brickyard.com:/user/local/cvsroot checkout foo
+cvs -d :ext:bach@@chainsaw.yard.com:/usr/local/cvsroot checkout foo
@end example
(The @file{bach@@} can be omitted if the username is
the same on both the local and remote hosts.)
+@c Should we mention "rsh host echo hi" and "rsh host
+@c cat" (the latter followed by typing text and ^D)
+@c as troubleshooting techniques? Probably yes
+@c (people tend to have trouble setting this up),
+@c but this kind of thing can be hard to spell out.
+
@node Password authenticated
@subsection Direct connection with password authentication
@@ -1229,6 +1976,9 @@ some adjustments on both the server and client sides.
@cindex Pserver (subcommand)
@cindex password server, setting up
@cindex authenticating server, setting up
+@c FIXME: this isn't quite right regarding port
+@c numbers; CVS looks up "cvspserver" in
+@c /etc/services (on unix, but what about non-unix?).
On the server side, the file @file{/etc/inetd.conf}
needs to be edited so @code{inetd} knows to run the
command @code{cvs pserver} when it receives a
@@ -1247,7 +1997,8 @@ cvs -b /usr/local/bin pserver
@end example
The @samp{-b} option specifies the directory which contains
-the @sc{rcs} binaries on the server.
+the @sc{rcs} binaries on the server. You could also use the
+@samp{-T} option to specify a temporary directory.
If your @code{inetd} wants a symbolic service
name instead of a raw port number, then put this in
@@ -1264,11 +2015,20 @@ cvspserver 2401/tcp
@code{inetd}, or do whatever is necessary to force it
to reread its initialization files.
+@c FIXME: should be documenting how to troubleshoot
+@c this. One strange situation I ran into recently
+@c was that if inetd.conf specifies a non-existent
+@c cvs (e.g. /usr/local/bin/cvs doesn't exist in
+@c the above example), the client says
+@c cvs-1.8 [login aborted]: unrecognized auth response from harvey:
+@c which is a very unhelpful response (can it be
+@c improved? does inetd log somewhere?)
+
@cindex CVS passwd file
-@cindex passwd file
+@cindex passwd (admin file)
Because the client stores and transmits passwords in
cleartext (almost---see @ref{Password authentication
-security} for details), a separate @sc{cvs} password
+security}, for details), a separate @sc{cvs} password
file may be used, so people don't compromise their
regular passwords when they access the repository.
This file is @file{$CVSROOT/CVSROOT/passwd}
@@ -1302,16 +2062,59 @@ indicates corresponding valid system usernames). In
any case, @sc{cvs} will have no privileges which the
(valid) user would not have.
+@cindex user aliases
+ It is possible to ``map'' cvs-specific
+usernames onto system usernames (i.e., onto system
+login names) in the @file{$CVSROOT/CVSROOT/passwd} file
+by appending a colon and the system username after the
+password. For example:
+
+@example
+cvs:ULtgRLXo7NRxs:kfogel
+generic:1sOp854gDF3DY:spwang
+anyone:1sOp854gDF3DY:spwang
+@end example
+
+ Thus, someone remotely accessing the repository
+on @file{chainsaw.yard.com} with the following
+command:
+
+@example
+cvs -d :pserver:cvs@@chainsaw.yard.com:/usr/local/cvsroot checkout foo
+@end example
+
+ would end up running the server under the
+system identity kfogel, assuming successful
+authentication. However, the remote user would not
+necessarily need to know kfogel's system password, as
+the @file{$CVSROOT/CVSROOT/passwd} file might contain a
+different password, used only for @sc{cvs}. And as the
+example above indicates, it is permissible to map
+multiple cvs usernames onto a single system username.
+
+ This feature is designed to allow people
+repository access without full system access (in
+particular, see @xref{Read-only access}); however, also
+@xref{Password authentication security}. Any sort of
+repository access very likely implies a degree of
+general system access as well.
+
Right now, the only way to put a password in the
@sc{cvs} @file{passwd} file is to paste it there from
somewhere else. Someday, there may be a @code{cvs
passwd} command.
+@c We might also suggest using the @code{htpasswd} command
+@c from freely available web servers as well, but that
+@c would open up a can of worms in that the users next
+@c questions are likely to be "where do I get it?" and
+@c "how do I use it?"
@node Password authentication client
@subsubsection Using the client with password authentication
@cindex Login (subcommand)
@cindex password client, using
@cindex authenticated client, using
+@cindex :pserver:
Before connecting to the server, the client must @dfn{log
in} with the command @code{cvs login}. Logging in
verifies a password with the server, and also records
@@ -1325,7 +2128,7 @@ argument or the @code{CVSROOT} environment variable.
password:
@example
-cvs -d bach@@chainsaw.brickyard.com:/usr/local/cvsroot login
+cvs -d :pserver:bach@@chainsaw.yard.com:/usr/local/cvsroot login
CVS password:
@end example
@@ -1335,11 +2138,10 @@ complaining that the password was incorrect.
Once you have logged in, you can force @sc{cvs} to
connect directly to the server and authenticate with
-the stored password by prefixing the repository with
-@samp{:pserver:}:
+the stored password:
@example
-cvs -d :pserver:bach@@chainsaw.brickyard.com:/usr/local/cvsroot checkout foo
+cvs -d :pserver:bach@@chainsaw.yard.com:/usr/local/cvsroot checkout foo
@end example
The @samp{:pserver:} is necessary because without it,
@@ -1360,6 +2162,13 @@ trivially encoded to protect them from "innocent"
compromise (i.e., inadvertently being seen by a system
administrator who happens to look at that file).
+@c FIXME: seems to me this needs somewhat more
+@c explanation.
+@cindex Logout (subcommand)
+The password for the currently choosen remote repository
+can be removed from the CVS_PASSFILE by using the
+@code{cvs logout} command.
+
The @code{CVS_PASSFILE} environment variable overrides
this default. If you use this variable, make sure you
set it @emph{before} @code{cvs login} is run. If you
@@ -1367,12 +2176,6 @@ were to set it after running @code{cvs login}, then
later @sc{cvs} commands would be unable to look up the
password for transmission to the server.
-@cindex CVS_PASSWORD, environment variable
-The @code{CVS_PASSWORD} environment variable overrides
-@emph{all} stored passwords. If it is set, @sc{cvs}
-will use it for all password-authenticated
-connections.
-
@node Password authentication security
@subsubsection Security considerations with password authentication
@@ -1384,6 +2187,11 @@ system administrator accidentally looking at the file),
and will not prevent even a naive attacker from gaining
the password.
+@c FIXME: The bit about "access to the repository
+@c implies general access to the system is *not* specific
+@c to pserver; it applies to kerberos and SSH and
+@c everything else too. Should reorganize the
+@c documentation to make this clear.
The separate @sc{cvs} password file (@pxref{Password
authentication server}) allows people
to use a different password for repository access than
@@ -1393,6 +2201,13 @@ the server system through a variety of means. Thus, repository
access implies fairly broad system access as well. It
might be possible to modify @sc{cvs} to prevent that,
but no one has done so as of this writing.
+@c OpenBSD uses chroot() and copies the repository to
+@c provide anonymous read-only access (for details see
+@c http://www.openbsd.org/anoncvs.shar). While this
+@c closes the most obvious holes, I'm not sure it
+@c closes enough holes to recommend it (plus it is
+@c *very* easy to accidentally screw up a setup of this
+@c type).
Furthermore, there may be other ways in which having
access to @sc{cvs} allows people to gain more general
access to the system; noone has done a careful audit.
@@ -1408,25 +2223,31 @@ security, get Kerberos.
@subsection Direct connection with kerberos
@cindex kerberos
+@cindex :kserver:
The main disadvantage of using rsh is that all the data
needs to pass through additional programs, so it may be
slower. So if you have kerberos installed you can
connect via a direct @sc{tcp} connection,
-authenticating with kerberos (note that the data
-transmitted is @emph{not} encrypted).
+authenticating with kerberos.
To do this, @sc{cvs} needs to be compiled with kerberos
support; when configuring @sc{cvs} it tries to detect
whether kerberos is present or you can use the
@file{--with-krb4} flag to configure.
+The data transmitted is @emph{not} encrypted by
+default. Encryption support must be compiled into both
+the client and server; use the
+@file{--enable-encryption} configure option to turn it
+on. You must then use the @code{-x} global option to
+request encryption.
+
@cindex CVS_CLIENT_PORT
You need to edit @code{inetd.conf} on the server
machine to run @code{cvs kserver}. The client uses
port 1999 by default; if you want to use another port
specify it in the @code{CVS_CLIENT_PORT} environment
-variable on the client. Set @code{CVS_CLIENT_PORT} to
-@samp{-1} to force an rsh connection.
+variable on the client.
@cindex kinit
When you want to use @sc{cvs}, get a ticket in the
@@ -1435,11 +2256,139 @@ which allows you to log into the server machine. Then
you are ready to go:
@example
-cvs -d chainsaw.brickyard.com:/user/local/cvsroot checkout foo
+cvs -d :kserver:chainsaw.yard.com:/user/local/cvsroot checkout foo
@end example
-If @sc{cvs} fails to connect, it will fall back to
-trying rsh.
+Previous versions of @sc{cvs} would fall back to a
+connection via rsh; this version will not do so.
+
+@c ---------------------------------------------------------------------
+@node Read-only access
+@section Read-only repository access
+@cindex read-only repository access
+@cindex readers (admin file)
+@cindex writers (admin file)
+
+ It is possible to grant read-only repository
+access to people using the password-authenticated
+server (@pxref{Password authenticated}). (The
+other access methods do not have explicit support for
+read-only users because those methods all assume login
+access to the repository machine anyway, and therefore
+the user can do whatever local file permissions allow
+her to do.)
+
+ A user who has read-only access can do only
+those @sc{cvs} operations which do not modify the
+repository, except for certain ``administrative'' files
+(such as lock files and the history file). It may be
+desirable to use this feature in conjunction with
+user-aliasing (@pxref{Password authentication server}).
+However, note that read-only access does not repeal the
+existing security considerations in @xref{Password
+authentication security}.
+
+ There are two ways to specify read-only access
+for a user: by inclusion, and by exclusion.
+
+ "Inclusion" means listing that user
+specifically in the @file{$CVSROOT/CVSROOT/readers}
+file, which is simply a newline-separated list of
+users. Here is a sample @file{readers} file:
+
+@example
+melissa
+splotnik
+jrandom
+@end example
+
+ (Don't forget the newline after the last user.)
+
+ "Exclusion" means explicitly listing everyone
+who has @emph{write} access---if the file
+
+@example
+$CVSROOT/CVSROOT/writers
+@end example
+
+@noindent
+exists, then only
+those users listed in it have write access, and
+everyone else has read-only access (of course, even the
+read-only users still need to be listed in the
+@sc{cvs} @file{passwd} file). The
+@file{writers} file has the same format as the
+@file{readers} file.
+
+ Note: if your @sc{cvs} @file{passwd}
+file maps cvs users onto system users (@pxref{Password
+authentication server}), make sure you deny or grant
+read-only access using the @emph{cvs} usernames, not
+the system usernames. That is, the @file{readers} and
+@file{writers} files contain cvs usernames, which may
+or may not be the same as system usernames.
+
+ Here is a complete description of the server's
+behavior in deciding whether to grant read-only or
+read-write access:
+
+ If @file{readers} exists, and this user is
+listed in it, then she gets read-only access. Or if
+@file{writers} exists, and this user is NOT listed in
+it, then she also gets read-only access (this is true
+even if @file{readers} exists but she is not listed
+there). Otherwise, she gets full read-write access.
+
+ Of course there is a conflict if the user is
+listed in both files. This is resolved in the more
+conservative way, it being better to protect the
+repository too much than too little: such a user gets
+read-only access.
+
+@node Server temporary directory
+@section Temporary directories for the server
+@cindex temporary directories, and server
+@cindex server, temporary directories
+
+While running, the @sc{cvs} server creates temporary
+directories. They are named
+
+@example
+cvs-serv@var{pid}
+@end example
+
+@noindent
+where @var{pid} is the process identification number of
+the server. They are located in the directory
+specified by the @samp{TMPDIR} environment variable
+(@pxref{Environment variables}), the @samp{-T} global
+option (@pxref{Global options}), or failing that
+@file{/tmp}.
+
+In most cases the server will remove the temporary
+directory when it is done, whether it finishes normally
+or abnormally. However, there are a few cases in which
+the server does not or cannot remove the temporary
+directory, for example:
+
+@itemize @bullet
+@item
+If the server aborts due to an internal server error,
+it may preserve the directory to aid in debugging
+
+@item
+If the server is killed in a way that it has no way of
+cleaning up (most notably, @samp{kill -KILL} on unix).
+
+@item
+If the system shuts down without an orderly shutdown,
+which tells the server to clean up.
+@end itemize
+
+In cases such as this, you will need to manually remove
+the @file{cvs-serv@var{pid}} directories. As long as
+there is no server running with process identification
+number @var{pid}, it is safe to do so.
@c ---------------------------------------------------------------------
@node Starting a new project
@@ -1448,12 +2397,14 @@ trying rsh.
@cindex Creating a project
@comment --moduledb--
-Since @sc{cvs} 1.x is bad at renaming files and moving
-them between directories, the first thing you do when
-you start a new project should be to think through your
-file organization. It is not impossible---just
-awkward---to rename or move files.
-@xref{Moving files}.
+Because renaming files and moving them between
+directories is somewhat inconvenient, the first thing
+you do when you start a new project should be to think
+through your file organization. It is not impossible
+to rename or move files, but it does increase the
+potential for confusion and @sc{cvs} does have some
+quirks particularly in the area of renaming
+directories. @xref{Moving files}.
What to do next depends on the situation at hand.
@@ -1476,12 +2427,12 @@ be done in a couple of different ways.
where files already exists.
* From other version control systems:: Old projects where you want to
preserve history from another system.
-* From scratch:: Creating a module from scratch.
+* From scratch:: Creating a directory tree from scratch.
@end menu
@c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
@node From files
-@subsection Creating a module from a number of files
+@subsection Creating a directory tree from a number of files
@cindex Importing files
When you begin using @sc{cvs}, you will probably already have several
@@ -1489,12 +2440,12 @@ projects that can be
put under @sc{cvs} control. In these cases the easiest way is to use the
@code{import} command. An example is probably the easiest way to
explain how to use it. If the files you want to install in
-@sc{cvs} reside in @file{@var{dir}}, and you want them to appear in the
-repository as @file{$CVSROOT/yoyodyne/@var{dir}}, you can do this:
+@sc{cvs} reside in @file{@var{wdir}}, and you want them to appear in the
+repository as @file{$CVSROOT/yoyodyne/@var{rdir}}, you can do this:
@example
-$ cd @var{dir}
-$ cvs import -m "Imported sources" yoyodyne/@var{dir} yoyo start
+$ cd @var{wdir}
+$ cvs import -m "Imported sources" yoyodyne/@var{rdir} yoyo start
@end example
Unless you supply a log message with the @samp{-m}
@@ -1507,12 +2458,15 @@ more information about them.
You can now verify that it worked, and remove your
original source directory.
+@c FIXME: Need to say more about "verify that it
+@c worked". What should the user look for in the output
+@c from "diff -r"?
@example
$ cd ..
$ mv @var{dir} @var{dir}.orig
$ cvs checkout yoyodyne/@var{dir} # @r{Explanation below}
-$ ls -R yoyodyne
+$ diff -r @var{dir}.orig yoyodyne/@var{dir}
$ rm -r @var{dir}.orig
@end example
@@ -1532,6 +2486,10 @@ It is a good idea to check that the permissions
are reasonable, and that they belong to the proper
groups. @xref{File permissions}.
+If some of the files you want to import are binary, you
+may want to use the wrappers features to specify which
+files are binary and which are not. @xref{Wrappers}.
+
@c The node name is too long, but I am having trouble
@c thinking of something more concise.
@node From other version control systems
@@ -1567,6 +2525,16 @@ working directory.
@c branches. It could also do something about the case
@c where the RCS file had a (non-magic) "0" branch.
+The @sc{rcs} file should not be locked when you move it
+into @sc{cvs}; if it is, @sc{cvs} will have trouble
+letting you operate on it.
+@c What is the easiest way to unlock your files if you
+@c have them locked? Especially if you have a lot of them?
+@c This is a CVS bug/misfeature; importing RCS files
+@c should ignore whether they are locked and leave them in
+@c an unlocked state. Yet another reason for a separate
+@c "import RCS file" command.
+
@c How many is "many"? Or do they just import RCS files?
@item From another version control system
Many version control systems have the ability to export
@@ -1584,11 +2552,33 @@ Note: you must run it on a machine which has both
else in contrib it is unsupported (your mileage may
vary).
@end table
+@c CMZ and/or PATCHY were systems that were used in the
+@c high energy physics community (especially for
+@c CERNLIB). CERN has replaced them with CVS, but the
+@c CAR format seems to live on as a way to submit
+@c changes. There is a program car2cvs which converts
+@c but I'm not sure where one gets a copy.
+@c Not sure it is worth mentioning here, since it would
+@c appear to affect only one particular community.
+@c Best page for more information is:
+@c http://wwwcn1.cern.ch/asd/cvs/index.html
+@c See also:
+@c http://ecponion.cern.ch/ecpsa/cernlib.html
@c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
@node From scratch
-@subsection Creating a module from scratch
-
+@subsection Creating a directory tree from scratch
+
+@c Also/instead should be documenting
+@c $ cvs co -l .
+@c $ mkdir tc
+@c $ cvs add tc
+@c $ cd tc
+@c $ mkdir man
+@c $ cvs add man
+@c etc.
+@c Using import to create the directories only is
+@c probably a somewhat confusing concept.
For a new project, the easiest thing to do is probably
to create an empty directory structure, like this:
@@ -1633,8 +2623,8 @@ In simple cases these steps are sufficient to define a module.
Get a working copy of the modules file.
@example
-$ cvs checkout modules
-$ cd modules
+$ cvs checkout CVSROOT/modules
+$ cd CVSROOT
@end example
@item
@@ -1659,7 +2649,7 @@ Release the modules module.
@example
$ cd ..
-$ cvs release -d modules
+$ cvs release -d CVSROOT
@end example
@end enumerate
@@ -1671,36 +2661,128 @@ $ cvs release -d modules
@cindex File locking
@cindex Locking files
@cindex Working copy
+@cindex reserved checkouts
+@cindex unreserved checkouts
+@cindex RCS-style locking
When more than one person works on a software project
things often get complicated. Often, two people try to
-edit the same file simultaneously. Some other version
-control systems (including @sc{rcs} and @sc{sccs})
-try to solve that particular problem by introducing
-@dfn{file locking}, so that only one person can edit
-each file at a time. Unfortunately, file locking can
-be very counter-productive. If two persons want
-to edit different parts of a file, there may be no
-reason to prevent either of them from doing so.
-
-@sc{cvs} does not use file locking. Instead, it allows many
-people to edit their own @dfn{working copy} of a file
+edit the same file simultaneously. One solution, known
+as @dfn{file locking} or @dfn{reserved checkouts}, is
+to allow only one person to edit each file at a time.
+This is the only solution with some version control
+systems, including @sc{rcs} and @sc{sccs}. Currently
+the usual way to get reserved checkouts with @sc{cvs}
+is the @code{cvs admin -l} command (@pxref{admin
+options}). This is not as nicely integrated into
+@sc{cvs} as the watch features, described below, but it
+seems that most people with a need for reserved
+checkouts find it adequate.
+@c Or "find it better than worrying about implementing
+@c nicely integrated reserved checkouts" or ...?
+It also may be possible to use the watches
+features described below, together with suitable
+procedures (not enforced by software), to avoid having
+two people edit at the same time.
+
+@c Our unreserved checkout model might not
+@c be quite the same as others. For example, I
+@c think that some systems will tend to create a branch
+@c in the case where CVS prints "up-to-date check failed".
+@c It isn't clear to me whether we should try to
+@c explore these subtleties; it could easily just
+@c confuse people.
+The default model with @sc{cvs} is known as
+@dfn{unreserved checkouts}. In this model, developers
+can edit their own @dfn{working copy} of a file
simultaneously. The first person that commits his
-changes has no automatic way of knowing that another has started to
-edit it. Others will get an error message when they
-try to commit the file. They must then use @sc{cvs}
-commands to bring their working copy up to date with
-the repository revision. This process is almost
-automatic, and explained in this chapter.
-
-There are many ways to organize a team of developers.
-@sc{cvs} does not try to enforce a certain
-organization. It is a tool that can be used in several
-ways. It is often useful to inform the group of
-commits you have done. @sc{cvs} has several ways of
-automating that process. @xref{Informing others}.
-@xref{Revision management}, for more tips on how to use
-@sc{cvs}.
+changes has no automatic way of knowing that another
+has started to edit it. Others will get an error
+message when they try to commit the file. They must
+then use @sc{cvs} commands to bring their working copy
+up to date with the repository revision. This process
+is almost automatic.
+
+@c FIXME? should probably use the word "watch" here, to
+@c tie this into the text below and above.
+@sc{Cvs} also supports mechanisms which facilitate
+various kinds of communcation, without actually
+enforcing rules like reserved checkouts do.
+
+The rest of this chapter describes how these various
+models work, and some of the issues involved in
+choosing between them.
+
+@ignore
+Here is a draft reserved checkout design or discussion
+of the issues. This seems like as good a place as any
+for this.
+
+Might want a cvs lock/cvs unlock--in which the names
+differ from edit/unedit because the network must be up
+for these to work. unedit gives an error if there is a
+reserved checkout in place (so that people don't
+accidentally leave locks around); unlock gives an error
+if one is not in place (this is more arguable; perhaps
+it should act like unedit in that case).
+
+On the other hand, might want it so that emacs,
+scripts, etc., can get ready to edit a file without
+having to know which model is in use. In that case we
+would have a "cvs watch lock" (or .cvsrc?) (that is,
+three settings, "on", "off", and "lock"). Having cvs
+watch lock set would cause a get to record in the CVS
+directory which model is in use, and cause "cvs edit"
+to change behaviors. We'd want a way to query which
+setting is in effect (this would be handy even if it is
+only "on" or "off" as presently). If lock is in
+effect, then commit would require a lock before
+allowing a checkin; chmod wouldn't suffice (might be
+debatable--see chmod comment below, in watches--but it
+is the way people expect RCS to work and I can't think
+of any significant downside. On the other hand, maybe
+it isn't worth bothering, because people who are used
+to RCS wouldn't think to use chmod anyway).
+
+Implementation: use file attributes or use RCS
+locking. The former avoids more dependence on RCS
+behaviors we will need to reimplement as we librarify
+RCS, and makes it easier to import/export RCS files (in
+that context, want to ignore the locker field). But
+note that RCS locks are per-branch, which is the
+correct behavior (this is also an issue for the "watch
+on" features; they should be per-branch too).
+
+Here are a few more random notes about implementation
+details, assuming "cvs watch lock" and
+
+CVS/Watched file? Or try to fit this into CVS/Entries somehow?
+Cases: (1) file is checked out (unreserved or with watch on) by old
+version of CVS, now we do something with new one, (2) file is checked
+out by new version, now we do something with old one.
+
+Remote protocol would have a "Watched" analogous to "Mode". Of course
+it would apply to all Updated-like requests. How do we keep this
+setting up to date? I guess that there wants to be a Watched request,
+and the server would send a new one if it isn't up to date? (Ugh--hard
+to implement and slows down "cvs -q update"--is there an easier way?)
+
+"cvs edit"--checks CVS/Watched, and if watch lock, then sends
+"edit-lock" request. Which comes back with a Checked-in with
+appropriate Watched (off, on, lock, locked, or some such?), or error
+message if already locked.
+
+"cvs commit"--only will commit if off/on/locked. lock is not OK.
+
+Doc:
+note that "cvs edit" must be connected to network if watch lock is in
+effect.
+
+Talk about what to do if someone has locked a file and you want to
+edit that file. (breaking locks, or lack thereof).
+
+
+@end ignore
@menu
* File status:: A file can be in several states
@@ -1709,6 +2791,7 @@ automating that process. @xref{Informing others}.
* Informing others:: To cooperate you must inform
* Concurrency:: Simultaneous repository access
* Watches:: Mechanisms to track who is editing files
+* Choosing a model:: Reserved or unreserved checkouts?
@end menu
@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@@ -1716,35 +2799,151 @@ automating that process. @xref{Informing others}.
@section File status
@cindex File status
@cindex Status of a file
-@cindex Four states of a file
-
-After you have checked out a file out from @sc{cvs}, it is in
-one of these four states:
+@c Shouldn't this start with an example or something,
+@c introducing the unreserved checkout model? Before we
+@c dive into listing states?
+Based on what operations you have performed on a
+checked out file, and what operations others have
+performed to that file in the repository, one can
+classify a file in a number of states. The states, as
+reported by the @code{status} command, are:
+
+@c The order of items is chosen to group logically
+@c similar outputs together.
+@c People who want alphabetical can use the index...
@table @asis
@cindex Up-to-date
@item Up-to-date
The file is identical with the latest revision in the
-repository.
-@c -- The above is not always true if branching is used.
-
-@item Locally modified
-@cindex Locally modified
+repository for the branch in use.
+@c FIXME: should we clarify "in use"? The answer is
+@c sticky tags, and trying to distinguish branch sticky
+@c tags from non-branch sticky tags seems rather awkward
+@c here.
+@c FIXME: What happens with non-branch sticky tags? Is
+@c a stuck file "Up-to-date" or "Needs checkout" or what?
+
+@item Locally Modified
+@cindex Locally Modified
You have edited the file, and not yet committed your changes.
-@item Needing update
-@cindex Needing update
-Someone else has committed a newer revision to the repository.
-
-@item Needing merge
-@cindex Needing merge
-Someone else have committed a newer revision to the repository, and you
+@item Locally Added
+@cindex Locally Added
+You have added the file with @code{add}, and not yet
+committed your changes.
+@c There are many cases involving the file being
+@c added/removed/modified in the working directory, and
+@c added/removed/modified in the repository, which we
+@c don't try to describe here. I'm not sure that "cvs
+@c status" produces a non-confusing output in most of
+@c those cases.
+
+@item Locally Removed
+@cindex Locally Removed
+You have removed the file with @code{remove}, and not yet
+committed your changes.
+
+@item Needs Checkout
+@cindex Needs Checkout
+Someone else has committed a newer revision to the
+repository. The name is slightly misleading; you will
+ordinarily use @code{update} rather than
+@code{checkout} to get that newer revision.
+
+@item Needs Patch
+@cindex Needs Patch
+@c See also newb-123j0 in sanity.sh (although that case
+@c should probably be changed rather than documented).
+Like Needs Checkout, but the @sc{cvs} server will send
+a patch rather than the entire file. Sending a patch or
+sending an entire file accomplishes the same thing.
+
+@item Needs Merge
+@cindex Needs Merge
+Someone else has committed a newer revision to the repository, and you
have also made modifications to the file.
-@c -- What about "added" "removed" and so on?
+
+@item File had conflicts on merge
+@cindex File had conflicts on merge
+@c is it worth saying that this message was "Unresolved
+@c Conflict" in CVS 1.9 and earlier? I'm inclined to
+@c think that is unnecessarily confusing to new users.
+This is like Locally Modified, except that a previous
+@code{update} command gave a conflict. If you have not
+already done so, you need to
+resolve the conflict as described in @ref{Conflicts example}.
+
+@item Unknown
+@cindex Unknown
+@sc{Cvs} doesn't know anything about this file. For
+example, you have created a new file and have not run
+@code{add}.
+@c
+@c "Entry Invalid" and "Classify Error" are also in the
+@c status.c. The latter definitely indicates a CVS bug
+@c (should it be worded more like "internal error" so
+@c people submit bug reports if they see it?). The former
+@c I'm not as sure; I haven't tracked down whether/when it
+@c appears in "cvs status" output.
+
@end table
-You can use the @code{status} command to find out the status of a given
-file. @xref{status}.
+To help clarify the file status, @code{status} also
+reports the @code{Working revision} which is the
+revision that the file in the working directory derives
+from, and the @code{Repository revision} which is the
+latest revision in the repository for the branch in
+use.
+@c FIXME: should we clarify "in use"? The answer is
+@c sticky tags, and trying to distinguish branch sticky
+@c tags from non-branch sticky tags seems rather awkward
+@c here.
+@c FIXME: What happens with non-branch sticky tags?
+@c What is the Repository Revision there? See the
+@c comment at vn_rcs in cvs.h, which is kind of
+@c confused--we really need to document better what this
+@c field contains.
+@c Q: Should we document "New file!" and other such
+@c outputs or are they self-explanatory?
+@c FIXME: what about the date to the right of "Working
+@c revision"? It doesn't appear with client/server and
+@c seems unnecessary (redundant with "ls -l") so
+@c perhaps it should be removed for non-client/server too?
+@c FIXME: Need some examples.
+
+@c Would be nice to have an @example showing output
+@c from cvs status, with comments showing the xref
+@c where each part of the output is described. This
+@c might fit in nicely if it is desirable to split this
+@c node in two; one to introduce "cvs status" and one
+@c to list each of the states.
+The options to @code{status} are listed in
+@ref{Invoking CVS}. For information on its @code{Sticky tag}
+and @code{Sticky date} output, see @ref{Sticky tags}.
+For information on its @code{Sticky options} output,
+see the @samp{-k} option in @ref{update options}.
+
+You can think of the @code{status} and @code{update}
+commands as somewhat complementary. You use
+@code{update} to bring your files up to date, and you
+can use @code{status} to give you some idea of what an
+@code{update} would do (of course, the state of the
+repository might change before you actually run
+@code{update}). In fact, if you want a command to
+display file status in a more brief format than is
+displayed by the @code{status} command, you can invoke
+
+@cindex update, to display file status
+@example
+$ cvs -n -q update
+@end example
+
+The @samp{-n} option means to not actually do the
+update, but merely to display statuses; the @samp{-q}
+option avoids printing the name of each directory. For
+more information on the @code{update} command, and
+these options, see @ref{Invoking CVS}.
@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node Updating a file
@@ -1889,11 +3088,11 @@ int main(int argc,
gencode();
else
fprintf(stderr, "No code generated.\n");
-<<<<<<< driver.c
+@asis{}<<<<<<< driver.c
exit(nerr == 0 ? EXIT_SUCCESS : EXIT_FAILURE);
-=======
+@asis{}=======
exit(!!nerr);
->>>>>>> 1.6
+@asis{}>>>>>>> 1.6
@}
@end example
@@ -1947,6 +3146,23 @@ new revision: 1.7; previous revision: 1.6
done
@end example
+For your protection, @sc{cvs} will refuse to check in a
+file if a conflict occurred and you have not resolved
+the conflict. Currently to resolve a conflict, you
+must change the timestamp on the file, and must also
+insure that the file contains no conflict markers. If
+your file legitimately contains conflict markers (that
+is, occurrences of @samp{>>>>>>> } at the start of a
+line that don't mark a conflict), then @sc{cvs} has
+trouble handling this and you need to start hacking on
+the @code{CVS/Entries} file or other such workarounds.
+@c FIXME: There should be a "cvs resolved" command
+@c which clears the conflict indication. For a nice user
+@c interface, this should be invoked by an interactive
+@c merge tool like emerge rather than by the user
+@c directly--such a tool can verify that the user has
+@c really dealt with each conflict.
+
@cindex emerge
If you use release 1.04 or later of pcl-cvs (a @sc{gnu}
Emacs front-end for @sc{cvs}) you can use an Emacs
@@ -1974,6 +3190,8 @@ newsgroup.
@section Several developers simultaneously attempting to run CVS
@cindex locks, cvs
+@c For a discussion of *why* CVS creates locks, see
+@c the comment at the start of src/lock.c
If several developers try to run @sc{cvs} at the same
time, one may get the following message:
@@ -1987,15 +3205,16 @@ if it still needs to wait. If a lock seems to stick
around for an undue amount of time, find the person
holding the lock and ask them about the cvs command
they are running. If they aren't running a cvs
-command, look for and remove files starting with
-@file{#cvs.tfl}, @file{#cvs.rfl}, or @file{#cvs.wfl}
-from the repository.
+command, look in the repository directory mentioned in
+the message and remove files which they own whose names
+start with @file{#cvs.tfl}, @file{#cvs.rfl}, or
+@file{#cvs.wfl}.
Note that these locks are to protect @sc{cvs}'s
internal data structures and have no relationship to
-the word @dfn{lock} in the sense used by @sc{rcs}--a
-way to prevent other developers from working on a
-particular file.
+the word @dfn{lock} in the sense used by
+@sc{rcs}---which refers to reserved checkouts
+(@pxref{Multiple developers}).
Any number of people can be reading from a given
repository at a time; only when someone is writing do
@@ -2003,6 +3222,17 @@ the locks prevent other people from reading or writing.
@cindex Atomic transactions, lack of
@cindex Transactions, atomic, lack of
+@c the following talks about what one might call commit/update
+@c atomicity.
+@c Probably also should say something about
+@c commit/commit atomicity, that is, "An update will
+@c not get partial versions of more than one commit".
+@c CVS currently has this property and I guess we can
+@c make it a documented feature.
+@c For example one person commits
+@c a/one.c and b/four.c and another commits a/two.c and
+@c b/three.c. Then an update cannot get the new a/one.c
+@c and a/two.c and the old b/four.c and b/three.c.
One might hope for the following property
@example
@@ -2049,6 +3279,19 @@ section allow such coordination, while retaining the
ability of two developers to edit the same file at the
same time.
+@c Some people might ask why CVS does not enforce the
+@c rule on chmod, by requiring a cvs edit before a cvs
+@c commit. The main reason is that it could always be
+@c circumvented--one could edit the file, and
+@c then when ready to check it in, do the cvs edit and put
+@c in the new contents and do the cvs commit. One
+@c implementation note: if we _do_ want to have cvs commit
+@c require a cvs edit, we should store the state on
+@c whether the cvs edit has occurred in the working
+@c directory, rather than having the server try to keep
+@c track of what working directories exist.
+@c FIXME: should the above discussion be part of the
+@c manual proper, somewhere, not just in a comment?
For maximum benefit developers should use @code{cvs
edit} (not @code{chmod}) to make files read-write to
edit them, and @code{cvs release} (not @code{rm}) to
@@ -2078,8 +3321,9 @@ To enable the watch features, you first specify that
certain files are to be watched.
@cindex watch on (subcommand)
-@deffn Command {cvs watch on} [@code{-l}] files @dots{}
+@deffn Command {cvs watch on} [@code{-lR}] files @dots{}
+@cindex read-only files, and watches
Specify that developers should run @code{cvs edit}
before editing @var{files}. CVS will create working
copies of @var{files} read-only, to remind developers
@@ -2093,18 +3337,20 @@ added in the future; this allows the user to set
notification policies on a per-directory basis. The
contents of the directory are processed recursively,
unless the @code{-l} option is given.
+The @code{-R} option can be used to force recursion if the @code{-l}
+option is set in @file{~/.cvsrc} (@pxref{~/.cvsrc}).
If @var{files} is omitted, it defaults to the current directory.
@cindex watch off (subcommand)
@end deffn
-@deffn Command {cvs watch off} [@code{-l}] files @dots{}
+@deffn Command {cvs watch off} [@code{-lR}] files @dots{}
Do not provide notification about work on @var{files}. CVS will create
working copies of @var{files} read-write.
-The @var{files} and @code{-l} arguments are processed as for @code{cvs
+The @var{files} and options are processed as for @code{cvs
watch on}.
@end deffn
@@ -2120,7 +3366,7 @@ watch on}, so that developers use the @code{cvs edit}
command.
@cindex watch add (subcommand)
-@deffn Command {cvs watch add} [@code{-a} action] [@code{-l}] files @dots{}
+@deffn Command {cvs watch add} [@code{-a} action] [@code{-lR}] files @dots{}
Add the current user to the list of people to receive notification of
work done on @var{files}.
@@ -2154,14 +3400,14 @@ described below.)
The @code{-a} option may appear more than once, or not at all. If
omitted, the action defaults to @code{all}.
-The @var{files} and @code{-l} option are processed as for the
+The @var{files} and options are processed as for the
@code{cvs watch} commands.
@end deffn
@cindex watch remove (subcommand)
-@deffn Command {cvs watch remove} [@code{-a} action] [@code{-l}] files @dots{}
+@deffn Command {cvs watch remove} [@code{-a} action] [@code{-lR}] files @dots{}
Remove a notification request established using @code{cvs watch add};
the arguments are the same. If the @code{-a} option is present, only
@@ -2169,11 +3415,32 @@ watches for the specified actions are removed.
@end deffn
+@cindex notify (admin file)
When the conditions exist for notification, @sc{cvs}
-calls the @file{notify} administrative file, passing it
-the user to receive the notification and the user who
-is taking the action which results in notification.
-Normally @file{notify} will just send an email message.
+calls the @file{notify} administrative file. Edit
+@file{notify} as one edits the other administrative
+files (@pxref{Intro administrative files}). This
+file follows the usual conventions for administrative
+files (@pxref{syntax}), where each line is a regular
+expression followed by a command to execute. The
+command should contain a single ocurrence of @samp{%s}
+which will be replaced by the user to notify; the rest
+of the information regarding the notification will be
+supplied to the command on standard input. The
+standard thing to put in the @code{notify} file is the
+single line:
+
+@example
+ALL mail %s -s \"CVS notification\"
+@end example
+
+This causes users to be notified by electronic mail.
+@c FIXME: should it be this hard to set up this
+@c behavior (and the result when one fails to do so,
+@c silent failure to notify, so non-obvious)? Should
+@c CVS give a warning if no line in notify matches (and
+@c document the use of "DEFAULT :" for the case where
+@c skipping the notification is indeed desired)?
@cindex users (admin file)
Note that if you set this up in the straightforward
@@ -2188,13 +3455,49 @@ instead of passing the name of the user to be notified
to @file{notify}, @sc{cvs} will pass the @var{value}
(normally an email address on some other machine).
+@sc{Cvs} does not notify you for your own changes.
+Currently this check is done based on whether the user
+name of the person taking the action which triggers
+notification matches the user name of the person
+getting notification. In fact, in general, the watches
+features only track one edit by each user. It probably
+would be more useful if watches tracked each working
+directory separately, so this behavior might be worth
+changing.
+@c "behavior might be worth changing" is an effort to
+@c point to future directions while also not promising
+@c that "they" (as in "why don't they fix CVS to....")
+@c will do this.
+@c one implementation issue is identifying whether a
+@c working directory is same or different. Comparing
+@c pathnames/hostnames is hopeless, but having the server
+@c supply a serial number which the client stores in the
+@c CVS directory as a magic cookie should work.
+
@node Editing files
@subsection How to edit a file which is being watched
+@cindex checkout, as term for getting ready to edit
Since a file which is being watched is checked out
read-only, you cannot simply edit it. To make it
-read-write, and inform others that you are planning
-to edit it, use the @code{cvs edit} command.
+read-write, and inform others that you are planning to
+edit it, use the @code{cvs edit} command. Some systems
+call this a @dfn{checkout}, but @sc{cvs} uses that term
+for obtaining a copy of the sources (@pxref{Getting the
+source}), an operation which those systems call a
+@dfn{get} or a @dfn{fetch}.
+@c Issue to think about: should we transition CVS
+@c towards the "get" terminology? "cvs get" is already a
+@c synonym for "cvs checkout" and that section of the
+@c manual refers to "Getting the source". If this is
+@c done, needs to be done gingerly (for example, we should
+@c still accept "checkout" in .cvsrc files indefinitely
+@c even if the CVS's messages are changed from "cvs checkout: "
+@c to "cvs get: ").
+@c There is a concern about whether "get" is not as
+@c good for novices because it is a more general term
+@c than "checkout" (and thus arguably harder to assign
+@c a technical meaning for).
@cindex edit (subcommand)
@deffn Command {cvs edit} [options] files @dots{}
@@ -2209,7 +3512,7 @@ user on @var{files}; CVS will remove the watch when @var{files} are
@code{unedit}ed or @code{commit}ted. If the user does not wish to
receive notifications, she should specify @code{-a none}.
-The @var{files} and @code{-l} option are processed as for the @code{cvs
+The @var{files} and options are processed as for the @code{cvs
watch} commands.
@end deffn
@@ -2222,7 +3525,9 @@ your changes, or not to make any changes, you can use
the @code{cvs unedit} command.
@cindex unedit (subcommand)
-@deffn Command {cvs unedit} [@code{-l}] files @dots{}
+@cindex abandoning work
+@cindex reverting to repository version
+@deffn Command {cvs unedit} [@code{-lR}] files @dots{}
Abandon work on the working files @var{files}, and revert them to the
repository versions on which they are based. CVS makes those
@@ -2230,9 +3535,18 @@ repository versions on which they are based. CVS makes those
@code{cvs watch on}. CVS notifies users who have requested @code{unedit}
notification for any of @var{files}.
-The @var{files} and @code{-l} option are processed as for the
+The @var{files} and options are processed as for the
@code{cvs watch} commands.
+If watches are not in use, the @code{unedit} command
+probably does not work, and the way to revert to the
+repository version is to remove the file and then use
+@code{cvs update} to get a new copy. The meaning is
+not precisely the same; removing and updating may also
+bring in some changes which have been made in the
+repository since the last time you updated.
+@c It would be a useful enhancement to CVS to make
+@c unedit work in the non-watch case as well.
@end deffn
When using client/server @sc{cvs}, you can use the
@@ -2245,26 +3559,26 @@ successful @sc{cvs} command.
@subsection Information about who is watching and editing
@cindex watchers (subcommand)
-@deffn Command {cvs watchers} [@code{-l}] files @dots{}
+@deffn Command {cvs watchers} [@code{-lR}] files @dots{}
List the users currently watching changes to @var{files}. The report
includes the files being watched, and the mail address of each watcher.
-The @var{files} and @code{-l} arguments are processed as for the
+The @var{files} and options are processed as for the
@code{cvs watch} commands.
@end deffn
@cindex editors (subcommand)
-@deffn Command {cvs editors} [@code{-l}] files @dots{}
+@deffn Command {cvs editors} [@code{-lR}] files @dots{}
List the users currently working on @var{files}. The report
includes the mail address of each user, the time when the user began
working with the file, and the host and path of the working directory
containing the file.
-The @var{files} and @code{-l} arguments are processed as for the
+The @var{files} and options are processed as for the
@code{cvs watch} commands.
@end deffn
@@ -2277,10 +3591,12 @@ If you use the watch features on a repository, it
creates @file{CVS} directories in the repository and
stores the information about watches in that directory.
If you attempt to use @sc{cvs} 1.6 or earlier with the
-repository, you get an error message such as
+repository, you get an error message such as the
+following (all on one line):
@example
-cvs update: cannot open CVS/Entries for reading: No such file or directory
+cvs update: cannot open CVS/Entries for reading:
+No such file or directory
@end example
and your operation will likely be aborted. To use the
@@ -2291,31 +3607,264 @@ you cannot upgrade, use the @code{watch off} and
that will restore the repository to a state which
@sc{cvs} 1.6 can cope with.
+@node Choosing a model
+@section Choosing between reserved or unreserved checkouts
+@cindex choosing, reserved or unreserved checkouts
+
+Reserved and unreserved checkouts each have pros and
+cons. Let it be said that a lot of this is a matter of
+opinion or what works given different groups' working
+styles, but here is a brief description of some of the
+issues. There are many ways to organize a team of
+developers. @sc{cvs} does not try to enforce a certain
+organization. It is a tool that can be used in several
+ways.
+
+Reserved checkouts can be very counter-productive. If
+two persons want to edit different parts of a file,
+there may be no reason to prevent either of them from
+doing so. Also, it is common for someone to take out a
+lock on a file, because they are planning to edit it,
+but then forget to release the lock.
+
+@c "many groups"? specifics? cites to papers on this?
+@c some way to weasel-word it a bit more so we don't
+@c need facts :-)?
+People, especially people who are familiar with
+reserved checkouts, often wonder how often conflicts
+occur if unreserved checkouts are used, and how
+difficult they are to resolve. The experience with
+many groups is that they occur rarely and usually are
+relatively straightforward to resolve.
+
+The rarity of serious conflicts may be surprising, until one realizes
+that they occur only when two developers disagree on the proper design
+for a given section of code; such a disagreement suggests that the
+team has not been communicating properly in the first place. In order
+to collaborate under @emph{any} source management regimen, developers
+must agree on the general design of the system; given this agreement,
+overlapping changes are usually straightforward to merge.
+
+In some cases unreserved checkouts are clearly
+inappropriate. If no merge tool exists for the kind of
+file you are managing (for example word processor files
+or files edited by Computer Aided Design programs), and
+it is not desirable to change to a program which uses a
+mergeable data format, then resolving conflicts is
+going to be unpleasant enough that you generally will
+be better off to simply avoid the conflicts instead, by
+using reserved checkouts.
+
+The watches features described above in @ref{Watches}
+can be considered to be an intermediate model between
+reserved checkouts and unreserved checkouts. When you
+go to edit a file, it is possible to find out who else
+is editing it. And rather than having the system
+simply forbid both people editing the file, it can tell
+you what the situation is and let you figure out
+whether it is a problem in that particular case or not.
+Therefore, for some groups it can be considered the
+best of both the reserved checkout and unreserved
+checkout worlds.
+
@c ---------------------------------------------------------------------
-@node Branches
-@chapter Branches
+@node Revisions and branches
+@chapter Revisions and branches
@cindex Branches
@cindex Main trunk and branches
@cindex Revision tree, making branches
-So far, all revisions shown in this manual have been on
-the @dfn{main trunk}
-of the revision tree, i.e., all revision numbers
-have been of the form @var{x}.@var{y}. One useful
-feature, especially when maintaining several releases
-of a software product at once, is the ability to make
-branches on the revision tree. @dfn{Tags}, symbolic
-names for revisions, will also be
-introduced in this chapter.
+For many uses of @sc{cvs}, one doesn't need to worry
+too much about revision numbers; @sc{cvs} assigns
+numbers such as @code{1.1}, @code{1.2}, and so on, and
+that is all one needs to know. However, some people
+prefer to have more knowledge and control concerning
+how @sc{cvs} assigns revision numbers.
+
+If one wants to keep track of a set of revisions
+involving more than one file, such as which revisions
+went into a particular release, one uses a @dfn{tag},
+which is a symbolic revision which can be assigned to a
+numeric revision in each file.
+
+Another useful feature, especially when maintaining
+several releases of a software product at once, is the
+ability to make branches on the revision tree.
+@c FIXME: probably want another sentence or two, very
+@c briefly motivating branches.
@menu
+* Revision numbers:: The meaning of a revision number
+* Versions revisions releases:: Terminology used in this manual
+* Assigning revisions:: Assigning revisions
* Tags:: Tags--Symbolic revisions
* Branches motivation:: What branches are good for
* Creating a branch:: Creating a branch
* Sticky tags:: Sticky tags
+* Magic branch numbers:: Magic branch numbers
@end menu
@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
+@node Revision numbers
+@section Revision numbers
+@cindex Revision numbers
+@cindex Revision tree
+@cindex Linear development
+@cindex Number, revision-
+@cindex Decimal revision number
+@cindex Branch number
+@cindex Number, branch
+
+Each version of a file has a unique @dfn{revision
+number}. Revision numbers look like @samp{1.1},
+@samp{1.2}, @samp{1.3.2.2} or even @samp{1.3.2.2.4.5}.
+A revision number always has an even number of
+period-separated decimal integers. By default revision
+1.1 is the first revision of a file. Each successive
+revision is given a new number by increasing the
+rightmost number by one. The following figure displays
+a few revisions, with newer revisions to the right.
+
+@example
+ +-----+ +-----+ +-----+ +-----+ +-----+
+ ! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 !
+ +-----+ +-----+ +-----+ +-----+ +-----+
+@end example
+
+@c Probably should move the following down a few
+@c sections, until after "branch motivation".
+@sc{cvs} is not limited to linear development. The
+@dfn{revision tree} can be split into @dfn{branches},
+where each branch is a self-maintained line of
+development. Changes made on one branch can easily be
+moved back to the main trunk.
+
+Each branch has a @dfn{branch number}, consisting of an
+odd number of period-separated decimal integers. The
+branch number is created by appending an integer to the
+revision number where the corresponding branch forked
+off. Having branch numbers allows more than one branch
+to be forked off from a certain revision.
+
+@need 3500
+All revisions on a branch have revision numbers formed
+by appending an ordinal number to the branch number.
+The following figure illustrates branching with an
+example.
+
+@example
+@group
+ +-------------+
+ Branch 1.2.2.3.2 -> ! 1.2.2.3.2.1 !
+ / +-------------+
+ /
+ /
+ +---------+ +---------+ +---------+
+Branch 1.2.2 -> _! 1.2.2.1 !----! 1.2.2.2 !----! 1.2.2.3 !
+ / +---------+ +---------+ +---------+
+ /
+ /
++-----+ +-----+ +-----+ +-----+ +-----+
+! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 ! <- The main trunk
++-----+ +-----+ +-----+ +-----+ +-----+
+ !
+ !
+ ! +---------+ +---------+ +---------+
+Branch 1.2.4 -> +---! 1.2.4.1 !----! 1.2.4.2 !----! 1.2.4.3 !
+ +---------+ +---------+ +---------+
+
+@end group
+@end example
+
+@c -- However, at least for me the figure is not enough. I suggest more
+@c -- text to accompany it. "A picture is worth a thousand words", so you
+@c -- have to make sure the reader notices the couple of hundred words
+@c -- *you* had in mind more than the others!
+
+@c -- Why an even number of segments? This section implies that this is
+@c -- how the main trunk is distinguished from branch roots, but you never
+@c -- explicitly say that this is the purpose of the [by itself rather
+@c -- surprising] restriction to an even number of segments.
+
+The exact details of how the branch number is
+constructed is not something you normally need to be
+concerned about, but here is how it works: When
+@sc{cvs} creates a branch number it picks the first
+unused even integer, starting with 2. So when you want
+to create a branch from revision 6.4 it will be
+numbered 6.4.2. All branch numbers ending in a zero
+(such as 6.4.0) are used internally by @sc{cvs}
+(@pxref{Magic branch numbers}). The branch 1.1.1 has a
+special meaning. @xref{Tracking sources}.
+
+@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
+@node Versions revisions releases
+@section Versions, revisions and releases
+@cindex Revisions, versions and releases
+@cindex Versions, revisions and releases
+@cindex Releases, revisions and versions
+
+A file can have several versions, as described above.
+Likewise, a software product can have several versions.
+A software product is often given a version number such
+as @samp{4.1.1}.
+
+Versions in the first sense are called @dfn{revisions}
+in this document, and versions in the second sense are
+called @dfn{releases}. To avoid confusion, the word
+@dfn{version} is almost never used in this document.
+
+@node Assigning revisions
+@section Assigning revisions
+
+@c We avoid the "major revision" terminology. It seems
+@c like jargon. Hopefully "first number" is clear enough.
+By default, @sc{cvs} will assign numeric revisions by
+leaving the first number the same and incrementing the
+second number. For example, @code{1.1}, @code{1.2},
+@code{1.3}, etc.
+
+When adding a new file, the second number will always
+be one and the first number will equal the highest
+first number of any file in that directory. For
+example, the current directory contains files whose
+highest numbered revisions are @code{1.7}, @code{3.1},
+and @code{4.12}, then an added file will be given the
+numeric revision @code{4.1}.
+
+@c This is sort of redundant with something we said a
+@c while ago. Somewhere we need a better way of
+@c introducing how the first number can be anything
+@c except "1", perhaps. Also I don't think this
+@c presentation is clear on why we are discussing releases
+@c and first numbers of numeric revisions in the same
+@c breath.
+Normally there is no reason to care
+about the revision numbers---it is easier to treat them
+as internal numbers that @sc{cvs} maintains, and tags
+provide a better way to distinguish between things like
+release 1 versus release 2 of your product
+(@pxref{Tags}). However, if you want to set the
+numeric revisions, the @samp{-r} option to @code{cvs
+commit} can do that. The @samp{-r} option implies the
+@samp{-f} option, in the sense that it causes the
+files to be committed even if they are not modified.
+
+For example, to bring all your files up to
+revision 3.0 (including those that haven't changed),
+you might invoke:
+
+@example
+$ cvs commit -r 3.0
+@end example
+
+Note that the number you specify with @samp{-r} must be
+larger than any existing revision number. That is, if
+revision 3.0 exists, you cannot @samp{cvs commit
+-r 1.3}. If you want to maintain several releases in
+parallel, you need to use a branch (@pxref{Revisions and branches}).
+
+@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node Tags
@section Tags--Symbolic revisions
@cindex Tags
@@ -2351,17 +3900,47 @@ rcsutil.c 5.10
You can use the @code{tag} command to give a symbolic name to a
certain revision of a file. You can use the @samp{-v} flag to the
@code{status} command to see all tags that a file has, and
-which revision numbers they represent. Tag names can
+which revision numbers they represent. Tag names must
+start with an uppercase or lowercase letter and can
contain uppercase and lowercase letters, digits,
@samp{-}, and @samp{_}. The two tag names @code{BASE}
and @code{HEAD} are reserved for use by @sc{cvs}. It
is expected that future names which are special to
-@sc{cvs} will contain characters such as @samp{%} or
-@samp{=}, rather than being named analogously to
+@sc{cvs} will be specially named, for example by
+starting with @samp{.}, rather than being named analogously to
@code{BASE} and @code{HEAD}, to avoid conflicts with
actual tag names.
-@c FIXME: is the above list of valid characters in tag
-@c names complete?
+@c Including a character such as % or = has also been
+@c suggested as the naming convention for future
+@c special tag names. Starting with . is nice because
+@c that is not a legal tag name as far as RCS is concerned.
+@c FIXME: CVS actually accepts quite a few characters
+@c in tag names, not just the ones documented above
+@c (see RCS_check_tag). RCS
+@c defines legitimate tag names by listing illegal
+@c characters rather than legal ones. CVS is said to lose its
+@c mind if you try to use "/" (try making such a tag sticky
+@c and using "cvs status" client/server--see remote
+@c protocol format for entries line for probable cause).
+@c TODO: The testsuite
+@c should test for whatever are documented above as
+@c officially-OK tag names, and CVS should at least reject
+@c characters that won't work, like "/".
+
+You'll want to choose some convention for naming tags,
+based on information such as the name of the program
+and the version number of the release. For example,
+one might take the name of the program, immediately
+followed by the version number with @samp{.} changed to
+@samp{-}, so that CVS 1.9 would be tagged with the name
+@code{cvs1-9}. If you choose a consistent convention,
+then you won't constantly be guessing whether a tag is
+@code{cvs-1-9} or @code{cvs1_9} or what. You might
+even want to consider enforcing your convention in the
+taginfo file (@pxref{user-defined logging}).
+@c Might be nice to say more about using taginfo this
+@c way, like giving an example, or pointing out any particular
+@c issues which arise.
@cindex Adding a tag
@cindex tag, example
@@ -2379,7 +3958,7 @@ $ cvs status -v backend.c
File: backend.c Status: Up-to-date
Version: 1.4 Tue Dec 1 14:39:01 1992
- RCS Version: 1.4 /usr/local/cvsroot/yoyodyne/tc/backend.c,v
+ RCS Version: 1.4 /u/cvsroot/yoyodyne/tc/backend.c,v
Sticky Tag: (none)
Sticky Date: (none)
Sticky Options: (none)
@@ -2506,6 +4085,13 @@ does not require that you have a working copy of the
module. @xref{rtag}. (You can also use the @code{tag}
command; @pxref{tag}).
+@c Why does this example use -r? That seems like a
+@c confusing thing to do in an example where we are
+@c introducing branches. One user thought it was
+@c a mandatory part of creating a branch for example.
+@c And we are not sufficiently
+@c "step by step" in terms of explaining
+@c what argument one should give to -r.
@example
$ cvs rtag -b -r release-1-0 release-1-0-patches tc
@end example
@@ -2529,7 +4115,7 @@ $ cvs status -v driver.c backend.c
File: driver.c Status: Up-to-date
Version: 1.7 Sat Dec 5 18:25:54 1992
- RCS Version: 1.7 /usr/local/cvsroot/yoyodyne/tc/driver.c,v
+ RCS Version: 1.7 /u/cvsroot/yoyodyne/tc/driver.c,v
Sticky Tag: release-1-0-patches (branch: 1.7.2)
Sticky Date: (none)
Sticky Options: (none)
@@ -2542,7 +4128,7 @@ File: driver.c Status: Up-to-date
File: backend.c Status: Up-to-date
Version: 1.4 Tue Dec 1 14:39:01 1992
- RCS Version: 1.4 /usr/local/cvsroot/yoyodyne/tc/backend.c,v
+ RCS Version: 1.4 /u/cvsroot/yoyodyne/tc/backend.c,v
Sticky Tag: release-1-0-patches (branch: 1.4.2)
Sticky Date: (none)
Sticky Options: (none)
@@ -2560,7 +4146,7 @@ number is created by adding a digit at the tail of the revision number
it is based on. (If @samp{release-1-0} corresponds to revision 1.4, the
branch's revision number will be 1.4.2. For obscure reasons @sc{cvs} always
gives branches even numbers, starting at 2.
-@xref{Revision numbers}).
+@xref{Revision numbers}.).
@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node Sticky tags
@@ -2596,7 +4182,7 @@ $ cvs status -v driver.c
File: driver.c Status: Up-to-date
Version: 1.7.2.1 Sat Dec 5 19:35:03 1992
- RCS Version: 1.7.2.1 /usr/local/cvsroot/yoyodyne/tc/driver.c,v
+ RCS Version: 1.7.2.1 /u/cvsroot/yoyodyne/tc/driver.c,v
Sticky Tag: release-1-0-patches (branch: 1.7.2)
Sticky Date: (none)
Sticky Options: (none)
@@ -2616,14 +4202,18 @@ you delete them with @samp{cvs update -A}. The
the head of the trunk, and forgets any sticky tags,
dates, or options.
-@c Is the fact that CVS works this way a bug or a
-@c feature? If a feature, describe how you would use
-@c it to do something useful.
-Sticky tags are not just for branches. If you check
-out a certain revision (such as 1.4) it will also
-become sticky. Subsequent @samp{cvs update} will not
-retrieve the latest revision until you reset the tag
-with @samp{cvs update -A}. Likewise, use of the
+@cindex sticky date
+Sticky tags are not just for branches. For example,
+suppose that you want to avoid updating your working
+directory, to isolate yourself from possibly
+destabilizing changes other people are making. You
+can, of course, just refrain from running @code{cvs
+update}. But if you want to avoid updating only a
+portion of a larger tree, then sticky tags can help.
+If you check out a certain revision (such as 1.4) it
+will become sticky. Subsequent @code{cvs update} will
+not retrieve the latest revision until you reset the
+tag with @code{cvs update -A}. Likewise, use of the
@samp{-D} option to @code{update} or @code{checkout}
sets a @dfn{sticky date}, which, similarly, causes that
date to be used for future retrievals.
@@ -2648,7 +4238,7 @@ RCS: /tmp/cvs-sanity/cvsroot/first-dir/Attic/file1,v
VERS: 1.1
***************
$ cvs add file1
-cvs add: version 1.2 of `file1' will be resurrected
+cvs add: re-adding file file1 (in place of dead revision 1.2)
cvs add: use 'cvs commit' to add this file permanently
$ cvs commit -m test
Checking in file1;
@@ -2658,6 +4248,73 @@ done
$
@end example
+@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
+@node Magic branch numbers
+@section Magic branch numbers
+
+@c Want xref to here from "log" and "admin"?
+
+This section describes a @sc{cvs} feature called
+@dfn{magic branches}. For most purposes, you need not
+worry about magic branches; @sc{cvs} handles them for
+you. However, they are visible to you in certain
+circumstances, so it may be useful to have some idea of
+how it works.
+
+Externally, branch numbers consist of an odd number of
+dot-separated decimal integers. @xref{Revision
+numbers}. That is not the whole truth, however. For
+efficiency reasons @sc{cvs} sometimes inserts an extra 0
+in the second rightmost position (1.2.3 becomes
+1.2.0.3, 8.9.10.11.12 becomes 8.9.10.11.0.12 and so
+on).
+
+@sc{cvs} does a pretty good job at hiding these so
+called magic branches, but in a few places the hiding
+is incomplete:
+
+@itemize @bullet
+@ignore
+@c This is in ignore as I'm taking their word for it,
+@c that this was fixed
+@c a long time ago. But before deleting this
+@c entirely, I'd rather verify it (and add a test
+@c case to the testsuite).
+@item
+The magic branch can appear in the output from
+@code{cvs status} in vanilla @sc{cvs} 1.3. This is
+fixed in @sc{cvs} 1.3-s2.
+
+@end ignore
+@item
+The magic branch number appears in the output from
+@code{cvs log}.
+@c What output should appear instead?
+
+@item
+You cannot specify a symbolic branch name to @code{cvs
+admin}.
+
+@end itemize
+
+@c Can CVS do this automatically the first time
+@c you check something in to that branch? Should
+@c it?
+You can use the @code{admin} command to reassign a
+symbolic name to a branch the way @sc{rcs} expects it
+to be. If @code{R4patches} is assigned to the branch
+1.4.2 (magic branch number 1.4.0.2) in file
+@file{numbers.c} you can do this:
+
+@example
+$ cvs admin -NR4patches:1.4.2 numbers.c
+@end example
+
+It only works if at least one revision is already
+committed on the branch. Be very careful so that you
+do not assign the tag to the wrong number. (There is
+no way to see how the tag was assigned yesterday).
+
@c ---------------------------------------------------------------------
@node Merging
@chapter Merging
@@ -2676,6 +4333,7 @@ copy the changes onto another branch.
* Merging a branch:: Merging an entire branch
* Merging more than once:: Merging from a branch several times
* Merging two revisions:: Merging differences between two revisions
+* Merging adds and removals:: What if files are added or removed?
@end menu
@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@@ -2745,7 +4403,7 @@ like this:
@example
+-----+ +-----+ +-----+ +-----+ +-----+
-! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 ! <- The main trunk
+! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 ! <- The main trunk
+-----+ +-----+ +-----+ +-----+ +-----+
! *
! *
@@ -2763,7 +4421,7 @@ Now suppose that development continues on the
@example
+-----+ +-----+ +-----+ +-----+ +-----+
-! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 ! <- The main trunk
+! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 ! <- The main trunk
+-----+ +-----+ +-----+ +-----+ +-----+
! *
! *
@@ -2833,6 +4491,31 @@ that make up a module. You almost always use symbolic
tags rather than revision numbers when operating on
multiple files.
+@node Merging adds and removals
+@section Merging can add or remove files
+
+If the changes which you are merging involve removing
+or adding some files, @code{update -j} will reflect
+such additions or removals.
+
+@c FIXME: This example needs a lot more explanation.
+@c We also need other examples for some of the other
+@c cases (not all--there are too many--as long as we present a
+@c coherent general principle).
+For example:
+@example
+cvs update -A
+touch a b c
+cvs add a b c ; cvs ci -m "added" a b c
+cvs tag -b branchtag
+cvs update -r branchtag
+touch d ; cvs add d
+rm a ; cvs rm a
+cvs ci -m "added d, removed a"
+cvs update -A
+cvs update -jbranchtag
+@end example
+
@c ---------------------------------------------------------------------
@node Recursive behavior
@chapter Recursive behavior
@@ -2878,8 +4561,11 @@ following is true:
@itemize @bullet
@item
-@samp{cvs update testing} is equivalent to @samp{cvs
-update testing/testpgm.t testing/test2.t}
+@samp{cvs update testing} is equivalent to
+
+@example
+cvs update testing/testpgm.t testing/test2.t
+@end example
@item
@samp{cvs update testing man} updates all files in the
@@ -2899,6 +4585,8 @@ for most of the @sc{cvs} subcommands, not only the
The recursive behavior of the @sc{cvs} subcommands can be
turned off with the @samp{-l} option.
+Conversely, the @samp{-R} option can be used to force recursion if
+@samp{-l} is specified in @file{~/.cvsrc} (@pxref{~/.cvsrc}).
@example
$ cvs update -l # @r{Don't update files in subdirectories}
@@ -2906,63 +4594,138 @@ $ cvs update -l # @r{Don't update files in subdirectories}
@c ---------------------------------------------------------------------
@node Adding files
-@chapter Adding files to a module
+@chapter Adding files to a directory
@cindex Adding files
-To add a new file to a module, follow these steps.
+To add a new file to a directory, follow these steps.
@itemize @bullet
@item
-You must have a working copy of the module.
+You must have a working copy of the directory.
@xref{Getting the source}.
@item
-Create the new file inside your working copy of the module.
+Create the new file inside your working copy of the directory.
@item
Use @samp{cvs add @var{filename}} to tell @sc{cvs} that you
-want to version control the file.
+want to version control the file. If the file contains
+binary data, specify @samp{-kb} (@pxref{Binary files}).
@item
Use @samp{cvs commit @var{filename}} to actually check
in the file into the repository. Other developers
cannot see the file until you perform this step.
-
-@item
-If the file contains binary data it might be necessary
-to change the default keyword substitution.
-@xref{Keyword substitution}. @xref{admin examples}.
@end itemize
You can also use the @code{add} command to add a new
-directory inside a module.
+directory.
+@c FIXCVS and/or FIXME: Adding a directory doesn't
+@c require the commit step. This probably can be
+@c considered a CVS bug, but it is possible we should
+@c warn people since this behavior probably won't be
+@c changing right away.
Unlike most other commands, the @code{add} command is
not recursive. You cannot even type @samp{cvs add
foo/bar}! Instead, you have to
+@c FIXCVS: This is, of course, not a feature. It is
+@c just that noone has gotten around to fixing "cvs add
+@c foo/bar".
@example
$ cd foo
$ cvs add bar
@end example
-@xref{add}, for a more complete description of the @code{add}
-command.
+@cindex add (subcommand)
+@deffn Command {cvs add} [@code{-k} kflag] [@code{-m} message] files @dots{}
+
+Schedule @var{files} to be added to the repository.
+The files or directories specified with @code{add} must
+already exist in the current directory. To add a whole
+new directory hierarchy to the source repository (for
+example, files received from a third-party vendor), use
+the @code{import} command instead. @xref{import}.
+
+The added files are not placed in the source repository
+until you use @code{commit} to make the change
+permanent. Doing an @code{add} on a file that was
+removed with the @code{remove} command will undo the
+effect of the @code{remove}, unless a @code{commit}
+command intervened. @xref{Removing files}, for an
+example.
+
+The @samp{-k} option specifies the default way that
+this file will be checked out; for more information see
+@ref{Substitution modes}.
+
+@c As noted in BUGS, -m is broken client/server (Nov
+@c 96). Also see testsuite log2-* tests.
+The @samp{-m} option specifies a description for the
+file. This description appears in the history log (if
+it is enabled, @pxref{history file}). It will also be
+saved in the version history inside the repository when
+the file is committed. The @code{log} command displays
+this description. The description can be changed using
+@samp{admin -t}. @xref{admin}. If you omit the
+@samp{-m @var{description}} flag, an empty string will
+be used. You will not be prompted for a description.
+@end deffn
+
+For example, the following commands add the file
+@file{backend.c} to the repository:
+
+@c This example used to specify
+@c -m "Optimizer and code generation passes."
+@c to the cvs add command, but that doesn't work
+@c client/server (see log2 in sanity.sh). Should fix CVS,
+@c but also seems strange to document things which
+@c don't work...
+@example
+$ cvs add backend.c
+$ cvs commit -m "Early version. Not yet compilable." backend.c
+@end example
+
+When you add a file it is added only on the branch
+which you are working on (@pxref{Revisions and branches}). You can
+later merge the additions to another branch if you want
+(@pxref{Merging adds and removals}).
+@c Should we mention that earlier versions of CVS
+@c lacked this feature (1.3) or implemented it in a buggy
+@c way (well, 1.8 had many bugs in cvs update -j)?
+@c Should we mention the bug/limitation regarding a
+@c file being a regular file on one branch and a directory
+@c on another?
+@c FIXME: This needs an example, or several, here or
+@c elsewhere, for it to make much sense.
+@c Somewhere we need to discuss the aspects of death
+@c support which don't involve branching, I guess.
+@c Like the ability to re-create a release from a tag.
@c ---------------------------------------------------------------------
@node Removing files
-@chapter Removing files from a module
+@chapter Removing files
@cindex Removing files
@cindex Deleting files
+@c FIXME: this node wants to be split into several
+@c smaller nodes. Probably would fit well with merging
+@c this chapter with "adding files" and the others, as
+@c suggested at the top-level menu (death support could
+@c be its own section, for example, as could the
+@c various bits about undoing mistakes in adding and
+@c removing).
Modules change. New files are added, and old files
disappear. Still, you want to be able to retrieve an
-exact copy of old releases of the module.
+exact copy of old releases.
-Here is what you can do to remove a file from a module,
+Here is what you can do to remove a file,
but remain able to retrieve old revisions:
@itemize @bullet
+@c FIXME: should probably be saying something about
+@c having a working directory in the first place.
@item
Make sure that you have not made any uncommitted
modifications to the file. @xref{Viewing differences},
@@ -2973,7 +4736,7 @@ course not be able to retrieve the file as it was
immediately before you deleted it.
@item
-Remove the file from your working copy of the module.
+Remove the file from your working copy of the directory.
You can for instance use @code{rm}.
@item
@@ -2985,6 +4748,15 @@ Use @samp{cvs commit @var{filename}} to actually
perform the removal of the file from the repository.
@end itemize
+@c FIXME: Somehow this should be linked in with a more
+@c general discussion of death support. I don't know
+@c whether we want to use the term "death support" or
+@c not (we can perhaps get by without it), but we do
+@c need to discuss the "dead" state in "cvs log" and
+@c related subjects. The current discussion is
+@c scattered around, and not xref'd to each other.
+@c FIXME: I think this paragraph wants to be moved
+@c later down, at least after the first example.
When you commit the removal of the file, @sc{cvs}
records the fact that the file no longer exists. It is
possible for a file to exist on only some branches and
@@ -2993,23 +4765,24 @@ name later. CVS will correctly create or not create
the file, based on the @samp{-r} and @samp{-D} options
specified to @code{checkout} or @code{update}.
+@c FIXME: This style seems to clash with how we
+@c document things in general.
@cindex Remove (subcommand)
-@deffn Command {cvs remove} [@code{-lR}] files @dots{}
+@deffn Command {cvs remove} [options] files @dots{}
Schedule file(s) to be removed from the repository
(files which have not already been removed from the
working directory are not processed). This command
does not actually remove the file from the repository
-until you commit the removal. The @samp{-R} option
-(the default) specifies that it will recurse into
-subdirectories; @samp{-l} specifies that it will not.
+until you commit the removal. For a full list of
+options, see @ref{Invoking CVS}.
@end deffn
Here is an example of removing several files:
@example
$ cd test
-$ rm ?.c
+$ rm *.c
$ cvs remove
cvs remove: Removing .
cvs remove: scheduling a.c for removal
@@ -3020,9 +4793,40 @@ cvs commit: Examining .
cvs commit: Committing .
@end example
-If you change your mind you can easily resurrect the
-file before you commit it, using the @code{add}
-command.
+As a convenience you can remove the file and @code{cvs
+remove} it in one step, by specifying the @samp{-f}
+option. For example, the above example could also be
+done like this:
+
+@example
+$ cd test
+$ cvs remove -f *.c
+cvs remove: scheduling a.c for removal
+cvs remove: scheduling b.c for removal
+cvs remove: use 'cvs commit' to remove these files permanently
+$ cvs ci -m "Removed unneeded files"
+cvs commit: Examining .
+cvs commit: Committing .
+@end example
+
+If you execute @code{remove} for a file, and then
+change your mind before you commit, you can undo the
+@code{remove} with an @code{add} command.
+@ignore
+@c is this worth saying or not? Somehow it seems
+@c confusing to me.
+Of course,
+since you have removed your copy of file in the working
+directory, @sc{cvs} does not necessarily bring back the
+contents of the file from right before you executed
+@code{remove}; instead it gets the file from the
+repository again.
+@end ignore
+
+@c FIXME: what if you change your mind after you commit
+@c it? (answer is also "cvs add" but we don't say that...).
+@c We need some index entries for thinks like "undoing
+@c removal" too.
@example
$ ls
@@ -3047,12 +4851,51 @@ cvs update: warning: oj.c was lost
U oj.c
@end example
+When you remove a file it is removed only on the branch
+which you are working on (@pxref{Revisions and branches}). You can
+later merge the removals to another branch if you want
+(@pxref{Merging adds and removals}).
+
+@node Removing directories
+@chapter Removing directories
+@cindex removing directories
+@cindex directories, removing
+
+In concept removing directories is somewhat similar to
+removing files---you want the directory to not exist in
+your current working directories, but you also want to
+be able to retrieve old releases in which the directory
+existed.
+
+The way that you remove a directory is to remove all
+the files in it. Then specify the @samp{-P} option to
+@code{cvs update}, @code{cvs checkout}, or @code{cvs
+export}, which will cause @sc{cvs} to remove empty
+directories from working directories. Probably the
+best way to do this is to always specify @samp{-P}; if
+you want an empty directory then put a dummy file (for
+example @file{.keepme}) in it to prevent @samp{-P} from
+removing it.
+
+@c I'd try to give a rationale for this, but I'm not
+@c sure there is a particularly convincing one. What
+@c we would _like_ is for CVS to do a better job of version
+@c controlling whether directories exist, to eliminate the
+@c need for -P and so that a file can be a directory in
+@c one revision and a regular file in another.
+Note that @samp{-P} is implied by the @samp{-r} or @samp{-D}
+options of @code{checkout} and @code{export}. This way
+@sc{cvs} will be able to correctly create the directory
+or not depending on whether the particular version you
+are checking out contains any files in that directory.
+
@c ---------------------------------------------------------------------
@node Tracking sources
@chapter Tracking third-party sources
@cindex Third-party sources
@cindex Tracking sources
+@c FIXME: Need discussion of added and removed files.
If you modify a program to better fit your site, you
probably want to include your modifications when the next
release of the program arrives. @sc{cvs} can help you with
@@ -3083,6 +4926,8 @@ revision.
@menu
* First import:: Importing a module for the first time
* Update imports:: Updating a module with the import command
+* Reverting local changes:: Reverting a module to the latest vendor release
+* Binary files in imports:: Binary files require special handling
@end menu
@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@@ -3090,26 +4935,37 @@ revision.
@section Importing a module for the first time
@cindex Importing modules
+@c Should mention naming conventions for vendor tags,
+@c release tags, and perhaps directory names.
Use the @code{import} command to check in the sources
for the first time. When you use the @code{import}
command to track third-party sources, the @dfn{vendor
tag} and @dfn{release tags} are useful. The
@dfn{vendor tag} is a symbolic name for the branch
(which is always 1.1.1, unless you use the @samp{-b
-@var{branch}} flag---@xref{import options}). The
+@var{branch}} flag---@xref{import options}.). The
@dfn{release tags} are symbolic names for a particular
release, such as @samp{FSF_0_04}.
+@c I'm not completely sure this belongs here. But
+@c we need to say it _somewhere_ reasonably obvious; it
+@c is a common misconception among people first learning CVS
+Note that @code{import} does @emph{not} change the
+directory in which you invoke it. In particular, it
+does not set up that directory as a @sc{cvs} working
+directory; if you want to work with the sources import
+them first and then check them out into a different
+directory (@pxref{Getting the source}).
+
@cindex Wdiff (import example)
-Suppose you use @code{wdiff} (a variant of @code{diff}
-that ignores changes that only involve whitespace), and
-are going to make private modifications that you want
-to be able to use even when new releases are made in
-the future. You start by importing the source to your
-repository:
+Suppose you have the sources to a program called
+@code{wdiff} in a directory @file{wdiff-0.04},
+and are going to make private modifications that you
+want to be able to use even when new releases are made
+in the future. You start by importing the source to
+your repository:
@example
-$ tar xfz wdiff-0.04.tar.gz
$ cd wdiff-0.04
$ cvs import -m "Import of FSF v. 0.04" fsf/wdiff FSF_DIST WDIFF_0_04
@end example
@@ -3117,6 +4973,7 @@ $ cvs import -m "Import of FSF v. 0.04" fsf/wdiff FSF_DIST WDIFF_0_04
The vendor tag is named @samp{FSF_DIST} in the above
example, and the only release tag assigned is
@samp{WDIFF_0_04}.
+@c FIXME: Need to say where fsf/wdiff comes from.
@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node Update imports
@@ -3138,6 +4995,10 @@ revision becomes the head revision. If you have made local
changes, @code{import} will warn you that you must merge the changes
into the main trunk, and tell you to use @samp{checkout -j} to do so.
+@c FIXME: why "wdiff" here and "fsf/wdiff" in the
+@c "import"? I think the assumption is that one has
+@c "wdiff fsf/wdiff" or some such in modules, but it
+@c would be better to not use modules in this example.
@example
$ cvs checkout -jFSF_DIST:yesterday -jFSF_DIST wdiff
@end example
@@ -3161,6 +5022,32 @@ $ cvs checkout -jWDIFF_0_04 -jWDIFF_0_05 wdiff
@noindent
In this case, the two above commands are equivalent.
+@node Reverting local changes
+@section Reverting to the latest vendor release
+
+You can also revert local changes completely and return
+to the latest vendor release by changing the `head'
+revision back to the vendor branch on all files. For
+example, if you have a checked-out copy of the sources
+in @file{~/work.d/wdiff}, and you want to revert to the
+vendor's version for all the files in that directory,
+you would type:
+
+@example
+$ cd ~/work.d/wdiff
+$ cvs admin -bWDIFF .
+@end example
+
+@noindent
+You must specify the @samp{-bWDIFF} without any space
+after the @samp{-b}. @xref{admin options}.
+
+@node Binary files in imports
+@section How to handle binary files with cvs import
+
+Use the @samp{-k} wrapper option to tell import which
+files are binary. @xref{Wrappers}.
+
@c ---------------------------------------------------------------------
@node Moving files
@chapter Moving and renaming files
@@ -3171,7 +5058,7 @@ In this case, the two above commands are equivalent.
Moving files to a different directory or renaming them
is not difficult, but some of the ways in which this
works may be non-obvious. (Moving or renaming a
-directory is even harder. @xref{Moving directories}).
+directory is even harder. @xref{Moving directories}.).
The examples below assume that the file @var{old} is renamed to
@var{new}.
@@ -3186,11 +5073,27 @@ The examples below assume that the file @var{old} is renamed to
@node Outside
@section The Normal way to Rename
+@c More rename issues. Not sure whether these are
+@c worth documenting; I'm putting them here because
+@c it seems to be as good a place as any to try to
+@c set down the issues.
+@c * "cvs annotate" will annotate either the new
+@c file or the old file; it cannot annotate _each
+@c line_ based on whether it was last changed in the
+@c new or old file. Unlike "cvs log", where the
+@c consequences of having to select either the new
+@c or old name seem fairly benign, this may be a
+@c real advantage to having CVS know about renames
+@c other than as a deletion and an addition.
+
The normal way to move a file is to copy @var{old} to
@var{new}, and then issue the normal @sc{cvs} commands
to remove @var{old} from the repository, and add
-@var{new} to it. (Both @var{old} and @var{new} could
-contain relative paths, for example @file{foo/bar.c}).
+@var{new} to it.
+@c The following sentence is not true: one must cd into
+@c the directory to run "cvs add".
+@c (Both @var{old} and @var{new} could
+@c contain relative paths, for example @file{foo/bar.c}).
@example
$ mv @var{old} @var{new}
@@ -3208,8 +5111,9 @@ portion of the history you are accessing. For example,
time of the rename.
When @var{new} is committed its revision numbers will
-start at 1.0 again, so if that bothers you, use the
-@samp{-r rev} option to commit (@pxref{commit options})
+start again, usually at 1.1, so if that bothers you,
+use the @samp{-r rev} option to commit. For more
+information see @ref{Assigning revisions}.
@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node Inside
@@ -3271,9 +5175,9 @@ $ cvs remove @var{old}
$ cvs commit @var{old}
# @r{Remove all tags from @var{new}}
$ cvs update @var{new}
-$ cvs log @var{new} # @r{Remember the tag names}
-$ cvs tag -d @var{tag1}
-$ cvs tag -d @var{tag2}
+$ cvs log @var{new} # @r{Remember the non-branch tag names}
+$ cvs tag -d @var{tag1} @var{new}
+$ cvs tag -d @var{tag2} @var{new}
@dots{}
@end example
@@ -3305,10 +5209,18 @@ Disadvantages:
@item
You cannot easily see the history of the file across the rename.
+@ignore
+@c Is this true? I don't see how the revision numbers
+@c _could_ start over, when new,v is just old,v with
+@c the tags deleted.
+@c If there is some need to reinstate this text,
+@c it is "usually 1.1", not "1.0" and it needs an
+@c xref to Assigning revisions
@item
Unless you use the @samp{-r rev} (@pxref{commit
options}) flag when @var{new} is committed its revision
numbers will start at 1.0 again.
+@end ignore
@end itemize
@c ---------------------------------------------------------------------
@@ -3318,16 +5230,14 @@ numbers will start at 1.0 again.
@cindex Renaming directories
@cindex Directories, moving
-If you want to be able to retrieve old versions of the
-module, you must move each file in the directory
-with the @sc{cvs} commands. @xref{Outside}. The old, empty
-directory will remain inside the repository, but it
-will not appear in your workspace when you check out
-the module in the future.
-@c -- rephrase
+The normal way to rename or move a directory is to
+rename or move each file within it as described in
+@ref{Outside}. Then check out with the @samp{-P}
+option, as described in @ref{Removing directories}.
-If you really want to rename or delete a directory, you
-can do it like this:
+If you really want to hack the repository to rename or
+delete a directory in the repository, you can do it
+like this:
@enumerate
@item
@@ -3430,6 +5340,8 @@ history---what files have changed when, how, and by
whom, there are a variety of mechanisms for looking
through the history.
+@c FIXME: should also be talking about how you look at
+@c old revisions (e.g. "cvs update -p -r 1.2 foo.c").
@menu
* log messages:: Log messages
* history database:: The history database
@@ -3463,6 +5375,63 @@ You can use the history file (@pxref{history file}) to
log various @sc{cvs} actions. To retrieve the
information from the history file, use the @code{cvs
history} command (@pxref{history}).
+@c
+@c The history database has many problems:
+@c * It is very unclear what field means what. This
+@c could be improved greatly by better documentation,
+@c but there are still non-orthogonalities (for
+@c example, tag does not record the "repository"
+@c field but most records do).
+@c * Confusion about files, directories, and modules.
+@c Some commands record one, some record others.
+@c * File removal is not logged. There is an 'R'
+@c record type documented, but CVS never uses it.
+@c * Tags are only logged for the "cvs rtag" command,
+@c not "cvs tag". The fix for this is not completely
+@c clear (see above about modules vs. files).
+@c * Are there other cases of operations that are not
+@c logged? One would hope for all changes to the
+@c repository to be logged somehow (particularly
+@c operations like tagging, "cvs admin -k", and other
+@c operations which do not record a history that one
+@c can get with "cvs log"). Operations on the working
+@c directory, like export, get, and release, are a
+@c second category also covered by the current "cvs
+@c history".
+@c * The history file does not record the options given
+@c to a command. The most serious manifestation of
+@c this is perhaps that it doesn't record whether a command
+@c was recursive. It is not clear to me whether one
+@c wants to log at a level very close to the command
+@c line, as a sort of way of logging each command
+@c (more or less), or whether one wants
+@c to log more at the level of what was changed (or
+@c something in between), but either way the current
+@c information has pretty big gaps.
+@c * Further details about a tag--like whether it is a
+@c branch tag or, if a non-branch tag, which branch it
+@c is on. One can find out this information about the
+@c tag as it exists _now_, but if the tag has been
+@c moved, one doesn't know what it was like at the time
+@c the history record was written.
+@c * Whether operating on a particular tag, date, or
+@c options was implicit (sticky) or explicit.
+@c
+@c Another item, only somewhat related to the above, is a
+@c way to control what is logged in the history file.
+@c This is probably the only good way to handle
+@c different people having different ideas about
+@c information/space tradeoffs.
+@c
+@c It isn't really clear that it makes sense to try to
+@c patch up the history file format as it exists now to
+@c include all that stuff. It might be better to
+@c design a whole new CVSROOT/nhistory file and "cvs
+@c nhistory" command, or some such, or in some other
+@c way trying to come up with a clean break from the
+@c past, which can address the above concerns. Another
+@c open question is how/whether this relates to
+@c taginfo/loginfo/etc.
@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node user-defined logging
@@ -3517,13 +5486,11 @@ aborted.
@section Annotate command
@cindex annotate (subcommand)
-@deffn Command {cvs annotate} [@code{-l}] files @dots{}
+@deffn Command {cvs annotate} [@code{-flR}] [@code{-r rev}|@code{-D date}] files @dots{}
For each file in @var{files}, print the head revision
of the trunk, together with information on the last
-modification for each line. The @code{-l} option means
-to process the local directory only, not to recurse
-(@pxref{Common options}). For example:
+modification for each line. For example:
@example
$ cvs annotate ssfile
@@ -3544,6 +5511,16 @@ or replaced; you need to use @code{cvs diff} for that
@end deffn
+The options to @code{cvs annotate} are listed in
+@ref{Invoking CVS}, and can be used to select the files
+and revisions to annotate. The options are described
+in more detail in @ref{Common options}.
+
+@c FIXME: maybe an example using the options? Just
+@c what it means to select a revision might be worth a
+@c few words of explanation ("you want to see who
+@c changed this line *before* 1.4"...).
+
@c ---------------------------------------------------------------------
@node Keyword substitution
@chapter Keyword substitution
@@ -3609,6 +5586,14 @@ will normally never be locked when you use @sc{cvs}.
Same as @code{$@asis{Header}$}, except that the @sc{rcs}
filename is without a path.
+@cindex Name keyword
+@item $@asis{Name}$
+Tag name used to check out this file.
+@c FIXME: should supply an example (e.g. "if you use
+@c "cvs update -r foo" then Name expands to "foo"). Also
+@c should add Name to testsuite (best way to ensure
+@c that the example is correct!)
+
@cindex Locker keyword
@item $@asis{Locker}$
The login name of the user who locked the revision
@@ -3856,6 +5841,10 @@ contain data which looks like a keyword (@pxref{Keyword
substitution}), so keyword expansion must be turned
off.
+@c FIXME: the third is that one can't do merges with
+@c binary files. xref to Multiple Developers and the
+@c reserved checkout issues.
+
The @samp{-kb} option available with some @sc{cvs}
commands insures that neither line ending conversion
nor keyword expansion will be done. If you are using
@@ -3885,6 +5874,7 @@ $ cvs add -m"A test file" kotest
$ cvs ci -m"First checkin; contains a keyword" kotest
$ cvs admin -kb kotest
$ cvs update -A kotest
+$ cvs commit -m "make it binary" kotest # @r{For non-unix systems}
@end example
When you check in the file @file{kotest} the keywords
@@ -3894,7 +5884,213 @@ admin -kb} command sets the default keyword
substitution method for this file, but it does not
alter the working copy of the file that you have. The
easiest way to get the unexpanded version of
-@file{kotest} is @code{cvs update -A}.
+@file{kotest} is @code{cvs update -A}. If you need to
+cope with line endings (that is, you are using a
+@sc{cvs} client on a non-unix system), then you need to
+check in a new copy of the file, as shown by the
+@code{cvs commit} command above.
+@c FIXME: should also describe what the *other users*
+@c need to do, if they have checked out copies which
+@c have been corrupted by lack of -kb. I think maybe
+@c "cvs update -kb" or "cvs
+@c update -A" would suffice, although the user who
+@c reported this suggested removing the file, manually
+@c removing it from CVS/Entries, and then "cvs update"
+
+However, in using @code{cvs admin -k} to change the
+keyword expansion, be aware that the keyword expansion
+mode is not version controlled. This means that, for
+example, that if you have a text file in old releases,
+and a binary file with the same name in new releases,
+@sc{cvs} provides no way to check out the file in text
+or binary mode depending on what version you are
+checking out. There is no good workaround for this
+problem.
+
+You can also set a default for whether @code{cvs add}
+and @code{cvs import} treat a file as binary based on
+its name; for example you could say that files who
+names end in @samp{.exe} are binary. @xref{Wrappers}.
+There is currently no way to have @sc{cvs} detect
+whether a file is binary based on its contents. The
+main difficulty with designing such a feature is that
+it is not clear how to distinguish between binary and
+non-binary files, and the rules to apply would vary
+considerably with the operating system.
+@c For example, it would be good on MS-DOS-family OSes
+@c for anything containing ^Z to be binary. Having
+@c characters with the 8th bit set imply binary is almost
+@c surely a bad idea in the context of ISO-8859-* and
+@c other such character sets. On VMS or the Mac, we
+@c could use the OS's file typing. This is a
+@c commonly-desired feature, and something of this sort
+@c may make sense. But there are a lot of pitfalls here.
+
+@c I'm not sure about the best location for this. In
+@c one sense, it might belong right after we've introduced
+@c CVS's basic version control model, because people need
+@c to figure out builds right away. The current location
+@c is based on the theory that it kind of akin to the
+@c "Revision management" section.
+@node Builds
+@chapter How your build system interacts with CVS
+@cindex builds
+@cindex make
+
+As mentioned in the introduction, @sc{cvs} does not
+contain software for building your software from source
+code. This section describes how various aspects of
+your build system might interact with @sc{cvs}.
+
+@c Is there a way to discuss this without reference to
+@c tools other than CVS? I'm not sure there is; I
+@c wouldn't think that people who learn CVS first would
+@c even have this concern.
+One common question, especially from people who are
+accustomed to @sc{rcs}, is how to make their build get
+an up to date copy of the sources. The answer to this
+with @sc{cvs} is two-fold. First of all, since
+@sc{cvs} itself can recurse through directories, there
+is no need to modify your @file{Makefile} (or whatever
+configuration file your build tool uses) to make sure
+each file is up to date. Instead, just use two
+commands, first @code{cvs -q update} and then
+@code{make} or whatever the command is to invoke your
+build tool. Secondly, you do not necessarily
+@emph{want} to get a copy of a change someone else made
+until you have finished your own work. One suggested
+approach is to first update your sources, then
+implement, build and
+test the change you were thinking of, and then commit
+your sources (updating first if necessary). By
+periodically (in between changes, using the approach
+just described) updating your entire tree, you ensure
+that your sources are sufficiently up to date.
+
+@cindex bill of materials
+One common need is to record which versions of which
+source files went into a particular build. This kind
+of functionality is sometimes called @dfn{bill of
+materials} or something similar. The best way to do
+this with @sc{cvs} is to use the @code{tag} command to
+record which versions went into a given build
+(@pxref{Tags}).
+
+Using @sc{cvs} in the most straightforward manner
+possible, each developer will have a copy of the entire
+source tree which is used in a particular build. If
+the source tree is small, or if developers are
+geographically dispersed, this is the preferred
+solution. In fact one approach for larger projects is
+to break a project down into smaller
+@c I say subsystem instead of module because they may or
+@c may not use the modules file.
+separately-compiled subsystems, and arrange a way of
+releasing them internally so that each developer need
+check out only those subsystems which are they are
+actively working on.
+
+Another approach is to set up a structure which allows
+developers to have their own copies of some files, and
+for other files to access source files from a central
+location. Many people have come up with some such a
+@c two such people are paul@sander.cupertino.ca.us (for
+@c a previous employer)
+@c and gtornblo@senet.abb.se (spicm and related tools),
+@c but as far as I know
+@c noone has nicely packaged or released such a system (or
+@c instructions for constructing one).
+system using features such as the symbolic link feature
+found in many operating systems, or the @code{VPATH}
+feature found in many versions of @code{make}. One build
+tool which is designed to help with this kind of thing
+is Odin (see
+@code{ftp://ftp.cs.colorado.edu/pub/distribs/odin}).
+@c Should we be saying more about Odin? Or how you use
+@c it with CVS? Also, the Prime Time Freeware for Unix
+@c disk (see http://www.ptf.com/) has Odin (with a nice
+@c paragraph summarizing it on the web), so that might be a
+@c semi-"official" place to point people.
+@c
+@c Of course, many non-CVS systems have this kind of
+@c functionality, for example OSF's ODE
+@c (http://www.osf.org/ode/) or mk
+@c (http://www.io.org/~pzi/heading.html;
+@c ftp://ftp.interlog.com/pub/unix/mk is out of date). But I'm not sure
+@c there is any point in mentioning them here unless they
+@c can work with CVS.
+
+@node Compatibility
+@chapter Compatibility between CVS Versions
+
+@cindex CVS, versions of
+@cindex versions, of CVS
+@cindex compatibility, between CVS versions
+@c We don't mention versions older than CVS 1.3
+@c on the theory that it would clutter it up for the vast
+@c majority of people, who don't have anything that old.
+@c
+The repository format is compatible going back to
+@sc{cvs} 1.3. But see @ref{Watches Compatibility}, if
+you have copies of @sc{cvs} 1.6 or older and you want
+to use the optional developer communication features.
+@c If you "cvs rm" and commit using 1.3, then you'll
+@c want to run "rcs -sdead <file,v>" on each of the
+@c files in the Attic if you then want 1.5 and
+@c later to recognize those files as dead (I think the
+@c symptom if this is not done is that files reappear
+@c in joins). (Wait: the above will work but really to
+@c be strictly correct we should suggest checking
+@c in a new revision rather than just changing the
+@c state of the head revision, shouldn't we?).
+@c The old convert.sh script was for this, but it never
+@c did get updated to reflect use of the RCS "dead"
+@c state.
+@c Note: this is tricky to document without confusing
+@c people--need to carefully say what CVS version we
+@c are talking about and keep in mind the distinction
+@c between a
+@c repository created with 1.3 and on which one now
+@c uses 1.5+, and a repository on which one wants to
+@c use both versions side by side (e.g. during a
+@c transition period).
+@c We might want to separate out the 1.3 compatibility
+@c section (for repository & working directory) from the
+@c rest--that might help avoid confusing people who
+@c are upgrading (for example) from 1.6 to 1.8.
+@c
+@c A minor incompatibility is if a current version of CVS
+@c puts "Nfoo" into CVS/Tag, then CVS 1.9 or older will
+@c see this as if there is no tag. Seems to me this is
+@c too obscure to mention.
+
+The working directory format is compatible going back
+to @sc{cvs} 1.5. It did change between @sc{cvs} 1.3
+and @sc{cvs} 1.5. If you run @sc{cvs} 1.5 or newer on
+a working directory checked out with @sc{cvs} 1.3,
+@sc{cvs} will convert it, but to go back to @sc{cvs}
+1.3 you need to check out a new working directory with
+@sc{cvs} 1.3.
+
+The remote protocol is interoperable going back to @sc{cvs} 1.5, but no
+further (1.5 was the first official release with the remote protocol,
+but some older versions might still be floating around). In many
+cases you need to upgrade both the client and the server to take
+advantage of new features and bugfixes, however.
+
+@c Perhaps should be saying something here about the
+@c "D" lines in Entries (written by CVS 1.9; 1.8 and
+@c older don't use them). These are supposed to be
+@c compatible in both directions, but I'm not sure
+@c they quite are 100%. One common gripe is if you
+@c "rm -r" a directory and 1.9 gets confused, as it
+@c still sees it in Entries. That one is fixed in
+@c (say) 1.9.6. Someone else reported problems with
+@c starting with a directory which was checked out with
+@c an old version, and then using a new version, and
+@c some "D" lines appeared, but not for every
+@c directory, causing some directories to be skipped.
+@c They weren't sure how to reproduce this, though.
@c ---------------------------------------------------------------------
@node Revision management
@@ -3949,35 +6145,35 @@ too regimented and thus counter-productive to the real
goal, which is to get software written.
@c ---------------------------------------------------------------------
-@node Invoking CVS
-@appendix Reference manual for CVS commands
-@cindex Command reference
-@cindex Reference, commands
-@cindex Invoking CVS
-
-This appendix describes how to invoke @sc{cvs}, and
-describes in detail those subcommands of @sc{cvs} which
-are not fully described elsewhere. To look up a
-particular subcommand, see @ref{Index}.
+@node CVS commands
+@appendix Guide to CVS commands
+
+This appendix describes the overall structure of
+@sc{cvs} commands, and describes some commands in
+detail (others are described elsewhere; for a quick
+reference to @sc{cvs} commands, @pxref{Invoking CVS}).
+@c The idea is that we want to move the commands which
+@c are described here into the main body of the manual,
+@c in the process reorganizing the manual to be
+@c organized around what the user wants to do, not
+@c organized around CVS commands.
@menu
* Structure:: Overall structure of CVS commands
* ~/.cvsrc:: Default options with the ~/.csvrc file
* Global options:: Options you give to the left of cvs_command
* Common options:: Options you give to the right of cvs_command
-* add:: Add a new file/directory to the repository
* admin:: Administration front end for rcs
* checkout:: Checkout sources for editing
* commit:: Check files into the repository
-* diff:: Run diffs between revisions
+* diff:: Show differences between revisions
* export:: Export sources from CVS, similar to checkout
* history:: Show status of files and users
* import:: Import sources into CVS, using vendor branches
-* log:: Print out 'rlog' information for files
+* log:: Show log messages for files
* rdiff:: 'patch' format diffs between releases
* release:: Indicate that a Module is no longer in use
* rtag:: Add a tag to a module
-* status:: Status info on the revisions
* tag:: Add a tag to checked out version
* update:: Bring work tree in sync with repository
@end menu
@@ -3990,10 +6186,7 @@ particular subcommand, see @ref{Index}.
@cindex Command structure
@cindex Format of CVS commands
-The first release of @sc{cvs} consisted of a number of shell-scripts.
-Today @sc{cvs} is implemented as a single program that is a front-end
-to @sc{rcs} and @code{diff}. The overall format of all
-@sc{cvs} commands is:
+The overall format of all @sc{cvs} commands is:
@example
cvs [ cvs_options ] cvs_command [ command_options ] [ command_args ]
@@ -4001,7 +6194,7 @@ cvs [ cvs_options ] cvs_command [ command_options ] [ command_args ]
@table @code
@item cvs
-The program that is a front-end to @sc{rcs}.
+The name of the @sc{cvs} program.
@item cvs_options
Some options that affect all sub-commands of @sc{cvs}. These are
@@ -4113,6 +6306,14 @@ located. Overrides the setting of the @code{$RCSBIN} environment
variable and any precompiled directory. This parameter should be
specified as an absolute pathname.
+@cindex TMPDIR, overriding
+@cindex Overriding TMPDIR
+@item -T @var{tempdir}
+Use @var{tempdir} as the directory where temporary files are
+located. Overrides the setting of the @code{$TMPDIR} environment
+variable and any precompiled directory. This parameter should be
+specified as an absolute pathname.
+
@cindex CVSROOT, overriding
@cindex Overriding CVSROOT
@item -d @var{cvs_root_directory}
@@ -4124,7 +6325,9 @@ the @code{$CVSROOT} environment variable. @xref{Repository}.
@cindex Overriding EDITOR
@item -e @var{editor}
Use @var{editor} to enter revision log information. Overrides the
-setting of the @code{$CVSEDITOR} and @code{$EDITOR} environment variables.
+setting of the @code{$CVSEDITOR} and @code{$EDITOR}
+environment variables. For more information, see
+@ref{Committing your changes}.
@item -f
Do not read the @file{~/.cvsrc} file. This
@@ -4133,16 +6336,19 @@ non-orthogonality of the @sc{cvs} option set. For
example, the @samp{cvs log} option @samp{-N} (turn off
display of tag names) does not have a corresponding
option to turn the display on. So if you have
-@samp{-N} in the @file{~/.cvsrc} entry for @samp{diff},
+@samp{-N} in the @file{~/.cvsrc} entry for @samp{log},
you may need to use @samp{-f} to show the tag names.
-@footnote{Yes, this really should be fixed, and it's
-being worked on}
@item -H
+@itemx --help
Display usage information about the specified @samp{cvs_command}
(but do not actually execute the command). If you don't specify
-a command name, @samp{cvs -H} displays a summary of all the
-commands available.
+a command name, @samp{cvs -H} displays overall help for
+@sc{cvs}, including a list of other help options.
+@c It seems to me it is better to document it this way
+@c rather than trying to update this documentation
+@c every time that we add a --help-foo option. But
+@c perhaps that is confusing...
@item -l
Do not log the cvs_command in the command history (but execute it
@@ -4163,7 +6369,7 @@ Cause the command to be somewhat quiet; informational messages,
such as reports of recursion through subdirectories, are
suppressed.
-@cindex Read-only files
+@cindex read-only files, and -r
@item -r
Make new working files files read-only. Same effect
as if the @code{$CVSREAD} environment variable is set
@@ -4181,6 +6387,7 @@ Trace program execution; display messages showing the steps of
potential impact of an unfamiliar command.
@item -v
+@item --version
Display version and copyright information for @sc{cvs}.
@cindex CVSREAD, overriding
@@ -4191,6 +6398,15 @@ setting of the @code{$CVSREAD} environment variable.
Files are created read-write by default, unless @code{$CVSREAD} is
set or @samp{-r} is given.
+@item -x
+Encrypt all communication between the client and the
+server. Only has an effect on the @sc{cvs} client. As
+of this writing, this is only implemented when using a
+Kerberos connection (@pxref{Kerberos authenticated}).
+Encryption support is not available by default; it must
+be enabled using a special configure option,
+@file{--enable-encryption}, when you build @sc{cvs}.
+
@item -z @var{gzip-level}
Set the compression level. Only has an effect on the
@sc{cvs} client.
@@ -4233,30 +6449,152 @@ file using @samp{-D}, @sc{cvs} records the date you specified, so that
further updates in the same directory will use the same date
(for more information on sticky tags/dates, @pxref{Sticky tags}).
-A wide variety of date formats are supported by the underlying
-@sc{rcs} facilities, similar to those described in co(1), but not
-exactly the same. The @var{date_spec} is interpreted as being
-in the local timezone, unless a specific timezone is specified.
-Examples of valid date specifications include:
-
-@example
- 1 month ago
- 2 hours ago
- 400000 seconds ago
- last year
- last Monday
- yesterday
- a fortnight ago
- 3/31/92 10:00:07 PST
- January 23, 1987 10:05pm
- 22:00 GMT
-@end example
-
@samp{-D} is available with the @code{checkout},
@code{diff}, @code{export}, @code{history},
@code{rdiff}, @code{rtag}, and @code{update} commands.
(The @code{history} command uses this option in a
-slightly different way; @pxref{history options}).
+slightly different way; @pxref{history options}).
+
+@c What other formats should we accept? I don't want
+@c to start accepting a whole mess of non-standard
+@c new formats (there are a lot which are in wide use in
+@c one context or another), but practicality does
+@c dictate some level of flexibility.
+@c * POSIX.2 (e.g. touch, ls output, date) and other
+@c POSIX and/or de facto unix standards (e.g. at). The
+@c practice here is too inconsistent to be of any use.
+@c * VMS dates. This is not a formal standard, but
+@c there is a published specification (see SYS$ASCTIM
+@c and SYS$BINTIM in the _VMS System Services Reference
+@c Manual_), it is implemented consistently in VMS
+@c utilities, and VMS users will expect CVS running on
+@c VMS to support this format (and if we're going to do
+@c that, better to make CVS support it on all
+@c platforms. Maybe).
+@c
+@c NOTE: The tar manual has some documentation for
+@c getdate.y (just for our info; we don't want to
+@c attempt to document all the formats accepted by
+@c getdate.y).
+@c
+@c One more note: In output, CVS should consistently
+@c use one date format, and that format should be one that
+@c it accepts in input as well. The former isn't
+@c really true (see survey below), and I'm not
+@c sure that either of those formats is accepted in
+@c input.
+@c
+@c cvs log
+@c current 1996/01/02 13:45:31
+@c Internet 02 Jan 1996 13:45:31 UT
+@c ISO 1996-01-02 13:45:31
+@c cvs ann
+@c current 02-Jan-96
+@c Internet-like 02 Jan 96
+@c ISO 96-01-02
+@c cvs status
+@c current Tue Jun 11 02:54:53 1996
+@c Internet [Tue,] 11 Jun 1996 02:54:53
+@c ISO 1996-06-11 02:54:53
+@c note: date possibly should be omitted entirely for
+@c other reasons.
+@c cvs editors
+@c current Tue Jun 11 02:54:53 1996 GMT
+@c cvs history
+@c current 06/11 02:54 +0000
+@c any others?
+@c There is a good chance the proper solution has to
+@c involve at least some level of letting the user
+@c decide which format (with the default being the
+@c formats CVS has always used; changing these might be
+@c _very_ disruptive since scripts may very well be
+@c parsing them).
+@c
+@c Another random bit of prior art concerning dates is
+@c the strptime function which takes templates such as
+@c "%m/%d/%y", and apparent a variant of getdate()
+@c which also honors them. See
+@c X/Open CAE Specification, System Interfaces and
+@c Headers Issue 4, Version 2 (September 1994), in the
+@c entry for getdate() on page 231
+
+@cindex timezone, in input
+@cindex zone, time, in input
+A wide variety of date formats are supported by
+@sc{cvs}. The most standard ones are ISO8601 (from the
+International Standards Organization) and the Internet
+e-mail standard (specified in RFC822 as amended by
+RFC1123).
+
+@c Probably should be doing more to spell out just what
+@c the rules are, rather than just giving examples.
+@c But I want to keep this simple too.
+@c So I don't know....
+@c A few specific issues: (1) Maybe should reassure
+@c people that years after 2000
+@c work (they are in the testsuite, so they do indeed
+@c work). (2) What do two digit years
+@c mean? Where do we accept them? (3) Local times can
+@c be ambiguous or nonexistent if they fall during the
+@c hour when daylight savings time goes into or out of
+@c effect. Pretty obscure, so I'm not at all sure we
+@c should be documenting the behavior in that case.
+ISO8601 dates have many variants but a few examples
+are:
+
+@example
+1972-09-24
+1972-09-24 20:05
+@end example
+@c I doubt we really accept all ISO8601 format dates
+@c (for example, decimal hours like 1972-09-24 20,2)
+@c I'm not sure we should, many of them are pretty
+@c bizarre and it has lots of gratuitous multiple ways
+@c to specify the same thing.
+
+For more details about ISO8601 dates, see:
+
+@example
+http://www.ft.uni-erlangen.de/~mskuhn/iso-time.html
+@end example
+@c Perhaps we want to also cite other sources in
+@c case that page goes away. For example:
+@c http://www.saqqara.demon.co.uk/datefmt.htm
+
+In addition to the dates allowed in Internet e-mail
+itself, @sc{cvs} also allows some of the fields to be
+omitted. For example:
+@c FIXME: Need to figure out better, and document,
+@c what we want to allow the user to omit.
+@c NOTE: "omit" does not imply "reorder".
+@c FIXME: Need to cite a web page describing how to get
+@c RFC's.
+
+@example
+24 Sep 1972 20:05
+24 Sep
+@end example
+
+The date is interpreted as being in the
+local timezone, unless a specific timezone is
+specified.
+
+These two date formats are preferred. However,
+@sc{cvs} currently accepts a wide variety of other date
+formats. They are intentionally not documented here in
+any detail, and future versions of @sc{cvs} might not
+accept all of them.
+@c Maybe at
+@c some point have CVS start give warnings on "unofficial"
+@c formats (many of which might be typos or user
+@c misunderstandings, and/or formats people never/rarely
+@c use to specify dates)?
+
+One such format is
+@code{@var{month}/@var{day}/@var{year}}. This may
+confuse people who are accustomed to having the month
+and day in the other order; @samp{1/4/96} is January 4,
+not April 1.
Remember to quote the argument to the @samp{-D}
flag so that your shell doesn't interpret spaces as
@@ -4277,17 +6615,14 @@ tag or date. (The most recent revision of the file
will be used).
@need 800
-@samp{-f} is available with these commands: @code{checkout},
-@code{export}, @code{rdiff}, @code{rtag}, and @code{update}.
+@samp{-f} is available with these commands:
+@code{annotate}, @code{checkout}, @code{export},
+@code{rdiff}, @code{rtag}, and @code{update}.
@strong{Warning:} The @code{commit} command also has a
@samp{-f} option, but it has a different behavior for
that command. @xref{commit options}.
-@item -H
-Help; describe the options available for this command. This is
-the only option supported for all @sc{cvs} commands.
-
@item -k @var{kflag}
Alter the default @sc{rcs} processing of keywords.
@xref{Keyword substitution}, for the meaning of
@@ -4300,7 +6635,7 @@ file, and continues to use it with future update
commands on the same file until you specify otherwise.
The @samp{-k} option is available with the @code{add},
-@code{checkout}, @code{diff} and
+@code{checkout}, @code{diff}, @code{import} and
@code{update} commands.
@item -l
@@ -4311,10 +6646,11 @@ recursing through subdirectories.
as the overall @samp{cvs -l} option, which you can specify to the
left of a cvs command!
-Available with the following commands: @code{checkout},
-@code{commit}, @code{diff}, @code{export}, @code{log},
-@code{remove}, @code{rdiff}, @code{rtag},
-@code{status}, @code{tag}, and @code{update}.
+Available with the following commands: @code{annotate}, @code{checkout},
+@code{commit}, @code{diff}, @code{edit}, @code{editors}, @code{export},
+@code{log}, @code{rdiff}, @code{remove}, @code{rtag},
+@code{status}, @code{tag}, @code{unedit}, @code{update}, @code{watch},
+and @code{watchers}.
@cindex Editor, avoiding invocation of
@cindex Avoiding editor invocation
@@ -4337,28 +6673,21 @@ Available with the @code{checkout}, @code{commit}, @code{export},
and @code{rtag} commands.
@item -P
-Prune (remove) directories that are empty after being updated, on
-@code{checkout}, or @code{update}. Normally, an empty directory
-(one that is void of revision-controlled files) is left alone.
-Specifying @samp{-P} will cause these directories to be silently
-removed from your checked-out sources. This does not remove the
-directory from the repository, only from your checked out copy.
-Note that this option is implied by the @samp{-r} or @samp{-D}
-options of @code{checkout} and @code{export}.
-@c -- implied--
+Prune empty directories. See @xref{Removing directories}.
@item -p
Pipe the files retrieved from the repository to standard output,
rather than writing them in the current directory. Available
with the @code{checkout} and @code{update} commands.
-@item -W
-Specify file names that should be filtered. You can
-use this option repeatedly. The spec can be a file
-name pattern of the same type that you can specify in
-the @file{.cvswrappers} file.
-Avaliable with the following commands: @code{import},
-and @code{update}.
+@item -R
+Process directories recursively. This is on by default.
+
+Available with the following commands: @code{annotate}, @code{checkout},
+@code{commit}, @code{diff}, @code{edit}, @code{editors}, @code{export},
+@code{rdiff}, @code{remove}, @code{rtag},
+@code{status}, @code{tag}, @code{unedit}, @code{update}, @code{watch},
+and @code{watchers}.
@item -r @var{tag}
Use the revision specified by the @var{tag} argument instead of the
@@ -4368,7 +6697,28 @@ always available: @samp{HEAD} refers to the most recent version
available in the repository, and @samp{BASE} refers to the
revision you last checked out into the current working directory.
-The tag specification is sticky when you use this option
+@c FIXME: What does HEAD really mean? I believe that
+@c the current answer is the head of the default branch
+@c for all cvs commands except diff. For diff, it
+@c seems to be (a) the head of the trunk (or the default
+@c branch?) if there is no sticky tag, (b) the head of the
+@c branch if there is a branch sticky tag, and (c) the
+@c same as BASE if there is a non-branch sticky tag. (c)
+@c would appear to be strange, maybe accidental, and so there would
+@c presumably be
+@c little problem changing it. (b) is ugly as it differs
+@c from what HEAD means for other commands, but people
+@c might be used to it (note a change in NEWS? Or provide
+@c advance warning of it changing?) and possible useful
+@c (could be fixed by a new tag ".bhead" which would mean
+@c the head of the appropriate branch). This
+@c should be investigated, test cases written, and
+@c documented (but HEAD should mean the same thing for all
+@c CVS commands, so I don't know if we should be
+@c documenting the current "cvs diff" behavior).
+
+The tag specification is sticky when you use this
+@c option
with @code{checkout} or @code{update} to make your own
copy of a file: @sc{cvs} remembers the tag and continues to use it on
future update commands, until you specify otherwise (for more information
@@ -4388,128 +6738,16 @@ which you can specify to the left of a cvs command!
@code{diff}, @code{history}, @code{export}, @code{rdiff},
@code{rtag}, and @code{update} commands.
-@end table
-
-@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-@node add
-@appendixsec add---Add a new file/directory to the repository
-@cindex Add (subcommand)
-
-@itemize @bullet
-@item
-Synopsis: add [-k kflag] [-m 'message'] files@dots{}
-@item
-Requires: repository, working directory.
-@item
-Changes: working directory.
-@item
-Synonym: new
-@end itemize
-
-Use the @code{add} command to create a new file or directory in the
-source repository. The files or directories specified with @code{add}
-must already exist in the current directory (which must have been
-created with the @code{checkout} command). To add a whole new directory
-hierarchy to the source repository (for example, files received
-from a third-party vendor), use the @code{import} command
-instead. @xref{import}.
-
-If the argument to @code{add} refers to an immediate
-sub-directory, the directory is created at the correct place in
-the source repository, and the necessary @sc{cvs} administration
-files are created in your working directory. If the directory
-already exists in the source repository, @code{add} still creates
-the administration files in your version of the directory.
-This allows you to use @code{add} to add a particular directory
-to your private sources even if someone else created that
-directory after your checkout of the sources. You can do the
-following:
-
-@example
-$ mkdir new_directory
-$ cvs add new_directory
-$ cvs update new_directory
-@end example
-
-An alternate approach using @code{update} might be:
-
-@example
-$ cvs update -d new_directory
-@end example
-
-(To add any available new directories to your working directory,
-it's probably simpler to use @code{checkout} (@pxref{checkout})
-or @samp{update -d} (@pxref{update})).
-
-The added files are not placed in the source repository until you
-use @code{commit} to make the change permanent. Doing an
-@code{add} on a file that was removed with the @code{remove}
-command will resurrect the file, unless a @code{commit} command
-intervened.
-@xref{Removing files}, for an example.
-
-
-Unlike most other commands @code{add} never recurses down
-directories. It cannot yet handle relative paths. Instead of
-
-@example
-$ cvs add foo/bar.c
-@end example
-
-you have to do
-
-@example
-$ cd foo
-$ cvs add bar.c
-@end example
-
-@menu
-* add options:: add options
-* add examples:: add examples
-@end menu
-
-@c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
-@node add options
-@appendixsubsec add options
-@cindex Add options
-
-There are only two options you can give to @samp{add}:
+@item -W
+Specify file names that should be filtered. You can
+use this option repeatedly. The spec can be a file
+name pattern of the same type that you can specify in
+the @file{.cvswrappers} file.
+Avaliable with the following commands: @code{import},
+and @code{update}.
-@table @code
-@item -k @var{kflag}
-This option specifies the default way that this file
-will be checked out. The @var{kflag} argument
-(@pxref{Substitution modes}) is stored in the @sc{rcs}
-file and can be changed with @code{admin -k}
-(@pxref{admin options}). See @ref{Binary files}, for
-information on using this option for binary files.
-
-@item -m @var{description}
-Using this option, you can give a description for the file. This
-description appears in the history log (if it is enabled,
-@pxref{history file}). It will also be saved in the @sc{rcs} history
-file inside the repository when the file is committed. The
-@code{log} command displays this description.
-
-The description can be changed using @samp{admin -t}.
-@xref{admin}.
-
-If you omit the @samp{-m @var{description}} flag, an empty string will be
-used. You will not be prompted for a description.
@end table
-@c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
-@node add examples
-@appendixsubsec add examples
-
-To add the file @file{backend.c} to the repository, with a
-description, the following can be used.
-
-@example
-$ cvs add -m "Optimizer and code generation passes." backend.c
-$ cvs commit -m "Early version. Not yet compilable." backend.c
-@end example
-
@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node admin
@appendixsec admin---Administration front end for rcs
@@ -4530,6 +6768,9 @@ all its options and arguments to the @code{rcs} command; it does
no filtering or other processing. This command @emph{does} work
recursively, however, so extreme care should be used.
+@c "group" should probably read "unix group" (but what
+@c does NT local do?). "compiled in value" is
+@c unclear--compiled in to what?
If there is a group whose name matches a compiled in
value which defaults to @code{cvsadmin}, only members
of that group can use @code{cvs admin}. To disallow
@@ -4551,7 +6792,7 @@ with @sc{cvs}. Some even makes it impossible to use
This description of the available options is based on
the @samp{rcs(1)} man page, but modified to suit
-readers that are more interrested in @sc{cvs} than
+readers that are more interested in @sc{cvs} than
@sc{rcs}.
@table @code
@@ -4569,12 +6810,10 @@ login names appearing in the comma-separated list
When used with bare @sc{rcs}, this
option sets the default branch to @var{rev}; in
@sc{cvs} sticky tags (@pxref{Sticky tags}) are a better
-way to decide which branch you want to work on. With
-@sc{cvs}, this option can be used to control behavior
-with respect to the vendor branch.
-@c FIXME: document how you use it with the vendor
-@c branch (or fix cvs so that there is a more graceful
-@c way to handle the case).
+way to decide which branch you want to work on. There
+is one use with @sc{cvs}: to revert to the vendor's
+version when using vendor branches (@pxref{Reverting
+local changes}).
@item -c@var{string}
Useful with @sc{cvs}. Sets the comment leader to
@@ -4592,6 +6831,8 @@ names appearing in the comma-separated list
@var{logins} from the access list of the RCS file. If
@var{logins} is omitted, erase the entire access list.
+@c FIXME: Doesn't work with client/server CVS; we
+@c should probably just not accept the option.
@item -I
Run interactively, even if the standard input is not a
terminal.
@@ -4608,8 +6849,6 @@ substitution}. Giving an explicit @samp{-k} option to
@code{cvs update}, @code{cvs export}, or @code{cvs
checkout} overrides this default.
-@cindex Reserved checkouts
-@cindex RCS-style locking
@item -l[@var{rev}]
Lock the revision with number @var{rev}. If a branch
is given, lock the latest revision on that branch. If
@@ -4846,6 +7085,8 @@ collection of source directories and files, or paths to
directories or files in the repository. The symbolic
names are defined in the @samp{modules} file.
@xref{modules}.
+@c Needs an example, particularly of the non-"modules"
+@c case but probably of both.
Depending on the modules you specify, @code{checkout} may
recursively create directories and populate them with
@@ -4884,6 +7125,9 @@ to the @code{update} command, that is, any new
directories that have been created in the repository
will appear in your work area. @xref{update}.
+For the output produced by the @code{checkout} command
+see @ref{update output}.
+
@menu
* checkout options:: checkout options
* checkout examples:: checkout examples
@@ -4914,7 +7158,8 @@ Process @sc{rcs} keywords according to @var{kflag}. See
co(1). This option is sticky; future updates of
this file in this working directory will use the same
@var{kflag}. The @code{status} command can be viewed
-to see the sticky options. @xref{status}.
+to see the sticky options. See @ref{Invoking CVS}, for
+more information on the @code{status} command.
@item -l
Local; run only in current working directory.
@@ -4925,11 +7170,14 @@ with the @samp{-o} option in the modules file;
@pxref{modules}).
@item -P
-Prune empty directories.
+Prune empty directories. See @ref{Moving directories}.
@item -p
Pipe files to the standard output.
+@item -R
+Checkout directories recursively. This option is on by default.
+
@item -r @var{tag}
Use revision @var{tag}. This option is sticky, and implies @samp{-P}.
See @ref{Sticky tags}, for more information on sticky tags/dates.
@@ -4948,11 +7196,18 @@ Copy the module file, sorted, to the standard output,
instead of creating or modifying any files or
directories in your working directory.
+@c Should clarify whether dir can specify a
+@c subdirectory (for example "foo/bar"). As of May,
+@c 1996, it is said to work for local CVS if the parent
+@c directories already exist, and not at all for remote
+@c CVS. The remote CVS behavior at least seems like it
+@c is clearly a bug.
@item -d @var{dir}
Create a directory called @var{dir} for the working
files, instead of using the module name. Unless you
also use @samp{-N}, the paths created under @var{dir}
will be as short as possible.
+@c FIXME: What the #$@!#$# does "short as possible" mean?
@item -j @var{tag}
With two @samp{-j} options, merge changes from the
@@ -5014,12 +7269,8 @@ $ cvs checkout -D yesterday tc
@itemize @bullet
@item
-Version 1.3 Synopsis: commit [-lnR] [-m 'log_message' |
--f file] [-r revision] [files@dots{}]
-@item
-Version 1.3.1 Synopsis: commit [-lnRf] [-m 'log_message' |
+Synopsis: commit [-lnRf] [-m 'log_message' |
-F file] [-r revision] [files@dots{}]
-@c -- rename-f-F--
@item
Requires: working directory, repository.
@item
@@ -5028,11 +7279,6 @@ Changes: repository.
Synonym: ci
@end itemize
-@strong{Warning:} The @samp{-f @var{file}} option will
-probably be renamed to @samp{-F @var{file}}, and @samp{-f}
-will be given a new behavior in future releases of @sc{cvs}.
-@c -- rename-f-F--
-
Use @code{commit} when you want to incorporate changes
from your working source files into the source
repository.
@@ -5064,8 +7310,7 @@ repository. This log message can be retrieved with the
@code{log} command; @xref{log}. You can specify the
log message on the command line with the @samp{-m
@var{message}} option, and thus avoid the editor invocation,
-or use the @samp{-f @var{file}} option to specify
-@c -- rename-f-F--
+or use the @samp{-F @var{file}} option to specify
that the argument file contains the log message.
@menu
@@ -5094,22 +7339,21 @@ Commit directories recursively. This is on by default.
@item -r @var{revision}
Commit to @var{revision}. @var{revision} must be
either a branch, or a revision on the main trunk that
-is higher than any existing revision number. You
+is higher than any existing revision number
+(@pxref{Assigning revisions}). You
cannot commit to a specific revision on a branch.
+@c FIXME: Need xref for branch case.
@end table
@code{commit} also supports these options:
@table @code
@item -F @var{file}
-This option is present in @sc{cvs} releases 1.3-s3 and
-later. Read the log message from @var{file}, instead
+Read the log message from @var{file}, instead
of invoking an editor.
@item -f
-@c -- rename-f-F--
-This option is present in @sc{cvs} 1.3-s3 and later releases
-of @sc{cvs}. Note that this is not the standard behavior of
+Note that this is not the standard behavior of
the @samp{-f} option as defined in @xref{Common options}.
Force @sc{cvs} to commit a new revision even if you haven't
@@ -5122,14 +7366,12 @@ $ cvs commit -f @var{file}
$ cvs commit -r 1.8 @var{file}
@end example
-@item -f @var{file}
-@c -- rename-f-F--
-This option is present in @sc{cvs} releases 1.3, 1.3-s1 and
-1.3-s2. Note that this is not the standard behavior of
-the @samp{-f} option as defined in @xref{Common options}.
-
-Read the log message from @var{file}, instead
-of invoking an editor.
+@c This is odd, but it's how CVS has worked for some
+@c time.
+The @samp{-f} option disables recursion (i.e., it
+implies @samp{-l}). To force @sc{cvs} to commit a new
+revision for all files in all subdirectories, you must
+use @samp{-f -R}.
@item -m @var{message}
Use @var{message} as the log message, instead of
@@ -5141,36 +7383,6 @@ invoking an editor.
@node commit examples
@appendixsubsec commit examples
-@appendixsubsubsec New major release number
-
-When you make a major release of your product, you
-might want the revision numbers to track your major
-release number. You should normally not care about
-the revision numbers, but this is a thing that many
-people want to do, and it can be done without doing any
-harm.
-
-To bring all your files up to the @sc{rcs} revision 3.0
-(including those that haven't changed), you might do:
-
-@example
-$ cvs commit -r 3.0
-@end example
-
-Note that it is generally a bad idea to try to make the
-@sc{rcs} revision number equal to the current release number
-of your product. You should think of the revision
-number as an internal number that the @sc{cvs} package
-maintains, and that you generally never need to care
-much about. Using the @code{tag} and @code{rtag}
-commands you can give symbolic names to the releases
-instead. @xref{tag} and @xref{rtag}.
-
-Note that the number you specify with @samp{-r} must be
-larger than any existing revision number. That is, if
-revision 3.0 exists, you cannot @samp{cvs commit
--r 1.3}.
-
@appendixsubsubsec Committing to a branch
You can commit to a branch revision (one that has an
@@ -5249,12 +7461,12 @@ $ cvs checkout -r EXPR1 whatever_module
@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node diff
-@appendixsec diff---Run diffs between revisions
+@appendixsec diff---Show differences between revisions
@cindex Diff (subcommand)
@itemize @bullet
@item
-Synopsis: diff [-l] [rcsdiff_options] [[-r rev1 | -D date1] [-r rev2 | -D date2]] [files@dots{}]
+Synopsis: diff [-lR] [rcsdiff_options] [[-r rev1 | -D date1] [-r rev2 | -D date2]] [files@dots{}]
@item
Requires: working directory, repository.
@item
@@ -5292,14 +7504,6 @@ them):
Use the most recent revision no later than @var{date}.
See @samp{-r} for how this affects the comparison.
-@sc{cvs} can be configured to pass the @samp{-D} option
-through to @code{rcsdiff} (which in turn passes it on
-to @code{diff}. @sc{Gnu} diff uses @samp{-D} as a way to
-put @code{cpp}-style @samp{#define} statements around the output
-differences. There is no way short of testing to
-figure out how @sc{cvs} was configured. In the default
-configuration @sc{cvs} will use the @samp{-D @var{date}} option.
-
@item -k @var{kflag}
Process @sc{rcs} keywords according to @var{kflag}. See
co(1).
@@ -5323,18 +7527,72 @@ outcome in any way).
One or both @samp{-r} options can be replaced by a
@samp{-D @var{date}} option, described above.
+
+@item --ifdef=@var{arg}
+Output in ifdef format. Consult the documentation of
+your underlying diff program concerning the @samp{-D}
+option to diff, for more information on this format.
@end table
-Any other options that are found are passed through to
+@c FIXME? Probably should document -c here, and
+@c perhaps arrange for CVS to support it via a diff library or
+@c some such. Or perhaps figure that "all" diff
+@c programs support -c? Ideas is to preserve the
+@c ability to pass the buck to diff on all the hairy
+@c stuff, while still providing at least one, and
+@c perhaps several popular standard formats. But this
+@c is all in the idea stage, and probably needs more
+@c thought and refinement. -u might be similar, in
+@c terms of being something that it might make sense to
+@c document here.
+@c FIXME: also should be a way to pass through
+@c arbitrary options, so that the user can do
+@c "--pass=-Z --pass=foo" or something even if CVS
+@c doesn't know about the -Z option to diff.
+@c Note on -N: The current CVS implementation does require that the
+@c underlying diff supports -N so we can document it as
+@c a pass-through even if the implementation details
+@c are more complicated.
+@c
+@c FIXME? Reference to discussion of which diff CVS
+@c uses (one in path, or....).
+The following options are passed through to
@code{rcsdiff}, which in turn passes them to
@code{diff}. The exact meaning of the options depends
-on which @code{diff} you are using. The long options
-introduced in @sc{gnu} diff 2.0 are not yet supported in
-@sc{cvs}. See the documentation for your @code{diff} to see
-which options are supported.
+on which @code{diff} you are using. See the
+documentation for your @code{diff} for details.
+
+@code{-a} @code{-b} @code{-B} @code{-c} @w{@code{-C}
+@var{nlines}} @code{-d} @code{-e} @code{-f} @code{-h}
+@code{-H} @code{-i} @code{-n} @code{-N} @code{-p}
+@code{-s} @code{-t} @code{-u} @code{-U} @var{nlines}
+@w{@code{-F} @var{regexp}} @w{@code{-I} @var{regexp}}
+@w{@code{-L} @var{label}} @code{-T} @w{@code{-V}
+@var{arg}} @w{@code{-W} @var{columns}} @code{-w}
+@code{-y} @code{-0} @code{-1} @code{-2} @code{-3}
+@code{-4} @code{-5} @code{-6} @code{-7} @code{-8}
+@code{-9} @code{--binary} @code{--brief}
+@code{--changed-group-format=@var{arg}}
+@code{--context[=@var{lines}]} @code{--ed}
+@code{--expand-tabs} @code{--forward-ed}
+@code{--horizon-lines=@var{arg}}
+@code{--ignore-all-space} @code{--ignore-blank-lines}
+@code{--ignore-case}
+@code{--ignore-matching-lines=@var{regexp}}
+@code{--ignore-space-change} @code{--initial-tab}
+@code{--label=@var{label}} @code{--left-column}
+@code{--minimal} @code{--new-file}
+@code{--new-line-format=@var{arg}}
+@code{--old-line-format=@var{arg}} @code{--paginate}
+@code{--rcs} @code{--report-identical-files}
+@code{--code-c-function} @code{--side-by-side}
+@code{--show-function-line=@var{regexp}}
+@code{--speed-large-files}
+@code{--suppress-common-lines} @code{--text}
+@code{--unchanged-group-format=@var{arg}}
+@code{--unified[=@var{lines}]}
+@code{--width=@var{columns}}
-@c -- Document some common useful diff options, such as
-@c -u and -c.
@c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
@node diff examples
@appendixsubsec diff examples
@@ -5380,7 +7638,7 @@ $ cvs diff -u | less
@itemize @bullet
@item
-Synopsis: export [-flNn] [-r rev|-D date] [-k subst] [-d dir] module@dots{}
+Synopsis: export [-flNnR] [-r rev|-D date] [-k subst] [-d dir] module@dots{}
@item
Requires: repository.
@item
@@ -5539,6 +7797,8 @@ Certain commands have a single record type:
release
@item O
checkout
+@item E
+export
@item T
rtag
@end table
@@ -5638,6 +7898,8 @@ Contributed examples will gratefully be accepted.
@appendixsec import---Import sources into CVS, using vendor branches
@cindex Import (subcommand)
+@c FIXME: This node is way too long for one which has subnodes.
+
@itemize @bullet
@item
Synopsis: import [-options] repository vendortag releasetag@dots{}
@@ -5669,7 +7931,8 @@ you to do.
If @sc{cvs} decides a file should be ignored
(@pxref{cvsignore}), it does not import it and prints
-@samp{I } followed by the filename
+@samp{I } followed by the filename (@pxref{import output}, for a
+complete description of the output).
If the file @file{$CVSROOT/CVSROOT/cvswrappers} exists,
any file whose names match the specifications in that
@@ -5691,8 +7954,19 @@ branch (e.g., for 1.1.1). You must also specify at
least one @var{releasetag} to identify the files at
the leaves created each time you execute @code{import}.
+@c I'm not completely sure this belongs here. But
+@c we need to say it _somewhere_ reasonably obvious; it
+@c is a common misconception among people first learning CVS
+Note that @code{import} does @emph{not} change the
+directory in which you invoke it. In particular, it
+does not set up that directory as a @sc{cvs} working
+directory; if you want to work with the sources import
+them first and then check them out into a different
+directory (@pxref{Getting the source}).
+
@menu
* import options:: import options
+* import output:: import output
* import examples:: import examples
@end menu
@@ -5725,7 +7999,7 @@ in the future.
Indicate the RCS keyword expansion mode desired. This
setting will apply to all files created during the
import, but not to any files that previously existed in
-the repository. See @ref{Substitution modes} for a
+the repository. See @ref{Substitution modes}, for a
list of valid @samp{-k} settings.
@item -I @var{name}
@@ -5749,6 +8023,46 @@ file. @xref{Wrappers}.
@end table
@c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
+@node import output
+@appendixsubsec import output
+
+@code{import} keeps you informed of its progress by printing a line
+for each file, preceded by one character indicating the status of the file:
+
+@table @code
+@item U @var{file}
+The file already exists in the repository and has not been locally
+modified; a new revision has been created (if necessary).
+
+@item N @var{file}
+The file is a new file which has been added to the repository.
+
+@item C @var{file}
+The file already exists in the repository but has been locally modified;
+you will have to merge the changes.
+
+@item I @var{file}
+The file is being ignored (@pxref{cvsignore}).
+
+@cindex symbolic link, importing
+@cindex link, symbolic, importing
+@c FIXME: also (somewhere else) probably
+@c should be documenting what happens if you "cvs add"
+@c a symbolic link. Also maybe what happens if
+@c you manually create symbolic links within the
+@c repository (? - not sure why we'd want to suggest
+@c doing that).
+@item L @var{file}
+The file is a symbolic link; @code{cvs import} ignores symbolic links.
+People periodically suggest that this behavior should
+be changed, but if there is a consensus on what it
+should be changed to, it doesn't seem to be apparent.
+(Various options in the @file{modules} file can be used
+to recreate symbolic links on checkout, update, etc.;
+@pxref{modules}.)
+@end table
+
+@c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
@node import examples
@appendixsubsec import examples
@@ -5756,31 +8070,51 @@ file. @xref{Wrappers}.
@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node log
-@appendixsec log---Print out 'rlog' information for files
+@appendixsec log---Print out log information for files
@cindex Log (subcommand)
@itemize @bullet
@item
-Synopsis: log [-l] rlog-options [files@dots{}]
+Synopsis: log [options] [files@dots{}]
@item
Requires: repository, working directory.
@item
Changes: nothing.
-@item
-Synonym: rlog
@end itemize
-Display log information for files. @code{log} calls
-the @sc{rcs} utility @code{rlog}, which prints all available
-information about the @sc{rcs} history file. This includes
-the location of the @sc{rcs} file, the @dfn{head} revision
-(the latest revision on the trunk), all symbolic names (tags)
-and some other things. For each revision, the revision
-number, the author, the number of lines added/deleted and
-the log message are printed. All times are displayed in
-Coordinated Universal Time (UTC). (Other parts of @sc{cvs}
-print times in the local timezone).
-@c -- timezone--
+Display log information for files. @code{log} used to
+call the @sc{rcs} utility @code{rlog}. Although this
+is no longer true in the current sources, this history
+determines the format of the output and the options,
+which are not quite in the style of the other @sc{cvs}
+commands.
+
+@cindex timezone, in output
+@cindex zone, time, in output
+@c Kind of a funny place to document the timezone used
+@c in output from commands other than @code{log}.
+@c There is also more we need to say about this,
+@c including what happens in a client/server environment.
+The output includes the location of the @sc{rcs} file,
+the @dfn{head} revision (the latest revision on the
+trunk), all symbolic names (tags) and some other
+things. For each revision, the revision number, the
+author, the number of lines added/deleted and the log
+message are printed. All times are displayed in
+Coordinated Universal Time (UTC). (Other parts of
+@sc{cvs} print times in the local timezone).
+@c FIXCVS: need a better way to control the timezone
+@c used in output. Previous/current versions of CVS did/do
+@c sometimes support -z in RCSINIT, and/or an
+@c undocumented (except by reference to 'rlog') -z option
+@c to cvs log, but this has not been a consistent,
+@c documented feature. Perhaps a new global option,
+@c where LT means the client's timezone, which the
+@c client then communicates to the server, is the
+@c right solution.
+
+@strong{Warning:} @code{log} uses @samp{-R} in a way that conflicts
+with the normal use inside @sc{cvs} (@pxref{Common options}).
@menu
* log options:: log options
@@ -5791,42 +8125,29 @@ print times in the local timezone).
@node log options
@appendixsubsec log options
-Only one option is interpreted by @sc{cvs} and not passed on to @code{rlog}:
-
-@table @code
-@item -l
-Local; run only in current working directory. (Default
-is to run recursively).
-@end table
-
-By default, @code{rlog} prints all information that is
-available. All other options (including those that
-normally behave differently) are passed through to
-@code{rlog} and restrict the output. See rlog(1) for a
-complete description of options. This incomplete list
-(which is a slightly edited extract from rlog(1)) lists
-all options that are useful in conjunction with @sc{cvs}.
-
-@strong{Please note:} There can be no space between the option
-and its argument, since @code{rlog} parses its options
-in a different way than @sc{cvs}.
+By default, @code{log} prints all information that is
+available. All other options restrict the output.
@table @code
@item -b
Print information about the revisions on the default
branch, normally the highest branch on the trunk.
-@item -d@var{dates}
+@item -d @var{dates}
Print information about revisions with a checkin
date/time in the range given by the
-semicolon-separated list of dates. The following table
-explains the available range formats:
+semicolon-separated list of dates. The date formats
+accepted are those accepted by the @samp{-D} option to
+many other @sc{cvs} commands (@pxref{Common options}).
+Dates can be combined into ranges as follows:
+@c Should we be thinking about accepting ISO8601
+@c ranges? For example "1972-09-10/1972-09-12".
@table @code
@item @var{d1}<@var{d2}
@itemx @var{d2}>@var{d1}
Select the revisions that were deposited between
-@var{d1} and @var{d2} inclusive.
+@var{d1} and @var{d2}.
@item <@var{d}
@itemx @var{d}>
@@ -5841,16 +8162,21 @@ Select the single, latest revision dated @var{d} or
earlier.
@end table
-The date/time strings @var{d}, @var{d1}, and @var{d2}
-are in the free format explained in co(1). Quoting is
-normally necessary, especially for < and >. Note that
-the separator is a semicolon (;).
+The @samp{>} or @samp{<} characters may be followed by
+@samp{=} to indicate an inclusive range rather than an
+exclusive one.
+
+Note that the separator is a semicolon (;).
@item -h
Print only the @sc{rcs} pathname, working pathname, head,
default branch, access list, locks, symbolic names, and
suffix.
+@item -l
+Local; run only in current working directory. (Default
+is to run recursively).
+
@item -N
Do not print the list of tags for this file. This
option can be very useful when your site uses a lot of
@@ -5882,10 +8208,7 @@ branch containing @var{rev}.
@item @var{branch}
An argument that is a branch means all revisions on
-that branch. You can unfortunately not specify a
-symbolic branch here. You must specify the numeric
-branch number. @xref{Magic branch numbers}, for an
-explanation.
+that branch.
@item @var{branch1}:@var{branch2}
A range of branches means all revisions
@@ -5897,8 +8220,10 @@ The latest revision in @var{branch}.
A bare @samp{-r} with no revisions means the latest
revision on the default branch, normally the trunk.
+There can be no space between the @samp{-r} option and
+its argument.
-@item -s@var{states}
+@item -s @var{states}
Print information about revisions whose state
attributes match one of the states given in the
comma-separated list @var{states}.
@@ -5910,13 +8235,14 @@ Print the same as @samp{-h}, plus the descriptive text.
Print information about revisions checked in by users
with login names appearing in the comma-separated list
@var{logins}. If @var{logins} is omitted, the user's
-login is assumed.
+login is assumed. There can be no space between the
+@samp{-w} option and its argument.
@end table
-@code{rlog} prints the intersection of the revisions
-selected with the options @samp{-d}, @samp{-l},
-@samp{-s}, and @samp{-w}, intersected with the union of
-the revisions selected by @samp{-b} and @samp{-r}.
+@code{log} prints the intersection of the revisions
+selected with the options @samp{-d}, @samp{-s}, and
+@samp{-w}, intersected with the union of the revisions
+selected by @samp{-b} and @samp{-r}.
@c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
@node log examples
@@ -5985,6 +8311,9 @@ recent revision (instead of ignoring the file).
@item -l
Local; don't descend subdirectories.
+@item -R
+Examine directories recursively. This option is on by default.
+
@item -r @var{tag}
Use revision @var{tag}.
@end table
@@ -6087,7 +8416,7 @@ history log.
@menu
* release options:: release options
-* release output:: release options
+* release output:: release output
* release examples:: release examples
@end menu
@@ -6103,12 +8432,12 @@ Delete your working copy of the file if the release
succeeds. If this flag is not given your files will
remain in your working directory.
-@strong{Warning:} The @code{release} command uses
-@samp{rm -r @file{module}} to delete your file. This
+@strong{Warning:} The @code{release} command deletes
+all directories and files recursively. This
has the very serious side-effect that any directory
that you have created inside your checked-out sources,
and not added to the repository (using the @code{add}
-command; @pxref{add}) will be silently deleted---even
+command; @pxref{Adding files}) will be silently deleted---even
if it is non-empty!
@end table
@@ -6122,15 +8451,18 @@ up-to-date.
@strong{Warning:} Any new directories that you have
created, but not added to the @sc{cvs} directory hierarchy
-with the @code{add} command (@pxref{add}) will be
+with the @code{add} command (@pxref{Adding files}) will be
silently ignored (and deleted, if @samp{-d} is
specified), even if they contain files.
+@c FIXCVS: This is a bug. But is it true? I think
+@c maybe they print "? dir" now.
@table @code
@item U @var{file}
+@itemx P @var{file}
There exists a newer revision of this file in the
repository, and you have not modified your local copy
-of the file.
+of the file (@samp{U} and @samp{P} mean the same thing).
@item A @var{file}
The file has been added to your private copy of the
@@ -6155,13 +8487,6 @@ not in the list of files for @sc{cvs} to ignore (see the
description of the @samp{-I} option, and
@pxref{cvsignore}). If you remove your working
sources, this file will be lost.
-
-Note that no warning message like this is printed for
-spurious directories that @sc{cvs} encounters. The
-directory, and all its contents, are silently ignored.
-
-@c FIXME -- CVS should be fixed to print "? foo" for
-@c such spurious directories
@end table
@c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
@@ -6181,7 +8506,7 @@ $
@end example
@node rtag
-@appendixsec rtag---Add a tag to the RCS file
+@appendixsec rtag---Add a symbolic tag to a module
@cindex Rtag (subcommand)
@itemize @bullet
@@ -6242,7 +8567,7 @@ Do not run any tag program that was specified with the
(@pxref{modules}).
@item -R
-Commit directories recursively. This is on by default.
+Tag directories recursively. This is on by default.
@item -r @var{tag}
Only tag those files that contain @var{tag}. This can
@@ -6256,15 +8581,17 @@ are available:
@table @code
@item -a
+@c FIXME: What does this option mean in terms of user
+@c concepts, not CVS internals?
Use the @samp{-a} option to have @code{rtag} look in the
-@file{Attic} (@pxref{Removing files}) for removed files
+@file{Attic} (@pxref{Attic}) for removed files
that contain the specified tag. The tag is removed from
these files, which makes it convenient to re-use a
symbolic tag as development continues (and files get
removed from the up-coming distribution).
@item -b
-Make the tag a branch tag. @xref{Branches}.
+Make the tag a branch tag. @xref{Revisions and branches}.
@item -d
Delete the tag instead of creating it.
@@ -6286,69 +8613,8 @@ module).
@end ignore
@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-@node status
-@appendixsec status---Status info on the revisions
-@cindex Status (subcommand)
-
-@itemize @bullet
-@item
-status [-lR] [-v] [files@dots{}]
-@item
-Requires: working directory, repository.
-@item
-Changes: nothing.
-@end itemize
-
-Display a brief report on the current status of files
-with respect to the source repository, including any
-sticky tags, dates, or @samp{-k} options.
-
-You can also use this command to determine the
-potential impact of a @samp{cvs update} on your working
-source directory---but remember that things might
-change in the repository before you run @code{update}.
-
-@menu
-* status options:: status options
-@end menu
-
-@c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
-@node status options
-@appendixsubsec status options
-
-These standard options are supported by @code{status}
-(@pxref{Common options}, for a complete description of
-them):
-
-@table @code
-@item -l
-Local; run only in current working directory.
-
-@item -R
-Commit directories recursively. This is on by default.
-@end table
-
-There is one additional option:
-
-@table @code
-@item -v
-Verbose. In addition to the information normally
-displayed, print all symbolic tags, together with the
-numerical value of the revision or branch they refer
-to.
-@end table
-
-@ignore
-@c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
-@c @node status examples
-@appendixsubsec status examples
-
-@c -- FIXME
-@end ignore
-
-@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node tag
-@appendixsec tag---Add a symbolic tag to checked out version of RCS file
+@appendixsec tag---Add a symbolic tag to checked out versions of files
@c -- //////// - unnecessary. Also
@c -- in a lot of other
@c -- places.
@@ -6356,7 +8622,7 @@ to.
@itemize @bullet
@item
-tag [-lR] [-b] [-d] symbolic_tag [files@dots{}]
+tag [-lR] [-b] [-c] [-d] symbolic_tag [files@dots{}]
@item
Requires: working directory, repository.
@item
@@ -6416,7 +8682,7 @@ different revision. This option is new in @sc{cvs}
Local; run only in current working directory.
@item -R
-Commit directories recursively. This is on by default.
+Tag directories recursively. This is on by default.
@end table
Two special options are available:
@@ -6424,10 +8690,15 @@ Two special options are available:
@table @code
@item -b
The -b option makes the tag a branch tag
-(@pxref{Branches}), allowing concurrent, isolated
+(@pxref{Revisions and branches}), allowing concurrent, isolated
development. This is most useful for creating a patch
to a previously released software distribution.
+@item -c
+The -c option checks that all files which are to be tagged are
+unmodified. This can be used to make sure that you can reconstruct the
+current file contents.
+
@item -d
Delete a tag.
@@ -6473,7 +8744,6 @@ since your last checkout or update.
@menu
* update options:: update options
* update output:: update output
-* update examples:: update examples
@end menu
@c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
@@ -6501,20 +8771,21 @@ Process @sc{rcs} keywords according to @var{kflag}. See
co(1). This option is sticky; future updates of
this file in this working directory will use the same
@var{kflag}. The @code{status} command can be viewed
-to see the sticky options. @xref{status}.
+to see the sticky options. See @ref{Invoking CVS}, for
+more information on the @code{status} command.
@item -l
Local; run only in current working directory. @xref{Recursive behavior}.
@item -P
-Prune empty directories.
+Prune empty directories. See @ref{Moving directories}.
@item -p
Pipe files to the standard output.
@item -R
-Operate recursively. This is on by default.
-@xref{Recursive behavior}.
+Update directories recursively (default). @xref{Recursive
+behavior}.
@item -r tag
Retrieve revision @var{tag}. This option is sticky,
@@ -6591,9 +8862,9 @@ date. An optional date is specified by adding a colon
@node update output
@appendixsubsec update output
-@code{update} keeps you informed of its progress by
-printing a line for each file, preceded by one
-character indicating the status of the file:
+@code{update} and @code{checkout} keep you informed of
+its progress by printing a line for each file, preceded
+by one character indicating the status of the file:
@table @code
@item U @var{file}
@@ -6603,6 +8874,11 @@ the repository but not in your source, and for files
that you haven't changed but are not the most recent
versions available in the repository.
+@item P @var{file}
+Like @samp{U}, but the @sc{cvs} server sends a patch
+instead of an entire file. These two things accomplish
+the same thing.
+
@item A @var{file}
The file has been added to your private copy of the
sources, and will be added to the source repository
@@ -6632,6 +8908,8 @@ before you ran @code{update}) will be made. The exact
name of that file is printed while @code{update} runs.
@item C @var{file}
+@cindex .# files
+@cindex __ files (VMS)
A conflict was detected while trying to merge your
changes to @var{file} with changes from the source
repository. @var{file} (the copy in your working
@@ -6640,11 +8918,21 @@ on the two revisions; an unmodified copy of your file
is also in your working directory, with the name
@file{.#@var{file}.@var{revision}} where @var{revision}
is the @sc{rcs} revision that your modified file started
-from. (Note that some systems automatically purge
+from. Resolve the conflict as described in
+@ref{Conflicts example}
+@c "some systems" as in out-of-the-box OSes? Not as
+@c far as I know. We need to advise sysadmins as well
+@c as users how to set up this kind of purge, if that is
+@c what they want.
+@c We also might want to think about cleaner solutions,
+@c like having CVS remove the .# file once the conflict
+@c has been resolved or something like that.
+(Note that some systems automatically purge
files that begin with @file{.#} if they have not been
accessed for a few days. If you intend to keep a copy
of your original file, it is a very good idea to rename
-it.)
+it.) Under @sc{vms}, the file name starts with
+@file{__} rather than @file{.#}.
@item ? @var{file}
@var{file} is in your working directory, but does not
@@ -6652,28 +8940,712 @@ correspond to anything in the source repository, and is
not in the list of files for @sc{cvs} to ignore (see the
description of the @samp{-I} option, and
@pxref{cvsignore}).
+@end table
-Note that no warning message like this is printed for
-spurious directories that @sc{cvs} encounters. The
-directory, and all its contents, are silently ignored.
+@node Invoking CVS
+@appendix Quick reference to CVS commands
+@cindex Command reference
+@cindex Reference, commands
+@cindex Invoking CVS
+
+This appendix describes how to invoke @sc{cvs}, with
+references to where each command or feature is
+described in detail. Other relevant references are the
+@samp{--help}/@samp{-H} option to @sc{cvs}
+(@pxref{Global options}) and @ref{Index}.
+
+@c The idea behind this table is that we want each item
+@c to be a sentence or two at most. Preferably a
+@c single line.
+@c
+@c In some cases refs to "foo options" are just to get
+@c this thing written quickly, not because the "foo
+@c options" node is really the best place to point.
+@table @code
+@item add [@var{options}] [@var{files}@dots{}]
+Add a new file/directory. See @ref{Adding files}.
+
+@table @code
+@item -k @var{kflag}
+Set keyword expansion.
+
+@item -m @var{msg}
+Set file description.
@end table
-@c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
-@node update examples
-@appendixsubsec update examples
+@item admin [@var{options}] [@var{files}@dots{}]
+Administration of history files in the repository. See
+@ref{admin}.
+@c This list omits those options which are not
+@c documented as being useful with CVS. That might be
+@c a mistake...
+
+@table @code
+@item -b[@var{rev}]
+Set default branch.
+@c FIXME: Should xref to a section which describes how
+@c to use this with the vendor branch.
-The following line will display all files which are not
-up-to-date without actually change anything in your
-working directory. It can be used to check what has
-been going on with the project.
+@item -c@var{string}
+Set comment leader.
-@example
-$ cvs -n -q update
-@end example
+@item -k@var{subst}
+Set keyword substitution. See @ref{Keyword
+substitution}.
+
+@item -l[@var{rev}]
+Lock revision @var{rev}, or latest revision.
+
+@item -m@var{rev}:@var{msg}
+Replace the log message of revision @var{rev} with
+@var{msg}.
+
+@item -o@var{range}
+Delete revisions from the history files
+
+@item -q
+Run quietly; do not print diagnostics.
+
+@item -s@var{state}[:@var{rev}]
+Set the state.
+
+@c Does not work for client/server CVS
+@item -t
+Set file description from standard input.
+
+@item -t@var{file}
+Set file description from @var{file}.
+
+@item -t-@var{string}
+Set file description to @var{string}.
+
+@item -u[@var{rev}]
+Unlock revision @var{rev}, or latest revision.
+@end table
+
+@item annotate [@var{options}] [@var{files}@dots{}]
+Show last revision where each line was modified. See
+@ref{annotate}.
+
+@table @code
+@item -D @var{date}
+Annotate the most recent revision no later than
+@var{date}. See @ref{Common options}.
+
+@item -f
+Use head revision if tag/date not found. See
+@ref{Common options}.
+
+@item -l
+Local; run only in current working directory. @xref{Recursive behavior}.
+
+@item -R
+Operate recursively (default). @xref{Recursive
+behavior}.
+
+@item -r @var{tag}
+Annotate revision @var{tag}. See @ref{Common options}.
+@end table
+
+@item checkout [@var{options}] @var{modules}@dots{}
+Get a copy of the sources. See @ref{checkout}.
+
+@table @code
+@item -A
+Reset any sticky tags/date/options. See @ref{Sticky
+tags} and @ref{Keyword substitution}.
+
+@item -c
+Output the module database. See @ref{checkout options}.
+
+@item -D @var{date}
+Check out revisions as of @var{date} (is sticky). See
+@ref{Common options}.
+
+@item -d @var{dir}
+Check out into @var{dir}. See @ref{checkout options}.
+
+@item -f
+Use head revision if tag/date not found. See
+@ref{Common options}.
+
+@c Probably want to use rev1/rev2 style like for diff
+@c -r. Here and in on-line help.
+@item -j @var{rev}
+Merge in changes. See @ref{checkout options}.
+
+@item -k @var{kflag}
+Use @var{kflag} keyword expansion. See
+@ref{Substitution modes}.
+
+@item -l
+Local; run only in current working directory. @xref{Recursive behavior}.
+
+@item -N
+Don't shorten module paths if -d specified. See @ref{checkout options}.
+
+@item -n
+Do not run module program (if any). See @ref{checkout options}.
+
+@item -P
+Prune empty directories. See @ref{Moving directories}.
+
+@item -p
+Check out files to standard output (avoids
+stickiness). See @ref{checkout options}.
+
+@item -R
+Operate recursively (default). @xref{Recursive
+behavior}.
+
+@item -r @var{tag}
+Checkout revision @var{tag} (is sticky). See @ref{Common options}.
+
+@item -s
+Like -c, but include module status. See @ref{checkout options}.
+@end table
+
+@item commit [@var{options}] [@var{files}@dots{}]
+Check changes into the repository. See @ref{commit}.
+
+@table @code
+@item -F @var{file}
+Read log message from @var{file}. See @ref{commit options}.
+
+@item -f
+@c What is this "disables recursion"? It is from the
+@c on-line help; is it documented in this manual?
+Force the file to be committed; disables recursion.
+See @ref{commit options}.
+
+@item -l
+Local; run only in current working directory. See @ref{Recursive behavior}.
+
+@item -m @var{msg}
+Use @var{msg} as log message. See @ref{commit options}.
+
+@item -n
+Do not run module program (if any). See @ref{commit options}.
+
+@item -R
+Operate recursively (default). @xref{Recursive
+behavior}.
+
+@item -r @var{rev}
+Commit to @var{rev}. See @ref{commit options}.
+@c FIXME: should be dragging over text from
+@c commit options, especially if it can be cleaned up
+@c and made concise enough.
+@end table
+
+@item diff [@var{options}] [@var{files}@dots{}]
+Show differences between revisions. See @ref{diff}.
+In addition to the options shown below, accepts a wide
+variety of options to control output style, for example
+@samp{-c} for context diffs.
+
+@table @code
+@item -D @var{date1}
+Diff revision for date against working file. See
+@ref{diff options}.
+
+@item -D @var{date2}
+Diff @var{rev1}/@var{date1} against @var{date2}. See
+@ref{diff options}.
+
+@item -l
+Local; run only in current working directory. See @ref{Recursive behavior}.
+
+@item -N
+Include diffs for added and removed files. See
+@ref{diff options}.
+
+@item -R
+Operate recursively (default). @xref{Recursive
+behavior}.
+
+@item -r @var{rev1}
+Diff revision for @var{rev1} against working file. See
+@ref{diff options}.
+
+@item -r @var{rev2}
+Diff rev1/date1 against rev2. See @ref{diff options}.
+@end table
+
+@item edit [@var{options}] [@var{files}@dots{}]
+Get ready to edit a watched file. See @ref{Editing files}.
+
+@table @code
+@item -a @var{actions}
+Specify actions for temporary watch, where
+@var{actions} is @code{edit}, @code{unedit},
+@code{commit}, @code{all}, or @code{none}. See
+@ref{Editing files}.
+
+@item -l
+Local; run only in current working directory. See @ref{Recursive behavior}.
+
+@item -R
+Operate recursively (default). @xref{Recursive
+behavior}.
+@end table
+
+@item editors [@var{options}] [@var{files}@dots{}]
+See who is editing a watched file. See @ref{Watch information}.
+
+@table @code
+@item -l
+Local; run only in current working directory. See @ref{Recursive behavior}.
+
+@item -R
+Operate recursively (default). @xref{Recursive
+behavior}.
+@end table
+
+@item export [@var{options}] @var{modules}@dots{}
+Export files from CVS. See @ref{export}.
+
+@table @code
+@item -D @var{date}
+Check out revisions as of @var{date}. See
+@ref{Common options}.
+
+@item -d @var{dir}
+Check out into @var{dir}. See @ref{export options}.
+
+@item -f
+Use head revision if tag/date not found. See
+@ref{Common options}.
+
+@item -k @var{kflag}
+Use @var{kflag} keyword expansion. See
+@ref{Substitution modes}.
+
+@item -l
+Local; run only in current working directory. @xref{Recursive behavior}.
+
+@item -N
+Don't shorten module paths if -d specified. See @ref{export options}.
+
+@item -n
+Do not run module program (if any). See @ref{export options}.
+
+@item -P
+Prune empty directories. See @ref{Moving directories}.
+
+@item -R
+Operate recursively (default). @xref{Recursive
+behavior}.
+
+@item -r @var{tag}
+Checkout revision @var{tag} (is sticky). See @ref{Common options}.
+@end table
+
+@item history [@var{options}] [@var{files}@dots{}]
+Show repository access history. See @ref{history}.
+
+@table @code
+@item -a
+All users (default is self). See @ref{history options}.
+
+@item -b @var{str}
+Back to record with @var{str} in module/file/repos
+field. See @ref{history options}.
+
+@item -c
+Report on committed (modified) files. See @ref{history options}.
+
+@item -D @var{date}
+Since @var{date}. See @ref{history options}.
+
+@item -e
+Report on all record types. See @ref{history options}.
+
+@item -l
+Last modified (committed or modified report). See @ref{history options}.
+
+@item -m @var{module}
+Report on @var{module} (repeatable). See @ref{history
+options}.
+
+@item -n @var{module}
+In @var{module}. See @ref{history options}.
+
+@item -o
+Report on checked out modules. See @ref{history options}.
+
+@item -r @var{rev}
+Since revision @var{rev}. See @ref{history options}.
+
+@item -T
+@c What the @#$@# is a TAG? Same as a tag? This
+@c wording is also in the online-line help.
+Produce report on all TAGs. See @ref{history options}.
+
+@item -t @var{tag}
+Since tag record placed in history file (by anyone).
+See @ref{history options}.
+
+@item -u @var{user}
+For user @var{user} (repeatable). See @ref{history
+options}.
+
+@item -w
+Working directory must match. See @ref{history options}.
+
+@item -x @var{types}
+Report on @var{types}, one or more of
+@code{TOEFWUCGMAR}. See @ref{history options}.
+
+@item -z @var{zone}
+Output for time zone @var{zone}. See @ref{history
+options}.
+@end table
+
+@item import [@var{options}] @var{repository} @var{vendor-tag} @var{release-tags}@dots{}
+Import files into CVS, using vendor branches. See
+@ref{import}.
+
+@table @code
+@item -b @var{bra}
+Import to vendor branch @var{bra}. See
+@ref{import options}.
+
+@item -d
+Use the file's modification time as the time of
+import. See @ref{import options}.
+
+@item -k @var{kflag}
+Set default RCS keyword substitution mode. See
+@ref{import options}.
+
+@item -m @var{msg}
+Use @var{msg} for log message. See
+@ref{import options}.
+
+@item -I @var{ign}
+More files to ignore (! to reset). See
+@ref{import options}.
+
+@item -W @var{spec}
+More wrappers. See @ref{import options}.
+@end table
+
+@item init
+Create a CVS repository if it doesn't exist. See
+@ref{Creating a repository}.
+
+@item log [@var{options}] [@var{files}@dots{}]
+Print out history information for files. See @ref{log}.
+
+@table @code
+@item -b
+Only list revisions on the default branch. See @ref{log options}.
+
+@item -d @var{dates}
+Specify dates (@var{d1}<@var{d2} for range, @var{d} for
+latest before). See @ref{log options}.
+
+@item -h
+Only print header. See @ref{log options}.
+
+@item -l
+Local; run only in current working directory. See @ref{Recursive behavior}.
+
+@item -N
+Do not list tags. See @ref{log options}.
+
+@item -R
+Only print name of RCS file. See @ref{log options}.
+
+@item -r @var{revs}
+Only list revisions @var{revs}. See @ref{log options}.
+
+@item -s @var{states}
+Only list revisions with specified states. See @ref{log options}.
+
+@item -t
+Only print header and descriptive text. See @ref{log
+options}.
+
+@item -w @var{logins}
+Only list revisions checked in by specified logins. See @ref{log options}.
+@end table
+
+@item login
+Prompt for password for authenticating server. See
+@ref{Password authentication client}.
+
+@item logout
+Remove stored password for authenticating server. See
+@ref{Password authentication client}.
+
+@item rdiff [@var{options}] @var{modules}@dots{}
+Show differences between releases. See @ref{rdiff}.
+
+@table @code
+@item -c
+Context diff output format (default). See @ref{rdiff options}.
+
+@item -D @var{date}
+Select revisions based on @var{date}. See @ref{Common options}.
+
+@item -f
+Use head revision if tag/date not found. See
+@ref{Common options}.
+
+@item -l
+Local; run only in current working directory. See @ref{Recursive behavior}.
+
+@item -R
+Operate recursively (default). @xref{Recursive
+behavior}.
+
+@item -r @var{rev}
+Select revisions based on @var{rev}. See @ref{Common options}.
+
+@item -s
+Short patch - one liner per file. See @ref{rdiff options}.
+
+@item -t
+Top two diffs - last change made to the file. See
+@ref{diff options}.
+
+@item -u
+Unidiff output format. See @ref{rdiff options}.
+
+@item -V @var{vers}
+Use RCS Version @var{vers} for keyword expansion. See
+@ref{rdiff options}.
+@end table
+
+@item release [@var{options}] @var{directory}
+Indicate that a directory is no longer in use. See
+@ref{release}.
+
+@table @code
+@item -d
+Delete the given directory. See @ref{release options}.
+@end table
+
+@item remove [@var{options}] [@var{files}@dots{}]
+Remove an entry from the repository. See @ref{Removing files}.
+
+@table @code
+@item -f
+Delete the file before removing it. See @ref{Removing files}.
+
+@item -l
+Local; run only in current working directory. See @ref{Recursive behavior}.
+
+@item -R
+Operate recursively (default). @xref{Recursive
+behavior}.
+@end table
+
+@item rtag [@var{options}] @var{tag} @var{modules}@dots{}
+Add a symbolic tag to a module. See @ref{rtag}.
+
+@table @code
+@c Is this one of those dumb options which used to
+@c work around the lack of death support?
+@item -a
+Clear tag from removed files that would not otherwise
+be tagged. See @ref{rtag options}.
+
+@item -b
+Create a branch named @var{tag}. See @ref{rtag options}.
+
+@item -D @var{date}
+Tag revisions as of @var{date}. See @ref{rtag options}.
+
+@item -d
+Delete the given tag. See @ref{rtag options}.
+
+@item -F
+Move tag if it already exists. See @ref{rtag options}.
+
+@item -f
+Force a head revision match if tag/date not found.
+See @ref{rtag options}.
+
+@item -l
+Local; run only in current working directory. See @ref{Recursive behavior}.
+
+@item -n
+No execution of tag program. See @ref{rtag options}.
+
+@item -R
+Operate recursively (default). @xref{Recursive
+behavior}.
+
+@item -r @var{tag}
+Tag existing tag @var{tag}. See @ref{rtag options}.
+@end table
+
+@item status [@var{options}] @var{files}@dots{}
+Display status information in a working directory. See
+@ref{File status}.
+
+@table @code
+@item -l
+Local; run only in current working directory. See @ref{Recursive behavior}.
+
+@item -R
+Operate recursively (default). @xref{Recursive
+behavior}.
+
+@item -v
+Include tag information for file. See @ref{Tags}.
+@end table
+
+@item tag [@var{options}] @var{tag} [@var{files}@dots{}]
+Add a symbolic tag to checked out version of files.
+See @ref{tag}.
+
+@table @code
+@item -b
+Create a branch named @var{tag}. See @ref{tag options}.
+
+@item -D @var{date}
+Tag revisions as of @var{date}. See @ref{tag options}.
+
+@item -d
+Delete the given tag. See @ref{tag options}.
+
+@item -F
+Move tag if it already exists. See @ref{tag options}.
+
+@item -f
+Force a head revision match if tag/date not found.
+See @ref{tag options}.
+
+@item -l
+Local; run only in current working directory. See @ref{Recursive behavior}.
+
+@item -n
+No execution of tag program. See @ref{tag options}.
+
+@item -R
+Operate recursively (default). @xref{Recursive
+behavior}.
+
+@item -r @var{tag}
+Tag existing tag @var{tag}. See @ref{tag options}.
+@end table
+
+@item unedit [@var{options}] [@var{files}@dots{}]
+Undo an edit command. See @ref{Editing files}.
+
+@table @code
+@item -a @var{actions}
+Specify actions for temporary watch, where
+@var{actions} is @code{edit}, @code{unedit},
+@code{commit}, @code{all}, or @code{none}. See
+@ref{Editing files}.
+
+@item -l
+Local; run only in current working directory. See @ref{Recursive behavior}.
+
+@item -R
+Operate recursively (default). @xref{Recursive
+behavior}.
+@end table
+
+@item update [@var{options}] [@var{files}@dots{}]
+Bring work tree in sync with repository. See
+@ref{update}.
+
+@table @code
+@item -A
+Reset any sticky tags/date/options. See @ref{Sticky
+tags} and @ref{Keyword substitution}.
+
+@item -D @var{date}
+Check out revisions as of @var{date} (is sticky). See
+@ref{Common options}.
+
+@item -d
+Create directories. See @ref{update options}.
+
+@item -f
+Use head revision if tag/date not found. See
+@ref{Common options}.
+
+@item -I @var{ign}
+More files to ignore (! to reset). See
+@ref{import options}.
+
+@c Probably want to use rev1/rev2 style like for diff
+@c -r. Here and in on-line help.
+@item -j @var{rev}
+Merge in changes. See @ref{update options}.
+
+@item -k @var{kflag}
+Use @var{kflag} keyword expansion. See
+@ref{Substitution modes}.
+
+@item -l
+Local; run only in current working directory. @xref{Recursive behavior}.
+
+@item -P
+Prune empty directories. See @ref{Moving directories}.
+
+@item -p
+Check out files to standard output (avoids
+stickiness). See @ref{update options}.
+
+@item -R
+Operate recursively (default). @xref{Recursive
+behavior}.
+
+@item -r @var{tag}
+Checkout revision @var{tag} (is sticky). See @ref{Common options}.
+
+@item -W @var{spec}
+More wrappers. See @ref{import options}.
+@end table
+
+@item watch [on|off|add|remove] [@var{options}] [@var{files}@dots{}]
+
+on/off: turn on/off read-only checkouts of files. See
+@ref{Setting a watch}.
+
+add/remove: add or remove notification on actions. See
+@ref{Getting Notified}.
+
+@table @code
+@item -a @var{actions}
+Specify actions for temporary watch, where
+@var{actions} is @code{edit}, @code{unedit},
+@code{commit}, @code{all}, or @code{none}. See
+@ref{Editing files}.
+
+@item -l
+Local; run only in current working directory. See @ref{Recursive behavior}.
+
+@item -R
+Operate recursively (default). @xref{Recursive
+behavior}.
+@end table
+
+@item watchers [@var{options}] [@var{files}@dots{}]
+See who is watching a file. See @ref{Watch information}.
+
+@table @code
+@item -l
+Local; run only in current working directory. See @ref{Recursive behavior}.
+
+@item -R
+Operate recursively (default). @xref{Recursive
+behavior}.
+@end table
+
+@end table
@c ---------------------------------------------------------------------
@node Administrative files
-@appendix Reference manual for the Administrative files
+@appendix Reference manual for Administrative files
@cindex Administrative files (reference)
@cindex Files, reference manual
@cindex Reference manual (files)
@@ -6683,7 +9655,9 @@ Inside the repository, in the directory
@file{$CVSROOT/CVSROOT}, there are a number of
supportive files for @sc{cvs}. You can use @sc{cvs} in a limited
fashion without any of them, but if they are set up
-properly they can help make life easier.
+properly they can help make life easier. For a
+discussion of how to edit them, @xref{Intro
+administrative files}.
The most important of these files is the @file{modules}
file, which defines the modules inside the repository.
@@ -6693,12 +9667,13 @@ file, which defines the modules inside the repository.
* Wrappers:: Treat directories as files
* commit files:: The commit support files
* commitinfo:: Pre-commit checking
-* editinfo:: Specifying how log messages are created
+* verifymsg:: How are log messages evaluated?
+* editinfo:: Specifying how log messages are created
+ (obsolete)
* loginfo:: Where should log messages be sent?
* rcsinfo:: Templates for the log messages
* cvsignore:: Ignoring files via cvsignore
* history file:: History information
-* Setting up:: Setting up the repository
* Variables:: Various variables are expanded
@end menu
@@ -6771,9 +9746,33 @@ in the @sc{cvs} source repository.
A module definition can refer to other modules by
including @samp{&@var{module}} in its definition.
@code{checkout} creates a subdirectory for each such
-module, in your working directory.
-@c -- Nope. "in your working directory" is wrong. What
-@c -- is right?
+module, in the directory containing the module. For
+example, if modules contains
+
+@example
+m4test &unsupported
+@end example
+
+then a checkout will create an @code{m4test} directory
+which contains a directory called @code{unsupported},
+which in turns contains all the directories and files
+which live there.
+@c FIXME: this is hard to describe since we don't tell
+@c the user what the repository contains. Best way to
+@c fix this whole mess is an extended example where we
+@c first say what is in the repository, then show a
+@c regular module, an alias module, and an & module.
+@c We should mention the concept of options only
+@c *after* we've taken care of those basics.
+@c
+@c FIXCVS: What happens if regular and & modules are
+@c combined, as in "ampermodule first-dir &second-dir"?
+@c When I tried it, it seemed to just ignore the
+@c "first-dir". I think perhaps it should be an error
+@c (but this needs further investigation).
+@c In addition to discussing what each one does, we
+@c should put in a few words about why you would use one or
+@c the other in various situations.
@table @code
@item -d @var{name}
@@ -6785,6 +9784,7 @@ module name.
Specify a program @var{prog} to run whenever files in a
module are exported. @var{prog} runs with a single
argument, the module name.
+@c FIXME: Is it run on server? client?
@cindex Checkin program
@item -i @var{prog}
@@ -6792,14 +9792,16 @@ Specify a program @var{prog} to run whenever files in a
module are committed. @var{prog} runs with a single
argument, the full pathname of the affected directory
in a source repository. The @file{commitinfo},
-@file{loginfo}, and @file{editinfo} files provide other
+@file{loginfo}, and @file{verifymsg} files provide other
ways to call a program on commit.
+@c FIXME: Is it run on server? client?
@cindex Checkout program
@item -o @var{prog}
Specify a program @var{prog} to run whenever files in a
module are checked out. @var{prog} runs with a single
argument, the module name.
+@c FIXME: Is it run on server? client?
@cindex Status of a module
@cindex Module status
@@ -6819,6 +9821,7 @@ module are tagged with @code{rtag}. @var{prog} runs
with two arguments: the module name and the symbolic
tag specified to @code{rtag}. There is no way to
specify a program to run when @code{tag} is executed.
+@c FIXME: Is it run on server? client?
@cindex Update program
@item -u @var{prog}
@@ -6827,6 +9830,7 @@ update} is executed from the top-level directory of the
checked-out module. @var{prog} runs with a single
argument, the full path to the source repository for
this module.
+@c FIXME: Is it run on server? client?
@end table
@end table
@@ -6837,9 +9841,14 @@ this module.
@cindex CVSWRAPPERS, environment variable
@cindex Wrappers
+@c FIXME: need some better way of separating this out
+@c by functionality. -t/-f is one feature, -m is
+@c another, and -k is a third. And this discussion
+@c should be better motivated (e.g. start with the
+@c problems, then explain how the feature solves it).
+
Wrappers allow you to set a hook which transforms files on
-their way in and out of @sc{cvs}. Most or all of the
-wrappers features do not work with client/server @sc{cvs}.
+their way in and out of @sc{cvs}.
The file @file{cvswrappers} defines the script that will be
run on a file when its name matches a regular
@@ -6848,7 +9857,8 @@ file or directory. One script is executed on the file/directory
before being checked into the repository (this is denoted
with the @code{-t} flag) and the other when the file is
checked out of the repository (this is denoted with the
-@code{-f} flag)
+@code{-f} flag). The @samp{-t}/@samp{-f} feature does
+not work with client/server @sc{cvs}.
The @file{cvswrappers} also has a @samp{-m} option to
specify the merge methodology that should be used when
@@ -6867,13 +9877,16 @@ binary files.
The basic format of the file @file{cvswrappers} is:
+@c FIXME: @example is all wrong for this. Use @deffn or
+@c something more sensible.
@example
wildcard [option value][option value]...
where option is one of
--f from cvs filter value: path tofilter
+-f from cvs filter value: path to filter
-t to cvs filter value: path to filter
-m update methodology value: MERGE or COPY
+-k keyword expansion value: expansion mode
and value is a single-quote delimited value.
@end example
@@ -6894,6 +9907,11 @@ file is checked out of the repository. The
methodology should be used when updating the files in
the repository (that is no merging should be performed).
+@c What pitfalls arise when using indent this way? Is
+@c it a winning thing to do? Would be nice to at least
+@c hint at those issues; we want our examples to tell
+@c how to solve problems, not just to say that cvs can
+@c do certain things.
The last example line says that all files that end with
a @code{*.c} should be filtered with @file{indent}
before being checked into the repository. Unlike the previous
@@ -6911,6 +9929,57 @@ which is the name of the file to filter from. The end
result of this filter will be a file in the users directory
that they can work on as they normally would.
+Note that the @samp{-t}/@samp{-f} features do not
+conveniently handle one portion of CVS's operation:
+determining when files are modified. CVS will still
+want a file (or directory) to exist, and it will use
+its modification time to determine whether a file is
+modified. If CVS erroneously thinks a file is
+unmodified (for example, a directory is unchanged but
+one of the files within it is changed), you can force
+it to check in the file anyway by specifying the
+@samp{-f} option to @code{cvs commit} (@pxref{commit
+options}).
+@c This is, of course, a serious design flaw in -t/-f.
+@c Probably the whole functionality needs to be
+@c redesigned (starting from requirements) to fix this.
+
+For another example, the following command imports a
+directory, treating files whose name ends in
+@samp{.exe} as binary:
+
+@example
+cvs import -I ! -W "*.exe -k 'b'" first-dir vendortag reltag
+@end example
+
+@c Another good example, would be storing files
+@c (e.g. binary files) compressed in the repository.
+@c ::::::::::::::::::
+@c cvswrappers
+@c ::::::::::::::::::
+@c *.t12 -m 'COPY'
+@c *.t[0-9][0-9] -f 'gunzipcp %s' -t 'gzipcp %s %s' -m 'COPY'
+@c
+@c ::::::::::::::::::
+@c gunzipcp
+@c ::::::::::::::::::
+@c :
+@c [ -f $1 ] || exit 1
+@c zcat $1 > /tmp/.#$1.$$
+@c mv /tmp/.#$1.$$ $1
+@c
+@c ::::::::::::::::::
+@c gzipcp
+@c ::::::::::::::::::
+@c :
+@c DIRNAME=`echo $1 | sed -e "s|/.*/||g"`
+@c if [ ! -d $DIRNAME ] ; then
+@c DIRNAME=`echo $1 | sed -e "s|.*/||g"`
+@c fi
+@c gzip -c $DIRNAME > $2
+@c One catch--"cvs diff" will not invoke the wrappers
+@c (probably a CVS bug, although I haven't thought it out).
+
@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node commit files
@appendixsec The commit support files
@@ -6934,12 +10003,19 @@ The program is responsible for checking that the commit
is allowed. If it exits with a non-zero exit status
the commit will be aborted.
+@item verifymsg
+The specified program is used to evaluate the log message,
+and possibly verify that it contains all required
+fields. This is most useful in combination with the
+@file{rcsinfo} file, which can hold a log message
+template (@pxref{rcsinfo}).
+
@item editinfo
The specified program is used to edit the log message,
and possibly verify that it contains all required
fields. This is most useful in combination with the
@file{rcsinfo} file, which can hold a log message
-template (@pxref{rcsinfo}).
+template (@pxref{rcsinfo}). (obsolete)
@item loginfo
The specified program is called when the commit is
@@ -6961,15 +10037,34 @@ imagination is the limit!
@cindex Syntax of info files
@cindex Common syntax of info files
-The four files @file{commitinfo}, @file{loginfo},
-@file{rcsinfo} and @file{editinfo} all have a common
-format. The purpose of the files are described later
-on. The common syntax is described here.
+@c FIXME: having this so totally separate from the
+@c Variables node is rather bogus.
+
+The administrative files such as @file{commitinfo},
+@file{loginfo}, @file{rcsinfo}, @file{verifymsg}, etc.,
+all have a common format. The purpose of the files are
+described later on. The common syntax is described
+here.
+@cindex regular expression syntax
Each line contains the following:
@itemize @bullet
@item
-A regular expression
+@c Say anything about DEFAULT and ALL? Right now we
+@c leave that to the description of each file (and in fact
+@c the practice is inconsistent which is really annoying).
+A regular expression. This is a basic regular
+expression in the syntax used by GNU emacs.
+@c FIXME: What we probably should be saying is "POSIX Basic
+@c Regular Expression with the following extensions (`\('
+@c `\|' '+' etc)"
+@c rather than define it with reference to emacs.
+@c The reference to emacs is not strictly speaking
+@c true, as we don't support \=, \s, or \S. Also it isn't
+@c clear we should document and/or promise to continue to
+@c support all the obscure emacs extensions like \<.
+@c Also need to better cite (or include) full
+@c documentation for the syntax.
@item
A whitespace separator---one or more spaces and/or tabs.
@@ -6988,6 +10083,13 @@ The first regular expression that matches the current
directory name in the repository is used. The rest of the line
is used as a file name or command-line as appropriate.
+@c FIXME: need an example. In particular, show what
+@c the regular expression is matched against (one
+@c ordinarily clueful person got confused about whether it
+@c includes the filename--"directory name" above should be
+@c unambiguous but there is nothing like an example to
+@c confirm people's understanding of this sort of thing).
+
@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node commitinfo
@appendixsec Commitinfo
@@ -7032,14 +10134,129 @@ Note: when @sc{CVS} is accessing a remote repository,
(i.e., server) side, not the client side (@pxref{Remote
repositories}).
+@c FIXME: should discuss using commitinfo to control
+@c who has checkin access to what (e.g. Joe can check into
+@c directories a, b, and c, and Mary can check into
+@c directories b, c, and d--note this case cannot be
+@c conveniently handled with unix groups). Of course,
+@c adding a new set of features to CVS might be a more
+@c natural way to fix this problem than telling people to
+@c use commitinfo.
+@c FIXME: Should make some reference, especially in
+@c the context of controlling who has access, to the fact
+@c that commitinfo can be circumvented. Perhaps
+@c mention SETXID (but has it been carefully examined
+@c for holes?). This fits in with the discussion of
+@c general CVS security in "Password authentication
+@c security" (the bit which is not pserver-specific).
+
+@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
+@node verifymsg
+@appendixsec Verifying log messages
+@cindex verifymsg (admin file)
+@cindex log message, verifying
+
+Once you have entered a log message, you can evaluate
+that message to check for specific content, such as
+a bug ID. Use the @file{verifymsg} file to
+specify a program that is used to verify the log message.
+This program could be a simple script that checks
+that the entered message contains the required fields.
+
+The @file{verifymsg} file is often most useful together
+with the @file{rcsinfo} file, which can be used to
+specify a log message template.
+
+Each line in the @file{verifymsg} file consists of a
+regular expression and a command-line template. The
+template must include a program name, and can include
+any number of arguments. The full path to the current
+log message template file is appended to the template.
+
+One thing that should be noted is that the @samp{ALL}
+keyword is not supported. If more than one matching
+line is found, the first one is used. This can be
+useful for specifying a default verification script in a
+module, and then overriding it in a subdirectory.
+
+@cindex DEFAULT in verifymsg
+If the repository name does not match any of the
+regular expressions in this file, the @samp{DEFAULT}
+line is used, if it is specified.
+
+If the verification script exits with a non-zero exit status,
+the commit is aborted.
+
+Note that the verification script cannot change the log
+message; it can merely accept it or reject it.
+@c FIXME? Is this an annoying limitation? It would be
+@c relatively easy to fix (although it would *not* be a
+@c good idea for a verifymsg script to interact with the user
+@c at least in the client/server case because of locks
+@c and all that jazz).
+
+The following is a little silly example of a
+@file{verifymsg} file, together with the corresponding
+@file{rcsinfo} file, the log message template and an
+verification script. We begin with the log message template.
+We want to always record a bug-id number on the first
+line of the log message. The rest of log message is
+free text. The following template is found in the file
+@file{/usr/cvssupport/tc.template}.
+
+@example
+BugId:
+@end example
+
+The script @file{/usr/cvssupport/bugid.verify} is used to
+evaluate the log message.
+
+@example
+#!/bin/sh
+#
+# bugid.verify filename
+#
+# Verify that the log message contains a valid bugid
+# on the first line.
+#
+if head -1 < $1 | grep '^BugId:[ ]*[0-9][0-9]*$' > /dev/null; then
+ exit 0
+else
+ echo "No BugId found."
+ exit 1
+fi
+@end example
+
+The @file{verifymsg} file contains this line:
+
+@example
+^tc /usr/cvssupport/bugid.edit
+@end example
+
+The @file{rcsinfo} file contains this line:
+
+@example
+^tc /usr/cvssupport/tc.template
+@end example
+
+
+
@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node editinfo
@appendixsec Editinfo
-@cindex Editinfo
+@cindex editinfo (admin file)
@cindex Editor, specifying per module
@cindex Per-module editor
@cindex Log messages, editing
+@emph{NOTE:} The @file{editinfo} feature has been
+rendered obsolete. To set a default editor for log
+messages use the @code{EDITOR} environment variable
+(@pxref{Environment variables}) or the @samp{-e} global
+option (@pxref{Global options}). See @ref{verifymsg},
+for information on the use of the @file{verifymsg}
+feature for evaluating log messages.
+
If you want to make sure that all log messages look the
same way, you can use the @file{editinfo} file to
specify a program that is used to edit the log message.
@@ -7053,8 +10270,7 @@ file, the editor specified in the environment variable
@code{$CVSEDITOR} is used instead. If that variable is
not set, then the environment variable @code{$EDITOR}
is used instead. If that variable is not
-set a precompiled default, normally @code{vi}, will be
-used.
+set a default will be used. See @ref{Committing your changes}.
The @file{editinfo} file is often most useful together
with the @file{rcsinfo} file, which can be used to
@@ -7081,9 +10297,10 @@ If the edit script exits with a non-zero exit status,
the commit is aborted.
Note: when @sc{CVS} is accessing a remote repository,
-@file{editinfo} will be run on the @emph{remote}
-(i.e., server) side, not the client side (@pxref{Remote
-repositories}).
+or when the @samp{-m} or @samp{-F} options to @code{cvs
+commit} are used, @file{editinfo} will not be consulted.
+There is no good workaround for this; use
+@file{verifymsg} instead.
@menu
* editinfo example:: Editinfo example
@@ -7145,7 +10362,7 @@ The @file{rcsinfo} file contains this line:
@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node loginfo
@appendixsec Loginfo
-@cindex Loginfo
+@cindex loginfo (admin file)
@cindex Storing log messages
@cindex Mailing log messages
@cindex Distributing log messages
@@ -7159,11 +10376,6 @@ relative to the @code{$CVSROOT}. If a match is found, then
the remainder of the line is a filter program that
should expect log information on its standard input.
-The filter program may use one and only one % modifier
-(a la printf). If @samp{%s} is specified in the filter
-program, a brief title is included (enclosed in single
-quotes) showing the modified file names.
-
If the repository name does not match any of the
regular expressions in this file, the @samp{DEFAULT}
line is used, if it is specified.
@@ -7177,6 +10389,46 @@ The first matching regular expression is used.
@xref{commit files}, for a description of the syntax of
the @file{loginfo} file.
+The user may specify a format string as
+part of the filter. The string is composed of a
+@samp{%} followed by a space, or followed by a single
+format character, or followed by a set of format
+characters surrounded by @samp{@{} and @samp{@}} as
+separators. The format characters are:
+
+@table @t
+@item s
+file name
+@item V
+old version number (pre-checkin)
+@item v
+new version number (post-checkin)
+@end table
+
+All other characters that appear in a format string
+expand to an empty field (commas separating fields are
+still provided).
+
+For example, some valid format strings are @samp{%},
+@samp{%s}, @samp{%@{s@}}, and @samp{%@{sVv@}}.
+
+The output will be a string of tokens separated by
+spaces. For backwards compatibility, the the first
+token will be the repository name. The rest of the
+tokens will be comma-delimited lists of the information
+requested in the format string. For example, if
+@samp{/u/src/master} is the repository, @samp{%@{sVv@}}
+is the format string, and three files (@t{ChangeLog},
+@t{Makefile}, @t{foo.c}) were modified, the output
+might be:
+
+@example
+/u/src/master ChangeLog,1.1,1.2 Makefile,1.3,1.4 foo.c,1.12,1.13
+@end example
+
+As another example, @samp{%@{@}} means that only the
+name of the repository will be generated.
+
Note: when @sc{CVS} is accessing a remote repository,
@file{loginfo} will be run on the @emph{remote}
(i.e., server) side, not the client side (@pxref{Remote
@@ -7184,6 +10436,7 @@ repositories}).
@menu
* loginfo example:: Loginfo example
+* Keeping a checked out copy:: Updating a tree on every checkin
@end menu
@c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
@@ -7214,17 +10467,66 @@ like this:
@example
#!/bin/sh
-(echo "-----------------------------------------------------------------";
+(echo "------------------------------------------------------";
echo -n $USER" ";
date;
echo;
sed '1s+'$@{CVSROOT@}'++') >> $1
@end example
+@node Keeping a checked out copy
+@appendixsubsec Keeping a checked out copy
+
+@c What other index entries? It seems like
+@c people might want to use a lot of different
+@c words for this functionality.
+@cindex keeping a checked out copy
+@cindex checked out copy, keeping
+@cindex web pages, maintaining with CVS
+
+It is often useful to maintain a directory tree which
+contains files which correspond to the latest version
+in the repository. For example, other developers might
+want to refer to the latest sources without having to
+check them out, or you might be maintaining a web site
+with @sc{cvs} and want every checkin to cause the files
+used by the web server to be updated.
+@c Can we offer more details on the web example? Or
+@c point the user at how to figure it out? This text
+@c strikes me as sufficient for someone who already has
+@c some idea of what we mean but not enough for the naive
+@c user/sysadmin to understand it and set it up.
+
+The way to do this is by having loginfo invoke
+@code{cvs update}. Doing so in the naive way will
+cause a problem with locks, so the @code{cvs update}
+must be run in the background.
+@c Should we try to describe the problem with locks?
+@c It seems like a digression for someone who just
+@c wants to know how to make it work.
+@c Another choice which might work for a single file
+@c is to use "cvs -n update -p" which doesn't take
+@c out locks (I think) but I don't see many advantages
+@c of that and we might as well document something which
+@c works for multiple files.
+Here is an example (this should all be on one line):
+
+@example
+^cyclic-pages (date; cat; (sleep 2; cd /u/www/local-docs;
+ cvs -q update -d) &) >> $CVSROOT/CVSROOT/updatelog 2>&1
+@end example
+
+This will cause checkins to repository directories
+starting with @code{cyclic-pages} to update the checked
+out tree in @file{/u/www/local-docs}.
+@c More info on some of the details? The "sleep 2" is
+@c so if we are lucky the lock will be gone by the time
+@c we start and we can wait 2 seconds instead of 30.
+
@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node rcsinfo
@appendixsec Rcsinfo
-@cindex Rcsinfo
+@cindex rcsinfo (admin file)
@cindex Form for log message
@cindex Log message template
@cindex Template for log message
@@ -7232,7 +10534,7 @@ like this:
The @file{rcsinfo} file can be used to specify a form to
edit when filling out the commit log. The
@file{rcsinfo} file has a syntax similar to the
-@file{editinfo}, @file{commitinfo} and @file{loginfo}
+@file{verifymsg}, @file{commitinfo} and @file{loginfo}
files. @xref{syntax}. Unlike the other files the second
part is @emph{not} a command-line template. Instead,
the part after the regular expression should be a full pathname to
@@ -7246,13 +10548,26 @@ All occurances of the name @samp{ALL} appearing as a
regular expression are used in addition to the first
matching regular expression or @samp{DEFAULT}.
+@c FIXME: should be offering advice, somewhere around
+@c here, about where to put the template file. The
+@c verifymsg example uses /usr/cvssupport but doesn't
+@c say anything about what that directory is for or
+@c whether it is hardwired into CVS or who creates
+@c it or anything. In particular we should say
+@c how to version control the template file. A
+@c probably better answer than the /usr/cvsssupport
+@c stuff is to use checkoutlist. FIXME: it doesn't
+@c seem like checkoutlist is documented at all!
+@c Also I am starting to see a connection between
+@c this and the Keeping a checked out copy node.
+@c Probably want to say something about that.
The log message template will be used as a default log
message. If you specify a log message with @samp{cvs
commit -m @var{message}} or @samp{cvs commit -f
@var{file}} that log message will override the
template.
-@xref{editinfo example}, for an example @file{rcsinfo}
+@xref{verifymsg}, for an example @file{rcsinfo}
file.
When @sc{CVS} is accessing a remote repository,
@@ -7269,7 +10584,7 @@ directory.
@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node cvsignore
@appendixsec Ignoring files via cvsignore
-@cindex Cvsignore, global
+@cindex cvsignore (admin file), global
@cindex Global cvsignore
@cindex Ignoring files
@c -- This chapter should maybe be moved to the
@@ -7343,6 +10658,20 @@ exclamation mark (@samp{!}) clears the ignore list.
This can be used if you want to store any file which
normally is ignored by @sc{cvs}.
+Specifying @samp{-I !} to @code{cvs import} will import
+everything, which is generally what you want to do if
+you are importing files from a pristine distribution or
+any other source which is known to not contain any
+extraneous files. However, looking at the rules above
+you will see there is a fly in the ointment; if the
+distribution contains any @file{.cvsignore} files, then
+the patterns from those files will be processed even if
+@samp{-I !} is specified. The only workaround is to
+remove the @file{.cvsignore} files in order to do the
+import. Because this is awkward, in the future
+@samp{-I !} might be modified to override
+@file{.cvsignore} files in each directory.
+
@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@node history file
@appendixsec The history file
@@ -7354,7 +10683,7 @@ to log information for the @code{history} command
(@pxref{history}). This file must be created to turn
on logging. This is done automatically if the
@code{cvs init} command is used to set up the
-repository (@pxref{Setting up}).
+repository (@pxref{Creating a repository}).
The file format of the @file{history} file is
documented only in comments in the @sc{cvs} source
@@ -7362,39 +10691,6 @@ code, but generally programs should use the @code{cvs
history} command to access it anyway, in case the
format changes with future releases of @sc{cvs}.
-@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-@node Setting up
-@appendixsec Setting up the repository
-@cindex Repository, setting up
-@cindex Creating a repository
-@cindex Setting up a repository
-
-To set up a @sc{cvs} repository, choose a directory
-with ample disk space available for the revision
-history of the source files. It should be accessable
-(directly or via a networked file system) from all
-machines which want to use @sc{cvs} in server or local
-mode; the client machines need not have any access to
-it other than via the @sc{cvs} protocol.
-
-To create a repository, run the @code{cvs init}
-command. It will set up an empty repository in the
-@sc{cvs} root specified in the usual way
-(@pxref{Repository}). For example,
-
-@example
-cvs -d /usr/local/cvsroot init
-@end example
-
-@code{cvs init} is careful to never overwrite any
-existing files in the repository, so no harm is done if
-you run @code{cvs init} on an already set-up
-repository.
-
-@code{cvs init} will enable history logging; if you
-don't want that, remove the history file after running
-@code{cvs init}. @xref{history file}.
-
@node Variables
@appendixsec Expansions in administrative files
@@ -7462,7 +10758,14 @@ particularly useful to specify this option via
For example, if you want the administrative file to
refer to a test directory you might create a user
variable @code{TESTDIR}. Then if @sc{cvs} is invoked
-as @code{cvs -s TESTDIR=/work/local/tests}, and the
+as
+
+@example
+cvs -s TESTDIR=/work/local/tests
+@end example
+
+@noindent
+and the
administrative file contains @code{sh
$@{=TESTDIR@}/runtests}, then that string is expanded
to @code{sh /work/local/tests/runtests}.
@@ -7492,6 +10795,7 @@ A whitespace-separated list of file name patterns that
@sc{cvs} should treat as wrappers. @xref{Wrappers}.
@cindex CVSREAD
+@cindex read-only files, and CVSREAD
@item $CVSREAD
If this is set, @code{checkout} and @code{update} will
try hard to make the files in your working directory
@@ -7517,11 +10821,8 @@ directory.
@item $EDITOR
@itemx $CVSEDITOR
Specifies the program to use for recording log messages
-during commit. If not set, the default is
-@samp{/usr/ucb/vi}. @code{$CVSEDITOR} overrides
-@code{$EDITOR}. @code{$CVSEDITOR} does not exist in
-@sc{cvs} 1.3, but the next release will probably
-include it.
+during commit. @code{$CVSEDITOR} overrides
+@code{$EDITOR}. See @ref{Committing your changes}.
@cindex PATH
@item $PATH
@@ -7531,9 +10832,10 @@ programs it uses.
@cindex RCSBIN
@item $RCSBIN
-Specifies the full pathname of the location of @sc{rcs} programs,
-such as co(1) and ci(1). If not set, a compiled-in
-value is used, or your @code{$PATH} is searched.
+This is the value @sc{cvs} is using for where to find
+@sc{rcs} binaries. @xref{Global options}, for a
+description of how to specify this. If not set, a
+compiled-in value is used, or your @code{$PATH} is searched.
@cindex HOME
@item $HOME
@@ -7545,13 +10847,9 @@ file is searched (@code{$HOMEPATH} is used for Windows-NT).
@cindex CVS_RSH
@item $CVS_RSH
-Used in client-server mode when accessing a remote
-repository using @sc{rsh}. The default value is
-@code{rsh}. You can set it to use another program for
-accssing the remote server (e.g. for HP-UX 9, you
-should set it to @code{remsh} because @code{rsh}
-invokes the restricted shell). @pxref{Connecting via
-rsh}
+Specifies the external program which CVS connects with,
+when @code{:ext:} access method is specified.
+@pxref{Connecting via rsh}.
@item $CVS_SERVER
Used in client-server mode when accessing a remote
@@ -7565,11 +10863,6 @@ Used in client-server mode when accessing the @code{cvs
login server}. Default value is @file{$HOME/.cvspass}.
@pxref{Password authentication client}
-@item $CVS_PASSWORD
-Used in client-server mode when accessing the @code{cvs
-login server}.
-@pxref{Password authentication client}
-
@item $CVS_CLIENT_PORT
Used in client-server mode when accessing the server
via Kerberos.
@@ -7605,10 +10898,37 @@ seconds so that you can attach to it with a debugger.
Used under OS/2 only. It specifies the name of the
command interpreter and defaults to @sc{cmd.exe}.
+@cindex TMPDIR
+@item $TMPDIR
+@cindex TMP
+@itemx $TMP
+@cindex TEMP
+@itemx $TEMP
+@cindex temporary files, location of
+@c I'm not even sure I've documented all the
+@c conventions here. Furthermore, those conventions are
+@c pretty crazy and they should be simplified.
+Directory in which temporary files are located. Those
+parts of @sc{cvs} which are implemented using @sc{rcs}
+inspect the above variables in the order they appear
+above and the first value found is taken; if none of
+them are set, a host-dependent default is used,
+typically @file{/tmp}. The @sc{cvs} server uses
+@code{TMPDIR}. @xref{Global options}, for a
+description of how to specify this.
+Some parts of @sc{cvs} will always use @file{/tmp} (via
+the @code{tmpnam} function provided by the system).
+
+On Windows NT, @code{TMP} is used (via the @code{_tempnam}
+function provided by the system).
+The @code{patch} program which is used by the @sc{cvs}
+client uses @code{TMPDIR}, and if it is not set, uses
+@file{/tmp} (at least with GNU patch 2.1).
@end table
-@sc{cvs} is a front-end to @sc{rcs}. The following environment
+@sc{cvs} invokes @sc{rcs} to perform certain
+operations. The following environment
variables affect @sc{rcs}. Note that if you are using
the client/server @sc{cvs}, these variables need to be
set on the server side (which may or not may be
@@ -7631,18 +10951,6 @@ Options prepended to the argument list, separated by
spaces. A backslash escapes spaces within an option.
The @code{$RCSINIT} options are prepended to the
argument lists of most @sc{rcs} commands.
-
-@cindex TMPDIR
-@item $TMPDIR
-@cindex TMP
-@itemx $TMP
-@cindex TEMP
-@itemx $TEMP
-Name of the temporary directory. The environment
-variables are inspected in the order they appear above
-and the first value found is taken; if none of them are
-set, a host-dependent default is used, typically
-@file{/tmp}.
@end table
@c ---------------------------------------------------------------------
@@ -7650,7 +10958,7 @@ set, a host-dependent default is used, typically
@appendix Troubleshooting
@menu
-* Magic branch numbers:: Magic branch numbers
+* Error messages:: Partial list of CVS errors
@end menu
@ignore
@@ -7661,64 +10969,567 @@ set, a host-dependent default is used, typically
@c -- Give hints on how to fix them
@end ignore
-@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-@node Magic branch numbers
-@appendixsec Magic branch numbers
+@node Error messages
+@appendixsec Partial list of error messages
-Externally, branch numbers consist of an odd number of
-dot-separated decimal integers. @xref{Revision
-numbers}. That is not the whole truth, however. For
-efficiency reasons @sc{cvs} sometimes inserts an extra 0
-in the second rightmost position (1.2.3 becomes
-1.2.0.3, 8.9.10.11.12 becomes 8.9.10.11.0.12 and so
-on).
+Here is a partial list of error messages that you may
+see from @sc{cvs}. It is not a complete list---@sc{cvs}
+is capable of printing many, many error messages, often
+with parts of them supplied by the operating system,
+but the intention is to list the common and/or
+potentially confusing error messages.
-@sc{cvs} does a pretty good job at hiding these so
-called magic branches, but in at least four places the
-hiding is incomplete.
+The messages are alphabetical, but introductory text
+such as @samp{cvs update: } is not considered in
+ordering them.
-@itemize @bullet
+In some cases the list includes messages printed by old
+versions of @sc{cvs} (partly because users may not be
+sure which version of @sc{cvs} they are using at any
+particular moment).
+
+@table @code
+@c FIXME: What is the correct way to format a multiline
+@c error message here? Maybe @table is the wrong
+@c choice? Texinfo gurus?
+@item cannot change permissions on temporary directory
+@example
+Operation not permitted
+@end example
+This message has been happening in a non-reproducible,
+occasional way when we run the client/server testsuite,
+both on Red Hat Linux 3.0.3 and 4.1. We haven't been
+able to figure out what causes it, nor is it known
+whether it is specific to linux (or even to this
+particular machine!). If the problem does occur on
+other unices, @samp{Operation not permitted} would be
+likely to read @samp{Not owner} or whatever the system
+in question uses for the unix @code{EPERM} error. If
+you have any information to add, please let us know as
+described in @ref{BUGS}. If you experience this error
+while using @sc{cvs}, retrying the operation which
+produced it should work fine.
+@c Most recently this was in the multibranch-5 test.
+@c But I'm not sure it is specific to that test.
+
+@c For one example see basica-1a10 in the testsuite
+@c For another example, "cvs co ." on NT; see comment
+@c at windows-NT/filesubr.c (expand_wild).
+@item cannot open CVS/Entries for reading: No such file or directory
+This generally indicates a @sc{cvs} internal error, and
+can be handled as with other @sc{cvs} bugs
+(@pxref{BUGS}). Usually there is a workaround---the
+exact nature of which would depend on the situation but
+which hopefully could be figured out.
+
+@item cvs [update aborted]: could not patch @var{file}: No such file or directory
+This means that there was a problem finding the
+@code{patch} program. Make sure that it is in your
+@code{PATH}. Note that despite appearances the message
+is @emph{not} referring to whether it can find @var{file}.
+@c Future versions of @sc{cvs} are
+@c expected to dispense with the need for an external
+@c patch program, but might as well not advertise
+@c vaporware.
+@c Even after that change is made, probably want to
+@c preserve this message, see above about old messages.
+
+@item cvs update: could not patch @var{file}; will refetch
+This means that for whatever reason the client was
+unable to apply a patch that the server sent. The
+message is nothing to be concerned about, because
+inability to apply the patch only slows things down and
+has no effect on what @sc{cvs} does.
+@c xref to update output. Or File status?
+@c Or some place else that
+@c explains this whole "patch"/P/Needs Patch thing?
+
+@item dying gasps from @var{server} unexpected
+This message seems to be caused by a hard-to-track-down
+bug in @sc{cvs} or the systems it runs on (we don't
+know---we haven't tracked it down yet!). If you see it,
+you probably can just retry the operation which failed,
+or if you have discovered information concerning its
+cause, please let us know as described in @ref{BUGS}.
+
+@item end of file from server (consult above messages if any)
+The most common cause for this message is if you are
+using an external @code{rsh} program and it exited with
+an error. In this case the @code{rsh} program should
+have printed a message, which will appear before the
+above message. For more information on setting up a
+@sc{cvs} client and server, see @ref{Remote repositories}.
+
+@cindex mkmodules
+@item cvs commit: Executing 'mkmodules'
+This means that your repository is set up for a version
+of @sc{cvs} prior to @sc{cvs} 1.8. When using @sc{cvs}
+1.8 or later, the above message will be preceded by
+
+@example
+cvs commit: Rebuilding administrative file database
+@end example
+
+If you see both messages, the database is being rebuilt
+twice, which is unnecessary but harmless. If you wish
+to avoid the duplication, and you have no versions of
+@sc{cvs} 1.7 or earlier in use, remove @code{-i mkmodules}
+every place it appears in your @code{modules}
+file. For more information on the @code{modules} file,
+see @ref{modules}.
+
+@item cvs [server aborted]: received broken pipe signal
+This message seems to be caused by a hard-to-track-down
+bug in @sc{cvs} or the systems it runs on (we don't
+know---we haven't tracked it down yet!). It seems to
+happen only after a @sc{cvs} command has completed, and
+you should be able to just ignore the message.
+However, if you have discovered information concerning its
+cause, please let us know as described in @ref{BUGS}.
+
+@item cvs commit: Up-to-date check failed for `@var{file}'
+This means that someone else has committed a change to
+that file since the last time that you did a @code{cvs
+update}. So before proceeding with your @code{cvs
+commit} you need to @code{cvs update}. CVS will merge
+the changes that you made and the changes that the
+other person made. If it does not detect any conflicts
+it will report @samp{M cacErrCodes.h} and you are ready
+to @code{cvs commit}. If it detects conflicts it will
+print a message saying so, will report @samp{C cacErrCodes.h},
+and you need to manually resolve the
+conflict. For more details on this process see
+@ref{Conflicts example}.
+
+@item Usage: diff3 [-exEX3 [-i | -m] [-L label1 -L label3]] file1 file2 file3
+@example
+Only one of [exEX3] allowed
+@end example
+This indicates a problem with the installation of
+@code{diff3} and @code{rcsmerge}. Specifically
+@code{rcsmerge} was compiled to look for GNU diff3, but
+it is finding unix diff3 instead. The exact text of
+the message will vary depending on the system. The
+solution is to make sure @code{rcsmerge} finds GNU
+diff3. Depending on how @code{rcsmerge} was compiled,
+it might be sufficient to place GNU diff3 in your
+@code{PATH}, or it might be necessary to recompile
+@code{rcsmerge} or find a binary distribution of
+@code{rcsmerge} which looks in the @code{PATH}.
+@c Should we mention the cvsaux binaries here?
+
+@item cvs commit: warning: editor session failed
+This means that the editor which @sc{cvs} is using exits with a nonzero
+exit status. Some versions of vi will do this even when there was not
+a problem editing the file. If so, point the
+@sc{CVSEDITOR} environment variable to a small script
+such as:
+
+@example
+#!/bin/sh
+vi $*
+exit 0
+@end example
+
+@c "warning: foo was lost" and "no longer pertinent" (both normal).
+@c Would be nice to write these up--they are
+@c potentially confusing for the new user.
+@end table
+
+@c ---------------------------------------------------------------------
+@node Copying
+@appendix GNU GENERAL PUBLIC LICENSE
+@center Version 2, June 1991
+
+@display
+Copyright @copyright{} 1989, 1991 Free Software Foundation, Inc.
+59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
+
+Everyone is permitted to copy and distribute verbatim copies
+of this license document, but changing it is not allowed.
+@end display
+
+@unnumberedsec Preamble
+
+ The licenses for most software are designed to take away your
+freedom to share and change it. By contrast, the GNU General Public
+License is intended to guarantee your freedom to share and change free
+software---to make sure the software is free for all its users. This
+General Public License applies to most of the Free Software
+Foundation's software and to any other program whose authors commit to
+using it. (Some other Free Software Foundation software is covered by
+the GNU Library General Public License instead.) You can apply it to
+your programs, too.
+
+ When we speak of free software, we are referring to freedom, not
+price. Our General Public Licenses are designed to make sure that you
+have the freedom to distribute copies of free software (and charge for
+this service if you wish), that you receive source code or can get it
+if you want it, that you can change the software or use pieces of it
+in new free programs; and that you know you can do these things.
+
+ To protect your rights, we need to make restrictions that forbid
+anyone to deny you these rights or to ask you to surrender the rights.
+These restrictions translate to certain responsibilities for you if you
+distribute copies of the software, or if you modify it.
+
+ For example, if you distribute copies of such a program, whether
+gratis or for a fee, you must give the recipients all the rights that
+you have. You must make sure that they, too, receive or can get the
+source code. And you must show them these terms so they know their
+rights.
+
+ We protect your rights with two steps: (1) copyright the software, and
+(2) offer you this license which gives you legal permission to copy,
+distribute and/or modify the software.
+
+ Also, for each author's protection and ours, we want to make certain
+that everyone understands that there is no warranty for this free
+software. If the software is modified by someone else and passed on, we
+want its recipients to know that what they have is not the original, so
+that any problems introduced by others will not reflect on the original
+authors' reputations.
+
+ Finally, any free program is threatened constantly by software
+patents. We wish to avoid the danger that redistributors of a free
+program will individually obtain patent licenses, in effect making the
+program proprietary. To prevent this, we have made it clear that any
+patent must be licensed for everyone's free use or not licensed at all.
+
+ The precise terms and conditions for copying, distribution and
+modification follow.
+
+@iftex
+@heading TERMS AND CONDITIONS FOR COPYING,
+@heading DISTRIBUTION AND MODIFICATION
+@end iftex
+@ifinfo
+@center TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
+@end ifinfo
+
+@enumerate 0
@item
-The magic branch can appear in the output from
-@code{cvs status} in vanilla @sc{cvs} 1.3. This is
-fixed in @sc{cvs} 1.3-s2.
+This License applies to any program or other work which contains
+a notice placed by the copyright holder saying it may be distributed
+under the terms of this General Public License. The ``Program'', below,
+refers to any such program or work, and a ``work based on the Program''
+means either the Program or any derivative work under copyright law:
+that is to say, a work containing the Program or a portion of it,
+either verbatim or with modifications and/or translated into another
+language. (Hereinafter, translation is included without limitation in
+the term ``modification''.) Each licensee is addressed as ``you''.
+
+Activities other than copying, distribution and modification are not
+covered by this License; they are outside its scope. The act of
+running the Program is not restricted, and the output from the Program
+is covered only if its contents constitute a work based on the
+Program (independent of having been made by running the Program).
+Whether that is true depends on what the Program does.
@item
-The magic branch number appears in the output from
-@code{cvs log}. This is much harder to fix, since
-@code{cvs log} runs @code{rlog} (which is part of the
-@sc{rcs} distribution), and modifying @code{rlog} to
-know about magic branches would probably break someone's
-habits (if they use branch 0 for their own purposes).
+You may copy and distribute verbatim copies of the Program's
+source code as you receive it, in any medium, provided that you
+conspicuously and appropriately publish on each copy an appropriate
+copyright notice and disclaimer of warranty; keep intact all the
+notices that refer to this License and to the absence of any warranty;
+and give any other recipients of the Program a copy of this License
+along with the Program.
+
+You may charge a fee for the physical act of transferring a copy, and
+you may at your option offer warranty protection in exchange for a fee.
@item
-You cannot specify a symbolic branch name to @code{cvs log}.
+You may modify your copy or copies of the Program or any portion
+of it, thus forming a work based on the Program, and copy and
+distribute such modifications or work under the terms of Section 1
+above, provided that you also meet all of these conditions:
+@enumerate a
@item
-You cannot specify a symbolic branch name to @code{cvs
-admin}.
+You must cause the modified files to carry prominent notices
+stating that you changed the files and the date of any change.
-@end itemize
+@item
+You must cause any work that you distribute or publish, that in
+whole or in part contains or is derived from the Program or any
+part thereof, to be licensed as a whole at no charge to all third
+parties under the terms of this License.
-You can use the @code{admin} command to reassign a
-symbolic name to a branch the way @sc{rcs} expects it
-to be. If @code{R4patches} is assigned to the branch
-1.4.2 (magic branch number 1.4.0.2) in file
-@file{numbers.c} you can do this:
+@item
+If the modified program normally reads commands interactively
+when run, you must cause it, when started running for such
+interactive use in the most ordinary way, to print or display an
+announcement including an appropriate copyright notice and a
+notice that there is no warranty (or else, saying that you provide
+a warranty) and that users may redistribute the program under
+these conditions, and telling the user how to view a copy of this
+License. (Exception: if the Program itself is interactive but
+does not normally print such an announcement, your work based on
+the Program is not required to print an announcement.)
+@end enumerate
-@example
-$ cvs admin -NR4patches:1.4.2 numbers.c
-@end example
+These requirements apply to the modified work as a whole. If
+identifiable sections of that work are not derived from the Program,
+and can be reasonably considered independent and separate works in
+themselves, then this License, and its terms, do not apply to those
+sections when you distribute them as separate works. But when you
+distribute the same sections as part of a whole which is a work based
+on the Program, the distribution of the whole must be on the terms of
+this License, whose permissions for other licensees extend to the
+e