aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorPeter Wemm <peter@FreeBSD.org>1998-01-26 03:09:57 +0000
committerPeter Wemm <peter@FreeBSD.org>1998-01-26 03:09:57 +0000
commit57e58c3aa7a2477ce7fa56bfea9d927b4eb43ccd (patch)
treea9812ba7ade0fde6f62c1626b45d522ba104c314
parent3398c9be05502e12d986ef6e89739df1dc9ba9e6 (diff)
downloadsrc-57e58c3aa7a2477ce7fa56bfea9d927b4eb43ccd.tar.gz
src-57e58c3aa7a2477ce7fa56bfea9d927b4eb43ccd.zip
Import cvs-1.9.23 as at 19980123. There are a number of really nice
things fixed in here, including the '-ko' vs. -A problem with remote cvs which caused all files with -ko to be resent each time (which is damn painful over a modem, I can tell you). It also found a heap of stray empty directories that should have been pruned with the -P flag to cvs update but were not for some reason. It also has the fully integrated rcs and diff, so no more fork/exec overheads for rcs,ci,patch,diff,etc. This means that it parses the control data in the rcs files only once rather than twice or more. If the 'cvs diff' vs. Index thing is going to be fixed for future patch compatability, this is the place to do it.
Notes
Notes: svn path=/vendor/cvs/dist/; revision=32785
-rw-r--r--contrib/cvs/BUGS63
-rw-r--r--contrib/cvs/ChangeLog497
-rw-r--r--contrib/cvs/DEVEL-CVS2
-rw-r--r--contrib/cvs/FAQ8596
-rw-r--r--contrib/cvs/HACKING23
-rw-r--r--contrib/cvs/INSTALL248
-rw-r--r--contrib/cvs/MINOR-BUGS4
-rw-r--r--contrib/cvs/Makefile.in9
-rw-r--r--contrib/cvs/NEWS32
-rw-r--r--contrib/cvs/PROJECTS7
-rw-r--r--contrib/cvs/README2
-rw-r--r--contrib/cvs/TESTS9
-rw-r--r--contrib/cvs/TODO453
-rw-r--r--contrib/cvs/acconfig.h20
-rw-r--r--contrib/cvs/config.h.in44
-rwxr-xr-xcontrib/cvs/configure757
-rw-r--r--contrib/cvs/configure.in148
-rw-r--r--contrib/cvs/contrib/ChangeLog36
-rw-r--r--contrib/cvs/contrib/README4
-rw-r--r--contrib/cvs/contrib/pvcs_to_rcs439
-rw-r--r--contrib/cvs/diff/ChangeLog202
-rw-r--r--contrib/cvs/diff/Makefile.in104
-rw-r--r--contrib/cvs/diff/analyze.c1087
-rw-r--r--contrib/cvs/diff/cmpbuf.c40
-rw-r--r--contrib/cvs/diff/cmpbuf.h20
-rw-r--r--contrib/cvs/diff/context.c468
-rw-r--r--contrib/cvs/diff/diagmeet.note71
-rw-r--r--contrib/cvs/diff/diff.c1214
-rw-r--r--contrib/cvs/diff/diff.h345
-rw-r--r--contrib/cvs/diff/diff3.c1809
-rw-r--r--contrib/cvs/diff/dir.c220
-rw-r--r--contrib/cvs/diff/ed.c200
-rw-r--r--contrib/cvs/diff/ifdef.c428
-rw-r--r--contrib/cvs/diff/io.c714
-rw-r--r--contrib/cvs/diff/normal.c71
-rw-r--r--contrib/cvs/diff/side.c284
-rw-r--r--contrib/cvs/diff/system.h270
-rw-r--r--contrib/cvs/diff/util.c722
-rw-r--r--contrib/cvs/diff/version.c5
-rw-r--r--contrib/cvs/doc/ChangeLog699
-rw-r--r--contrib/cvs/doc/RCSFILES14
-rw-r--r--contrib/cvs/doc/cvs.texinfo6063
-rw-r--r--contrib/cvs/doc/cvsclient.texi644
-rw-r--r--contrib/cvs/lib/ChangeLog74
-rw-r--r--contrib/cvs/lib/Makefile.in6
-rw-r--r--contrib/cvs/lib/fncase.c115
-rw-r--r--contrib/cvs/lib/getdate.y32
-rw-r--r--contrib/cvs/lib/getline.c34
-rw-r--r--contrib/cvs/lib/system.h80
-rw-r--r--contrib/cvs/lib/xgetwd.c12
-rw-r--r--contrib/cvs/man/ChangeLog15
-rw-r--r--contrib/cvs/man/cvs.131
-rw-r--r--contrib/cvs/src/ChangeLog1445
-rw-r--r--contrib/cvs/src/ChangeLog-973249
-rw-r--r--contrib/cvs/src/Makefile.in6
-rw-r--r--contrib/cvs/src/add.c343
-rw-r--r--contrib/cvs/src/admin.c721
-rw-r--r--contrib/cvs/src/buffer.c438
-rw-r--r--contrib/cvs/src/buffer.h4
-rw-r--r--contrib/cvs/src/checkin.c16
-rw-r--r--contrib/cvs/src/checkout.c540
-rw-r--r--contrib/cvs/src/classify.c54
-rw-r--r--contrib/cvs/src/client.c1253
-rw-r--r--contrib/cvs/src/client.h28
-rw-r--r--contrib/cvs/src/commit.c196
-rw-r--r--contrib/cvs/src/create_adm.c66
-rw-r--r--contrib/cvs/src/cvs.h118
-rwxr-xr-xcontrib/cvs/src/cvsbug.sh2
-rw-r--r--contrib/cvs/src/cvsrc.c15
-rw-r--r--contrib/cvs/src/diff.c144
-rw-r--r--contrib/cvs/src/edit.c59
-rw-r--r--contrib/cvs/src/entries.c282
-rw-r--r--contrib/cvs/src/error.c8
-rw-r--r--contrib/cvs/src/expand_path.c21
-rw-r--r--contrib/cvs/src/fileattr.c84
-rw-r--r--contrib/cvs/src/fileattr.h11
-rw-r--r--contrib/cvs/src/filesubr.c37
-rw-r--r--contrib/cvs/src/find_names.c25
-rw-r--r--contrib/cvs/src/hash.c51
-rw-r--r--contrib/cvs/src/hash.h4
-rw-r--r--contrib/cvs/src/history.c13
-rw-r--r--contrib/cvs/src/ignore.c51
-rw-r--r--contrib/cvs/src/import.c325
-rw-r--r--contrib/cvs/src/lock.c8
-rw-r--r--contrib/cvs/src/log.c135
-rw-r--r--contrib/cvs/src/login.c81
-rw-r--r--contrib/cvs/src/logmsg.c29
-rw-r--r--contrib/cvs/src/main.c268
-rw-r--r--contrib/cvs/src/mkmodules.c44
-rw-r--r--contrib/cvs/src/modules.c70
-rw-r--r--contrib/cvs/src/myndbm.c11
-rw-r--r--contrib/cvs/src/no_diff.c2
-rw-r--r--contrib/cvs/src/options.h.in82
-rw-r--r--contrib/cvs/src/parseinfo.c185
-rw-r--r--contrib/cvs/src/patch.c105
-rw-r--r--contrib/cvs/src/rcs.c3345
-rw-r--r--contrib/cvs/src/rcs.h111
-rw-r--r--contrib/cvs/src/rcscmds.c617
-rw-r--r--contrib/cvs/src/recurse.c92
-rw-r--r--contrib/cvs/src/release.c21
-rw-r--r--contrib/cvs/src/remove.c19
-rw-r--r--contrib/cvs/src/repos.c60
-rw-r--r--contrib/cvs/src/root.c80
-rw-r--r--contrib/cvs/src/rtag.c30
-rw-r--r--contrib/cvs/src/run.c97
-rwxr-xr-xcontrib/cvs/src/sanity.sh7878
-rw-r--r--contrib/cvs/src/scramble.c157
-rw-r--r--contrib/cvs/src/server.c1209
-rw-r--r--contrib/cvs/src/server.h6
-rw-r--r--contrib/cvs/src/status.c27
-rw-r--r--contrib/cvs/src/subr.c241
-rw-r--r--contrib/cvs/src/tag.c26
-rw-r--r--contrib/cvs/src/update.c342
-rw-r--r--contrib/cvs/src/vers_ts.c64
-rw-r--r--contrib/cvs/src/version.c2
-rw-r--r--contrib/cvs/src/watch.c2
-rw-r--r--contrib/cvs/src/wrapper.c54
-rw-r--r--contrib/cvs/src/zlib.c193
-rw-r--r--contrib/cvs/tools/pcl-cvs/ChangeLog5
-rw-r--r--contrib/cvs/tools/pcl-cvs/INSTALL2
-rw-r--r--contrib/cvs/tools/pcl-cvs/ToDo2
-rw-r--r--contrib/cvs/tools/pcl-cvs/pcl-cvs.el14
122 files changed, 44690 insertions, 8121 deletions
diff --git a/contrib/cvs/BUGS b/contrib/cvs/BUGS
index 6f482b6a6045..58be27c8c6aa 100644
--- a/contrib/cvs/BUGS
+++ b/contrib/cvs/BUGS
@@ -1,12 +1,12 @@
-See the README file for information on how to report bugs (and what
-will happen to your bug reports if you do).
+See the Cederqvist manual (cvs.texinfo) for information on how to
+report bugs (and what will happen to your bug reports if you do).
The following is a list of some of the known bugs. It may or may not
be comprehensive. We would dearly love for people to volunteer to
help us keep it up to date (for starters, if you notice any
-inaccuracies, please let bug-cvs know as described in README). There
-are some other reported bugs in MINOR-BUGS; the difference, at least
-in theory, is that those bugs are less serious.
+inaccuracies, please let bug-cvs know as described in the Cederqvist
+manual). There are some other reported bugs in MINOR-BUGS; the
+difference, at least in theory, is that those bugs are less serious.
* For platform-specific information (in some cases including known
@@ -15,25 +15,45 @@ similar file for the unix-like operating systems (not yet, at least).
This file also might contain some platform-specific bugs.
-* Exporting binary files on non-unix clients with "cvs export" does
-not work. The workaround is to use "cvs checkout" instead. If you
-are thinking of fixing this, check out the comment "For cvs export,
-assume it is a text file." in client.c.
+* One cannot specify some files as binary in a "cvs import" using
+CVSROOT/cvswrappers (for why, note that client_process_import_file has
+no way of knowing about CVSROOT/cvswrappers which is off on the
+server).
-* Wrappers do not work client/server, and there are a variety of other
+* I don't think that "cvs add" honors any of the -k wrappers, at least
+not in client/server mode. I would think it should. Getting
+CVSROOT/cvswrappers to work would presumably best be done by keeping a
+copy of it in the CVS directory on the client, as has also been
+discussed for CVS/Template, &c. Getting a client-side .cvswrappers to
+work is a separate issue.
+
+
+* Need more work on the procedure for fixing it if a binary file is
+accidentally added in text mode (sanity.sh test cases, better
+documentation, probably update and/or admin -kb should update
+the -k setting in CVS/Entries).
+
+
+* Wrappers (-t/-f) do not work client/server, and there are a variety of other
bugs and annoyances with wrappers.
-* 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"?).
+* If your login name contains a space or various other characters
+(particularly an issue on Windows), CVS will have trouble (it will
+write invalid RCS files, probably). The fix would be to have CVS
+change such characters to underscores before writing them to the RCS
+file. Furthermore, the LOGNAME or USER environment variables usually
+won't override the system login name, so this can be hard to work
+around.
+
+
+* If you specify the -w global option to client/server CVS, it only
+overrides a CVSREAD environment variable set on the client, not a
+CVSREAD variable which was set on the server (for example, in .bashrc
+when the server was run via rsh). The fix of course will be to
+provide a "Option-read-write" request which sends -w, in addition to
+"Global_option -r" which sends -r.
* "make remotecheck" sometimes fails on test 187a3 with
@@ -57,11 +77,6 @@ file's description.
(and from the repository)?
-* `cvs checkout -d nested/dir/path <module>' just doesn't work. The
- simpler version -- `cvs checkout -d single-dir <module>' works,
- however.
-
-
* The following bug was reported against CVS 1.9:
Create a module named test with a file named test in it.
diff --git a/contrib/cvs/ChangeLog b/contrib/cvs/ChangeLog
index af4807f67ce7..6ff5bd11be30 100644
--- a/contrib/cvs/ChangeLog
+++ b/contrib/cvs/ChangeLog
@@ -1,3 +1,500 @@
+15 Jan 1998 W. L. Estes <wlestes@hamlet.uncg.edu>
+ and Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * cvs.spec, Makefile.in: Fix some problems with the spec file
+ distributed with cvs. RPM chokes on a build root of slash, so
+ that is gone now. CVS is relocatable (as far as I know) so I
+ added a prefix tag. The source location was incorrect and in
+ fixing that I had to add a `g' flag to one of the sed commands in
+ the Makefile.in so the spec file gets generated correctly.
+
+13 Jan 1998 Jim Kingdon
+
+ * cvsnt.mak: Add lib/fncase.c. Plus of course the usual
+ "because Visual C++ feels like it" changes.
+
+Tue Jan 13 16:49:38 1998 Ian Lance Taylor <ian@cygnus.com>
+
+ * acconfig.h (USE_SETMODE_STDOUT): Add undef line.
+ (HAVE_SETMODE): Likewise.
+ * configure.in: If cygwin32, define USE_SETMODE_STDOUT and
+ HAVE_SETMODE.
+ * configure, config.h.in: Regenerate.
+
+ * acconfig.h (UTIME_EXPECTS_WRITABLE): Add undef line.
+ * configure.in: If cygwin32, define UTIME_EXPECTS_WRITABLE.
+ * configure, config.h.in: Regenerate.
+
+ * configure.in: Add test for cygwin32, and set LIBOBJS and LIBS
+ accordingly.
+ * configure: Regenerate.
+
+Sun Jan 11 11:43:55 1998 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * HACKING: Add example of indentation for switch statement. I
+ always have to look this one up, and it seems worthwhile to
+ specify it here rather than be unsure which switch statement in
+ CVS to use as an example.
+
+Wed Jan 7 09:41:08 1998 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * TODO: Revise item 149 (concerning changing CVS/Root and such).
+ "This whole area is a rather bad pile of individual decisions which
+ accumulated over time, some of them probably bad decisions with
+ hindsight."
+
+Wed Dec 31 09:25:20 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * FAQ: Re-import from FAQ-O-Matic. Features a change regarding
+ removing directories.
+
+Tue Dec 23 08:28:44 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * README.VMS, INSTALL, HACKING, BUGS, README: Change bug-cvs
+ address from prep.ai.mit.edu to gnu.org per email from Martin
+ Hamilton. When referring to bug-reporting procedure refer to
+ Cederqvist not README.
+
+Tue Dec 16 13:13:53 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * FAQ: Re-import from FAQ-O-Matic. The content is the same, but
+ instead of being from Mosaic, it is from "lynx -dump -nolist".
+ This output is somewhat better (for example, it is formatted for
+ 80 columns or so, rather than Mosaic which is rather
+ inconsistent), and also lynx is free and still maintained whereas
+ NCSA Mosaic is proprietary and no longer maintained.
+
+ * FAQ: Re-import from FAQ-O-Matic. Features an update to the
+ Sablime question.
+
+ * NEWS: Add item about GSSAPI.
+
+Fri Dec 12 14:00:57 1997 Ian Lance Taylor <ian@cygnus.com>
+
+ * configure.in: Add --with-gssapi option, and look for gssapi.h
+ and GSSAPI Kerberos v5 libraries.
+ * acconfig.h: Add HAVE_GSSAPI.
+ * configure, config.h.in: Regenerate.
+
+Thu Dec 11 15:58:06 1997 Eric Mumpower <nocturne@cygnus.com>
+
+ * configure.in: Let --with-krb4 override the system Kerberos
+ header files and libraries, if any.
+ * configure: Regenerate.
+
+Thu Dec 4 20:01:02 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * configure.in (AC_CHECK_FUNCS): Remove mempcpy per change to
+ src/rcs.c.
+ * configure: Regenerated (never was regenerated after getwd change).
+
+1997-12-04 Jim Meyering <meyering@na-net.ornl.gov>
+
+ * configure.in (AC_CHECK_FUNCS): Add mempcpy.
+
+Thu Dec 4 10:42:32 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * BUGS: Update for kfogel .cvswrappers fix.
+
+Tue Dec 2 22:14:03 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * MINOR-BUGS: Update per info-cvs mail from Steve Cameron.
+
+1997-11-29 Jim Kingdon
+
+ * cvsnt.mak: Remove lib/getwd.c (see lib/ChangeLog for rationale).
+
+ * cvsnt.mak: The usual "because Developer Studio feels like
+ it" changes.
+
+Sat Nov 29 22:10:32 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * configure.in (AC_REPLACE_FUNCS): Remove getwd (see lib/ChangeLog
+ for rationale).
+
+Mon Nov 24 10:36:39 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * INSTALL: Update QNX information per email from Michael Hunter of
+ QNX.
+
+Wed Nov 19 17:44:21 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * INSTALL: Add Sequent entry per bug-cvs report.
+
+1997-11-17 Karl Fogel <kfogel@floss.red-bean.com>
+
+ * BUGS: Remove item about exporting binary files to non-unix
+ clients; this is fixed.
+
+Mon Nov 17 09:07:44 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * BUGS: Add yet another binary files problem.
+
+1997-11-14 Karl Fogel <kfogel@floss.red-bean.com>
+
+ * cvsnt.mak: updated for diff/ subdir.
+
+Fri Nov 14 12:25:10 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * BUGS: Remove item about dying gasps message. At least one known
+ cause has been fixed.
+
+Wed Nov 12 20:24:49 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * FAQ: Re-import from FAQ-O-Matic. Features a wording fix to
+ "What do I do first? How do I create a Repository?" and a
+ formatting fix (makes it clear which bullets are under what)
+ to "What is a module?"
+
+ * NEWS: Add item about RCS library. Remove item about RCSBIN in
+ CVSROOT/config.
+ * INSTALL: Simplify instructions to reflect the fact that one need
+ not any longer install RCS and GNU diff.
+ * PROJECTS: Remove item about RCS library; it is done.
+
+Mon, 10 Nov 1997 Jim Kingdon
+
+ * cvsnt.dsp: For diff/diff.c, also look for include files in
+ diff directory. This means we get diff/system.h not lib/system.h.
+
+Sun Nov 9 16:16:56 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * TODO (#195): New item, about rsync and such issues.
+
+Thu Nov 6 14:29:14 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * TODO (#194): New item, about separated metadata.
+
+ * TODO (#186): Rewrite paragraph on CVSclusters to be clearer
+ about what this can do and why I think it is a cool idea.
+
+Sun Nov 2 19:34:30 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * DEVEL-CVS: Wording fix: want to specify that new developers are
+ granted checkin access and the ability to send to devel-cvs, not
+ specify whether this is implemented via an "account" (whatever
+ that is) (editorial change, not run by devel-cvs).
+
+Fri Oct 31 16:30:57 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * NEWS: Mention admin -o rev1::rev2.
+
+Wed Oct 29 08:40:05 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * TODO: Add item 193, about alternatives to timestamps in CVS/Entries.
+
+Tue Oct 28 19:59:48 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * TODO (190): "rcs failed" message is no longer affected by global
+ -q option.
+
+1997-10-28 Jim Kingdon
+
+ * .cvsignore: Add Visual C++ files du jour, namely
+ {diff,vc50}.{pdb,idb,pch}.
+
+ * cvsnt.dsp: Add files for diff library. The custom build
+ stuff for diff/version.c and diff/diff.c was to deal with
+ there also being a src/version.c and src/diff.c. There
+ might be an easier way.
+
+Mon Oct 27 11:21:15 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * FAQ: Re-import from FAQ-O-Matic. Features an edit from Larry
+ Jones regarding CVS on Windows.
+
+Mon Oct 20 15:23:17 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * BUGS: Add item about spaces in login names.
+
+Mon Oct 20 10:25:42 1997 Hannes R. Boehm <hannes@boehm.org>
+
+ * INSTALL (Tested platforms): Add Red Hat Linux 4.2.
+
+Wed Oct 15 10:55:20 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * TODO (#192): Also mention issue with opening connections to new
+ servers if CVSROOT changes.
+
+ * TODO (#191): Add thoughts on external difference programs.
+
+1997-10-11 Noel Cragg <noel@swish.red-bean.com>
+
+ * BUGS: remove note about the `-d' flag bug that was just fixed.
+
+ * TODO: new item 192.
+
+Thu Oct 9 12:59:28 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * TODO: Revise item #182 to be clearer and to point to the
+ unofficial patch.
+
+Thu Sep 25 14:48:26 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * build.com: Also recurse into diff directory.
+
+Wed Sep 24 10:35:50 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * configure.in: Don't check for system-supplied regex matcher; see
+ comment for rationale.
+ * configure: Regenerated.
+
+Tue Sep 23 16:00:25 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * BUGS: Add item about cvs add and -k wrappers.
+
+Mon Sep 22 11:21:11 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * TODO: Revise item #191 in response to xdelta 1.10 release and a
+ few other random thoughts.
+
+Sun Sep 21 17:56:28 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * configure.in: Instead of checking for memchr, just define
+ HAVE_MEMCHR and HAVE_STRCHR.
+ Add comment about AC_FUNC_VFORK and vfork in general.
+ * acconfig.h: Add HAVE_MEMCHR and HAVE_STRCHR.
+ * configure, config.h.in: Regenerated.
+
+ * config.h.in: Regenerate using autoheader from autoconf 2.10.
+
+Sat Sep 20 01:17:10 1997 Tim Pierce <twp@twp.tezcat.com>
+
+ [notes: (1) includes the patches to config.h.in which he sent
+ (presumably generated), (2) I have omitted a change, which was
+ sent without a ChangeLog entry, to change re_exec to
+ re_compile_pattern in configure.in, (3) Also adds diff/Makefile in
+ AC_OUTPUT -kingdon]
+
+ * Makefile.in (USOURCE_SUBDIRS, check, remotecheck, installcheck):
+ Add diff.
+
+ Note that AC_CHECK_FUNCS(vfork)
+ has been replaced by AC_FUNC_VFORK... libdiff wants the more
+ specific test, and it seems unlikely to break CVS.
+
+ * configure.in: Add AC_FUNC_CLOSEDIR_VOID, AC_FUNC_VFORK,
+ AC_STRUCT_ST_BLKSIZE.
+ (AC_CHECK_HEADERS): Add limits.h and sys/file.h.
+ (AC_REPLACE_FUNCS): Add memchr.
+ (AC_CHECK_FUNCS): Remove vfork.
+
+Fri Sep 19 09:59:33 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * TODO: Add item #191, concerning how to store binary files.
+
+Wed Sep 17 16:13:49 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * TESTS: Add ideas about ability to pass spaces in arguments, and
+ stdin, to the program under test, as something to consider for the
+ different test frameworks.
+
+Tue Sep 16 00:14:55 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * BUGS: Add item about importing binary files.
+
+ * TODO: Adjust item #150 to reflect the fact that the client is
+ not quite so mean about tossing the log message as it was.
+
+Fri Sep 12 13:04:31 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * INSTALL: Update Windows entries per email from Greg Strockbine
+ <gstrock@dpc.com>.
+
+Thu Sep 11 15:03:21 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * TODO: New item #190, about meaning of -q and -Q global options.
+
+Wed Sep 10 18:48:41 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * TODO: A few more thoughts on "cvs message" (item 150).
+
+Tue Sep 9 22:20:15 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * README.VMS (Notes regarding compiling on VAX/VMS): Add item
+ about mode_t and pid_t.
+
+Sun Sep 7 17:34:03 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * FAQ: Re-import from FAQ-O-Matic. The metavariables are back.
+
+ * FAQ: Re-import from FAQ-O-Matic. Features comment from
+ julian@whistle about update -r branch:date. It also clobbered the
+ metavariables (confusion about "<" as data vs. HTML tag I would
+ guess), which I plan on fixing in a moment.
+
+ * configure.in: Add comment about re_exec and regexp syntax.
+
+ * configure.in (AC_REPLACE_FUNCS): Remove strdup; CVS was long
+ ago converted to use its own routine xstrdup.
+ * configure: Regenerated.
+
+Sat Sep 6 00:08:20 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * FAQ: Re-import from FAQ-O-Matic. In particular: GIC info
+ updated, binary files updated (e.g. -kb not -ko), rename database
+ and rCVS info updated (refer to TODO), tweaks to section on
+ contributing (HACKING, DEVEL-CVS, &c), Cyclic info updated
+ (e.g. remove Indiana address), usenet info updated
+ (e.g. comp.software.config-mgmt not gnu.*).
+
+Fri Sep 5 20:46:26 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * FAQ: Add another introductory paragraph which talks about out of
+ date material from 1995 FAQ.
+
+ * FAQ: Re-import from FAQ-O-Matic. This was mainly as a proof of
+ concept that I could edit the Cygnus question and have the diffs
+ come out looking right (which worked), but I also discovered that
+ the previous checkin was truncated partway through.
+
+ * FAQ: Replace file with an introductory paragraph plus a
+ downloaded copy of Molli's FAQ-O-Matic. I believe the content
+ closely matches the 1995 Grubbs FAQ but because everything is
+ re-ordered it would be painstaking work to verify this.
+
+Thu Sep 4 17:33:53 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * BUGS: Add item about -w global option and client/server.
+
+Wed Sep 3 23:03:34 1997 Noel Cragg <noel@harvey.cyclic.com>
+
+ * TODO: Verbosify verbiage in item #189.
+
+Wed Sep 3 14:14:54 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * TODO: Add item #189, concerning renames.
+
+Sat Aug 30 03:26:57 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * TODO: Fix typo in Noel's change.
+
+Sat Aug 30 03:17:36 1997 Noel Cragg <noel@harvey.cyclic.com>
+
+ * TODO: Add a header so emacs chooses the correct editing mode.
+ Made several entries more verbose (expanded some of the less
+ well-known acronyms and/or added pointers to further
+ documentation).
+
+Wed Aug 20 09:51:52 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * INSTALL: Remove "SparcClassing" typo that has been there for
+ a while.
+
+Wed Aug 20 09:51:52 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+ and Loren James Rittle <rittle@comm.mot.com>
+
+ * INSTALL: Update information for SunOS4, Solaris, Digital Unix,
+ and HPUX.
+
+Fri Aug 15 16:42:12 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * INSTALL: Remove the "CVS 1.6" crud; it really isn't needed. Add
+ paragraph about the meaning of the last three arguments to cvs
+ import.
+
+Thu Aug 14 14:42:53 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+ and Loren James Rittle <rittle@comm.mot.com>
+
+ * INSTALL: Update information for SunOS4 and Solaris.
+
+Mon Aug 4 00:02:24 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * BUGS: Be specific about wrappers not working client/server.
+
+Sat Aug 2 09:23:50 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * INSTALL: In step 4, be more generic (the CVS sources are just an
+ example, and people might not have them handy).
+
+Fri Jul 25 17:02:30 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * INSTALL: Refer to cvs.texinfo as the Cederqvist manual; that
+ seems to be the description which best applies no matter how it
+ was obtained. Be a little more explicit about the "$" prompt
+ convention and setting environment variables. Use double quotes
+ because they work on both DOS and Unix.
+
+Thu Jul 24 12:22:49 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * NEWS: Also mention SystemAuth.
+
+ * INSTALL (MIPS): Add more detailed report concerning Irix 6.2,
+ as reported by larry.jones@sdrc.com (Larry Jones).
+
+Tue Jul 22 17:35:31 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * INSTALL (PowerPC): Add item for Lynx 2.5.
+
+21 Jul 1997 Jim Kingdon
+
+ * Makefile.in (DISTFILES): Add cvsnt.dsp.
+
+Mon Jul 21 09:40:10 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * configure.in: Adjust comment regarding version of autoconf which
+ introduced --bindir.
+
+Fri Jul 18 09:47:12 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * TODO: Remove item 161 (the comments in cvs.texinfo have a much
+ more complete discussion of date format issues). In item 30,
+ change "patch" to "rdiff" and expand discussion slightly. Remove
+ item 64 (the performance issues in initial checkout have probably
+ changed quite a bit since that was written and in any event it
+ isn't particularly useful without specifics of what is slow and
+ ideas for speeding it up).
+
+ * INSTALL: Reorganize to separate out building/installing CVS
+ executables from what to do once you have them. Adjust Visual C++
+ instructions to deal with Visual C++ 5.x. Add brief mentions of
+ platforms other than unix and Windows.
+
+Thu Jul 17 21:13:16 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * TODO: In item 39, talk about how PRCS 1.2 as a possible model.
+
+Sat Jul 12 15:43:01 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * HACKING: Rewrite paragraph on arbitrary limits to reflect the
+ fact that the known arbitrary limits are gone.
+
+8 Jul 1997 Jim Kingdon
+
+ * cvsnt.dsp: Turn on browse information.
+
+Thu Jul 3 10:07:01 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * INSTALL: Sending exact suggested text is almost as good as a diff.
+
+ * INSTALL (i386 family): Add lines about Watcom and EMX on OS/2.
+
+ * TODO: Add notes about popt and option parsing in general.
+
+Wed Jul 2 13:11:03 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * TODO: Update item 149 to reflect CVS/Root.
+
+ * TODO: Add item 187, about usage errors vs. help messages.
+
+Mon Jun 23 18:24:13 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * NEWS: Adjust mention of read-only access in the light of
+ changes to cvs.texinfo.
+
+ * TODO: Add item 186, concerning multisite.
+
+Sun, 22 Jun 1997 Jim Kingdon
+
+ * cvsnt.dsp: New file. This apparently is what Visual C++ 5.0
+ uses in lieu of a .mak file (or so it seems).
+ * .cvsignore: Add cvsnt.opt cvsnt.dsw cvsnt.plg. These seem to
+ be the generated files du jour for Visual C++ 5.0.
+
+Thu Jun 19 17:16:39 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * NEWS: Add item about CVSROOT/config.
+
Wed Jun 18 00:00:02 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
* NEWS: Mention pserver --allow-root.
diff --git a/contrib/cvs/DEVEL-CVS b/contrib/cvs/DEVEL-CVS
index fe8a8632198b..b91b9ba126c0 100644
--- a/contrib/cvs/DEVEL-CVS
+++ b/contrib/cvs/DEVEL-CVS
@@ -50,7 +50,7 @@ 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.
+are no objections, the person will be made a developer.
----------------------------------------------------------------------
Policy regarding checkout-only access:
diff --git a/contrib/cvs/FAQ b/contrib/cvs/FAQ
index c7fcdd78bec2..20912ddb40e3 100644
--- a/contrib/cvs/FAQ
+++ b/contrib/cvs/FAQ
@@ -1,11 +1,8585 @@
-This file formerly contained a CVS FAQ, maintained by David Grubbs.
-However, it has been out of date for a long time, he officially gave up
-maintaining it in the fall of 1995, and noone else has taken it over.
-Most of the information which used to be in it can be found in the CVS
-manual, doc/cvs.texinfo in this distribution. For information on
-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 the "Configuration Management" category at http://www.yahoo.com/
-or see http://www.iac.honeywell.com/Pub/Tech/CM/index.html.
+This file contains a CVS FAQ. Until 1995 it was maintained by David
+Grubbs. It was out of date and not being maintained, but it had a
+certain following and in 1997 Pascal Molli decided to start
+maintaining it with the FAQ-O-Matic package which allows any
+contributor with a web browser to help maintain it. The following
+text is (mostly automatically) extracted from the FAQ-O-Matic. The
+odds are good that the file that you are currently reading is out of
+date with respect to the online FAQ-O-Matic, which is part of Pascal
+Molli's CVS web site at http://www.loria.fr/~molli/cvs-index.html
+(currently under "Documentation"). The online version is also
+somewhat better in terms of things like tables of contents (at least
+until someone can write some code to extract data from a FAQ-O-Matic
+and insert things like tables of contents).
+
+The answers which are dated "6/13/1997" below are really from the 1995
+FAQ, for the most part. Many of them are out of date. If you have
+some time, you are encouraged to double-check them against other
+sources like the Cederqvist manual and update the FAQ. If you don't
+have such time, take them with a grain of salt or a few.
+
+ Category: /, all questions
+
+ Category: /
+
+ " [INLINE] "
+
+ 1. About FAQ-O-Matic
+
+This is FAQ-O-Matic, a quick-and-dirty Perl hack (aren't they all?) by
+Jon Howell.
+
+It seems like most FAQ maintainers make a valiant initial effort, then get
+a life and don't have time to keep their FAQs up to date. Also, I often
+find out a solution to a problem, and feel like I could write a single
+FAQ answer on it in a few minutes, but where to post it?
+
+Thus the FAQ-O-Matic was born. FAQ-O-Matic is a couple sleazy Perl scripts
+that allow people to submit FAQ answers to this database, so it can stay
+current, with just a tiny bit of work on any one person's part.
+
+Yes, a bad guy could come along and wipe out all the FAQ entries. Please don't.
+But to give the good guys some measure of comfort, each submission is stored
+in an RCS file, so if someone does tamper, we can recover the database.
+
+Guidelines for submissions:
+
+1. Please _try to be fairly unbiased in matters of opinion._ Mailing lists are
+the place to start flame wars (just kidding :v), but definitely not here.
+
+2. Please _use HTML only conservatively_ in your entries. Links are appropriate
+,
+but put the URL in the plaintext also so it's useable on printed versions of
+the FAQ. Inline images pointing off this site are inappropriate, as is much
+fancy formatting. This is meant to be bandwidth-light and dumb-browser-friendly
+.
+
+3. If you feel there's a place for a _new category, or a reorganization of
+existing questions_, don't hesitate to mail me (molli@loria.fr).
+Category changes need to be done from my end.
+
+4. Please _leave an email address_ at the bottom of your submission so that oth
+ers
+can drop you a note.
+
+5. _If you only have a question_, not an answer, you should probably post
+it to a mailing list, not here. If there are frequently asked questions to whic
+h
+the answer is not forthcoming on mailing lists (or perhaps there's no
+useful answer yet other than "no one knows"), then it's appropriate to
+post here, in hopes that someone will see it and know the answer.
+
+6. Please refrain from crude or inconsiderate language. Please don't use
+this as a forum for advertising. However, mention of worthy commercial
+products is certainly appropriate (even if you sell said product). Just
+don't overdo it. :v)
+
+ Last modified: _6/13/1997_
+
+ 2. Adding a new category ?
+
+just send me a mail at
+molli@loria.fr
+
+ Last modified: _6/13/1997_
+
+ Category: /Advanced_Topics_/
+
+ " Advanced Topics "
+
+ Category: /Advanced_Topics_/Branching_and_Mergin/
+
+ " + Branching and Merging"
+
+ 1. What is a branch?
+
+ Unfortunately, the word "branch" is an overloaded technical
+ term. It is used in too many different ways in three
+ categories. It might help to understand some of the issues by
+ going through the categories:
+
+ How Humans use the word "branch":
+
+ Most development starts with everyone working on the same
+ software, making changes and heading toward a single goal. This
+ is called something like "Main Line Development". Note that
+ though many people do main line development on CVS's "Main
+ Branch", that is a choice, not a requirement.
+
+ After a release or when one or more developers want to go off
+ and work on some project for a while, the Software Engineers
+ assigned to deal with large software issues generate a "Branch
+ in Development" to support the release or project. (Keep in
+ mind that a programmer is no more a Software Engineer than a
+ carpenter is a Civil Engineer.)
+
+ Essentially, the word "branch" implies a way to allow
+ simultaneous development on the same files by multiple people.
+
+ The above terms are human-oriented. They refer to actions that
+ people would like to take. They do *not* imply any particular
+ implementation or set of procedures. Branches in development
+ can be supported in many different ways.
+
+ How CVS uses the word "branch":
+
+ CVS uses the word "branch" in a number of ways. The two most
+ important are:
+
+
+ - The vendor branch holds releases from (normally) an outside
+ software vendor. It is implemented using a specific RCS branch
+ (i.e. 1.1.1).
+
+
+ - The "Main Branch", which normally holds your "Main Line
+ Development", but is defined as the collection of revisions you
+ get when you "checkout" something fresh, or when you use the
+ '-A' option to "update".
+
+ Important Note: The CVS "Main Branch" is *not* the same as the
+ RCS concept with the same name. If you are using Vendor
+ Branches, files you have never changed are on three branches at
+ the same time:
+
+
+ - The RCS 1.1.1 branch.
+ - The CVS Vendor branch.
+ - The CVS "Main Branch".
+
+ The concepts overlap, but they are not equivalent.
+
+ In referring to CVS, "branch" can be used in four other ways:
+
+
+ - A CVS working directory satisfies the definition of "branch"
+ for a single developer -- you are on a private "virtual branch"
+ that does not appear in any of the RCS files or the CVS control
+ files.
+
+
+ - The CVS "default branch" is the Repository source for the
+ collection of files in your working directory. It is *not* the
+ same as the RCS "default branch". Normally the CVS default
+ branch is the same as the CVS Main branch. If you use the "-r
+ <branch_tag>" option to the "checkout" command, you will record
+ a "sticky" tag that changes your default branch to the one you
+ checked out.
+
+
+ - A "magic" branch can be a branch that hasn't happened yet. It
+ is implemented by a special tag you can check out that is not
+ attached to a real RCS branch. When you commit a file to a
+ magic branch, the branch becomes real (i.e. a physical RCS
+ branch).
+
+
+ - And, of course, CVS uses "branch" to indicate a
+ human-oriented "branch in development".
+
+ How RCS uses the word "branch":
+
+
+ - The RCS "Main Branch" (Synonym: "The Trunk") contains a
+ series of two-part revision numbers separated by a single '.'
+ (e.g. 1.2). It is treated specially and is the initial default
+ branch. (The default default?)
+
+
+ - The RCS "Default" branch starts out attached to the RCS "Main
+ Branch". For RCS purposes, it can be changed to point to any
+ branch. Within CVS, you *must*not* alter the RCS default
+ branch. It is used to support the CVS idea of a "Main Branch"
+ and it must either point to the RCS Main Branch, or the Vendor
+ Branch (1.1.1) if you haven't made any changes to the file
+ since you executed "import".
+
+ Last modified: _6/13/1997_
+
+ 2. Why (or when) would I want to create a branch?
+
+ Remember that you can think of your working directory as a "branch for
+ one". You can consider yourself to be on a branch all the time because
+ you can work without interfering with others until your project (big
+ or small) is done.
+
+ The four major situations when you should create a branch:
+
+ When you expect to take a long time or make a large set of changes
+ that the merging process will be difficult. Both "long" and "large"
+ are defined in your own environment.
+
+ When you want to be able to "commit" and "tag" your work repeatedly
+ without affecting others.
+
+ If you ever think you need Source Control for your own work, but don't
+ want your changes to affect others, create a private branch. (Put your
+ username in the branch tag, to make it obvious that it is private.)
+
+ When you need to share code among a group of developers, but not the
+ whole development organization working on the files.
+
+ Rather than trying to share a working directory, you can move onto a
+ branch and share your work with others by "committing" your work onto
+ the branch. Developers not working on the branch won't see your work
+ unless they switch to your branch or explicitly merge your branch into
+ theirs.
+
+ When you need to make minor changes to a released system.
+
+ Normally a "release" is labeled by a branch tag, allowing later work
+ on the released files. If the release is labeled by a non-branch tag,
+ it is easy to add a branch tag to a previously tagged module with the
+ "rtag" command. If the release is not tagged, you made a mistake.
+ Recovery requires identifying all revisions involved in the release
+ and adding a tag to them.
+
+ Last modified: _6/13/1997_
+
+ 3. How do I create and checkout a branch?
+
+ Suggested technique:
+
+ Attach a non-branch tag to all the revisions you want to branch
+ from. (i.e. the branch point revisions)
+
+ When you decide you really need a branch, attach a branch tag to the
+ same revisions marked by the non-branch tag.
+
+ "Checkout" or "update" your working directory onto the branch.
+
+ Suggested procedure when using modules:
+
+ cvs rtag <branch_point_tag> module
+
+ cvs rtag -b -r <branch_point_tag> <branch_tag> <module>
+
+ cvs checkout -r <branch_tag> module
+
+ Suggested procedure when using your working directory, which
+ contains the revisions of your working files you want to branch from:
+
+ cvs tag <branch_point_tag>
+
+ cvs rtag -b -r <branch_point_tag> <branch_tag> <module>
+
+ cvs update -r <branch_tag>
+
+ In each procedure above, Step #1 applies a non-branch tag to all the
+ branch point revisions in the module/directory. Though this is not
+ strictly necessary, if you don't add a non-branch tag to the revisions
+ you branch from, you won't be able to refer to the branch point in the
+ future.
+
+ Between steps 1 & 2 you may commit changes. The result would be same
+ because "rtag -r <oldtag> <newtag>" applies <newtag> to the same
+ revision that <oldtag> is attached to. You can use this technique to
+ avoid attaching *any* branch tags until you need them.
+
+ Step B.2 has two corollaries:
+
+ If you plan to create the branch tag before committing anything in
+ your working directory, you can use "cvs tag -b <branch_tag>" instead
+ of the "rtag" command.
+
+ The <module> can be a relative path to a directory from which your
+ working directory was checked out.
+
+ If you have trouble figuring out what <module> to use (or pathname to
+ use in its place), you can aim it at whatever parent directories you
+ believe will cover all your work.
+
+ If you are sure the <branch_tag> is not being used anywhere else, you
+ can even aim it at the whole Repository ($CVSROOT), if you have to. It
+ might take some extra time, but assuming that your <tag> is a unique
+ string and you don't use the '-f' option to "rtag -r", "rtag" will
+ only add a <tag> to files in which it actually *finds* the earlier
+ <tag>.
+
+ In each procedure above, Step #3 may occur any time after step 2.
+ Unless you explicitly remove them with "tag -d", a <tag> is permanent.
+
+ The <branch_tag> is an unusual creature. It labels a branch in a way
+ that allows you to "checkout" the branch, to "commit" files to the end
+ of the branch and to refer to the end of the branch. It does not label
+ the base of the branch (the branch point).
+
+ There are two obvious ways to choose the <branch_point_tag> and
+ <branch_tag> names. But keep in mind that the <branch_tag> is typed by
+ any developer who wants to work on the branch -- you should make it
+ mean something to them.
+
+ Style #1 presumes that the simple version string refers to a set of
+ designed, documented or promised features, not to a specific set of
+ files. In this case, you tag the branch with the generic Version
+ string and assume that whenever you refer to "Version", you want the
+ "latest" set of files associated with that Version, including all
+ patches. (You can substitute whatever you like for "bp_", as long as
+ your <branch_point_tag> is some modification of the <branch_tag>.)
+
+ <branch_point_tag> Matching <branch_tag>
+
+ bp_V1_3 V1_3
+ bp_Release2-3-5 Release2-3-5
+ bp_Production4_5 Release4_5
+
+ Style #2 presumes that the simple version string refers to the
+ specific set of files used to construct the first release of
+ "version". In this case, you tag the branch-point revisions with the
+ generic Version string and assume that whenever you refer to this
+ Version, you want the original set of released revisions. To get the
+ latest patched revisions of the release, you refer to the branch tag
+ "latest_<branch_point_tag>". (You can substitute what ever you like
+ for "latest_", as long as your <branch_tag> is some modification of
+ the <branch_point_tag>.)
+
+ <branch_point_tag> Matching <branch_tag>
+
+ V1_3 latest_V1_3
+ Release2-3-5 latest_Release2-3-5
+ Release4_5 latest_Production4_5
+
+ In both styles you can find out what you had to change since the
+ original release of this Version by typing:
+
+ cvs diff -r <branch_point_tag> -r <branch_tag>
+
+ For Style 1, this is:
+
+ cvs diff -r bp_<branch_tag> -r <branch_tag>
+
+ For Style 2, this is:
+
+ cvs diff -r <branch_point_tag> -r latest_<branch_point_tag>
+
+ Notes on "being on a branch":
+
+ - "update -r <tag>" tells CVS to attach a "sticky tag" to working
+ directory (in ./CVS/Tag) and the checked-out files (on each line of
+ ./CVS/Entries).
+
+
+ - A "sticky" <tag> (including a <branch_tag>) causes most CVS commands
+ to act as if "-r <tag>" were on the command line.
+
+
+ - A "sticky" <branch_tag> indicates that the working directory (and
+ working files) are "on the branch".
+
+ Last modified: _6/13/1997_
+
+ 4. Once created, how do I manage a branch?
+
+ The most important thing you should know about managing a branch is
+ that the creation of a branch is not a lightweight act. When you
+ create a branch, you must also create a set of procedures to keep
+ track of it.
+
+ Specifically, you must:
+
+
+ - Remember that the branch exists. (This is non-trivial if you create
+ a lot of them.)
+
+
+ - Plan when to merge it back into the main line of development.
+
+
+ - Schedule the order that multiple branch merges are to be done.
+
+
+ - If you ever intend to merge branches into each other, instead of
+ limiting merges of branch work back into the "main line", you must
+ keep careful track of which parts of which branches have merged into
+ which other branches.
+
+ The simplest way to deal with branches is to limit their number,
+ "collapse" them back into the main line as quickly as is reasonable
+ and forget them. If a group wants to continue working, tell them to
+ create another branch off the fully merged main line.
+
+ Remember that CVS is just a tool. Over time, it will probably handle
+ branching better, requiring less careful attendance. But no matter how
+ good it becomes, the whole idea of "branching" is a complicated
+ management problem. Don't take it lightly.
+
+ Last modified: _6/13/1997_
+
+ 5. Are there any extra issues in managing multiple branches?
+
+ If you plan to split from the "main line" and merge back after a time,
+ the only problem will be scheduling the order of branch merges. As
+ each branch is merged, the main line must be rebuilt and tested.
+ Merging multiple branches (i.e. "lines of development") before
+ building and testing creates more problems than you are ready for.
+
+ If you plan to collapse some branches into others, then move the
+ combined branches back into the main line, you have to be careful with
+ the revisions and tags you hand to your "update -j" command, but it
+ shouldn't be much trouble.
+
+ If you plan to allow every branch to incrementally take the work done
+ on other branches, you are creating an almost insurmountable
+ bookkeeping problem. Every developer will say "Hey, I can handle
+ taking just this little bit," but for the system as a whole it is
+ disaster. Try it once and see. If you are forced into this situation,
+ you will need to keep track of the beginning and end points of every
+ merge ever done. Good Luck.
+
+ Last modified: _6/13/1997_
+
+ 6. How do I merge a whole branch back into the trunk?
+
+ If you don't have a working directory, you can checkout and merge in
+ one command:
+
+ cvs checkout -j <branch_tag> <module>
+ cd <module>
+
+ If you already have a working directory:
+
+ cd <working_directory>
+ cvs update <== Optional, to bring it up to date.
+ cvs update -j <branch_tag>
+
+ CVS will print lines beginning with
+
+ 'U' for files that you hadn't changed, but the branch did.
+
+ 'M' for files that you changed and the branch didn't
+ *and* for files that you both changed that were merged
+ without overlaps. (This overload is unfortunate.)
+
+ 'C' for files that you both changed in a way that conflicts
+ with each other.
+
+ You need to go edit all the 'C' files and clean up the conflicts. Then
+ you must commit them.
+
+ Last modified: _6/13/1997_
+
+ 7. How do I merge changes from the trunk into my branch or between
+ branches?
+
+ The idea is similar to the above, but since CVS doesn't treat the main
+ branch like other branches, you'll have to be more careful. There are
+ 5 different ways to look at the problem.
+
+ The way to merge *all* changes made on the trunk into a working
+ branch is to move to the branch you want via "checkout -r" or "update
+ -r":
+
+ cvs update -r <branch_tag> {optional files}
+
+ Then merge the changes from the trunk into your working branch using
+ the pseudo-tag named "HEAD":
+
+ cvs up -j HEAD {optional files}
+
+ You will get everything from the branch point of the branch named
+ <branch_tag> up to the HEAD of the main branch. This is still kind of
+ strange. If the file is on a branch, HEAD should be the latest thing
+ on the branch, not the HEAD of MAIN. But that's not the way CVS
+ (currently) works.
+
+ If you run "cvs up -j HEAD" again after adding more revisions to the
+ trunk, you may get overlaps for the text you have already merged. It
+ depends on your version of your RCS "merge" command (actually the "co
+ -j" option, which depends on the version of "diff3" you configured RCS
+ to use).
+
+ You can merge the difference between any two <tags> using two "-j"
+ options on "update" or "checkout".
+
+ Identify the two tags on the branch you want to merge from.
+
+ cvs update -j <tag1> -j <tag2> {optional files}
+
+ This step assumes you were careful about tagging milestones. You can
+ use this technique for any two <tags> on the same branch, even the
+ trunk. It is also possible to use tags on different branches, but
+ you'll have to ponder the meaning of the difference between those two
+ tags.
+
+ In place of one of the <tags>, you can use a <branch_tag> to refer to
+ the latest revision on that branch. See 4C.11 and 4C.3 for info on
+ branch points.
+
+ Merges can also be performed by handing RCS revisions to the '-j'
+ options, but since revision numbers aren't the same in all files,
+ merging by number is normally limited to one file. Sets of files with
+ the exact same trees of branches and revision numbers would work too,
+ but that's a rare situation.
+
+ To "take" revisions from other branches instead of merging them, see
+ 4C.19 for an idea.
+
+ A way to gain the effect of merging the main to the branch is to
+ merge the branch into the main using the normal
+
+ cvs update -A {optional files}
+ cvs update -j <branch_tag> {optional files}
+ cvs commit
+ cvs tag -F -b <same_branch_tag> {optional files}
+
+ See part B of 4D.5
+
+ Other oddities.
+
+ This also works, but is probably not officially supported:
+
+ cvs update -j N {optional files}
+
+ where N is a number. This will merge all the changes from the branch
+ point up to the highest revision on the main branch starting with N.
+ For example, if your highest trunk revision is 1.52, you can use this
+ to grab revisions from the trunk:
+
+ cvs update -j 1 {optional files}
+
+ Another example: Say you have a branch point at rev 1.2 for a branch
+ named "BR1" and trunk revisions 1.3, 1.4, 2.1, 2.2, 2.3, 3.1, 3.2.
+ Then:
+
+ cvs update -j 1 {optional files}
+
+ will merge the changes from 1.2 to 1.4
+
+ cvs update -j 2 {optional files}
+
+ will merge the changes from 1.2 to 2.3
+
+ cvs update -j 3 {optional files}
+
+ will merge the changes from 1.2 to 3.2, which in this example, is
+ equivalent to the use of "-j HEAD" in part A above.
+
+ The intuitive (at least to me):
+
+ cvs up -j MAIN (or TRUNK) {optional files}
+
+ doesn't work. If the trunk (i.e. "main branch") had an implicit branch
+ named "MAIN", you could use:
+
+ cvs up -j MAIN:10/26 -j MAIN:now {optional files}
+
+ and refer to date-stamped revisions on the trunk using the
+ <branch_tag>:<date> support that works on other branches.
+
+ You might also think you could place an explicit tag on branch 1 (or
+ higher) (e.g. MAINHACK:1) and use it in place of the implicit "MAIN",
+ but I haven't found the right combination.
+
+ [[If you find working techniques, I'll add them here.]]
+
+ Last modified: _6/13/1997_
+
+ 8. How do I merge onto the Main Branch a file that exists only on a branch
+ other than the Main Branch? (i.e. it is in the Attic)
+
+ For how such a file can exist, see 3A.2 and 3A.3.
+
+ For how to avoid creating such a file, see 3A.5.
+
+ Though you might think that the "update -j" command could perform the
+ "merge" of a file from the side branch to the Main Branch, it isn't
+ (yet) smart enough. Unfortunately, there is no single CVS command to
+ do this -- it takes three steps:
+
+ To move something onto the Main Branch from the Attic, you have to
+ physically move the file from the Attic to the main Repository
+ directory associated with your working directory.
+
+ It is exactly like resurrecting a removed file. See 3L.4
+
+ I use something like this: (csh-like syntax)
+
+ set repos = `cat ./CVS/Repository` mv $repos/Attic/filename,v
+ $repos/filename,v
+
+ (If you use relative paths in your Repository files, that first line
+ becomes: set repos = $CVSROOT/`cat ./CVS/Repository`)
+
+ Now that the file is physically in the right place within the
+ Repository, "update -A" will make it appear in your working directory
+ on the Main Branch. Do that now.
+
+ You now have a choice. The act of physically moving the file has
+ fused together the <branch_tag> branch and the Main Branch for this
+ file. You can continue that way, making changes along the RCS Main
+ Branch which CVS will (for this type of file only) treat as both the
+ Main Branch and the <branch_tag> branch.
+
+ The other choice, which I would suggest, is to re-tag the file with
+ <branch_tag>, restoring a normal-looking magic branch tag to the file:
+
+ cvs tag -F -b <branch_tag> <file>
+
+ After you have done the above, you can run "update -A" or "update -r
+ <branch_tag>" to resume whatever you were doing before you started
+ this procedure.
+
+ Caveat: The final result is a file whose revision tree doesn't look
+ like it was ever on any branch but the Main Branch until the above
+ "tag -F -b" command was executed. CVS and RCS have no way of saving
+ the history of the actions you have just performed.
+
+ Last modified: _6/13/1997_
+
+ 9. How do I know what branch I'm (working) on?
+
+ Type:
+ cvs status
+
+ and look at the "Sticky Tag" field for each file. If:
+
+ The *same* tag is on *every* file in your working tree, *and*
+
+ That tag matches the contents of the ./CVS/Tag file, *and*
+
+ That tag is a branch tag,
+
+ then you know what branch you are working on. You can get sticky Tag
+ information directly from the ./CVS/Entries file instead of "cvs
+ status".
+
+ If all the sticky Tags don't agree, then your directory is temporarily
+ inconsistent. This is a feature allowing you to make changes (or
+ perform merges) to individual files on multiple branches without
+ checking out the whole directory.
+
+ The sticky Tag on each file in the ./CVS/Entries file (as displayed by
+ the "status" command) indicates what branch the working file is on.
+ New files are added to the Tag stored in ./CVS/Tag.
+
+ To force your entire working directory onto the same branch, type:
+
+ cvs update -r <branch_tag>
+
+ Last modified: _6/13/1997_
+
+ 10. Do I really have to know the name of the branch I'm working on?
+
+ If a developer can't be relied on to know what branch of development
+ to work on, then either the developer's manager isn't planning
+ branches properly or the developer has serious problems.
+
+ I have found that one of the hardest concepts to get across to
+ developers (and some managers) is that "a branch in development" (as
+ opposed to the use of RCS branches to support some other scheme) is a
+ heavyweight act. Every time you create a real branch in development,
+ you must spawn a set of managerial procedures and a schedule by which
+ you plan to merge each branch into each other branch. Unless you plan
+ to keep it simple and collapse (by merging and forgetting) branches
+ quickly, they are not to be created lightly.
+
+ In other words, if you don't regularly attend group meetings in which
+ the branch to be worked on is a major topic of discussion, then the
+ group is not managing branches properly.
+
+ We created a couple major branches a few months ago and even the
+ customer service people refer to the "XYZ branch" as a shorthand for
+ "continuing development on the XYZ project".
+
+ Last modified: _6/13/1997_
+
+ 11. How do I refer to the revision where I branched so I can see what
+ changed since the Branch Point on another branch?
+
+ Given the current <branch_tag> format, there is no direct way to refer
+ to the branch point, which is more useful in many ways than referring
+ to the branch, which always refers to the latest revision on the
+ branch.
+
+ When CVS adds a branch tag, it attaches an RCS symbol to a
+ non-existent revision number containing the revision number of the
+ branch point as a prefix. (See Section 3O, on the "tag" command.) RCS
+ can't use the CVS magic branch tag and many of the CVS commands can't
+ refer to it.
+
+ To be certain of your ability to refer to a branch point, you must
+ create a "branch point" tag at the same time as the Branch tag. See
+ 4C.3.
+
+ Last modified: _6/13/1997_
+
+ 12. Why didn't the command "cvs admin -bBRANCH1 *" create a branch?
+
+ Because your command creates an RCS branch, not a CVS branch. See the
+ above discussion on branches. RCS branches are used to support CVS
+ branches, but they are not the same. You can't act as if you have
+ direct control over the RCS files.
+
+ The "admin" command was placed there as a convenience to allow you to
+ execute raw "rcs" commands on the Repository, taking advantage of
+ CVS's ability to find the files in the Repository.
+
+ But you have to remember that you are using RCS commands on a CVS
+ Repository, which is not generally safe unless you know exactly what
+ CVS depends on.
+
+ For one thing, CVS insists on control of the default branch. It is set
+ either to the Main branch or the Vendor branch depending on whether
+ you have changed the Vendor's code. If you change the default branch,
+ you are monkeying with the internals and you will get unexpected
+ results.
+
+ To set your "default CVS branch" to BRANCH1, you must use "checkout"
+ or "update" with the "-r BRANCH1" option. Then you have changed CVS's
+ idea of your "default branch", which has little to do with RCS's
+ default branch.
+
+ Last modified: _6/13/1997_
+
+ 13. Is it possible to set the "default CVS branch" for everyone?
+
+ No. It doesn't work that way.
+
+ When using CVS, all administrative information (such as what branch
+ you checked out) is stored in CVS sub-directories, local to the user.
+ There is no global state, other than the description and logging files
+ in the $CVSROOT/CVSROOT directory.
+
+ You tell "checkout" or "update" what branch you want to check out via
+ the "-r <tag>" option. The default is CVS's "Main Branch".
+
+ I don't see a problem in *designing* a new way to indicate what branch
+ you get by default, instead of the main one, but that's not how it
+ currently works.
+
+ Last modified: _6/13/1997_
+
+ 14. How do I perform a large merge?
+
+ Large merges require a bit more planning to be able to track what has
+ happened in the inevitable cases where something goes wrong. No tool
+ can force a "merge" to make perfect sense.
+
+ Though you can handle the details in many different ways, the two ends
+ of the spectrum of merge techniques are: gonzo and paranoid.
+
+ The gonzo method assumes that you know everything about your sources
+ so that recovery from failures is "just a matter of typing." You
+ created the branch this way:
+
+ cvs checkout <module>
+ cd <module>
+ cvs tag -b <branch_tag>
+ cvs update -r <branch_tag>
+ >>> Edit away.
+ cvs commit <<== Onto branch
+
+ Now you want to merge your branch back into the Main branch, you are
+ certain you can make it work, or at least detect all the failures, so
+ you dive in and hack away: (For simplicity, we will assume you are
+ collapsing (i.e. merging and forgetting) a side-branch into the Main
+ branch from your single working directory.)
+
+ cvs update -A
+ cvs update -j <branch_tag>
+ >>> Edit the 'C' files and remove the overlaps.
+ >>> Edit some more to make it all compile and work.
+ cvs commit
+
+ Looks simple. For more details on the output from the "update -j"
+ command, see 3P.2 and 4C.6.
+
+ Note: You could also checkout a whole new working directory and
+ perform the merge at the same time by replacing the two
+ update commands with these two commands:
+
+ cvs checkout -j <branch_tag> <module>
+ cd <module>
+
+ The paranoid way is more difficult, but it can catch all sorts of
+ problems. You created the branch this way:
+
+ cvs checkout <module>
+ cd <module>
+ cvs tag <branch_point_tag>
+ cvs tag -b <branch_tag>
+ cvs update -r <branch_tag>
+ >>> Edit away.
+ cvs commit <<== Onto branch
+
+ The extra tag command places a non-branch tag on the Branch Point, an
+ act that makes it easier to do "diffs" later. Now we decide to perform
+ the merge:
+
+ cvs tag <latest_on_branch_tag>
+ cvs update -A
+ *1* cvs diff -r <branch_point_tag> -r <latest_on_branch_tag>
+ >>> *1* shows all the changes on the branch.
+ *2* cvs diff -r <branch_point_tag> -r HEAD
+ >>> *2* shows the changes on the trunk since branching.
+ cvs tag <premerge_tag>
+ cvs update -j <branch_tag>
+ >>> Edit the 'C' files and remove the overlaps.
+ *3* cvs diff
+ >>> Verify that *3* matches *1*, except for line numbers.
+ cvs commit
+ cvs tag <just_merge_changes_tag>
+ >>> Edit some more to make it all compile and work.
+ cvs commit
+ cvs tag <after_merge_cleanup_tag>
+
+ The reason *3* and *1* match so closely is that they are the
+ differences between two pairs of starting points and ending points
+ after the same data was inserted. If they are significantly different,
+ you will want to figure out why.
+
+ NOTE: You will have to tell everyone to stay the hell out of the
+ Repository while you do this. If they commit something while you are
+ in the middle of a merge, your job will be much more difficult. If
+ they "update" at the wrong time, their work will be randomized until
+ you finish. It's better to call a halt.
+
+ See 3H.13 for some more information about dealing with merges after
+ import. The last part of the procedure is applicable to any large
+ merge.
+
+ Last modified: _6/13/1997_
+
+ 15. Is a Vendor merge any different from a branch merge?
+
+ No. In most ways, a Vendor branch is exactly the same as any other
+ branch. In a Vendor merge, the data is append to the branch by the
+ "import" command, rather than by hand-editing, but the merge process
+ is the same.
+
+ See the "import" command in section 3H.
+
+ Last modified: _6/13/1997_
+
+ 16. How do I go back to a previous version of the code on a branch?
+
+
+
+
+ You can avoid digging into RCS revision numbers (executing "update
+ -r (rev)" on each file) by trying one of these:
+
+Use non-branch tags as you normally would. Non-branch tags
+ attach to specific revisions, so a "tag (tag)" command would
+ mark the revisions you have in your working directory, which
+ are on your branch. If you need to retrieve them, use "update
+ -r (non-branch-tag)"
+
+ Doing this overrides the sticky (branch-tag) attached to your
+ working directory with a non-branch tag, which means you won't
+ be able to commit until you again move forward to the end of
+ the branch with "update -r (branch-tag)".
+
+Use the "update -r (branch-tag):(date)" trick.
+
+ This is almost like using the '-D' option, but it looks for
+ revisions extant on (date) only along the given branch.
+
+ As in #1, you can't commit to this kind of working area,
+ because it has a sticky date referring to revisions in the
+ middle of a branch.
+
+[comment from the audience: You are dreaming..
+this does not work.. try it, you get
+No such tag: "MYTAG:May 1"
+or similar. I wish it did because I need it. julian@whistle.com]
+
+
+You can branch a branch.
+
+ If you add a branch tag to file in a working directory that was
+ checked out on a branch, you will branch the branch. This
+ works just fine, though you'll have to play some games to merge
+ everything back together again. You'll also create 6-part
+ revision numbers. (They'll be 8-part revision numbers if you
+ branch a branch that started out with some unmodified files on
+ the Vendor branch. Think about it. How does revision
+ 1.2.4.2.4.2.2.1 grab you?)
+
+
+(fixed formatting, kingdon@cyclic.com)
+
+ Last modified: _9/8/1997_
+
+ 17. Once I've found the files I want, how do I start changing them? I keep
+ getting warnings about sticky tags.
+
+ What you probably did was type "cvs update -r <tag>" where <tag> is a
+ non-branch tag. "update" created a sticky tag for a specific revision,
+ not a branch. To start working right there, you have to create a
+ branch to work on.
+
+ You have two choices.
+
+ You can do it in place and keep working:
+
+ cvs tag -b <branch_tag> <<== To tag the current files.
+ cvs update -r <branch_tab> <<== To move onto the branch.
+
+ You can do it "externally" and create a new working directory:
+
+ cvs rtag -b -r <tag> <branch_tag> <module>
+ cvs checkout -r <branch_tag> <module>
+
+ <module> can be a relative path within the Repository.
+
+ <tag> in the above is the non-branch tag you placed earlier
+ that caused the error in your question. Be warned that
+ if <tag> is not set on all the files (or all the right
+ revisions) you won't get exactly what you wanted.
+
+ Last modified: _6/13/1997_
+
+ 18. Why do I get the latest files on the branch when I tried to "update -r
+ <tag>"?
+
+ If "update -r <tag>" always retrieves the latest files on a branch,
+ then <tag> is really a <branch_tag>. A branch tag is supposed to be
+ used to grab a branch to work on. Since you can't modify a file in the
+ middle of a branch, checking out a <branch_tag> will give you the
+ latest revision on the branch.
+
+ If you want to "checkout" a specific collection of revisions, you must
+ use a "non-branch" tag. See the first part of 4C.16.
+
+ Last modified: _6/13/1997_
+
+ 19. How can I avoid a merge? I just want to move the latest revision on my
+ working branch directly onto the trunk.
+
+ There is no direct way to do this using CVS, though the technique is
+ not difficult using shell commands. Here's one way:
+
+ Move your working directory to the Main Branch.
+
+ cvs update -A
+
+ Use "update -p" to grab the latest revision on the branch and write
+ it over your working files. Make sure you don't have an modified files
+ -- you will lose them. The following is in "csh" syntax. Change the
+ wildcard to grab the files you want
+
+ foreach i (Makefile *.cc *.hh)
+ cvs update -p -r <branch_tag> $i > $i
+ end
+
+ Commit all the working files onto the Main Branch.
+
+ cvs commit -m 'Moved branch <branch_tag> onto MAIN'
+
+ You should experiment with the above before blasting everything.
+
+ Last modified: _6/13/1997_
+
+ 20. How to I avoid merge collisions in the RCS $\Log$ data?
+
+ In short, you can't. The RCS $\Log$ keyword is handled differently
+ from all other RCS keywords.
+
+ On the info-cvs mailing list, there is a periodic discussion that goes
+ something like this:
+
+ Question: How do I deal with $\Log$? Answer1: You can't do much with
+ it. Here's how it works. . . Answer2: I've found a limited way to use
+ it. . . Answer3: Get rid of it. $\Log$ is an abomination.
+
+ I tend to lean toward answer #3. There are only two sets of people who
+ would ever have access to logs stored within sources files, developers
+ and source customers.
+
+ For developers:
+
+ Log entries within sources files are notoriously incomplete, rushed,
+ poorly phrased and in many cases incorrect, making them useless for
+ debugging or file maintenance. I remember a maxim from "Software
+ Tools" (I believe): "Read the code, not the comments." No managerial
+ order or plan for programmer discipline will affect this in the real
+ world.
+
+ Log entries are usually in an unreadable mixture of styles. Many log
+ entries are just plain meaningless. Some are foolish. Some are even
+ insulting. Examples:
+
+ "Corrected spelling of misspelling." "Bug fix." "Reversed stupid
+ change in previous revisions." "If Joe could do his job, this would
+ already have worked."
+
+ Log entries are not managed well by the tools. Any merge can cause
+ conflicts in the $\Log$ data. Branch merges produce incomplete logs.
+ They can be edited into chaos and they are not regenerated. They waste
+ space duplicating information available to the developer with a single
+ command.
+
+ Even if correct when originally entered, as changes are made to the
+ file, log entries become false over time. Humans are not good at
+ reading down through a list and remembering only the last change
+ affecting something. Over time *most* of the log is wrong.
+
+ Even if still correct, the log data is almost useless to developers
+ without the code diffs. If you can get code diffs, you can display the
+ log.
+
+ For source customers the problem is even worse. The last thing you
+ want to show customers is a hodge-podge of tiny comments about large
+ changes followed by a series of emergency fixes before delivery. If
+ you distribute sources, then you should provide documentation, or
+ changelogs reviewed by people who won't let comments like "Fixed for
+ stupid customer." out the door.
+
+ Conclusion: Though some people would prefer to see in this FAQ
+ techniques for making the $\Log$ entries the best they can be, I
+ believe them to be a lost cause. My suggestion is to hunt down, root
+ out and destroy all occurrences of $\Log$ and the unusable data
+ attached to it wherever you may find it.
+
+ Last modified: _6/13/1997_
+
+ 21. Why should I trust automatic merges?
+
+ Some developers have the feeling that three-way merging doesn't work.
+ They fear and distrust the way the "update" command automatically
+ merges committed changes from the Repository into the working file.
+
+ Experience has shown that most merges are utterly painless and most of
+ the rest are easily resolved. The few conflicts that cause headaches
+ are nearly all due to poor communication between developers, a problem
+ no source control system can obviate.
+
+ Some developers were troubled in the past by flaky Unix software. I
+ can't say that everything is perfect, but the tools CVS depends on
+ (RCS and diff, mainly) are fairly solid nowadays. They work.
+
+ Since it does seem to work for most of us, the algorithm is unlikely
+ to change soon. Why not test it on a couple trouble spots and if it
+ works for you, use it for a while? Then you can make an informed
+ decision.
+
+ Last modified: _6/13/1997_
+
+ 22. How does CVS decide if it can safely perform a merge?
+
+ CVS can merge any text file, possibly discovering a conflict and
+ leaving overlaps for you to edit. Editing the conflict markers out of
+ the file is a moment's work, but resolving the conflict could take an
+ arbitrary amount of time. CVS works to determine if it *should* merge,
+ not if it *can*.
+
+ See 2B.6 for how the merge proceeds.
+
+ Last modified: _6/13/1997_
+
+ 23. After resolving merge conflicts in a file, what if I want to keep my
+ previous version, and not take any of the branch changes?
+
+ If you want to retain your previous version, a version on the MAIN
+ branch greater than 1.1 (one you committed there), just throw the
+ merged file away and "cvs update" the file.
+
+ You don't need to commit something to remember it. The tags you place
+ before and after the merge should give all the handles you need to
+ find various versions. You don't have to create a new version of the
+ file.
+
+ If you want to retain the previous Vendor revision, you can grab a
+ copy of it using "cvs update -p" and commit it or use the technique
+ described in 3B.3 to revert back to the Vendor branch.
+
+ Last modified: _6/13/1997_
+
+ Category: /Advanced_Topics_/Engineering/
+
+ " + Engineering"
+
+ 1. Where can I find out about Software Engineering?
+
+ A couple different people suggested this book:
+
+ Software Configuration Management: Coordination for Team Productivity;
+ Wayne A. Babich; Addison Wesley; 1986; ISBN 0-201-10161-0
+
+ A number of others suggested Appendix B of the book "Decline and Fall
+ of the American Programmer" by Ed Yourdon, called "The Programmer's
+ Bookshelf". It list 87 books you are expected to have read. Since they
+ publish many of the books, Prentice-Hall distributes this list as
+ "Prentice Hall Professional Technical reference PTR-125-AA3.
+
+ One interesting item from the Yourdon book: The total number of
+ professional computer books sold is less than the number of
+ programmers currently in the United States. It wasn't clear from the
+ book whether this meant "per year" or not, but it is still
+ frightening.
+
+ Last modified: _6/13/1997_
+
+ 2. How do I flexibly arrange the modules file to describe my sources?
+
+ An equivalent question might be, "How do I structure my sources?" This
+ can be a difficult question especially in the areas that are more
+ political than technical.
+
+ Generally you want to think about which pieces of your system need to
+ be checked out together, built as one system or tagged as a consistent
+ whole. You should certainly create module names that correspond to
+ complete, buildable collections that you would tag and release as one
+ "product". It is also convenient to create module names for small
+ sections of the Repository containing files that will all be worked on
+ at the same time by the same person or group.
+
+ Once you have defined the structure of your work, you can usually see
+ how to lay it out in a Repository. After that the modules file is
+ easy. You set up module names and aliases to match what you need to
+ check out by name. If you like relative directories, it is possible,
+ but not recommended, to work completely without a modules file. See
+ 1D.11 and 2C.7 for some info about the modules file.
+
+ Here are a few types of modules. You should experiment to see what
+ kind of structure each of these produces. They all have different
+ uses.
+
+ Connected projects in one group with two separate helper
+ directories. The helper directories can contain build tools, header
+ files, libraries, or whatever you like.
+
+ These are all aliases that checkout relative pathnames. The equivalent
+ results could be produced by placing the selected relative pathnames
+ on the "cvs checkout" command line.
+
+ pr1 -a P1 HELPERS
+ pr2 -a P2 HELPERS
+ pr3 -a P3 HELPERS
+ pr12 -a P1 P2 HELPERS
+ pr13 -a P1 P3 HELPERS
+ pr23 -a P2 P3 HELPERS
+
+ P1 -a group1/proj1
+ P2 -a group1/proj2
+ P3 -a group1/proj3
+ HELPERS -a group1/helper1 group1/helper2 MAKEFILE
+ MAKEFILE -a group1/Makefile
+
+ Actual Repository directory structure: (from $CVSROOT down)
+
+ group1/ Makefile The top level Makefile. helper1/ helper2/ Helper
+ files and dirs proj1/ Files and dirs proj2/ Files and dirs proj3/
+ Files and dirs
+
+ "checkout group1" produces a duplicate of the above. "checkout projX"
+ produces all but "projY" and "projZ". "checkout projXY" produces all
+ but "projZ".
+
+ Here is the exact same set of module names describing the same
+ Repository layout using module names (and aliases containing module
+ names) instead of merely aliases for relative pathnames.
+
+ There is one difference in the result. The name of the top level
+ directory in the checked out working tree will match the "module" name
+ (e.g. pr1) instead of always being "group1" as it was in the first
+ example above.
+
+ pr1 group1 proj1 &HELPERS
+ pr2 group1 proj2 &HELPERS
+ pr3 group1 proj3 &HELPERS
+ pr12 group1 proj1 proj2 &HELPERS
+ pr13 group1 proj1 proj3 &HELPERS
+ pr23 group1 proj2 proj3 &HELPERS
+
+ HELPERS -a helper1 helper2 group1-Makefile
+ helper1 group1/helper1
+ helper2 group1/helper2
+ group1-Makefile -d . group1 Makefile
+
+ The above line (with the -d in it) says that when the module named
+ "group1-Makefile" is checked out, the file named Makefile file will be
+ found in a directory named $CVSROOT/group1 and will be checked out
+ into a directory named '.', which obviously already exists.
+
+ The & references say to interpret those pathnames relative to the
+ directory where the whole module is stored. For the "pr1" module, that
+ directory is "group1", so the &HELPERS reference winds up placing
+ Makefile in '.' relative to "group1".
+
+ A short one containing the basic "module" actions:
+
+ m1 head/path file1 dir2 file3 dir4 file5
+
+ When checked out, a directory named "m1" appears in your current
+ directory. Elements named file1, dir2, file3, dir4, and file5 appear
+ in it. They were originally taken as relative paths from
+ $CVSROOT/head/path.
+
+ Here's another way to construct a working directory out of pieces of
+ the Repository:
+
+ projX projX Makefile &projX_inc &projX_src &projX_doc
+
+ # The first line selects a single file within projX, plus
+ # the contents of three other modules. Those three other
+ # modules rename their directories.
+
+ projX_inc -d include projX/inc projX_src -d source projX/src projX_doc
+ -d documentation projX/doc
+
+ A Unix tree. This is similar to what CVS was developed for and the
+ way I have used it for years.
+
+ # Top level
+ unix unix
+ u_bin unix/bin
+ u_etc unix/etc
+ u_man unix/man
+ usr-bin unix/usr.bin
+
+ # Subdirs of top level dirs. (tiny subset)
+ ls unix/bin/ls
+ fsck unix/etc/fsck
+ man8 unix/man/man8
+
+ # Programs without subdirs. (tiny subset)
+ cat unix/bin Makefile cat.c
+ uniq unix/usr.bin Makefile uniq.c
+
+ # /usr/local/src
+ localsrc localsrc
+ gnu localsrc/gnu
+ public localsrc/public
+ X11 localsrc/X11
+
+ # GNU and PD tools
+ cvs localsrc/gnu/cvs
+ emacs localsrc/gnu/emacs
+ rcs localsrc/gnu/rcs
+ btoa localsrc/public/btoa
+ tcsh localsrc/public/tcsh
+
+ # X11 related items.
+ tvtwm localsrc/X11/contrib/tvtwm
+
+ "unix" was checked out and built from the top down, using a set of
+ Makefiles that knew about the whole structure. "localsrc" was kept
+ checked out in /usr/local/src.
+
+ At any time I could run "checkout ls" or "checkout cat" and get a
+ simple directory with only that tool in it, plus a subset Makefile
+ that knew how to build that tool against the installed (or alternate,
+ via environment variables) headers and libraries.
+
+ I found it very handy to be able to run "ls" and see the three tools I
+ was porting that week.
+
+ Last modified: _6/13/1997_
+
+ 3. Can I have multiple source repositories, one for each project?
+
+ Yes, you can have as many Repositories as you like. But each
+ Repository must be managed separately, creating additional work.
+
+ Question 4A.1 provides a short description of setting up a single
+ Repository. A few additional considerations:
+
+ It is a good idea to start by creating a single Repository and split
+ it up (or create additional Repositories) only if you believe it is
+ really necessary. I would only create a new Repository if the data is
+ completely disconnected from the rest of the main Repository.
+
+ If there is a lot of overlap among the developers working on the
+ collections of files you want to place in different Repositories, or
+ if there is any connection between those collections, I would go out
+ of my way to create a single Repository. It is much easier to manage.
+
+ Disk space should not be a factor since you can build up a
+ Repository using symbolic links and/or remote mounts.
+
+ Each Repository is completely distinct. You can't check out modules
+ from different Repositories at the same time. A better way of looking
+ at it is that if you *can* check out two modules or directories with a
+ single "checkout" command (without contortions or explicit absolute
+ pathnames), then they are in the same Repository.
+
+ To "checkout" modules from multiple Repositories, you must use the
+ "cvs -d" option on all CVS commands or alter your $CVSROOT variable
+ when you change focus to another Repository. If you work with multiple
+ Repositories, it is a good idea to configure CVS to use absolute
+ pathnames in the ./CVS/Repository file, since most commands (other
+ than "checkout") will use that file rather than $CVSROOT.
+
+ If you configure CVS to use relative pathnames in your
+ ./CVS/Repository files, you must always be careful to set your
+ $CVSROOT properly or you will get unexpected results.
+
+ If you have two modules or directories by the same name at the same
+ relative path inside two different Repositories, you are asking for
+ disaster. You could unexpectedly update a directory with completely
+ unrelated files. This is not a fanciful example -- a Repository is
+ occasionally duplicated for release purposes in which case *all* the
+ paths in the two Repositories are the same.
+
+ Last modified: _6/13/1997_
+
+ 4. Who should administer the Repository and manage the modules file?
+
+ This is a "management style" question. In large or traditional groups,
+ the CVS procedures are warped to conform to local conventions. In
+ small groups, in groups with strong personalities or on new projects
+ the choice of source control procedures can help create some of the
+ working environment. Here is a taxonomy of environments I have worked
+ in or helped set up:
+
+ Situation 1.
+
+ A small number of competent developers working on a medium size
+ project. We all got along and we all respected each other (at least
+ technically). Anyone edited anything.
+
+ Modules and Repository admin was mostly left to me. I never found a
+ problem in minor changes made by anyone else.
+
+ Situation 2.
+
+ A large number of experienced developers sprinkled with wackos. Many
+ of the developers didn't want to deal with any kind of source control.
+ They wanted a full-service source control system that caused them zero
+ thought.
+
+ I learned "big stick" diplomacy here. There was a small number of
+ "designated" (by me) people who were allowed to do *anything* other
+ than "update" and "commit". Even "checkouts" were controlled. This is
+ where I found "history" and "release" the most useful.
+
+ Situation 3.
+
+ A small number of developers who wanted me to "help", but who didn't
+ want to deal with anything other than their favorite algorithms.
+
+ I didn't have the time to baby-sit this group, so I designated one of
+ them to be my official contact and made him do it all. He felt sullied
+ by the requirement to pay attention to anything other than his pet
+ coding projects, but enjoyed the "status" of being the only one who
+ could touch the control files without my kicking the chair out from
+ under him.
+
+ Situation 4.
+
+ A huge number of developers of covering the whole spectrum of
+ competence and experience split into 20 groups, none of which
+ cooperated with the others, working on 57 different projects, most of
+ which didn't inter-operate.
+
+ Managing it in any coherent way was not my responsibility (and beyond
+ my tolerance for chaos). Too many people. So I privately designated a
+ person in each group to be the contact and kept watch on the
+ Repository activity. When something went wrong, I notified the contact
+ for the group and told him what was happening and *he* kept his troops
+ in line. They were tougher with their own group that I would have
+ been.
+
+ Eventually only a few people were willing to touch the control files,
+ since they were flamed from all directions if they screwed up.
+
+ Situation 5.
+
+ In a medium group of really *serious*, and seriously overworked,
+ people, someone else was designated the "master". I convinced the
+ master I knew what I was doing and went on my way.
+
+ No one else in the world was allowed to touch anything.
+
+ Situation 6.
+
+ In a large amorphous group of beginners, experts and clowns, over whom
+ no one had official control, I was forced to employ a group of
+ relative beginners (who became experts rather quickly) to police the
+ world. The ultimate in locking the barn after the horse was stolen, we
+ kept Chaos from destroying us only by use of superior firepower.
+
+ My choice, if allowed, is to let anyone touch anything. I keep backups
+ of important items and let people know individually whether I want
+ them to touch things or not. If someone on my "no touch" list touches
+ and succeeds, they are allowed more slack. If they screw up after
+ being warned, their screwup becomes public. After a few months, I
+ usually have no trouble keeping the world running smoothly, at least
+ from my (and CVS's) perspective.
+
+ Last modified: _6/13/1997_
+
+ 5. Isn't disk space a big factor? CVS copies files out of the Repository,
+ duplicating everything.
+
+ Everyone knows that disk space is getting cheaper. How do we reconcile
+ this with the equally well-known problem that *all* disk is *always*
+ filled up?
+
+ In my opinion, the main reason disk space will never be an unlimited
+ resource is that it is the major variable in organizational time/space
+ tradeoffs. It isn't a problem of waste or an aspect of Murphy's law,
+ as some claim it is, but rather a direct consequence of good
+ management. Disk space is, and will always be, a limited resource.
+
+ First, the cost of *deploying* that disk is not dropping as fast as
+ the cost of the storage medium. The cost of machines to hold the disks
+ and the networks to connect them are dropping more slowly than disk
+ media. And the cost of the human time necessary to manage the
+ machines, networks, disks, and the developers using them, is not
+ dropping at all. The cost of human time continues to rise.
+
+ If management decides that expensive human time can be saved by using
+ all that new disk space to keep the last three releases online, then
+ that's what it will be used for. If each release takes up a Gigabyte
+ and you support 30 platforms, a simple time-saving suggestion has just
+ grabbed 100 Gigabytes of disk space. And we've ignored the potential
+ disk storage needed to support "better Customer Service", another
+ management refrain.
+
+ Even at 30 cents per Megabyte (next year's price), you've just used up
+ $30,000 of disk space. And that doesn't count the computers, tape
+ drives and humans necessary to maintain and deploy all of it. Spending
+ money to save time has its own overhead, too.
+
+ Binaries are getting bigger. Graphics and data collection devices can
+ eat up any amount of disk. There are more tools available, more
+ libraries, more raw data than you can ever store. My home computer has
+ a Gigabyte of disk on it. It could easily handle 30.
+
+ The "economy" of disk storage media will never remove the need to
+ manage disk space.
+
+ So, here's an un-reviewed suggestion originally from Graydon Dodson
+ <grdodson@lexmark.com>, which I've altered and edited heavily.
+
+
+ - Keep a directory where the whole tree is checked out. (It might be
+ built and tested once in a while to make sure it is worth linking to,
+ but that doesn't affect the source control aspect of this procedure).
+ Let's call it /master/build.
+
+
+ - Write a tool that creates a tree of directories (like the X11
+ "lndir" command) filled with links to the checked out files in the
+ /master/build tree.
+
+ This tool should also provide real copies of, not symlinks to, all the
+ files within the CVS administrative directories.
+
+
+ - You could also provide a way for the tool to take a list of whole
+ directories that you will never change, for which it would create a
+ single symlink to the directory and not a subtree of symlinks to
+ files. Or you could rm -r pieces of the resulting working directory
+ yourself and replace it with links.
+
+
+ - If you want to edit a file, you have to grab a real copy and keep it
+ until your revision shows up in the /master/build tree. I'd create a
+ script to do this: cvsgrab <file>
+
+ #!/bin/csh -f
+ set f = $1
+ if (! -l $f) then
+ echo "file $f is not a symlink"
+ exit 1
+ endif
+ rm $f
+ set rev = `grep "^/$f/" CVS/Entries | awk -F/ '{print $3}'`
+ cvs update -p -r $rev $f > $f
+
+ You can't do a plain "cvs update" since that would grab newer
+ revisions from the Repository, not the revision you wanted to start
+ with. After the file is no longer a symlink, you can work normally.
+ You'll have to run "update" before "commit" anyway if there are newer
+ revisions.
+
+
+ - Presumably there would also be a tool to traverse the link tree and
+ revert it to links if there are no modified files and/or if all the
+ real files match the revision of the /master/build tree.
+
+
+ - To avoid confusing CVS when the /master/build revisions are updated
+ but your CVS/Entries files is not, CVS would have to change to handle
+ symlinks. It currently causes problems with this scenario:
+
+ ./<file> is a symlink.
+
+ ./CVS/Entries says you are revision 1.2.
+
+ The corresponding CVS/Entries file in /master/build says the latest
+ revision is 1.3.
+
+ cvs update <file> shows a 'C' conflict flag.
+
+ Last modified: _6/13/1997_
+
+ Category: /Advanced_Topics_/Installing_CVS/
+
+ " + Installing CVS"
+
+ 1. What do I have to do before I install CVS?
+
+ You must decide where to set up a Repository.
+
+ Though you can construct a Repository tree structure using links and
+ mount points, there must be a single copy of each real file across
+ your entire organization. You may not "rdist" files and expect to edit
+ both copies.
+
+ CVS does not support a truly distributed Repository. You can have
+ multiple Repositories, but each one must be mounted (not copied or
+ "rdist"ed) from a single place onto all machines where it will be
+ used.
+
+ Initially, a Repository takes about same amount of disk space as the
+ sources you want to put into it, plus a bit of overhead for the RCS
+ files.
+
+ See Section 4B. For multiple Repositories, see 4G.3
+
+ You need a directory in everyone's $PATH variable where you can
+ install all the executables. /usr/local/bin is a common place.
+
+ You need some helper tools besides CVS such as "RCS" and a good set
+ of "diff" and "diff3" programs. See 1B.4 for suggestions.
+
+ Read the README, INSTALL and ChangeLog files to see what you are
+ getting into.
+
+ Make sure you have versions of all the programs mentioned in the
+ "cvs/src/options.h" and "cvs/src/rcs.h" files.
+
+ Though you can probably muddle along without it, you should appoint
+ one or more "Repository Administrators" who will be responsible for
+ maintaining the Repository structure, administrative files and the
+ "modules" interface.
+
+ Someone at your site should probably be on the info-cvs mailing list.
+ See 1B.5.
+
+ Last modified: _6/13/1997_
+
+ 2. How do I configure the CVS programs?
+
+ You should certainly start by reading the README file, the INSTALL
+ files and possibly the ChangeLogs in each directory, the Makefile.in
+ files and the "cvsinit.sh" program.
+
+ Edit the "options.h" file in the "src" directory.
+
+ You might need to specify a few site-specific pieces of information
+ including the names of a number of functions.
+
+ Hint1: You probably want to set the DIFF macro to use your version of
+ the GNU diff program with the '-a' option. Ours is set to "gdiff -a".
+
+ Hint2: You want to use RCS 5.6.0.1 or greater and set the "HAVE_RCS5"
+ macro.
+
+ Execute the ./configure command.
+
+ Type "make".
+
+ After running "make" you might try running the "sanity.sh" script:
+ ./src/sanity.sh `pwd`/src/cvs
+
+ It writes into /tmp/cvs-sanity by default.
+
+ Finish reading the INSTALL file and test out the system.
+
+ Last modified: _6/13/1997_
+
+ 3. What do I have to install?
+
+ Install the "cvs" executable and "mkmodules" from the CVS sources.
+ The man page is useful too. If you plan to report bugs, you should
+ also install "cvsbug".
+
+ Make sure you have versions of all the programs mentioned in the
+ options.h file, most of which are included in a standard Unix system.
+
+ Unless you plan to reimplement RCS [:-)], you must install RCS.
+
+ It is a very good idea to examine the RCS installation instructions
+ and make sure you are using the GNU versions of "diff" and "diff3" or
+ merges (an important part of CVS) will not work as well as you'd like.
+
+ Set your $CVSROOT environment variable and create the Repository
+ (which you planned out in 4A.1) with the "cvsinit" command at the top
+ of the CVS sources.
+
+ You'll need to edit the Repository control files created by
+ "cvsinit".
+
+ Install any helper programs mentioned in the modules file.
+
+ Last modified: _6/13/1997_
+
+ 4. How do I work around the merge problems in GNU diff version 2.1 or
+ later?
+
+ See 1B.4 If you use recent versions of RCS and "diff", you won't run
+ into the above. If you do, see 5B.8
+
+ Last modified: _6/13/1997_
+
+ Category: /Advanced_Topics_/Internal_errors/
+
+ " + Internal errors"
+
+ 1. Explain: "ci error: unexpected EOF in diff output"
+
+ RCS versions earlier than 5.5 print the above error when a file does
+ not end in a newline character. It can be caused by:
+
+
+ - Editing with Emacs and not using "require-final-newline".
+ - Committing a binary file.
+ - Filesystem failures (NFS!) that put nulls in your file.
+
+ The solution is to upgrade to RCS 5.5 or later. (Of course, this won't
+ fix filesystem failures. It will merely allow RCS (and therefore CVS)
+ to handle the file without error.)
+
+ Last modified: _6/13/1997_
+
+ 2. Explain: "RCS file /Repository/module/file.c,v is in use"
+
+ This is an RCS error that occurs when its internal lock file has been
+ left around by an RCS command interrupted by some sort of system
+ crash, disk failure or SIGKILL signal.
+
+ Go into the Repository and look for files with names similar to
+ "file.c,v", usually starting with ',', '_' or '#'. Make sure they are
+ really crash remnants and do not belong to transactions in progress --
+ a recent last-modified timestamp is a good indicator of a live
+ transaction. Delete them if they are old.
+
+ Last modified: _6/13/1997_
+
+ 3. Explain: "co error, line 2: Missing access list"
+
+ This is an error message from RCS Version 3 when it tries to read a
+ file created by a later version of RCS.
+
+ HP decided to "standardize" on an ancient version of RCS some time
+ ago. You can't use it for CVS. See 4H.6.
+
+ Since the error comes from having a later version of RCS than HP
+ supports, you probably did install the later version but must have
+ recently changed your $PATH or installed the HP package that has RCS
+ in it.
+
+ You should either reconfigure CVS to use absolute pathnames to the
+ proper versions of the RCS programs that CVS uses, or change your PATH
+ to look there first. If you haven't installed the latest version of
+ RCS, you should upgrade. See 1B.4
+
+ Last modified: _6/13/1997_
+
+ 4. Explain: "error: RCS file name `xyz .c' contains white space"
+
+ RCS 5.6 doesn't allow white space in filenames. Apparently this
+ restriction will be removed in RCS 5.7, but CVS may still require that
+ filenames have no white space in them.
+
+ Last modified: _6/13/1997_
+
+ 5. Explain: cvs checkout: warning: <X> is not (any longer) pertinent
+
+ This message occurs in three instances:
+
+ When there is an entry in the ./CVS/Entries for file <X> and there
+ is no RCS file in the Repository to back it up.
+
+ If the working file exists, and hasn't changed (determined from the
+ timestamp) it is removed.
+
+ When you try to check out a piece of the Repository with:
+
+ cvs checkout some/place/in/repository/tree
+
+ and at least the first element of the path (i.e. "some" in the above)
+ exists, but some part of the rest of it does not.
+
+ The checkout command checks the modules file first for the whole path,
+ then for a prefix of the path as a module name. If it doesn't find
+ *any* portion of your path in the modules file, it says:
+
+ cvs checkout: cannot find module `<module/path>' - ignored
+
+ If it finds some set of prefix directories, it prints the message you
+ see.
+
+ In practice this is usually a spelling error.
+
+ If the Repository files you are trying to check out or update are
+ not readable by you, the same problems can occur. Check the
+ permissions on the files involved.
+
+ Last modified: _6/13/1997_
+
+ 6. Why did a Repository file change from <file>,v to ,<file>,?
+
+ This is an RCS problem, since the ,<file>, syntax for file names is
+ used by RCS and not CVS.
+
+ RCS constructs a new <file>,v in a temporary file named ,<file>,
+ (which doubles as a lock file) then renames it to <file>,v when it is
+ done. The only way this is reliable is if your system's version of
+ rename(2) is an atomic, as required by POSIX.
+
+ If your system has a non-atomic (and therefore non-POSIX) rename(2)
+ system call, RCS runs uses an internal version of this algorithm to
+ approximate the atomic rename:
+
+ rm <file>,v; ln ,<file>, <file>,v; rm ,<file>,
+
+ If the system crashes, or you lose your NFS connection between the
+ first "rm", but before the "ln", you can be left only with the
+ ,<file>, file. If the crash or network failure occurs between the "ln"
+ and the final "rm", you could be left with a pair of linked names.
+
+ Recovery:
+ - If only the ,<file>, exists, rename it to <file>,v.
+
+
+ - If both ,<file>, and <file>,v exist and are linked, remove the
+ ,<file>, file.
+
+
+ - If both ,<file>, and <file>,v exist and are separate files, look at
+ the dates, "diff" them and make your best guess. This sounds like the
+ remnants of two separate events.
+
+ Last modified: _6/13/1997_
+
+ Category: /Advanced_Topics_/Other_Systems/
+
+ " + Other Systems"
+
+ 1. I use a NeXT. Is there anything I need to know?
+
+ NeXTSTEP 3.0's Interface Builder uses "nib" directories, rather than
+ the files used in previous revisions. It removes files it doesn't
+ recognize, making it impossible to place such a directory under CVS --
+ the CVS admin directory will be removed.
+
+ Some time ago, <Bob_Vadnais@pdh.com> posted a palette named CVSPalette
+ that claimed to resolve this problem. It was intended to preserve the
+ CVS administrative directories within nib documents (directories) that
+ Interface Builder usually removes.
+
+ CVSPalette is no longer in its announced place:
+
+ ftp.cs.orst.edu:/pub/next/submissions
+
+ though I did find two other interesting files on ftp.cs.orst.edu:
+
+ /software/NeXT/sources/tools/cvs-next-2_1_1.tar.Z
+
+ which is a port of CVS 1.3 (along with RCS and diff) and:
+
+ /software/NeXT/sources/programming/cvs.postamble-2.4.gz
+
+ which appears to be a set of wrappers for CVS commands that claim to
+ allow you to use CVS effectively (and without need for the "command
+ line") on a NeXT machine.
+
+ [[Anyone know the truth about CVS and NeXT?]]
+
+ Last modified: _6/13/1997_
+
+ 2. I use OS/2 and/or DOS and/or Windows. Is there anything I need to know?
+
+ When using a local repository, be sure to specify the local access
+ method or CVS will interpret the drive letter as a remote host name
+ due to the : following it:
+
+ WRONG: CVSROOT=C:\SRC\CVSROOT
+
+ RIGHT: CVSROOT=:local:C:\SRC\CVSROOT
+
+ (larry.jones@sdrc.com)
+
+ You can share RCS files between Unix and DOS while avoiding the MS-DOS
+ file name limits by setting your RCSINIT environment variable to
+ '-x/,v'. New RCS files will be created without the standard ",v"
+ suffix, though files ending in ",v" will still be found if there is no
+ matching file in the same directory without the ",v".
+
+ Erik van Linstee offers an OS/2 and a DOS port of CVS 1.3 in:
+
+ ftp.informatik.tu-muenchen.de:/pub/comp/os/os2/gnu/devtools or
+ ftp.rrzn.uni-hannover.de:/pub/os2-local
+
+ The files are named:
+
+ cvs13p?[bs].zip
+
+ Where the ? stands for the patch level (currently 8) and the b is for
+ the binaries, the s for the sources.
+
+ There are three binaries. An OS/2 only one (32-bit), a DOS only one
+ (16-bit) and an EMX one that runs on both (32-bit).
+
+ There are many differences between the Unix and the DOS versions of
+ CVS. Read the material that comes with the DOS version before using
+ it.
+
+ [[Updates?]].
+
+ Last modified: _9/22/1997_
+
+ 3. I use SCO Unix. Is there anything I need to know?
+
+ On SCO/UNIX 3.2 V2.0 POSIX signals don't work. Unfortunately the
+ configure program detects POSIXness and configures in the use of POSIX
+ signals. Workaround : Edit out the check for POSIXness in the
+ configure script. [[You could also remove all occurrences of
+ "-DPOSIX=1" from the Makefiles after configure is run. -dgg-]]
+
+ SCO/UNIX doesn't understand #!/<some shell> syntax. This breaks the
+ use of log.pl as it gets invoked by /bin/sh instead of
+ !#/usr/local/bin/perl. WorkAround : edit log.pl and change it into a
+ shell script which invokes perl with log.perl (renamed from log.pl) as
+ input.
+ Contributed by Joe Drumgoole
+
+ Last modified: _6/13/1997_
+
+ 4. I use AIX. Is there anything I need to know?
+
+ The only report on AIX claims to have no trouble using it in concert
+ with SunOS and IRIX platforms.
+
+ Last modified: _6/13/1997_
+
+ 5. I use IRIX. Is there anything I need to know?
+
+ If you see "uid" numbers where you would expect user names, try adding
+ -lsun to the link line. Without it CVS is unable to retrieve "passwd"
+ data through NIS.
+
+ Last modified: _6/13/1997_
+
+ 6. I use an HP system. Is there anything I need to know?
+
+ HP distributes RCS version 3 (a circa 1983 release!) with HP-UX. CVS
+ does not work with RCS version 3; it requires RCS version 4 or later.
+ Your best bet is to find the latest version of RCS and install it
+ somewhere.
+
+ HP-UX 8.07 has a serious bug with the mmap system call and NFS files;
+ the bug can crash the operating system. Make sure that you configure
+ RCS to avoid mmap by setting has_mmap to 0 in RCS's conf.h. This bug
+ is fixed in HP-UX 9.
+
+ Contributed by Paul Eggert
+
+ If using the setgid() trick described in 4D.13, you will have to
+ create an entry in the /etc/privgroup file to give the group assigned
+ to the cvs executable setgid permission (see setprivgrp(1m)).
+ Additionally, if you are restricting "read" access to the Repository
+ by limiting access to the executable (this requires yet another
+ group), then you will require that /etc/logingroup exists and is
+ configured correctly (usually it's just alink to /etc/group).
+
+ Contributed by Dale Woolridge
+
+ Last modified: _6/13/1997_
+
+ 7. I use AFS. Is there anything I need to know?
+
+ There is a problem with the way CVS performs its locking when the
+ files are within AFS. When your current PTS id != your uid, the locks
+ are not deleted. The stat() system call returns the PTS id of the
+ owner. If that id != your uid, CVS assumes you did not lock it, and
+ leaves the lock files alone. The next time you try to use it, it
+ complains that someone has the repository locked.
+
+ Contributed by Michael Ganzberger
+
+ [[This was against CVS 1.3. Is it still in CVS 1.4?]]
+
+ Last modified: _6/13/1997_
+
+ 8. I use A/UX. Is there anything I need to know?
+
+ [[??]]
+
+ Last modified: _6/13/1997_
+
+ Category: /Advanced_Topics_/Related_Software/
+
+ " + Related Software"
+
+ 1. How do I use CVS under Emacs? Is there an Emacs cvs-mode?
+
+ The pcl-cvs package distributed with CVS is an emacs package that
+ helps with the update/commit process. When you are ready to update,
+ you use the 'cvs-update' command within emacs. This executes "update"
+ and fills a cvs-mode buffer with a line for each file that changed.
+ The most helpful features are: descriptive words for what happened
+ (i.e. Merged or Conflict rather than 'U' or 'C'), single keys bound to
+ diffs and commits, and the ability to mark arbitrary groups of files,
+ possibly from different directories, for commit as a whole.
+
+ All the developers in my group that use emacs find pcl-cvs a much
+ friendlier and more helpful way to update/commit than raw cvs. One vi
+ user even converted to emacs just to use pcl-cvs.
+
+ Contributed by Jeffrey M Loomis
+
+ Last modified: _6/13/1997_
+
+ 2. What is GIC (Graphical Interface to CVS)?
+
+
+
+
+ GIC provides a graphical user interface to the Concurrent Version
+ System (CVS), a powerful revision control system. GIC is
+ implemented in the Tcl/Tk programming language and is intended to
+ augment the sometimes cumbersome CVS command line interface.
+
+ Note that according to the official GIC page at
+ http://www.cpsc.ucalgary.ca/redirect/grouplab/projects/gic/
+ GIC is no longer being maintained and tkCVS is recommended
+ instead. For more on tkCVS, see http://www.cyclic.com/tkcvs/
+
+ kingdon@cyclic.com
+
+ Last modified: _9/6/1997_
+
+ 3. What is CAVEMAN?
+
+ CAVEMAN is a front end to CVS written in PERL providing a collection
+ of features desired by the site where it was developed.
+
+
+ - The ability to spread a "project" over multiple Repositories.
+ - Optional automatic tagging after each commit.
+ - Additional locking of files.
+ - Extra before and after program hooks.
+ - A layer of event logging.
+ - All sorts of error messages.
+ - Many changes to the semantics of commands.
+
+ It is available via anonymous ftp on ftp.llnl.gov [128.115.54.18] in
+ gnu/caveman_vX.Y.Z.tar.gz (The numbers X, Y, & Z vary.)
+
+ contact Kathleen Dyer kdyer@llnl.gov
+ (510)423-6803
+ (510)423-5112 FAX
+
+ [[Does someone want to elaborate?]]
+
+ Last modified: _6/13/1997_
+
+ Category: /Advanced_Topics_/Setting_up_and_Manag/
+
+ " + Setting up and Managing the Repository"
+
+ 1. What do I do first? How do I create a Repository?
+
+ First, install all the programs. (See Section 4A.)
+
+ Then create a Repository by executing "cvsinit", which works only from
+ within the head of the CVS source directory. (It needs files from the
+ distribution to work.)
+
+ If you want a very primitive Repository and don't want to save a
+ history log, refer to modules, or use any of the "info" files for
+ logging, pre-commit checks, or editing templates, you can dispense
+ with "cvsinit" entirely. I would advise executing it.
+
+ The cvsinit program will create a short modules file containing the
+ module named "CVSROOT". Change to your work directory and type:
+
+ cvs checkout CVSROOT
+
+ Then read the files that are checked out.
+
+ You will certainly want to add modules of your own. Edit the "modules"
+ file and add lines to describe the items you want to "checkout" by
+ module name. Here's a short list that could be used for storing a
+ small number of GNU and PD sources:
+
+ local local
+
+ gnu local/gnu
+ emacs local/gnu/emacs
+ cvs local/gnu/cvs
+
+ public local/public
+ pdprog1 local/public/pdprog1
+ pdprog2 local/public/pdprog2
+
+ test test
+ junk test/junk
+
+ When you are done editing, "commit" the modules file. If you
+ configured CVS to use "dbm", you might have to edit and commit the
+ modules file twice to change the pathname of the mkmodules program in
+ the modules file.
+
+ Try using the "import" command to insert the "junk" module and play
+ around until you are comfortable.
+
+ Last modified: _11/7/1997_
+
+ 2. What are those files in $CVSROOT/CVSROOT?
+
+ There are eight Repository control (or "database") files of interest
+ in the CVSROOT directory:
+
+ modules contains the "modules" database. See 1D.11, 2C.7, 4B.6 and
+ 4B.7 for more details.
+
+ commitinfo contains two columns: 1. a regular expression to match
+ against pathnames within the Repository and
+
+ a <command> to execute for matching pathnames.
+
+ When you execute "commit", CVS passes the Repository pathname for each
+ directory (and the files to commit within that directory) to
+ <command>. If <command> exits with a non-zero status, the commit is
+ blocked.
+
+ A <command> associated with a pathname of "DEFAULT" is executed if
+ nothing else matches. Every <command> associated with a pathname of
+ "ALL" is executed separately.
+
+ rcsinfo contains the same first column as commitinfo, but the second
+ column is a template file for specifying the log entry you are
+ required to enter for each commit.
+
+ "DEFAULT" and "ALL" work the same as in the commitinfo file.
+
+ editinfo contains the same two columns as commitinfo, but the
+ <command> in the second column is intended to do some consistency
+ checking on the commit log.
+
+ "DEFAULT" works as in commitinfo.
+
+ loginfo contains the same two columns as commitinfo, but the
+ <command> is expected to read a log message from its standard input.
+ The <command> can do anything it wants with the log information, but
+ normally it is appended to a log file or sent to mailing lists.
+
+ "DEFAULT" & "ALL" work the same as in commitinfo.
+
+ cvsignore contains "ignore" patterns that are added to the built-in
+ ignore list. See 2D.10.
+
+ checkoutlist contains a list of other files kept under RCS in
+ $CVSROOT/CVSROOT that should be checked out by mkmodules to provide a
+ readable copy.
+
+ history contains a stream of text records, one for each event that
+ the "history" command is interested in. Though the contents of the
+ history file can be read, it is intended to be read and displayed by
+ the "history" command. This file is the only one in the above list
+ that is not under RCS.
+
+ Last modified: _6/13/1997_
+
+ 3. Is there any other state stored in the Repository besides in the
+ $CVSROOT/CVSROOT directory?
+
+ Only in the RCS files. The Repository holds exactly two things: the
+ tree of RCS files (each usually ending in ",v") and the CVSROOT
+ directory described above.
+
+ Last modified: _6/13/1997_
+
+ 4. How do I put sources into the Repository?
+
+ There are three main ways to put files in the Repository:
+
+ Use the "import" command described in Section 3H.
+
+ This method is the fastest way to put trees of new code into the
+ Repository and the *only* way to handle source releases from a 3rd
+ party software vendor.
+
+ Use "add" followed by "commit".
+
+ This is how to add new files and directories to the Repository, a few
+ at a time. Directories don't need to be committed.
+
+ You can move RCS files directly into the Repository.
+
+ You should create a directory hierarchy to hold them, but you can just
+ move arbitrary ",v" files into the Repository. The only "state" in the
+ Repository other than within ",v" files is in the required CVSROOT
+ directory at the top of the Repository.
+
+ Last modified: _6/13/1997_
+
+ 5. What file permissions should I use on (and in) the Repository?
+
+ If you run a completely open environment (which usually means that you
+ don't have, or don't want to waste, the time to deal with it):
+
+
+ - Set all directory permissions to 777.
+
+
+ - Have everyone set their umasks to 0.
+
+ (BTW, I don't suggest this. I am merely reporting it.)
+
+ If you are a normal Unix shop and want to use groups effectively:
+
+
+ - Set all the directory permissions in the Repository to 775.
+
+ If you are using a system that handles both System V and BSD
+ filesystems, you might have to set the permissions to 2775.)
+
+ If you are using one of the many recent versions of Unix that don't
+ allow you to use the full octal mode, then you'll have to type: chmod
+ u=rwx,g=rwx,o=rx,g+s <dir>
+
+
+ - Change all the groups on the directories to match the groups you
+ want to write to various directories.
+
+
+ - Make sure every user is in the appropriate groups.
+
+
+ - Have everyone set their umask to 002, including root.
+
+ If you don't want non-group members to even read the files, do the
+ above, but change:
+
+
+ - Repository directory permissions to 770. (or 2770)
+
+
+ - umasks to 007.
+
+ If you work in an environment where people can't be trusted to set
+ their "umask" to something reasonable, you might want to set the umask
+ for them:
+
+ mv /usr/local/bin/cvs /usr/local/bin/cvs.real
+ cat > /usr/local/bin/cvs
+ #!/bin/sh
+ umask 2 # Or whatever your site standard is.
+ exec /usr/local/bin/cvs.real ${1+"$@"}
+ ^D
+
+ Last modified: _6/13/1997_
+
+ 6. How do I structure my Repository?
+
+ The Repository holds your software. It can be all interrelated or it
+ can be a bunch of separately managed directories.
+
+ How you break a whole system down into its component parts, while
+ defining interfaces between them, is one aspect of "Software
+ Engineering", a discipline that requires the study of dozens of
+ strange and wonderful areas of the computer and management worlds.
+
+ CVS provides a way to keep track of changes to individual files, a way
+ to "tag" collections of files, and a way to "name" collections of
+ files and directories. That's all. Everything else is in the way you
+ apply it.
+
+ In other words, you should structure your Repository to match your
+ needs, usually tied in with the other tools you use to build, install
+ and distribute your work. Common needs include the ability to:
+
+
+ - mount (or automount) directories from many places in your
+ organization.
+ - check out just what you need and no more.
+ - check out multiple sections in a fixed relation to each other.
+ - check out large sections to match the assumptions built into your
+ build system. (Makefiles?)
+
+ In my opinion, you should start small and keep everything in one tree,
+ placing each major sub-system into a separate directory. Later, when
+ you know what you are doing, you can make it more sophisticated.
+
+ Last modified: _6/13/1997_
+
+ 7. Why would anyone use "modules"? They are too restrictive. I want to be
+ able to select just the files I want to edit.
+
+ Any form of structure is restrictive. If you believe that total chaos
+ is a viable working paradigm, or if you believe you can keep track of
+ the interrelations between all portions of your Repository in your
+ head, then you can do what you please.
+
+ If you believe that systems of files require management and structure,
+ then the "modules" idea is very useful. It is a way to impose a naming
+ scheme on a tree of files, a naming scheme that can be simpler than a
+ large list of relative pathnames.
+
+ The "modules" file represents a published interface to the Repository
+ set up by your Repository Administrator. If s/he did a creditable job,
+ the modules offered will be internally consistent and will smoothly
+ interact with the rest of your environment.
+
+ Last modified: _6/13/1997_
+
+ 8. How do I rename a file or directory? What are the consequences?
+
+ In CVS there is no single "rename" command.
+
+ See 2C.4 for the suggested way to rename a file or directory.
+
+ The rest of this section covers some of the consequences of renaming.
+
+ A "renaming database" has been proposed that would keep track of name
+ changes so that "update -r <tag>" would continue to work across the
+ renaming. But as it stands, you have to pick one of the following
+ options:
+
+ Use the technique described in 2C.4. (For each file, duplicate the
+ file in the Repository, "remove" the old version so it winds up in the
+ Attic and strip all Tags off the new version.)
+
+ - "update -r <tag>" produces the correct files.
+
+
+ - The duplicated revision history can be slightly misleading.
+
+
+ - A plain (i.e. without the "-r <tag>") "checkout" or "update -d" will
+ create directories "renamed" this way, but you can delete it and a
+ plain "update" won't bring it back.
+
+ Move the files and directories in the Repository to the new names.
+
+
+ - You save the revision history under a different file name.
+
+
+ - You save a little space.
+
+ - "update -r <tag>" produces the wrong files or directories.
+
+ This is not a good general solution, but if you plan never to look
+ back (someone may be gaining on you!), it is sometimes a useful
+ notion.
+
+ If you are clever with Makefiles, you might be able to rework them to
+ handle either the new or old names, depending on which ones exist at
+ the time. Then you can move an old <tag> onto the new, more
+ sophisticated, revision of the Makefile. (Yes, this changes the
+ "released" file if <tag> indicates a release. But it is an option.)
+
+
+ - Important Note: If you rename a directory, you must rename the
+ corresponding directory in every checked-out working directory. At the
+ same time, you must edit the pathname stored in the ./CVS/Repository
+ file within each of the moved directories.
+
+ The easiest way to move a lot of directories around is to tell
+ everyone to remove their working directories and check them out again
+ from scratch.
+
+
+ - The file exists in the working directory and in the ./CVS/Entries
+ file, but not in the Repository. For the old file, "update" prints:
+
+ cvs update: xyz.c is no longer in the repository
+
+ and deletes the file. If the file was modified, "update" prints:
+
+ cvs update: conflict: xyz.c is modified but no longer in the
+ repository C xyz.c
+
+ and leaves the file alone. In the new directory, you see:
+
+ U xyz.c
+
+ as you would if someone else executed "add" and "commit".
+
+ For each file, copy the working file to a new name in the working
+ directory and use the "cvs remove" to get rid of the old old file and
+ "cvs add" to add the new one. Since there is no way for CVS to remove
+ a directory, this only works for files.
+
+
+ - This is what most people think of first. Without a "rename" command,
+ the remove/add technique seems obvious.
+
+
+ - You lose the connection of your new working file to its past
+ revision history.
+
+ Last modified: _6/13/1997_
+
+ 9. What are "Attic" directories?
+
+ When you use the "remove" command on a file, CVS doesn't delete the
+ file, it only registers your desire to delete it.
+
+ When you "commit" a removed file, CVS moves the Repository's matching
+ RCS file into a sub-directory named "Attic" within the Repository.
+
+ Attic files are examined when the '-r' or '-D' option is used on
+ "checkout" or "update". If the specified revision, tag or date matches
+ one on a file in the Attic, that file is checked out with the others.
+
+ You can think of the Attic as a sort of dead branch, which is only
+ looked at when you refer to a <tag> or <date>.
+
+ Last modified: _6/13/1997_
+
+ 10. Is it OK to remove anything from the Repository?
+
+ In general, removing anything from the Repository is a bad idea. The
+ information in a deleted object is lost forever. There are many ways
+ to skip over files, directories and revisions without deleting them.
+
+ Here are some of the consequences of removing the following things
+ stored in the Repository:
+
+ CVSROOT files (Repository control files)
+
+ The Repository will work without any of them, but you should
+ understand what you are losing by deleting them. See 4B.2.
+
+ Revisions
+
+ The only way to remove revisions is to use the "admin -o" command (or
+ the equivalent RCS command "rcs -o").
+
+ They are lost forever. Any tags formerly attached to deleted revisions
+ are now pointing into the Phantom Zone. You'll need to contact Jor-el
+ to get them back.
+
+ Files
+
+ You should not remove a file unless you truly never want to see it
+ again. If you want to be able to check out an old revision of this
+ file, use "cvs remove" instead.
+
+ Tags
+
+ Tags take up little space and you can't recover from deleting them. If
+ you depend on tags for releases you will lose vital information.
+
+ Directories
+
+ There is no Attic for directories, so the only way to remove them is
+ to use "rm -r". They are gone forever.
+
+ If you delete (or move) a directory, all checked-out versions of that
+ directory will cause CVS to halt. You'll have to visit each
+ checked-out directory and remove the matching working directory by
+ hand.
+
+ Attic files
+
+ The "remove" command sends files to the Attic. To really delete them,
+ you have to go into the Attic and use "rm".
+
+ If a file in the Attic has a Tag on it that you might ever want to
+ check out again, you probably don't want to delete it.
+
+ Lock files (named: "#cvs.[wr]fl.<pid>")
+
+ These are lock files. If you are getting "lock" errors and the dates
+ on the lock files indicate that they are old, you can delete them.
+
+ Deleting lock files still in use by a CVS process might produce
+ unusual errors.
+
+ Last modified: _6/13/1997_
+
+ 11. Can I convert to CVS from RCS without losing my revision history?
+
+ Yes, you can simply move (or copy) your RCS files into a directory
+ within the Repository, check out that directory and start working.
+
+ Last modified: _6/13/1997_
+
+ 12. Can I move RCS files with branches in them into the Repository?
+
+ Yes, but they may not work if you created branches in a way that
+ conflicts with CVS's assumptions:
+
+ You can't use .0. branches. (They are reserved for "Magic" branch
+ tags.)
+
+ If you use branch 1.1.1, you can't use the Vendor branch.
+
+ You can use other RCS branches under CVS. There is no need to create
+ "magic" branch tags because the physical branch already exists.
+
+ Last modified: _6/13/1997_
+
+ 13. Can I use raw RCS commands on the Repository?
+
+ You can use raw rcs commands directly on the Repository if you take a
+ little care. The Repository itself contains no "CVS state" (as opposed
+ to RCS revision histories) outside the CVSROOT directory.
+
+ But using raw RCS commands to change branches, tags or other things
+ that CVS depends on may render the files unusable.
+
+ See 4D.7 on RCS/CVS sharing of the Repository and Section 3B on the
+ "admin" command.
+
+ Last modified: _6/13/1997_
+
+ 14. How do I convert from SCCS to RCS?
+
+ You'll have to execute something like "sccs2rcs" (in the CVS contrib
+ directory) on every file. Then you can move the resulting RCS files
+ into the Repository as described above.
+
+ Last modified: _6/13/1997_
+
+ 15. How do I limit access to the Repository?
+
+ There are all sorts of ways to restrict access to Repository files,
+ none of which are hooked directly into CVS.
+
+ Techniques for limiting access include:
+
+ Training, management and good backups.
+
+ The best form of Repository control is a combination of:
+
+
+ - A reliable backup scheme (verify it!)
+ - Enough training to ensure your developers are competent and
+ knowledgeable about all areas of your sources.
+ - Effective management of the boundaries and grey areas.
+
+ In many cases, technical solutions to "security" problems are
+ inadequate. You should first try to avoid them.
+
+ Personal Opinion: In an environment where "unknowns" are allowed to
+ touch important sources the "owner" of the CVS Repository must be a
+ large, loud, vigorous lout with a well-balanced truncheon and the
+ right to use it. Don't underestimate the effectiveness of letting
+ everyone know they will be strapped into the stocks on the Town Common
+ and pelted with vegetables if they break something they don't
+ understand without first asking the experts.
+
+ Set Unix groups and permissions. See 4B.5. You can set different
+ owners, groups and permissions for each sub-directory within the
+ Repository if that helps.
+
+ Catch invocations of "commit" by defining pre-commit programs in the
+ "commitinfo" file. This is fairly powerful, since it can block commits
+ based on anything you can program. Take a look at the programs in the
+ "contrib" directory of the CVS source tree.
+
+ Use multiple Repositories, each with its own protection scheme. If
+ you use NFS (or AFS) you can even use "export" restrictions to various
+ groups of machines to keep (for example) the Engineering Repository
+ off the Customer Service machines.
+
+ Try the "setgid" trick described in 4D.13.
+
+ Try to use the RCS access control lists, though I don't think CVS
+ will handle them cleanly.
+
+ Edit the source code to CVS to add your own access control.
+
+ Last modified: _6/13/1997_
+
+ 16. What are the Repository Administrator's responsibilities?
+
+ Generally, the Administrator should set "policy", create the
+ Repository and monitor its size and control files.
+
+ Some specific responsibilities include:
+
+ Examining the Repository once in a while to clean up:
+
+ Trash files left by misguided developers who mistake the Repository
+ for a working directory.
+
+ Non-RCS files. Other than the files CVS needs in the
+ $CVSROOT/CVSROOT directory, every file in the Repository should be an
+ RCS file.
+
+ Lock files (both CVS '#*' and RCS ',*' files) left around after
+ crashes.
+
+ Wrong permissions, groups and ownerships.
+
+ Locked files. (RCS locks, that is.)
+
+ Attic files that should never have been under CVS at all. Don't
+ blindly delete files from Attic directories -- they were mostly put
+ there (via the "cvs remove") for a reason. Files that should be
+ deleted are binary files (e.g. '*.o', 'core', executables) that were
+ mistakenly inserted by "import -I !".
+
+ Maintaining the modules file.
+
+ Storing site-specific ignore patterns in the
+ $CVSROOT/CVSROOT/cvsignore file.
+
+ Storing the names of non-standard CVSROOT files (See 4B.2) in the
+ $CVSROOT/CVSROOT/checkoutlist
+
+ Maintaining the other Repository control files: commitinfo, loginfo,
+ rcsinfo and editinfo.
+
+ Pruning the history file every once in a while. (Try the
+ "cln_hist.pl" script in the "contrib" directory.)
+
+ Staying aware of developments on the info-cvs mailing list and what
+ is available in the FTP and WWW archives.
+
+ Running "ps ax" once in a while and kill off any "update" programs
+ not running as "root". It is too easy to leave the "cvs" off the front
+ of the "cvs update" command.
+
+ Executing monitor programs to check the internal consistency of the
+ Repository files. Ideas:
+
+ Files that have a default RCS branch that is not 1.1.1 (From an
+ abuse of "admin -b".)
+
+ Files that have only Revisions 1.1 and 1.1.1.1, with a default
+ branch of "MAIN". (From an abuse of "admin -o".)
+
+ Existing branch tags and various branch consistency checks.
+
+ Last modified: _6/13/1997_
+
+ 17. How do I move the whole Repository?
+
+ Copy or move the tree. (On Unix systems, a set of piped "tar" commands
+ works great. If the Repository does not contain any symlinks, which it
+ normally doesn't, you can also use "cp -r".)
+
+ If you can avoid changing $CVSROOT (i.e. the "logical" pathname of the
+ Repository) by replacing the old location with a symbolic link to the
+ new location, you don't have to do anything else.
+
+ (You could also mount the new location on top of the old location if
+ you are using NFS or some other filesystem that allows it.)
+
+ If you must change $CVSROOT, you must also tell everyone to change the
+ CVSROOT environment variable in all running shells and in any personal
+ configuration files ('.' files on Unix) where it is set.
+
+ The Repository itself contains no references to its own name, except
+ possibly in some of the files in the CVSROOT directory. If your
+ modules (or loginfo, commitinfo, etc.) file mentions helper programs
+ directly in the Repository, you'll have to change the pathnames to
+ point to the new Repository location.
+
+ The main changes you'll have to make are to all the CVS administrative
+ files (./CVS/Repository and ./CVS/Root) in every working directory
+ ever checked out from the previous location of the Repository you just
+ moved.
+
+ You have three choices:
+
+ If all ./CVS/Repository files in all working directories contain
+ relative pathnames, you don't have to do anything else.
+
+ Have everyone "release" or delete their working directories (after
+ committing, or just saving, their work) and check them all out again
+ from the new Repository after the move.
+
+ Use "find . ( -name Repository -o -name Root )" and a PERL or shell
+ script to run through all the ./CVS/Repository and ./CVS/Root files
+ and edit the values in the files.
+
+ Last modified: _6/13/1997_
+
+ 18. How do I change permissions on a file in the Repository by using a CVS
+ command? (i.e. without using "chmod 777 $CVSROOT/dir/file")
+
+ When you first "import" or "add"/"commit" a file, the read and execute
+ bits on the Repository file are inherited from the original source
+ file, while the write bits on the Repository file are are turned off.
+ This is a standard RCS action.
+
+ After that, there is no way to alter the permissions on a file in the
+ Repository using CVS (or RCS) commands. You have to change the
+ permissions on both your working file and on the Repository file from
+ which it was retrieved.
+
+ Whenever you "checkout" the file or retrieve a new revision via
+ "update" (or after a "commit"), your working file is set to match the
+ permissions of the Repository file, minus any "umask" bits you have
+ set.
+
+ Last modified: _6/13/1997_
+
+ Category: /Advanced_Topics_/Tricks_of_the_Trade/
+
+ " + Tricks of the Trade"
+
+ 1. How can you even check in binary files, let alone allow CVS to do its
+ auto-merge trick on them?
+
+
+First of all, if you want to use binary files, you should get RCS 5.7
+and CVS 1.9 or later (earlier versions had some support, but there have been
+bug fixes). Secondly, follow the instructions for installing RCS very
+carefully (it is easy to get it installed so it works for everything
+except binary files).
+
+Then, specify 'cvs add -kb' instead of just 'cvs add' to add a binary
+file. If you want to set an existing file to binary, run 'cvs admin
+-kb' (and then check in a new copy of the file). Note that old
+versions of CVS used -ko instead of -kb for binary files, so if you
+see a reference to -ko in the context of binary files, you should
+think -kb instead.
+
+Of course when 'cvs update' finds that a merge is needed, it can't
+do this for binary files the same way as for text files. With the
+latest versions (e.g. CVS 1.9.14), it should be able to give you both
+versions and let you merge manually. Another approach is to
+run 'cvs admin -l' to lock files, as described in
+"How can I lock files while I'm working on them the way RCS does?"
+elsewhere in this FAQ. See also
+"Is there any way to import binary files?" and
+"How do I "add" a binary file?" elsewhere in this FAQ.
+
+kingdon@cyclic.com
+
+ Last modified: _9/6/1997_
+
+ 2. Can I edit the RCS (",v") files in the Repository?
+
+ Yes, but be very careful. The RCS files are not free-form files, they
+ have a structure that is easily broken by hand-editing. The only time
+ I would suggest doing this is to recover from emergency failures that
+ are difficult to deal with using CVS commands, including the "admin"
+ command, which can talk directly to RCS.
+
+ Though no one actively encourages the editing of RCS files, many
+ people have succumbed to the urge to do so when pressed for time. The
+ reasons given, usually with evident contrition, include:
+
+
+ - Editing mistakes in, or adding text to, log entries. (If you have
+ RCS 5.6 or later, you should use `cvs admin -m'.)
+ - Renaming or moving symbolic names. (You should `cvs admin -N'
+ instead.)
+ - Unlocking a file by changing the "locker" from someone else to
+ yourself. (It's safer to use `cvs admin -u -l'.)
+ - Making global changes to past history. Example: Eradicating former
+ employees names from old documents and Author entries. (And someone
+ thought the "history" command was evidence of Big Brother! I never
+ realized how much help a wide-open revision control system could have
+ provided to The Ministry of Truth.)
+
+ Last modified: _6/13/1997_
+
+ 3. Can I edit the ./CVS/{Entries,Repository,Tag} files?
+
+ Yes, but with CVS 1.3 and later, there is almost no reason to edit any
+ of the CVS administrative files.
+
+ If you move pieces of your Repository around it can be faster to edit
+ all the ./CVS/Repository files rather than checking out a large tree.
+ But that is nearly the only reason to do so.
+
+ Last modified: _6/13/1997_
+
+ 4. Someone executed "admin -o" and removed revisions to which tags/symbols
+ were attached. How do I fix them?
+
+ It depends on what you mean by "fix". I can think of three ways to fix
+ your predicament:
+
+ Remove the tags.
+
+ Assuming you really wanted to get rid of the revision and its
+ associated tags, you can remove them with the "admin" command. The
+ "tag -d" command will only remove tags attached to existing revisions.
+ You can remove a tag, even if it is attached to a non-existent
+ revision, by typing:
+
+ cvs admin -N<tag> <file>
+
+ Retrieve the outdated revision.
+
+ You should first look in your backup system for recent versions of the
+ file. If you can't use them, you can carefully extract each revision
+ that followed the earliest outdated revision using RCS (or "cvs
+ admin") commands and reconstruct the file with all the right
+ revisions, branches and tags. This is a lot of work.
+
+ You *can't* insert a revision into the current RCS file.
+
+ Move the Tags to another revision in each file.
+
+ If you want to move the tags to another valid revision, you have two
+ choices, both of which require that you find all the revision numbers
+ of the files you want to "tag" and execute the following command
+ sequences on each <file>.
+
+ Use "update" to grab the revision you want, then execute a normal
+ "tag" command to Tag that revision:
+
+ cvs update -r <rev> <file>
+ cvs tag <tag> <file>
+
+ Use "admin" to set the tag to a specific revision:
+
+ cvs admin -N<tag>:<rev> <file>
+
+ Last modified: _6/13/1997_
+
+ 5. How do I move or rename a magic branch tag?
+
+ (To rename a non-branch <tag> see 3O.9.)
+
+ Before reading this, read 3M.3 and 3M.4 and understand exactly how tag
+ and rtag use '-r' and why it won't do the right job here.
+
+ First, I have to explain exactly what a magic branch tag is.
+
+ A magic <branch_tag> is an artificial tag attached to a non-existent
+ revision on a non-existent branch number zero. It looks like this:
+
+ TAG1:<X>.0.Y
+
+ <X> is the "branch point revision", a normal revision with an
+ odd number of '.'s in it. (e.g. 1.5, 1.3.1.6, etc)
+
+ Y is an even number (e.g. 2, 4, 6, etc.) All CVS branches,
+ other than the Vendor branch, are even numbered.
+
+ TAG1 is considered by CVS to be attached to revision <X>. The first
+ "update -r TAG1 <file>" after applying TAG1 will produce a copy of
+ revision <X> with a sticky tag of TAG1. The first "commit" to that
+ file will cause CVS to construct an RCS branch named <X>.Y and check
+ in revision <X>.Y.1 on the new branch.
+
+ Note: TAG1 is *not* considered to be attached to <X> by RCS, which
+ explains why you can't refer directly to the branch point revision for
+ some CVS commands.
+
+ Moving a magic <branch_tag> is the act of reapplying the same tag to
+ different revisions in the file:
+
+ TAG1:<X>.0.Y
+ to
+ TAG1:<X>.0.Z or TAG1:<A>.0.B
+
+ You can move a magic branch tag to the revisions of your choice by
+ using "update" to find the revisions you want to tag and reapplying
+ the tag to all the files with the '-F' option to force it to move the
+ existing <branch_tag>.
+
+ cvs update -r <tag/rev> (or '-A' for the Main Branch)
+ cvs tag -F -b <branch_tag>
+
+ If the earlier location of TAG1 refers to a physical branch within any
+ RCS file, moving it will make the existing branch in the file seem to
+ disappear from CVS's view. This is not a good idea unless you really
+ want to forget the existence of those RCS branches.
+
+ If the "update" above retrieves the original branch point revision
+ (<X>), the "tag" command above will create the tag:
+
+ TAG1:<X>.0.Z
+
+ Where Z is 2 greater than the highest magic branch already on revision
+ <X>. The TAG1 branch will still have the same branch point (i.e.
+ revision <X>), but the first commit to the new TAG1 branch will create
+ a different RCS branch number (<X>.Z instead of <X>.Y).
+
+ Renaming a magic <branch_tag> is the act of changing
+
+ TAG1:<X>.0.Y
+ to
+ TAG2:<X>.0.Y
+
+ There is no harm in changing a tag name as long as you forget that
+ TAG1 ever existed and you clean up any working directories with sticky
+ TAG1 tags on them by using "update -A", "update -r <other_tag>" or by
+ removing the working directories.
+
+ On the other hand, actually changing the tag is not easy.
+
+ See 3M.3 for why the seemingly obvious solution won't work:
+
+ cvs tag -b -r <old_branch_tag> <new_branch_tag>
+
+ The only direct way to rename a magic tag is to use the "admin"
+ command on each file: (You might want to use '-n'. Read "man rcs" and
+ look at the '-n' and '-N' options.)
+
+ cvs admin -N<new_branch_tag>:<old_branch_tag> .
+ cvs tag -d <old_branch_tag>
+
+ But you have to be careful because "admin" is different from other CVS
+ commands:
+
+ "admin" can be used recursively, but only by specifying directory
+ names in its argument list (e.g. '.'),
+
+ Where "rtag -r <old_branch_tag>" would interpret <old_branch_tag> as
+ a magic CVS branch tag, "admin" is a direct interface to RCS which
+ sees a magic branch tag as a simple (though non-existent) RCS revision
+ number.
+
+ This is good for us in this particular case, but different from normal
+ CVS.
+
+ "admin" also skips the Attic and produces different kinds of errors
+ than CVS usually does. (Because they are coming directly from RCS.)
+
+ The other way to rename a magic <branch_tag> is to edit the Repository
+ files with a script of some kind. I've done it in the past, but I'll
+ leave it as an exercise for the reader.
+
+ Last modified: _6/13/1997_
+
+ 6. Can I use RCS locally to record my changes without making them globally
+ visible by committing them?
+
+ You can, but it will probably confuse CVS to have ",v" files in your
+ working directory. And you will lose all your log entries when you
+ finally commit it.
+
+ Your best bet is to create your own CVS branch and work there. You can
+ commit as many revisions as you want, then merge it back into the main
+ line (or parent branch) when you are finished.
+
+ Last modified: _6/13/1997_
+
+ 7. How can I allow access to the Repository by both CVS and RCS?
+
+ The first step is to try not to. If some people are using CVS, there
+ is no reason for everyone not to. It is not hard to learn the basics
+ and CVS makes certain operations *easier* than a series of RCS
+ commands. Personal preference in what software tools can be applied to
+ a shared Repository has to take second place to system integration
+ needs. If you disagree, try writing some Lisp code for inclusion in
+ your Unix kernel and see what kind of reception you get.
+
+ If you really must allow routine RCS access to the CVS Repository, you
+ can link an RCS sub-directory into a piece of the Repository:
+
+ ln -s /Repository/some/directory/I/want RCS
+
+ and RCS will work just fine.
+
+ Those who are using RCS will have to keep the following in mind:
+
+ If a file was originally added to the Repository by "import" and has
+ not been changed using CVS, the *RCS* default branch will remain
+ attached to the Vendor branch, causing revisions checked-in by "ci" to
+ wind up on the Vendor branch, instead of the main branch. Only CVS
+ moves the RCS default branch on first commit.
+
+ The way around this is to checkin (using "ci") all the files first and
+ move them into the Repository. That way they won't have Vendor
+ branches. Then RCS will work OK.
+
+ It is possible to use "rcs" and "ci" to make the files unusable by
+ CVS. The same is true of the CVS "admin" command.
+
+ Normal RCS practice locks a file on checkout with "co -l". In such
+ an environment, RCS users should plan to keep survival gear and food
+ for at least 30 days near their desks. When faced with bizarre and
+ unexpected permission errors, howling mobs of slavering CVS users will
+ run the RCS users out of town with pitchforks and machetes.
+
+ See 3C.8 for a way to avoid machetes aroused by lock collisions.
+
+ Though files checked in by RCS users will correctly cause
+ "up-to-date" failures during CVS "commits" and they will be
+ auto-merged into CVS working directories during "update", the opposite
+ won't happen.
+
+ RCS users will get no warning and will not be required to merge older
+ work into their code. They can easily checkin an old file on top of a
+ new revision added by CVS, discarding work committed earlier by CVS
+ users.
+
+ See the howling mob scenario described above.
+
+ RCS is great. I have used it for years. But I wouldn't mix it this
+ way. In a two-camp society, you are asking for real trouble, both in
+ technical hassles to clean up and in political hassles to soothe.
+ Branch merges will also be a major problem.
+
+ Last modified: _6/13/1997_
+
+ 8. I "updated" a file my friend, "bubba", committed yesterday. Why doesn't
+ the file now have a modified date of yesterday?
+
+ CVS restores dates from the RCS files only on first "checkout". After
+ that, it is more important to maintain a timestamp relative to the
+ other files in the working directory.
+
+ Example: You committed a source file at 5PM. Bubba updated his copy of
+ the file, grabbing your changes, then changed and committed a new
+ revision of the file at 6PM. At 7PM, you compile your file. Then you
+ execute "update". If CVS sets the date to the one in the RCS file, the
+ file would be given a timestamp of 6PM and your Makefile wouldn't
+ rebuild anything that depended on it. Bad news.
+
+ Note that the same logic applies to retrieving a revision out of the
+ Repository to replace a deleted file. If CVS changes your file in an
+ existing working directory, whether it was because a new revision was
+ committed by someone else or because you deleted your working file,
+ the timestamp on the retrieved working file *must* be set to the
+ current time.
+
+ When you first retrieve a file, there is no reason to expect any
+ particular timestamp on the file within your working area. But later,
+ when dependency checking is performed during a build, it is more
+ important for the timestamps on the local files to be consistent with
+ each other than than it is for working files to match the timestamps
+ on the files in the Repository. See 4D.17 for some more about
+ timestamps.
+
+ Last modified: _6/13/1997_
+
+ 9. While in the middle of a large "commit", how do I run other commands,
+ like "diff" or "stat" without seeing lock errors?
+
+ Type:
+ cvs -n <command>
+
+ The '-n' option to the main cvs command turns off lock checking, a
+ reasonable act for read-only commands given the promise offered by
+ '-n' not to alter anything. The "diff", "log" and "stat" commands
+ provide the same information (for files that are not being committed)
+ when used with and without the '-n' option.
+
+ Warning: Ignoring locks can produce inconsistent information across a
+ collection of files if you are looking at the revisions affected by an
+ active commit. Be careful when creating "patches" from the output of
+ "cvs -n diff". If you are looking only at your working files, tagged
+ revisions, and BASE revisions (revisions whose numbers are read from
+ your ./CVS/Entries files), you should get consistent results. Of
+ course, if you catch a single file in the middle of RCS activity, you
+ might get some strange errors.
+
+ Note that the suggested command is "cvs -n <command>". The visually
+ similar command "cvs <command> -n" has no relation to the suggested
+ usage and has an entirely different meaning for each command.
+
+ "cvs -n update" also works in the middle of a commit, providing
+ slightly different information from a plain "cvs update". But, of
+ course, it also avoids modifying anything.
+
+ You could also use the RCS functions, "rlog" and "rcsdiff" to display
+ some of the information by referring directly to the Repository files.
+
+ You need RCS version 5 or later for the commands described above to
+ work reliably.
+
+ Last modified: _6/13/1997_
+
+ 10. Where did the ./CVS/Entries.Static file come from? What is it for?
+
+ Each CVS working directory contains a ./CVS/Entries file listing the
+ files managed by CVS in that working directory. Normally, if the
+ "update" command finds a file in the Repository that is not in the
+ ./CVS/Entries file, "update" copies the appropriate revision of the
+ "new" file out of the Repository and adds the filename to the Entries
+ file. This happens for files:
+
+ Added to the Repository from another working directory.
+
+ Dragged out of the Attic when switching branches with "update -A" or
+ "update -r".
+
+ Whose names were deleted from the ./CVS/Entries file.
+
+ If the ./CVS/Entries.Static file exists, CVS will only bring out
+ revisions of files that are contained in either ./CVS/Entries or
+ ./CVS/Entries.Static. If a Repository file is found in *neither* file,
+ it is ignored.
+
+ The ./CVS/Entries.Static file is created when you check out an
+ individual file or a module that creates working directories that
+ don't contain all files in the corresponding Repository directory. In
+ those cases, without an ./CVS/Entries.Static file, a simple "update"
+ would bring more files out of the Repository than the original
+ "checkout" wanted.
+
+ The ./CVS/Entries.Static file can be removed by hand. It is
+ automatically removed if you run "update -d" to create new directories
+ (even if no new directories are created). (Internally, since
+ "checkout" turns on the '-d' flag and calls the "update" routine, a
+ "checkout" of a module or directory that writes into an existing
+ directory will also remove the ./CVS/Entries.Static file.)
+
+ Last modified: _6/13/1997_
+
+ 11. Why did I get the wrong Repository in the loginfo message?
+
+ You probably:
+
+ Use multiple Repositories.
+
+ Configured CVS to use absolute pathnames in the ./CVS/Repository
+ file.
+
+ Configured CVS not to use the ./CVS/Root file.
+
+ Typed the "commit" command in one Repository with your $CVSROOT
+ pointing at another.
+
+ "commit" and all other CVS commands will heed an absolute pathname in
+ the ./CVS/Repository file (or in the "-d CVSrootdir" override), but
+ the log function doesn't take arguments -- it just looks at $CVSROOT.
+
+ If you avoid even one of the four steps above, you won't see this
+ problem. If you configure ./CVS/Root, you won't be allowed to execute
+ the program causing the error.
+
+ Last modified: _6/13/1997_
+
+ 12. How do I run CVS setuid so I can only allow access through the CVS
+ program itself?
+
+ Setuid to root is not a great idea. Any program that modifies files
+ and is used by a widely distributed group of users is not a good
+ candidate for a setuid program. (The worst suggestion I've ever heard
+ was to make *Emacs* setuid to root.)
+
+ Root access on Unix is too powerful. Also, it might not work in some
+ (secure?) environments.
+
+ Running it setuid to some user other than root might work, if you add
+ this line to main.c near the beginning:
+
+ setuid(geteuid());
+
+ Otherwise it uses *your* access rights, rather than the effective
+ uid's.
+
+ Also, you have to invent a fake user whose name will show up in
+ various places. But many sites, especially those who might want a
+ setuid CVS for "security", want personal accountability -- no generic
+ accounts. I don't know whether accountability outweighs file security.
+
+ And finally, unless you take action to limit the "admin" command, you
+ are leaving yourself unprotected anyway.
+
+ Last modified: _6/13/1997_
+
+ 13. How about using groups and setgid() then?
+
+ Here is a way to run CVS setgid in some environments:
+
+ Stick this near the front of the main() in main.c:
+
+ setgid(getegid());
+
+ This will allow "access" to work on systems where it only works on the
+ real gid.
+
+ Create a group named "cvsg". (This example uses "cvsg". You can name
+ it as you wish.)
+
+ Put *no* users in the "cvsg" group. You can put Repository
+ administrators in this group if you want to.
+
+ Set the cvs executable to setgid (not setuid):
+
+ cd /usr/local/bin; chown root.cvsg cvs; chmod 2755 cvs
+
+ Make sure every file in the Repository is in group "cvsg":
+
+ chown -R root.cvsg $CVSROOT
+
+ Change all directory permissions to 770. This allows all access to
+ the files by the "cvsg" group (which has no members!) and no access at
+ all to anyone else.
+
+ find $CVSROOT -type d -exec chmod 2770 {} \;
+
+ On some systems you might have to type:
+
+ find $CVSROOT -type d -exec chmod u=rwx,g=rwx,o=,g+s {} \;
+
+ This should allow only the cvs program (or other "setgid to group
+ cvsg") programs to write into the area, but no one else. Yes the user
+ winds up owning the file, but s/he can't find it again later since
+ s/he can't traverse the tree. (If you enable the world execute bit
+ (mode 2771) on directories, users can traverse the tree and the user
+ who last wrote the file can still write to it.)
+
+ If you want to allow read access, check out an entire tree somewhere.
+ You have to do this anyway to build it.
+
+ Note: If you are using a stupid file system that can't inherit file
+ groups from the parent directory (even with the "setgid" (Octal 2000)
+ bit set), you might have to modify CVS (or RCS) to reset the group
+ every time you create a new file. I have not tested this.
+
+ The setgid() method shares with the setuid() method the problem of
+ keeping "admin" from breaking things.
+
+ Last modified: _6/13/1997_
+
+ 14. How do I use the "commitinfo" file?
+
+ Go read 4B.2 first.
+
+ The "commitinfo" file allows you to execute "sanity check" functions
+ before allowing a commit. If any function called from within the
+ commitinfo file exits with a non-zero status, the commit is denied.
+
+ To fill out a "commitinfo" file, ask yourself (and those sharing your
+ Repository) these questions:
+
+
+ - Is there anything you want to check or change before someone is
+ allowed to commit a file? If not, forget commitinfo.
+
+ If you want to serialize binary files, you might consider something
+ like the rcslock.pl program in the contrib directory of the CVS
+ sources.
+
+
+ - Do you want to execute the same exact thing before committing to
+ every file in the Repository? (This is useful if you want to program
+ the restrictions yourself.) If so, set up a single line in the
+ commitinfo:
+
+ DEFAULT /absolute/path/to/program
+
+ CVS executes the program once for each directory that "commit"
+ traverses, passing as arguments the directory and the files to be
+ committed within that directory.
+
+ Write your program accordingly. Some examples exist in the contrib
+ directory.
+
+
+ - Do you want a different kind of sanity check performed for different
+ directories? If so, you'll have to decide what to do for all
+ directories and enter lines like this:
+
+ regexp1 /absolute/path/to/program-for-regexp1
+ regexp2 /absolute/path/to/program-for-regexp2
+ DEFAULT /absolute/path/to/program-for-all-else
+
+
+ - Is there anything you want to happen before *all* commits, in
+ addition to other pattern matches? If so, include a line like this:
+
+ ALL /absolute/path/to/program
+
+ It is executed independently of all the above. And it's repeatable --
+ you can have as many ALL lines as you like.
+
+ Last modified: _6/13/1997_
+
+ 15. How do I use the "loginfo" files?
+
+ See 4B.2 and the "commitinfo" question above.
+
+ The "loginfo" file has the same format as the "commitinfo" file, but
+ its function is different. Where the "commitinfo" information is used
+ before a commit, the "loginfo" file is used after a commit.
+
+ All the commands in the "loginfo" file should read data from standard
+ input, then either append it to a file or send a message to a mailing
+ list. If you want to make it simple, you can put shell (the shell used
+ by "popen(3)") command lines directly in the "loginfo" (or
+ "commitinfo") file. These seem to work:
+
+ ^special /usr/ucb/Mail -s %s special-mailing-list ^other /usr/ucb/Mail
+ -s %s other-mailing-list DEFAULT (echo '===='; echo %s; cat) >
+ /path/name/to/log/file
+
+ Last modified: _6/13/1997_
+
+ 16. How can I keep people with restrictive umask values from blocking
+ access to the Repository?
+
+ If a user creates a new file with restricted permissions (e.g. 0600),
+ and commits it, the Repository will have a file in it that is
+ unreadable by everyone. The 0600 example would be unreadable by
+ *anyone* but root and the user who created it.
+
+ There are 3 solutions to this:
+
+ Let it happen. This is a valid way to protect things. If everyone is
+ working alone, a umask of 077 is OK. If everyone is working only in
+ small groups, a umask of 007 is OK.
+
+ Train your users not to create such things if you expect to share
+ them.
+
+ See 4B.5 for a small script that will reset the umask.
+
+ I personally don't like the idea of a program automatically
+ *loosening* security. It would be better for you all to talk about the
+ issue and decide how to work together.
+
+ Last modified: _6/13/1997_
+
+ 17. Why do timestamps sometimes get set to the date of the revision,
+ sometimes not? The inconsistency causes unnecessary recompiles.
+
+ The "checkout" command normally sets the timestamp of a working file
+ to match the timestamp stored on the revision in the Repository's RCS
+ file.
+
+ The "commit" command retains the timestamp of the file, if the act of
+ checking it in didn't change it (by expanding keywords).
+
+ The "update" command sets the time to the revision time the first time
+ it sees the file. After that, it sets the time of the file to the
+ current time. See 4D.8 for a reason why.
+
+ Here's a two-line PERL program to set timestamps on files based on
+ other timestamps. I've found this program useful. When you are certain
+ you don't want a source file to be recompiled, you can set its
+ timestamp to the stamp on the object file.
+
+ #!/usr/local/bin/perl
+ #
+ # Set timestamp of args 2nd-Last to that of the first arg.
+ #
+ ($dev,$ino,$mode,$nlink,$uid,$gid,$rdev,$size,$atime,$mtime,$ctime)
+ = stat(shift);
+ utime($atime,$mtime,@ARGV);
+
+ Last modified: _6/13/1997_
+
+ Category: /Commands_/
+
+ " Commands "
+
+ Category: /Commands_/add_ad_new/
+
+ " + "add", "ad", "new""
+
+ 1. What is "add" for?
+
+ To add a new directory to the Repository or to register the desire to
+ add a new file to the Repository.
+
+ The directory is created immediately, while the desire to add the file
+ is recorded in the local ./CVS administrative directory. To really add
+ the file to the Repository, you must then "commit" it.
+
+ Last modified: _6/13/1997_
+
+ 2. How do I add a new file to the branch I'm working on?
+
+ The user actions for adding a file to any branch, including the Main
+ Branch, are exactly the same.
+
+ You are in a directory checked out (or updated) with the '-A' option
+ (to place you on the Main Branch) or the "-r <branch_tag>" option (to
+ place you on a branch tagged with <branch_tag>). To add <file> to the
+ branch you are on, you type:
+
+ cvs add <file>
+ cvs commit <file>
+
+ If no ./CVS/Tag file exists (the '-A' option deletes it), the file
+ will be added to the Main Branch. If a ./CVS/Tag file exists (the "-r
+ <branch_tag>" option creates it), the file will be added to the branch
+ named (i.e. tagged with) <branch_tag>.
+
+ Unless you took steps to first add the file to the Main Branch, your
+ new file ends up in the Attic.
+
+ Last modified: _6/13/1997_
+
+ 3. Why did my new file end up in the Attic?
+
+ The file is thrown into the Attic to keep it from being visible when
+ you check out the Main Branch, since it was never committed to the
+ Main Branch.
+
+ Last modified: _6/13/1997_
+
+ 4. Now that it's in the Attic, how do I connect it to the Main branch?
+
+ That can be considered a kind of "merge". See 4C.8
+
+ Last modified: _6/13/1997_
+
+ 5. How do I avoid the hassle of reconnecting an Attic-only file to the Main
+ Branch?
+
+ You create it on the Main Branch first, then branch it.
+
+ If you haven't yet added the file or if you decided to delete the new
+ Attic file and start over, then do the following: (If you added the
+ file (or worse, the 157 files) to the Attic and don't want to start
+ over, try the procedure in 4C.8.)
+
+ Temporarily remove the sticky branch information. Either:
+
+ Move the whole directory back to the Main Branch. [This might not be
+ a good idea if you have modified files, since it will require a merge
+ in each direction.]
+
+ cvs update -A
+
+ *or*
+
+ Move the ./CVS/Tag file out of the way.
+
+ mv ./CVS/Tag HOLD_Tag
+
+ Add and branch the file "normally":
+
+ cvs add <file>
+ cvs commit <file>
+ cvs tag -b <branch_tag> <file>
+
+ [<branch_tag> is the same Branch Tag as you used on all the other
+ files. Look at ./CVS/Entries or the output from "cvs stat" for sticky
+ tags.]
+
+ Clean up the temporary step.
+
+ If you moved the ./CVS/Tag file, put it back. Then move the new file
+ onto the branch where you are working.
+
+ mv HOLD_Tag ./CVS/Tag
+ cvs update -r <branch_tag> <file>
+
+ If you ran "update -A" rather than moving the ./CVS/Tag file, move
+ the whole directory (including the new file) back onto the branch
+ where you were working:
+
+ cvs update -r <branch_tag>
+
+ Last modified: _6/13/1997_
+
+ 6. How do I cancel an "add"?
+
+ If you want to remove the file entirely and cancel the "add" at the
+ same time, type:
+
+ cvs remove -f <file>
+
+ If you want to cancel the "add", but leave the file as it was before
+ you typed "cvs add", then you have to fake it:
+
+ mv <file> <file>.hold
+ cvs remove <file>
+ mv <file>.hold <file>
+
+ Last modified: _6/13/1997_
+
+ 7. What are the ./CVS/file,p and ./CVS/file,t files for?
+
+ The ./CVS/file,p and ./CVS/file,t files are created by the "add"
+ command to hold command line options and message text between the time
+ of the "add" command and the expected "commit".
+
+ The ./CVS/file,p file is always null, since its function was absorbed
+ by the "options" field in the ./CVS/Entries file. If you put something
+ in this file it will be used as arguments to the RCS "ci" command that
+ commit uses to check the file in, but CVS itself doesn't put anything
+ there.
+
+ The ./CVS/file,t file is null unless you specify an initial message in
+ an "add -m 'message'" command. The text is handed to "rcs -i
+ -t./CVS/file,t" to create the initial RCS file container.
+
+ Both files must exist to commit a newly added file. If the
+ ./CVS/file,p file doesn't exist, CVS prints an error and aborts the
+ commit. If the ./CVS/file,t file doesn't exist, RCS prints an error
+ and CVS gets confused, but does no harm.
+
+ To recover from missing ,p and ,t files, just create two zero-length
+ files and rerun the "commit".
+
+ Last modified: _6/13/1997_
+
+ 8. How do I "add" a binary file?
+
+ If you configured CVS to use the GNU version of "diff" and "diff3",
+ you only need to turn off RCS keyword expansion.
+
+ First you turn off RCS keyword expansion for the initial checkin by
+ using "add -ko". It works like "update -ko" in creating a "sticky"
+ option only for the copy of the file in the current working directory.
+
+ cvs add -ko <file>
+
+ Commit the file normally. The sticky -ko option will be used.
+
+ cvs commit <file>
+
+ Then mark the RCS file in the Repository so that keyword expansion is
+ turned off for all checked out versions of the file.
+
+ cvs admin -ko <file>
+
+ Since "admin -ko" records the keyword substitution value in the
+ Repository's RCS file, you no longer need the sticky option. You can
+ turn it off with the "update -A" command, but if you were on a branch,
+ you'll have to follow it "update -r <branch_tag>" to put yourself back
+ on the branch.
+
+ Managing that binary file is another problem. See 4D.1.
+
+ Last modified: _6/13/1997_
+
+ Category: /Commands_/admin_adm_rcs/
+
+ " + "admin", "adm", "rcs""
+
+ 1. What is "admin" for?
+
+ To provide direct access to the underlying "rcs" command (which is not
+ documented in this FAQ) bypassing all safeguards and CVS assumptions.
+
+ Last modified: _6/13/1997_
+
+ 2. Wow! Isn't that dangerous?
+
+ Yes.
+
+ Though you can't hurt the internal structure of an RCS file using its
+ own "rcs" command, you *can* change the underlying RCS files using
+ "admin" in ways that CVS can't handle.
+
+ If you feel the need to use "admin", create some test files with the
+ RCS "ci" command and experiment on them with "rcs" before blasting any
+ CVS files.
+
+ Last modified: _6/13/1997_
+
+ 3. What would I normally use "admin" for?
+
+ Normally, you wouldn't use admin at all. In unusual circumstances,
+ experts can use it to set up or restore the internal RCS state that
+ CVS requires.
+
+ You can use "admin -o" (for "outdate") to remove revisions you don't
+ care about. This has its own problems, such as leaving dangling Tags
+ and confusing the "update" command.
+
+ There is some feeling among manipulators of binary files that "admin
+ -l" should be used to serialize access. See 3C.8.
+
+ An interesting use for "admin" came up while maintaining CVS itself. I
+ import versions of CVS onto the Vendor branch of my copy of CVS, make
+ changes to some files and ship the diffs (created by "cvs diff -c -r
+ TO_BRIAN") off to Brian Berliner. After creating the diff, I retag
+ ("cvs tag -F TO_BRIAN") the working directory, which is then ready to
+ produce the next patch.
+
+ I'll use "add.c" as an example (only because the name is short).
+
+ When the next release came out, I discovered that the released "add.c"
+ (version 1.1.1.3 on the Vendor branch) was exactly the same as my
+ modified file (version 1.3). I didn't care about the changelog on
+ versions 1.2 and 1.3 (or the evidence of having done the work), so I
+ decided to revert the file to the state where it looked like I had not
+ touched the file -- where I was just using the latest on the vendor
+ branch after a sequence of imports.
+
+ To do that, I removed all the revisions on the main branch, except for
+ the original 1.1 from which the Vendor branch sprouts:
+
+ cvs admin -o1.2: add.c
+
+ Then I set the RCS "default branch" back to the Vendor branch, the way
+ import would have created it:
+
+ cvs admin -b1.1.1 add.c
+
+ And I moved the "TO_BRIAN" Tag to the latest revision on the Vendor
+ branch, since that is the base from which further patches would be
+ created (if I made any):
+
+ cvs admin -NTO_BRIAN:1.1.1.3 add.c
+
+ Instead of 1.1.1.3, I could have used one of the "Release Tags" last
+ applied by "import" (3rd through Nth arguments).
+
+ Suggestion: Practice on non-essential files.
+
+ Last modified: _6/13/1997_
+
+ 4. What should I avoid when using "admin"?
+
+ If you know exactly what you are doing, hack away. But under normal
+ circumstances:
+
+ Never use "admin" to alter branches (using the '-b' option), which CVS
+ takes very seriously. If you change the default branch, CVS will not
+ work as expected. If you create new branches without using the "tag
+ -b" command, you may not be able to treat them as CVS branches.
+
+ See 3C.8 for a short discussion of how to use "admin -l" for
+ serializing access to binary files.
+
+ The "admin -o <file>" allows you to delete revisions, usually a bad
+ idea. You should commit a correction rather than back out a revision.
+ Outdating a revision is prone to all sorts of problems:
+
+ Discarding data is always a bad idea. Unless something in the
+ revision you just committed is a threat to your job or your life,
+ (like naming a function "<boss's name>_is_a_dweeb", or including the
+ combination to the local Mafioso's safe in a C comment), just leave it
+ there. No one cares about simple mistakes -- just commit a corrected
+ revision.
+
+ The time travel paradoxes you can cause by changing history are not
+ worth the trouble. Even if CVS can't interfere with your parents'
+ introduction, it *can* log commits in at least two ways (history and
+ loginfo). The reports now lie -- the revision referred to in the logs
+ no longer exists.
+
+ If you used "import" to place <file> into CVS, outdating all the
+ revisions on the Main branch back to and including revision 1.2 (or
+ worse, 1.1), will produce an invalid CVS file.
+
+ If the <file>,v file only contains revision 1.1 (and the connected
+ branch revision 1.1.1.1), then the default branch must be set to the
+ Vendor branch as it was when you first imported the file. Outdating
+ back through 1.2 doesn't restore the branch setting. Despite the above
+ admonition against it, "admin -b" is the only way to recover:
+
+ cvs admin -b1.1.1 <file>
+
+ Although you can't outdate a physical (RCS) branch point without
+ removing the whole branch, you *can* outdate a revision referred to by
+ a magic branch tag. If you do so, you will invalidate the branch.
+
+ If you "outdate" a tagged revision, you will invalidate all uses of
+ the <tag>, not just the one on <file>. A tag is supposed to be
+ attached to a consistent set of files, usually a set built as a unit.
+ By discarding one of the files in the set, you have destroyed the
+ utility of the <tag>. And it leaves a dangling tag, which points to
+ nothing.
+
+ And even worse, if you commit a revision already tagged, you will
+ alter what the <tag> pointed to without using the "tag" command. For
+ example, if revision 1.3 has <tag> attached to it and you "outdate"
+ the 1.3 revision, <tag> will point to a nonexistent revision. Although
+ this is annoying, it is nowhere near as much trouble as the problem
+ that will occur when you commit to this file again, recreating
+ revision 1.3. The old tag will point to the new revision, a file that
+ was not in existence when the <tag> was applied. And the discrepancy
+ is nearly undetectable.
+
+ If you don't understand the above, you should not use the admin
+ command at all.
+
+ Last modified: _6/13/1997_
+
+ 5. How do I restrict the "admin" command? The -i flag in the modules file
+ can restrict commits. What's the equivalent for "admin"?
+
+ At this writing, to disable the "admin" command, you will have to
+ change the program source code, recompile and reinstall.
+
+ Last modified: _6/13/1997_
+
+ 6. I backed out a revision with "admin -o" and committed a replacement. Why
+ doesn't "update" retrieve the new revision?
+
+ CVS is confused because the revision in the ./CVS/Entries file matches
+ the latest revision in the Repository *and* the timestamp in the
+ ./CVS/Entries file matches your working file. CVS believes that your
+ file is "up-to-date" and doesn't need to be updated.
+
+ You can cause CVS to notice the change by "touch"ing the file.
+ Unfortunately what CVS will tell you is that you have a "Modified"
+ file. If you then "commit" the file, you will bypass the normal CVS
+ check for "up-to-date" and will probably commit the revision that was
+ originally removed by "admin -o".
+
+ Changing a file without changing the revision number confuses CVS no
+ matter whether you did it by replacing the revision (using "admin -o"
+ and "commit" or raw RCS commands) or by applying an editor directly to
+ a Repository (",v") file. Don't do it unless you are absolutely
+ certain no one has the latest revision of the file checked out.
+
+ The best solution to this is to institute a program of deterrent
+ flogging of abusers of "admin -o".
+
+ The "admin" command has other problems." See 3B.4 above.
+
+ Last modified: _6/13/1997_
+
+ Category: /Commands_/checkout_co_get/
+
+ " + "checkout", "co", "get""
+
+ 1. What is "checkout" for?
+
+ To acquire a copy of a module (or set of files) to work on.
+
+ All work on files controlled by CVS starts with a "checkout".
+
+ Last modified: _6/13/1997_
+
+ 2. What is the "module" that "checkout" takes on the command line?
+
+ It is a name for a directory or a collection of files in the
+ Repository. It provides a compact name space and the ability to
+ execute before and after helper functions based on definitions in the
+ modules file.
+
+ See 1D.11.
+
+ Last modified: _6/13/1997_
+
+ 3. Isn't a CVS "checkout" just a bunch of RCS checkouts?
+
+ Like much of CVS, a similar RCS concept is used to support a CVS
+ function. But a CVS checkout is *not* the same as an RCS checkout.
+
+ Differences include:
+
+ CVS does not lock the files. Others may access them at the same
+ time.
+
+ CVS works best when you provide a name for a collection of files (a
+ module or a directory) rather than an explicit list of files to work
+ on.
+
+ CVS remembers what revisions you checked out and what branch you are
+ on, simplifying later commands.
+
+ Last modified: _6/13/1997_
+
+ 4. What's the difference between "update" and "checkout"?
+
+ The "checkout" and "update" commands are nearly equivalent in how they
+ treat individual files. They differ in the following ways:
+
+ The "checkout" command always creates a directory, moves into it,
+ then becomes equivalent to "update -d".
+
+ The "update" command does not create directories unless you add the
+ '-d' option.
+
+ "Update" is intended to be executed within a working directory
+ created by "checkout". It doesn't take a module or directory argument,
+ but figures out what Repository files to look at by reading the files
+ in the ./CVS administrative directory.
+
+ The two commands generate completely different types of records in
+ the "history" file.
+
+ Last modified: _6/13/1997_
+
+ 5. Why can't I check out a file from within my working directory?
+
+ Though you *can* check out a file, you normally check out a module or
+ directory. And you normally do it only once at the beginning of a
+ project.
+
+ After the initial "checkout", you can use the "update" command to
+ retrieve any file you want within the checked-out directory. There is
+ no need for further "checkout" commands.
+
+ If you want to retrieve another module or directory to work on, you
+ must provide two pathnames: where to find it in the Repository and
+ where to put it on disk. The "modules" file and your current directory
+ supply two pieces of naming information. While inside a checked-out
+ working directory, the CVS administrative information provides most of
+ the rest.
+
+ You should be careful not to confuse CVS with RCS and use "checkout"
+ in the RCS sense. An RCS "checkout" (which is performed by the RCS
+ "co" command) is closer to a "cvs update" than to a "cvs checkout".
+
+ Last modified: _6/13/1997_
+
+ 6. How do I avoid dealing with those long relative pathnames?
+
+ This question has also been phrased:
+
+ How do I avoid all those layers of directories on checkout? or Why do
+ I have to go to the top of my working directory and checkout some long
+ pathname to get a file or two?
+
+ This type of question occurs only among groups of people who decide
+ not to use "modules". The answer is to use "modules".
+
+ When you hand the "checkout" command a relative pathname rather than a
+ module name, all directories in the path are created, maintaining the
+ same directory hierarchy as in the Repository. The same kind of
+ environment results if you specify a "module" that is really an alias
+ expanding into a list of relative pathnames rather than a list of
+ module names.
+
+ If you use "module" names, "checkout" creates a single directory by
+ the name of the module in your current directory. This "module"
+ directory becomes your working directory.
+
+ The "module" concept combines the ability to "name" a collection of
+ files with the ability to structure the Repository so that consistent
+ sets of files are checked out together. It is the responsibility of
+ the Repository Administrators to set up a modules file that describes
+ the software within the Repository.
+
+ Last modified: _6/13/1997_
+
+ 7. Can I move a checked-out directory? Does CVS remember where it was
+ checked out?
+
+ Yes and Yes.
+
+ The ./CVS/Repository file in each working directory contains a
+ pathname pointing to the matching directory within the Repository. The
+ pathname is either absolute or relative to $CVSROOT, depending on how
+ you configured CVS.
+
+ When you move a checked-out directory, the CVS administrative files
+ will move along with it. As long as you don't move the Repository
+ itself, or alter your $CVSROOT variable, the moved directory will
+ continue to be usable.
+
+ CVS remembers where you checked out the directory in the "history"
+ file, which can be edited, or even ignored if you don't use the
+ "working directory" information displayed by the "history" command.
+
+ Last modified: _6/13/1997_
+
+ 8. How can I lock files while I'm working on them the way RCS does?
+
+ Until the day arrives of the all-powerful merge tool, there are still
+ files that must be accessed serially. For those instances, here's a
+ potential solution:
+
+ Install a pre-commit program in the "commitinfo" file to check for
+ RCS locks. The program "rcslock.pl" performs this function. It can be
+ found in the contrib directory of the CVS source distribution.
+
+ When you want to make a change to a file you know can't be merged,
+ first use "cvs admin -l" to lock the file. If you can't acquire the
+ lock, use the standard "locked out" protocol: go talk to the person
+ holding the lock.
+
+ Make sure the pre-commit program prints a message and exits with a
+ non-zero status if someone besides the user running "commit" has the
+ file locked. This non-zero exist status will cause the "commit" to
+ fail cleanly.
+
+ Make sure the pre-commit program exits with a zero status if the
+ file is either unlocked or locked by the user running "commit". The
+ "cvs commit" command that kicked off the pre-commit program will take
+ a zero exist status as an OK and checkin the file, which has the
+ side-effect of unlocking it.
+
+ ===> The following is opinion and context. Don't read it if you are
+ looking for a quick fix.
+
+ The topic of locking CVS files resurfaces on the network every so
+ often, producing the same results each time:
+
+ The Big Endians:
+
+ CVS was designed to avoid locks, using a copy-modify-merge model.
+ Locking is not necessary and you should take the time to learn the CVS
+ model which many people find workable. So why not get with the program
+ and learn how to think the CVS way?
+
+ The Little Endians:
+
+ The users determine how a tool is to be used, not the designers. We,
+ the users, have always used locking, our bosses demand locking,
+ locking is good, locking is God. I don't want to hear any more
+ lectures on the CVS model. Make locking work.
+
+ Any organization making active changes to a source base will
+ eventually face the need to do parallel development. Parallel
+ development implies merges. (If you plan to keep separate copies of
+ everything and never merge, good luck. Tell me who you work for so I
+ can buy stock in your disk suppliers this year and sell your stock
+ short next year.)
+
+ Merges will never go away. CVS chose to make "merges" stand front and
+ center as an important, common occurrence in development. It is one
+ way of looking at things.
+
+ For free-format text, the merge paradigm gives you a considerable
+ amount of freedom. It does take a bit of management, but any project
+ should be ready to deal with it.
+
+ On the other hand, there are many files that can't be merged using
+ text merge techniques. Straight text merge programs like "diff3" are
+ guaranteed to fail on executables (with relative branch statements),
+ files with self-referential counts stored in the file (such as TAGS
+ files), or files with relative motion statements in them (such as
+ Frame MIF files, many postscript files). They aren't all binary files.
+
+ For these types of files, and many others, there are only two
+ solutions:
+
+ Complex merge tools that are intimately aware of the contents of the
+ files to be merged. (ClearCase, and probably others, allow you to
+ define your own "files types" with associated "merge tools".)
+
+ Serialization of access to the file. The only technical solution to
+ the problem of serialization is "locking".
+
+ Since you can call a program that offers:
+
+ "Which one do you want? A/B?"
+
+ a "merge tool", more and more merge tools will appear which can be
+ hooked into a merge-intensive program like CVS. Think of a bitmap
+ "merge" tool that displays the bitmaps on the screen and offers a
+ "paint" interface to allow you to cut and paste, overlay, invert or
+ fuse the two images such that the result is a "merged" file.
+
+ My conclusion is that the need for locking is temporary, awaiting
+ better technology. For large development groups, locking is not an
+ alternative to merging for text files.
+
+ Last modified: _6/13/1997_
+
+ 9. What is "checkout -s"? How is it different from "checkout -c"?
+
+ The '-c' and '-s' options to "checkout" both cause the modules file to
+ appear on standard output, but formatted differently.
+
+ "checkout -c" lists the modules file alphabetized by the module name.
+ It also prints all data (including options like '-a' and "-o <prog>")
+ specified in the modules file.
+
+ "checkout -s" lists the modules file sorted by "status" field, then by
+ module name. The status field was intended to allow you to mark
+ modules with strings of your choice to get a quick sorted report based
+ on the data you chose to put in the status fields. I have used it for
+ priority ("Showstopper", etc as tied into a bug database), for porting
+ status ("Ported", "Compiled", etc. when porting a large collection of
+ modules), for "assignee" (the person responsible for maintenance), and
+ for "test suite" (which automatic test procedure to run for a
+ particular module).
+
+ Last modified: _6/13/1997_
+
+ Category: /Commands_/commit_ci_com/
+
+ " + "commit", "ci", "com""
+
+ 1. What is "commit" for?
+
+ To store new revisions in the Repository, making them visible to other
+ users.
+
+ Last modified: _6/13/1997_
+
+ 2. If I edit ten files, do I have to type "commit" ten times?
+
+ No. The "commit" command will take multiple filenames, directory names
+ and relative pathnames on the command line and commit them all with
+ the same log message. If a file is unchanged, even if it is explicitly
+ listed on the command line, CVS will skip it.
+
+ Like all CVS commands, "commit" will work on the whole directory by
+ default. Just type "cvs commit" to tell CVS to commit all modified
+ files (i.e. the files that "update" would display preceded by 'M') in
+ the current directory and in all sub-directories.
+
+ Last modified: _6/13/1997_
+
+ 3. Explain: cvs commit: Up-to-date check failed for `<file>'
+
+ You may not "commit" a file if your BASE revision (i.e. the revision
+ you last checked out, committed or retrieved via "update") doesn't
+ match the HEAD revision (i.e the latest revision on your branch,
+ usually the Main Branch).
+
+ In other words, someone committed a revision since you last executed
+ "checkout", "update" or "commit". You must now execute "update" to
+ merge the other person's changes into your working file before
+ "commit" will work. You are thus protected (somewhat) from a common
+ form of race condition in source control systems, where a checkin of a
+ minor alteration of a second copy of the same base file obliterates
+ the changes made in the first.
+
+ Normally, the "update" command's auto-merge should be followed by
+ another round of building and testing before the "commit".
+
+ Last modified: _6/13/1997_
+
+ 4. What happens if two people try to "commit" conflicting changes?
+
+ Conflicts can occur only when two developers check out the same
+ revision of the same file and make changes. The first developer to
+ commit the file has no chance of seeing the conflict. Only the second
+ developer runs into it, usually when faced with the "Up-to-date" error
+ explained in the previous question.
+
+ There are two types of conflicts:
+
+ When two developers make changes to the same section of code, the
+ auto-merge caused by "update" will print a 'C' on your terminal and
+ leave "overlap" markers in the file.
+
+ You are expected to examine and clean them up before committing the
+ file. (That may be obvious to *some* of you, but . . .)
+
+ A more difficult problem arises when two developers change different
+ sections of code, but make calls to, or somehow depend on, the old
+ version of each other's code.
+
+ The auto-merge does the "right" thing, if you view the file as a
+ series of text lines. But as a program, the two developers have
+ created a problem for themselves.
+
+ This is no different from making cross-referential changes in
+ *separate* files. CVS can't help you. In a perfect world, you would
+ each refer to the specification and resolve it independently. In the
+ real world you have to talk/argue, read code, test and debug until the
+ combined changes work again.
+
+ Welcome to the world of parallel development.
+
+ Last modified: _6/13/1997_
+
+ 5. I committed something and I don't like it. How do I remove it?
+
+ Though you *can* use the "admin -o" (synonym: "rcs -o") command to
+ delete revisions, unless the file you committed is so embarrassing
+ that the need to eradicate it overrides the need to be careful, you
+ should just grab an old version of the file ("update -p -r
+ <previous-rev>" might help here) and commit it on top of the offending
+ revision.
+
+ See Section 3B on "admin".
+
+ Last modified: _6/13/1997_
+
+ 6. Explain: cvs commit: sticky tag `V3' for file `X' is not a branch
+
+ The message implies two things:
+
+ You created your working directory by using "checkout -r V3", or you
+ recently executed "update -r V3".
+
+ The tag named V3 is not a branch tag.
+
+ CVS records (i.e. makes "sticky") any "-r <tag/rev>" argument handed
+ to the "checkout" or "update" commands. The <tag/rev> is recorded as
+ the CVS working branch, which is the branch to which "commit" will add
+ a new revision.
+
+ Branch tags are created when you use the -b switch on the "tag" or
+ "rtag" commands. Branch tags are magic tags that don't create a
+ physical branch, but merely mark the revision to branch from when the
+ branch is needed. The first commit to a magic branch creates a
+ physical branch in the RCS files.
+
+ You can commit onto the end of the Main Trunk, if you have no sticky
+ tag at all, or onto the end of a branch, if you have a sticky branch
+ tag. But you can't commit a file that has a sticky tag not pointing to
+ a branch. CVS assumes a sticky Tag or Revision that does not refer to
+ a branch is attached to the middle of a series of revisions. You can't
+ squeeze a new revision between two others. Sticky dates also block
+ commits since they never refer to a branch.
+
+ Scenario1:
+
+ If you don't want a branch and were just looking at an old revision,
+ then you can move back to the Main Branch by typing:
+
+ cvs update -A {files or dirs, default is '.'}
+
+ or you can move to the branch named <branch_tag> by:
+
+ cvs update -r <branch_tag> {files or dirs, default is '.'}
+
+ Scenario2:
+
+ If you really wanted to be on a branch and made an earlier mistake by
+ tagging your branch point with a non-branch tag, you can recover by
+ adding a new branch tag to the old non-branch tag:
+
+ cvs rtag -b -r <oldtag> <newtag> <module>
+
+ (It was not a big mistake. Branch-point tags can be useful. But the
+ <newtag> must have a different name.)
+
+ If you don't know the <module> name or don't use "modules", you can
+ also use "tag" this way:
+
+ cvs update -r <oldtag>
+ cvs tag -b <newtag> .
+
+ Then, to put your working directory onto the branch, you type:
+
+ cvs update -r <newtag>
+
+ You can't delete <oldtag> before adding <newtag>, and I would not
+ advise deleting the <oldtag> at all, because it is useful in referring
+ to the branch point. If you must, you can delete the non-branch tag
+ by:
+
+ cvs rtag -d <oldtag> <module>
+ or
+ cvs tag -d <oldtag> .
+
+ Scenario3:
+
+ If you made the same mistake as in Scenario2 (of placing a non-branch
+ tag where you wanted a branch tag), but really want <oldtag> to be the
+ name of your branch, you can execute a slightly different series of
+ commands to rename it and move your working directory onto the branch.
+
+ Warning: This is not a way to rename a branch tag. It is a way to turn
+ a non-branch tag into a branch tag with the same name.
+
+ cvs rtag -r <oldtag> <branch_point_tag> <module>
+ cvs rtag -d <oldtag> <module>
+ cvs rtag -b -r <branch_point_tag> <oldtag> <module>
+
+ Then, if you really must, delete the <branch_point_tag>:
+
+ cvs rtag -d <branch_point_tag> <module>
+
+ Note: The unwieldy mixture of "tag" and "rtag" is mostly because you
+ can't specify a revision (-r <tag>) to the "tag" command.
+
+ See 4C.3 for more info on creating a branch.
+
+ Last modified: _6/13/1997_
+
+ 7. Why does "commit -r <tag/rev>" put newly added files in the Attic?
+
+ If you specify "-r <rev>" (where <rev> is a dotted numeric number like
+ 2.4), it correctly sets the initial revision to <rev>, but it also
+ attaches the numeric <rev> as a sticky tag and throws the file into
+ the Attic. This is a bug. The obvious solution is to move the file out
+ of the Attic into the associated Repository directory and "update -A"
+ the file. There are no Tags to clean up.
+
+ If you specify "-r <tag>" to commit a newly added file, the <tag> is
+ treated like a <branch_tag>, which becomes a symbolic RCS label
+ pointing to the string '1', which can be considered to be the "Main
+ branch number" when the main branch is still at revision 1.N. The file
+ is also thrown into the Attic. See 4C.8 for a way to recover from
+ this.
+
+ In fact, a plain "commit" without the "-r" will throw a newly added
+ file into the Attic if you added it to a directory checked out on a
+ branch. See 3A.[2-5].
+
+ See Section 4C, on Branching, for many more details.
+
+ Last modified: _6/13/1997_
+
+ 8. Why would a "commit" of a newly added file not produce rev 1.1?
+
+ When committing a newly added file CVS looks for the highest main
+ branch major number in all files in the ./CVS/Entries file. Normally
+ it is '1', but if you have a file of revision 3.27 in your directory,
+ CVS will find the '3' and create revision 3.1 for the first rev of
+ <file>. Normally, the first revision is 1.1.
+
+ Last modified: _6/13/1997_
+
+ Category: /Commands_/diff_di_dif/
+
+ " + "diff", "di", "dif""
+
+ 1. What is "diff" for?
+
+ To display the difference between a working file and its BASE
+ revision (the revision last checked out, updated or committed):
+
+ cvs diff <file>
+
+ To display the difference between a working file and a committed
+ revision of the same file:
+
+ cvs diff -r <tag/rev> <file>
+
+ To display the difference between two committed revisions of the
+ same file:
+
+ cvs diff -r <tag1/rev1> -r <tag2/rev2> <file>
+
+ You can specify any number of <file> arguments. Without any <file>
+ arguments, it compares the whole directory.
+
+ In the examples above, "-D <date>" may be substituted wherever "-r
+ <tag/rev>" appears. The revision a <date> refers to is the revision
+ that existed on that date.
+
+ Last modified: _6/13/1997_
+
+ 2. Why did "diff" display nothing when I know there are later committed
+ revisions in the Repository?
+
+ By default, "diff" displays the difference between your working file
+ and the BASE revision. If you haven't made any changes to the file
+ since your last "checkout", "update" or "commit" there is no
+ difference to display.
+
+ To display the difference between your working file and the latest
+ revision committed to your current branch, type:
+
+ cvs diff -r HEAD <file>
+
+ Last modified: _6/13/1997_
+
+ 3. How do I display what changed in the Repository since I last executed
+ "checkout", "update" or "commit"?
+
+ A special tag (interpreted by CVS -- it does not appear in the Tag
+ list) named "BASE" always refers to the revision you last checked out,
+ updated or committed. Another special tag named "HEAD" always refers
+ to the latest revision on your working branch.
+
+ To compare BASE and HEAD, you type:
+
+ cvs diff -r BASE -r HEAD <file>
+
+ Last modified: _6/13/1997_
+
+ 4. How do I display the difference between my working file and what I
+ checked in last Thursday?
+
+ cvs diff -D "last Thursday" <file>
+
+ where "last Thursday" is a date string. To be more precise, the
+ argument to the '-D' option is a timestamp. Many formats are accepted.
+ See the man page under "-D date_spec" for details.
+
+ Last modified: _6/13/1997_
+
+ 5. Why can't I pass long options, like --unified, to "diff"?
+
+ CVS only handles single character '-X' arguments, not the FSF long
+ options. CVS also passes through only arguments it knows about,
+ because a few arguments are captured and interpreted by CVS.
+
+ If you didn't configure RCS and CVS to use the GNU version of diff,
+ long options wouldn't work even if future versions of CVS acquire the
+ ability to pass them through.
+
+ Most of the long options have equivalent single-character options,
+ which do work. The "--unified" option is equivalent to '-u' in
+ revisions of GNU diff since 1.15.
+
+ Last modified: _6/13/1997_
+
+ Category: /Commands_/export_exp_ex/
+
+ " + "export", "exp", "ex""
+
+ 1. What is "export" for?
+
+ "export" checks out a copy of a module in a form intended for export
+ outside the CVS environment. The "export" command produces the same
+ directory and file structure as the "checkout" command, but it doesn't
+ create "CVS" sub-directories and it removes all the RCS keywords from
+ the files.
+
+ Last modified: _6/13/1997_
+
+ 2. Why does it remove the RCS keywords so I can't use the "ident" command
+ on the source files?
+
+ It removes the RCS keywords, so that if the recipient of the exported
+ sources checks them into another set of RCS files (with or without
+ CVS), and then makes modifications through RCS or CVS commands, the
+ revision numbers that they had when you exported them will be
+ preserved. (That ident no longer works is just an unfortunate side
+ effect.)
+
+ The theory is that you are exporting the sources to someone else who
+ will make independent changes, and at some point you or they will want
+ to know what revisions from your Repository they started with
+ (probably to merge changes, or to try to decide whether to merge
+ changes).
+
+ A better way to handle this situation would be to give them their own
+ branch of your Repository. They would need to remember to checkin the
+ exported sources with RCS IDs intact (ci -k) so that their changes
+ would get revision numbers from the branch, rather than starting at
+ 1.1 again. Perhaps a future version of CVS will provide a way to
+ export sources this way.
+
+ Contributed by Dan Franklin
+
+ Last modified: _6/13/1997_
+
+ 3. Can I override the '-kv' flag CVS passes to RCS?
+
+ Not as of CVS version 1.4.
+
+ Last modified: _6/13/1997_
+
+ 4. Why doesn't "export" have a '-k' flag like "import" does?
+
+ Export is intended for a specific purpose -- to remove all trace of
+ revision control on the way *out* of CVS.
+
+ Last modified: _6/13/1997_
+
+ 5. Why does "export -D" check out every file in the Attic?
+
+ See 5B.3 for an explanation of the same problem with "update".
+
+ Last modified: _6/13/1997_
+
+ Category: /Commands_/history_hi_his/
+
+ " + "history", "hi", "his""
+
+ 1. What is "history" for?
+
+ To provide information difficult or impossible to extract out of the
+ RCS files, such as a "tag" history or a summary of module activities.
+
+ Last modified: _6/13/1997_
+
+ 2. Of what use is it?
+
+ I have found it useful in a number of ways, including:
+
+ Providing a list of files changed since
+
+
+ - A tagged release.
+ - Yesterday, last Thursday, or a specific date.
+ - Someone changed a specific file.
+
+ Providing a list of special events:
+
+
+ - Files added or removed since one of the above events.
+ - Merge failures since one of the above events. (Where did the
+ conflicts occur?)
+ - Has anyone (and who) grabbed the revision of this file I committed
+ last week, or are they still working blind?
+
+ Telling me how often a file/directory/module has been changed.
+
+ Dumping a summary of work done on a particular module, including who
+ last worked on it and what changed.
+
+ Displaying the checked-out modules and where they are being worked
+ on.
+
+ To tell me what users "joe" and "malcolm" have done this week.
+
+ Last modified: _6/13/1997_
+
+ 3. What is this, Big Brother?
+
+ War is Peace.
+ Freedom is Slavery.
+ Ignorance is Strength.
+
+ Normally manager types and those with the power to play Big Brother
+ don't care about this information. The Software Engineer responsible
+ for integration usually wants to know who is working on what and what
+ changed. Use your imagination.
+
+ Last modified: _6/13/1997_
+
+ 4. I deleted my working directory and "history" still says I have it
+ checked out. How do I fix it?
+
+ You can use "release -f" to forcibly add a "release" record to the
+ history file for a working directory associated with a "module". If
+ your version of "release" doesn't have the '-f' option, or you checked
+ out the directory using a relative path, you have to edit the
+ $CVSROOT/CVSROOT/history file.
+
+ You can remove the last 'O' line in the history file referring to the
+ module in question or add an 'F' record.
+
+ Last modified: _6/13/1997_
+
+ 5. So I *can* edit the History file?
+
+ Yes, but if you are using history at all, you should take a little
+ care not to lose information. I normally use Emacs on the file, since
+ it can detect that a file has changed out from under it. You could
+ also copy and zero out the history file, edit the copy and append any
+ new records to the edited copy before replacing it.
+
+ Last modified: _6/13/1997_
+
+ 6. Why does the history file grow so quickly?
+
+ It stores 'U' records, which come in handy sometimes when you are
+ tracking whether people have updated each other's code before testing.
+ There should (and probably will sometime) be a way to choose what
+ kinds of events go into the history file.
+
+ The contributed "cln_hist.pl" script will remove all the 'U' records,
+ plus matching pairs of 'O' and 'F' records during your normal clean up
+ of the history file.
+
+ Last modified: _6/13/1997_
+
+ 7. What is the difference between "cvs history -r <tag/rev>" and "cvs
+ history -t <tag>"?
+
+ The '-t' option looks for a Tag record stored by "rtag" in the history
+ file and limits the search to dates after the last <tag> of the given
+ name was added.
+
+ The '-r' option was intended to search all files looking for the <tag>
+ in the RCS files. It takes forever and needs to be rewritten.
+
+ Last modified: _6/13/1997_
+
+ 8. Why does "cvs history -c -t <tag>" fail to print anything?
+
+ You have been using "tag" instead of "rtag". The "tag" command
+ currently doesn't store a history record. This is another remnant of
+ CVS's earlier firm belief in "modules". But it also has a basis in how
+ "rtag" and "tag" were originally used.
+
+ "rtag" was intended for large-scale tagging of large chunks of the
+ Repository, an event work recording. "tag" was intended for adding and
+ updating tags on a few files or directories, though it could also be
+ used to tag the entire checked-out working tree when there is no
+ module defined to match the tree or when the working tree is the only
+ place where the right collection of revisions to tag can be found.
+
+ Last modified: _6/13/1997_
+
+ 9. "cvs history -a -o" only printed one line for each checked-out module.
+ Shouldn't it print all the directories where the modules are checked out?
+
+ Not as designed.
+
+ Command Question it is supposed to answer.
+ ---------------- ------------------------------------------
+ cvs history -o What modules do I have checked out?
+ cvs history -a -o <same for all users>
+
+ cvs history -o -w What working directories have I created
+ and what modules are in them?
+ cvs history -a -o -w <same for every user>
+
+ The -o option chooses the "checked out modules" report, which is the
+ default history report.
+
+ Last modified: _6/13/1997_
+
+ 10. I can't figure out "history", can you give me concrete examples?
+
+ Default output selects records only for the user who executes the
+ "history" command. To see records for other users, add one or more "-u
+ user" options or the '-a' option to select *all* users.
+
+ To list (for the selected users): Type "cvs history" and:
+
+
+ * Checked out modules: -o (the default)
+ * Files added since creation: -x A
+ * Modified files since creation: -c
+ * Modified files since last Friday: -c -D 'last Friday'
+ * Modified files since TAG was added: -c -t <tag>
+ * Modified files since TAG on files: -c -r <tag>
+ * Last modifier of file/Repository X? -c -l -[fp] X
+ * Modified files since string "str": -c -b str
+ * Tag history: (Actually "rtag".) -T
+ * History of file/Repository/module X: -[fpn] X
+ * Module report on "module": -m module
+
+ Last modified: _6/13/1997_
+
+ 11. Can we merge history files when we merge Repositories?
+
+ Assuming that the two Repositories have different sets of pathnames,
+ it should be possible to merge two history files by sorting them
+ together by the timestamp fields.
+
+ You should be able to run:
+
+ sort +0.1 ${dir1}/history ${dir2}/history > history
+
+ If you "diff" a standard history file before and after such a sort,
+ you might see other differences caused by garbage (split lines, nulls,
+ etc) in the file. If your Repository is mounted through NFS onto
+ multiple machines you will also see a few differences caused by
+ different clocks on different machines. (Especially if you don't use
+ NTP to keep the clocks in sync.)
+
+ Last modified: _6/13/1997_
+
+ Category: /Commands_/import_im_imp/
+
+ " + "import", "im", "imp""
+
+ 1. What is "import" for?
+
+ The "import" command is a fast way to insert a whole tree of files
+ into CVS.
+
+ The first "import" to a particular file within the Repository creates
+ an RCS file with a single revision on the "Vendor branch." Subsequent
+ "import"s of the same file within the Repository append a new revision
+ onto the Vendor branch. It does not, as some seem to believe, create a
+ new branch for each "import". All "imports" are appended to the single
+ Vendor branch.
+
+ If the file hasn't changed, no new revision is created -- the new
+ "Release-Tag" is added to the previous revision.
+
+ After the import is finished, files you have not changed locally are
+ considered to have changed in the "Main line of development". Files
+ you *have* changed locally must have the new Vendor code merged into
+ them before they are visible on the "Main line".
+
+ See 4C.6 and 4C.15
+
+ Last modified: _6/13/1997_
+
+ 2. How am I supposed to use "import"?
+
+ Create a source directory containing only the files you want to
+ import. Make sure you clean up any cruft left over from previous
+ builds or editing. You want to make sure that the directory contains
+ only what you want to call "source" from which everything else is
+ built.
+
+ If this is not the first import from this "Vendor", you should also
+ compare the output of "find . ! -name CVS -print | sort" executed both
+ at the head of a checked out working directory and at the head of the
+ sources to be imported. If you find any deleted or renamed files, you
+ have to deal with them by hand. (See 4B.8 on renaming.)
+
+ "cd" into your source directory and type:
+
+ cvs import -m "Message" <repos> <Vendor-Tag> <Release-Tag>
+
+ where <repos> is the relative directory pathname within the Repository
+ that corresponds to the sources you are importing.
+
+ You might also consider using the "-I !" option to avoid ignoring
+ anything. It is easier to remove bogus files from the Repository than
+ to create a sparse tree of the ignored files and rerun "import".
+
+ For example, if the FSF, CVS, Make and I are still active in the year
+ 2015, I'll import version 89.53 of GNU make this way:
+
+ cvs import -m "GNUmake V89.53" gnu/make GNU GNUMAKE_89_53
+
+ See 3H.13 for more details.
+
+ Last modified: _6/13/1997_
+
+ 3. Why does import put files on a branch? Why can't I work on the main
+ trunk instead of a Vendor branch?
+
+ This was a Design choice. The Vendor branch is the way "import" deals
+ with a Vendor release. It is a solution to the Engineering problem of
+ how to merge multiple external releases of Vendor-supplied sources
+ into your ongoing work. The Vendor releases are kept on a separate,
+ special, "Vendor" branch and your work is kept on the RCS trunk. New
+ Vendor releases are imported onto the Vendor branch and then merged
+ into your work, if there is any, on the trunk.
+
+ This way, you can use CVS to find out not only about your work, but
+ you can also find out what the Vendor changed by diffing between two
+ of the Release Tags you handed to "import".
+
+ CVS was designed to work this way. If you use CVS in some other way,
+ you should think carefully about what you are doing.
+
+ Note that the CVS "Main Branch" and the RCS Main Trunk are not the
+ same. Placing files on the Vendor Branch doesn't keep you from
+ creating a development branch to work on.
+
+ See Section 4C, on Branching.
+
+ If you are not working with 3rd party (i.e. Vendor) sources, you can
+ skip the "import" and avoid the Vendor branch entirely. It works just
+ as well to move pre-existing RCS files into Repository directories.
+
+ You can create a whole Repository tree by copying a directory
+ hierarchy of normal source files directly into the Repository and
+ applying CVS to it. Here's an idea you should *test* before using:
+
+ cd <your source tree>
+ set source = `pwd`
+ set module = xyzzy <<== Your choice of directory name
+ mkdir $CVSROOT/$module
+ cd $CVSROOT/$module
+ (cd $source; tar cf - .) | tar xvpBf -
+ find . -type f -exec ci -t-Original. {} \;
+
+ The RCS "ci" command, without -u or -l options, will turn your source
+ file into an RCS (",v") and delete the original source.
+
+ Last modified: _6/13/1997_
+
+ 4. Is there any way to import binary files?
+
+ If you configured CVS to use the GNU version of "diff" and "diff3",
+ then you can import any kind of file.
+
+ Binary files with RCS keywords in them are a problem, since you don't
+ want them to expand.
+
+ If the tree you are about to "import" is entirely filled with binary
+ files, you can use the '-ko' option on "import". Otherwise, I would
+ run the import normally, then fix the binary files as described below
+ in 3H.5.
+
+ See 4D.1 on Binary files.
+
+ Last modified: _6/13/1997_
+
+ 5. Why does "import" corrupt some binary files?
+
+ The RCS "co" command, when it is invoked by a CVS "checkout" or
+ "update" (or after a "commit") command, searches for and expands a
+ list of keywords within the file. They are documented in the RCS "co"
+ man page. Strings such as "$\Id$" (or "$\Id:"), or "$\Revision$" (or
+ "$\Revision:") are altered to the include the indicated information.
+
+ [[Note: The keywords should appear in the text without the '\'
+ character I have inserted to *avoid* expansion here. The only real RCS
+ keywords in this document are at the top of the file, where I store
+ the Revision and Date.]]
+
+ If RCS keyword strings show up in a binary file, they will be altered
+ unless you set the '-ko' option on the RCS files to tell RCS to keep
+ the original keyword values and not to expand new ones. After
+ "import", you can set the '-ko' option this way:
+
+ cvs admin -ko <file>
+ rm <file>
+ cvs update <file>
+
+ After an import that didn't use '-ko' (because the whole tree wasn't
+ of binary files) you should fix up the binary files as described above
+ before checking out any new copies of the files and before updating
+ any working directories you checked out earlier.
+
+ See 4D.1 on Binary files.
+
+ Last modified: _6/13/1997_
+
+ 6. How do I retain the original $\Revision$ strings in the sources?
+
+ If you want to leave old RCS keywords as they are, you can use the
+ '-ko' tricks described above.
+
+ Last modified: _6/13/1997_
+
+ 7. I imported some files for the Yarg compiler that compiles files with a
+ suffix of ".yarg" and whose comment prefix is "YARG> ". When I check them
+ out, they will no longer compile because they have this junk in them. Why?
+
+ YARG>YARG>YARG>YARG>YARG>YARG>YARG>YARG>YARG>YARG>YARG>YARG>YARG>
+ YARG> $\Log:
+ # Revision 1.3 1998/03/03 00:16:16 bubba
+ # What is 2+2 anyway?
+ #
+ # Revision 1.2 1998/03/03 00:15:15 bubba
+ # Added scorekeeping.
+ YARG>
+ YARG>YARG>YARG>YARG>YARG>YARG>YARG>YARG>YARG>YARG>YARG>YARG>YARG>
+
+ Well bubba, "Yarg" hasn't hit the big time yet. Neither RCS nor CVS
+ know about your suffix or your comment prefix. So you have two
+ choices:
+
+ Check out the Yarg-less module, and tell all the files about your
+ comment prefix. Visit each directory and type:
+
+ cvs admin -c"YARG> " *.yarg
+
+ If *all* files in the whole directory tree are Yarg files, you can use
+ this instead:
+
+ cvs admin -c"YARG> " .
+
+ Then save any changes you made, remove all the "*.yarg" files and grab
+ new copies from the Repository:
+
+ rm *.yarg (or: find . -name '*.yarg' -exec rm {} ';') (or: find .
+ -name '*.yarg' -print | xargs rm) (or: find . -name '*.yarg' -print0 |
+ xargs -0 rm if you have spaces in filenames and the GNU find/xargs.)
+ cvs update
+
+ It might be faster to remove the whole directory and check it out
+ again.
+
+ Change the import.c file in the CVS sources and add the .yarg
+ suffix, along with the "YARG> " comment prefix to the "comtable"
+ array.
+
+ If you ever plan to add new files with $\Log in them, you should also
+ go into the RCS sources and make the same change in the table
+ contained in the "rcsfnms.c" file.
+
+ Then delete the imported files from the Repository and re-"import" the
+ sources.
+
+ Last modified: _6/13/1997_
+
+ 8. How do I make "import" save the timestamps on the original files?
+
+ Use "import -d" to save the current timestamps on the files as the RCS
+ revision times.
+
+ See 4D.8 for another aspect of file timestamps.
+
+ Last modified: _6/13/1997_
+
+ 9. Why can't I "import" 3 releases on different branches?
+
+ I'll bet you typed something like this:
+
+ cd /src/blasto.v2
+ cvs import -b 1.1.2 VENDOR2 Version2
+ cd /src/blasto.v3
+ cvs import -b 1.1.3 VENDOR3 Version3
+ cd /src/blasto.v4
+ cvs import -b 1.1.4 VENDOR4 Version4
+
+ This is wrong, or at least it won't help you much. You have created
+ three separate Vendor branches, which is probably not what you wanted.
+
+ Earlier versions of CVS, as described in Brian Berliner's Usenix
+ paper, tried to support multiple Vendor branches on the theory that
+ you might receive source for the *same* program from multiple vendors.
+ It turns out that this is very rare, whereas the need to branch in
+ *your* development, for releases and for project branches, is much
+ greater.
+
+ So the model now is to use a single vendor branch to contain a series
+ of releases from the same vendor. Your work moves along on the Main
+ Trunk, or on a CVS branch to support a real "branch in development".
+
+ To set this up, you should type this instead of the above:
+
+ cd /src/blasto.v2
+ cvs import VENDOR Version2
+ cd /src/blasto.v3
+ cvs import VENDOR Version3
+ cd /src/blasto.v4
+ cvs import VENDOR Version4
+
+ Last modified: _6/13/1997_
+
+ 10. What do I do if the Vendor adds or deletes files between releases?
+
+ Added files show up with no extra effort. To handle "removed" files,
+ you should always compare the tree structure of the new release
+ against the one you have in your Repository. If the Vendor has removed
+ files since the previous release, go into a working directory
+ containing your current version of the sources and "cvs remove"
+ (followed by "cvs commit" to make it really take effect) each file
+ that is no longer in the latest release.
+
+ Using this scheme will allow you to "checkout" any version of the
+ vendor's code, with the correct revisions and files, by using
+ "checkout -r Version[234]".
+
+ Renames are harder to find, since you have to compare file contents to
+ determine that one has occurred. If you notice one, see 4B.8 on
+ renaming files.
+
+ Last modified: _6/13/1997_
+
+ 11. What about if the Vendor changes the names of files or directories, or
+ rearranges the whole structure between releases?
+
+ Currently CVS can't handle this cleanly. It requires "renaming" a
+ bunch of files or directories.
+
+ See 4B.8 on "renaming" for more details.
+
+ What I generally do is to close the Repository for a while and make
+ changes in both the Repository and in a copy of the vendor release
+ until the structure matches, then execute the import.
+
+ If you ever have to check out and build an old version, you may have
+ to use the new, or completely different Makefiles.
+
+ Last modified: _6/13/1997_
+
+ 12. I thought "import" was for Vendor releases, why would I use it for code
+ of my own? Do I have to use import?
+
+ For code you produce yourself, "import" is a convenience for fast
+ insertion of whole trees. It is not necessary. You can just as easily
+ create ",v" files using the RCS "ci" command and move them directly
+ into the Repository.
+
+ Other than the CVSROOT directory, the Repository consists entirely of
+ directories of ",v" files. The Repository contains no other state
+ information.
+
+ See Section 4B, on Setting up and Managing the Repository.
+
+ Last modified: _6/13/1997_
+
+ 13. How do I import a large Vendor release?
+
+ When the sum of the changes made by the Vendor and the changes made by
+ local developers is small, "import" is not a big problem. But when you
+ are managing a large Repository, any care taken up front will save you
+ time later.
+
+ First read the following, then, before executing "import", see the
+ questions in Section 4C dealing with branch merges and Vendor branch
+ merges.
+
+ If this is not the first import of this code, before starting, rtag
+ the whole directory you will be changing.
+
+ The first step is to make sure the structure of the new files
+ matches the structure of the current Repository.
+
+ Run "find . -print | sort" on both trees and "diff" the output.
+
+ Alter the "source" tree until the "diff" (of the list of filenames,
+ not of the whole trees) shows that the directory structures are
+ equivalent.
+
+ The "comm" command, if you have it, can help figure out what has been
+ added or deleted between releases.
+
+ If they deleted any files, you can handle them cleanly with "cvs
+ remove". The command "comm -23 files.old files.new" will show you a
+ list of files that need to be removed.
+
+ You should examine the list first to see if any have been renamed
+ rather than simply deleted.
+
+ If they renamed any files, see 4B.8 on renaming files.
+
+ Remember to *SAVE* the output from the import command.
+
+ When you have dealt with removed and renamed files, then you can
+ execute the import:
+
+ cd <new source>
+ cvs import -I ! -m "Message" <repos> <VendorTag> <ReleaseTag>
+
+ Where
+
+ "-I !" is an optional argument that keeps "import" from ignoring
+ files. The comparison of the "find" commands above will probably avoid
+ the need for this, but it is easier to remove files from the
+ Repository than to run a subset "import" to catch just the ignored
+ files. [You might have to quote or backwhack the '!'.]
+
+ Message is the log message to be stored in the RCS files.
+
+ <repos> is a relative path to a directory within the
+ Repository. The directory <new source> must be at
+ the same relative level within the new sources as
+ the <repos> you give is within the Repository. (I
+ realize this is not obvious. Experiment first.)
+
+ <VendorTag> is a Tag used to identify the Vendor who sent you
+ the files you are importing. All "imports" into
+ the same <repos> *must* use the same VendorTag.
+ You can find it later by using the "log" command.
+
+ <ReleaseTag> is a Tag used to identify the particular release of the
+ software you are importing. It must be unique and should be mnemonic
+ -- at least include the revision number in it. (Note: you can't use
+ '.' characters in a Tag. Substitute '_' or '-'.)
+
+ There will be six categories of files to deal with. (Actually there
+ are eight, but you have already dealt with "removed" and "renamed"
+ files.)
+
+ If this is the first "import" into a given <repos> directory, only the
+ first three of these ('I', 'L' and 'N') can occur.
+
+ Ignored file.
+
+ CVS prints: I filename
+
+ You'll need to examine it to see if it *should* have been ignored. If
+ you use "-I !", nothing will be ignored.
+
+ Symbolic link.
+
+ CVS prints: L linkname
+
+ Links are "ignored", but you'll probably want to create a "checkout
+ helper" function to regenerate them.
+
+ New file.
+
+ CVS prints: N filename
+
+ CVS creates a new file in the Repository. You don't have to do
+ anything to the file, but you might have to change Makefiles to refer
+ to it if this is really a new file.
+
+ A file unchanged by the Vendor since its last release.
+
+ CVS prints: U filename
+
+ CVS will notice this and simply add the new ReleaseTag to the latest
+ rev on the Vendor branch.
+
+ No work will be needed by you, whether you have changed the file or
+ not. No one will notice anything.
+
+ A file changed by the Vendor, but not by you.
+
+ CVS prints: U filename
+
+ CVS should add the file onto the vendor branch and attach the Release
+ Tag to it.
+
+ When you next execute "update" in any working directory you'll get the
+ new revision.
+
+ A file changed by both the Vendor and by you.
+
+ CVS prints: C filename
+
+ These are the trouble files. For each of these files (or in groups --
+ I usually do one directory at a time), you must execute:
+
+ cvs update -j <PreviousReleaseTag> -j <ReleaseTag>
+ or
+ cvs update -j <VendorTag:yesterday> -j <VendorTag>
+
+ It will print either 'M' (if no overlaps) or 'C', if overlaps. If a
+ 'C' shows up, you'll need to edit the file by hand.
+
+ Then, for every file, you'll need to execute "cvs commit".
+
+ See the part of Section 4C dealing with branch merges.
+
+ If you are truly performing a large import, you will most likely
+ need help. Managing those people is another problem area.
+
+ Since the merge of the Vendor branch is just like any other merge, you
+ should read section 4C for more info about performing and cleaning up
+ merges.
+
+ The larger the import, and the larger the group of people involved,
+ the more often you should use "tag" and "rtag" to record even trivial
+ milestones. See 4C.14, especially the "paranoid" section.
+
+ Before starting the import, you should install and test a "commitinfo"
+ procedure to record all commits in a file or via Email to a mail
+ archive. Along with the tags you placed on the Repository before the
+ import, this archive will help to track what was changed, if problems
+ occur
+
+ There are four stages to the recovery:
+
+ Parcel out the work -- Effective Emacs Engineering.
+
+ As input to the assignment process, you might want to examine the tree
+ and record the last person who changed the file. You can also
+ research, if you don't already know, who is expert in each area of the
+ software.
+
+ Examine the import log (you saved the output, right?), estimate how
+ much work is involved in each area and assign groups of files to
+ individual developers. Unless some directory is immense, it is easier
+ to manage if you assign whole directories to one person.
+
+ Keep a list. Suggest a completion date/time. Tell them to "commit" the
+ file when they are finished with the merge. If you tagged the
+ Repository before starting the import, you should have no trouble
+ figuring out what happened.
+
+ If you can, find out (or tell them) which working directory to use.
+ You should verify that the working directory they use is on the Main
+ Branch ("update -A") and without modified files.
+
+ If you trust your crew, have them notify you by Email. Have them send
+ you the output from "cvs update" in their working directory. You might
+ have to poll some people until you are certain they have finished, or
+ have given up. (This is not an invention. I've heard a false, "Yeah,
+ sure. I finished yesterday," more times that you'd believe.)
+
+ When all reports are in, go on to the Source Verification stage.
+
+ Source Verification -- CVS and other Tools.
+
+ If you didn't dictate which ones to use, find all working directories
+ and run "cvs -n update" in all of them. The history command and the
+ "commitinfo" log you set up might help to find checked out working
+ directories.
+
+ Sticky conflict flags will help, but they can't recover from
+ sloppiness or incompetence. You might want to check everything out
+ into a tree and grep for the parts of the merge conflict markers CVS
+ doesn't look for. CVS looks for the string '^>>>>>>> '. The merge
+ operation also puts '^<<<<<<< ' and '^======= ' markers in the file
+ that careless developers might leave there.
+
+ If you find problems simply by looking at the source files and working
+ directories, start the flogging now. Resolving the textual conflicts
+ is the easy part. Weed the turkeys out before reaching the next part
+ of the cleanup -- the resolution of logical conflicts.
+
+ Then apply a set of post-commit tags.
+
+ Logical Verification -- Diff and powerful eyeballs.
+
+ No source control system can solve the problem of resolving
+ distributed conflicts in program logic. If you change the argument
+ template for function A (defined in file A.c) and add new calls to
+ function A from within function B (defined in file B.c) using the old
+ argument format, you are outside the realm of CVS's competence.
+
+ Assign someone to understand what the Vendor changed by running "cvs
+ diff -c -r <PreviousReleaseTag> <ReleaseTag>", where the tags were
+ those handed to the last two invocations of "import".
+
+ Then have the same person compare that output (logically or you can
+ actually diff the diffs) to the output of the similar "cvs diff -c -r
+ <pre-import-tag> <post-commit-tag>". The two sets of differences
+ should be almost identical. They should both show only the work *you*
+ have performed.
+
+ Product Verification -- Build and Test.
+
+ Don't let your help off the hook until you verify that the merge
+ actually produced something that can compile and pass tests. Compiling
+ should really be part of the logical verification phase, but you
+ should test the output of the build system before declaring victory
+ and releasing the troops.
+
+ After it is all built, apply another set of tags to mark the end of
+ the "import process". You can delete the intermediate tags you added
+ during source and logic testing, but keep the "pre-import" and
+ "post-import" tags forever.
+
+ Of course, experience can tell you when to skip a step. But I'd start
+ out by considering each one as necessary unless you can prove
+ otherwise.
+
+ Last modified: _6/13/1997_
+
+ 14. Explain: ERROR: cannot create link to <file>: Permission denied
+
+ This error appears when you try to execute a second (or later)
+ "import" into the same module from a directory to which you don't have
+ write access.
+
+ The "link error" is caused by a feature purposely added to speed up
+ the import.
+
+ Though the error message is somewhat strange, it indicates that
+ "import" is supposed to be executed only in writable directories.
+
+ Last modified: _6/13/1997_
+
+ 15. Where does the -m <message> go when the file doesn't change?
+
+ The <message> handed to import is used as an RCS log message, but only
+ if the imported file changed since the last version on the Vendor
+ branch. If the imported file hasn't changed, then no new revision is
+ created. The <ReleaseTag> is still applied, but to the previous
+ revision. So the Tags are still correct, but the message is lost.
+
+ Maybe it should be appended to the previous log message. But currently
+ it isn't.
+
+ Last modified: _6/13/1997_
+
+ 16. How do I "import" just the files ignored by a previous "import"?
+
+ A real answer follows, but first, an editorial:
+
+ I am now convinced that you should always use the "-I !" option.
+ Removing a few extraneous files from the Repository is a lot easier
+ than the recovery step described below.
+
+ Let's assume your original import procedure was: (We assume there is
+ enough disk space in /tmp.)
+
+ cd <head-of-vendor-tree>
+ cvs import -m 'xyz 1.3' gnu/xyz GNU GNUXYZ_1_3 | tee /tmp/IMP
+
+ To import just the files ignored by "import", I would do this:
+
+ Create a list of the ignored files to import:
+
+ cd <head-of-vendor-tree> awk '/^I / {print $2}' /tmp/IMP | sed
+ 's|^gnu/xyz/||' > /tmp/IG [Edit the IG file to contain just the files
+ you want.]
+
+ Then create a sparse directory by handing your list to the GNU
+ version of "tar", installed in many places as "gtar":
+
+ mkdir /tmp/FIXUP gtar -T /tmp/IG -c -f - . | (cd /tmp/FIXUP; gtar xvBf
+ -)
+
+ Then rerun the import. Use the exact same command, but execute it in
+ the sparse directory tree you just created. And this time, tell it not
+ to ignore anything.
+
+ cd /tmp/FIXUP
+ cvs import -I ! -m 'xyz 1.3' gnu/xyz GNU GNUXYZ_1_3
+
+ Last modified: _6/13/1997_
+
+ 17. Why did "import" ignore all the symlinks?
+
+ This is another design choice.
+
+ Like the Unix "tar" command, "import" could sprout an option to follow
+ symbolic links, but I don't think CVS will ever follow symbolic links
+ by default.
+
+ Two possible future enhancements have been seriously discussed:
+
+ Treat symbolic links as data in its parent directory (the way
+ ClearCase does) in some sort of per-directory control file.
+
+ Treat symbolic links as version-controlled elements themselves,
+ whose data is the value of readlink(2).
+
+ For now, they are simply ignored.
+
+ If you want to save and reconstruct symlinks, you might want to define
+ a "checkout" or "update" program in the modules file which could
+ consult a file kept under CVS in your working directory and make sure
+ the specified links are in place.
+
+ Last modified: _6/13/1997_
+
+ Category: /Commands_/log_lo_rlog/
+
+ " + "log", "lo", "rlog""
+
+ 1. What is "log" for?
+
+ To provide an interface to the RCS "rlog" command, which displays
+ information about the underlying RCS files, including the revision
+ history and Tag (RCS calls it a "symbol") list.
+
+ Last modified: _6/13/1997_
+
+ 2. How do I extract the log entries between two revisions?
+
+ If both <rev1> and <rev2> are on the same branch, you can get what you
+ are looking for with: (If they aren't on the same branch you'll either
+ get an error or a display of the whole change log.)
+
+ cvs log -r<rev1>:<rev2> <file>
+
+ If you want all the revisions on the branch from <rev1> to the end of
+ the branch <rev1> is on, you can use:
+
+ cvs log -r<rev1>: <file>
+
+ (If <rev1> is a numeric RCS symbol attached to a branch revision with
+ an even number of '.'s in it, you get the whole branch.)
+
+ If you want all the revisions on the branch from the beginning of the
+ branch <rev2> is on up to revision <rev2>, you can use:
+
+ cvs log -r:<rev2> <file>
+
+ Note: Depending on whether <rev1> and <rev2> are:
+
+ - numeric or symbolic
+ - in the file or not
+ - on the same branch or not
+
+ the RCS "rlog" (and therefore the "cvs log") command will
+ display some combination of:
+
+ - error messages
+ - (intuitively correct) partial log listings
+ - a display of the entire change log.
+
+ Last modified: _6/13/1997_
+
+ 3. How do I extract the log entries on a whole branch?
+
+ cvs log -r<rev> <file>
+
+ where <rev> must be a branch revision (one with an even number of
+ dots) or a *non-branch* tag on a branch revision. Non-branch tags on a
+ branch revision are not normally attached by CVS, to add one you will
+ have to explicitly tag a physical branch number within each file.
+ Since these branch numbers are almost never the same in different
+ files, this command is not all that useful.
+
+ The intuitive command (at least from the CVS perspective):
+
+ cvs log -r<branch_tag> <file>
+
+ does not work.
+
+ Last modified: _6/13/1997_
+
+ 4. How do I generate ChangeLogs from RCS logs?
+
+ A program called rcs2log is distributed as part of GNU Emacs 19. A
+ (possibly older) version of this program appears in the contrib
+ directory of the cvs source tree.
+
+ Last modified: _6/13/1997_
+
+ 5. Why does "log" tell me a file was committed exactly 5 hours later
+
+ than I know it was?
+
+ I can tell by this question that you were working in a time zone that
+ is 5 hours behind GMT (e.g. the U.S. East Coast in winter).
+
+ RCS file dates are stored in GMT to allow users in different time
+ zones to agree on the meaning of a timestamp. At first glance this
+ doesn't seem necessary, but many companies use distributed file
+ systems, such as NFS or AFS, across multiple timezones.
+
+ Some standard form must be used. GMT, as the "grid origin", is an
+ obvious candidate. The only other reasonable choice is to put the
+ timezone information in all the time stamps, but that changes the RCS
+ file format incompatibly, a step which has been avoided in the last
+ few RCS releases.
+
+ Last modified: _6/13/1997_
+
+ Category: /Commands_/patch_pa_rdiff/
+
+ " + "patch", "pa", "rdiff""
+
+ 1. What is "patch" for?
+
+ To produce a "diff" between tagged releases to be handed to the
+ "patch" command at other sites. This is the standard way that source
+ patches are distributed on the network.
+
+ Last modified: _6/13/1997_
+
+ 2. Why does "patch" include files from the Attic when I use '-D'?
+
+ See the explanation of the same problem with "update -D" contained in
+ section 5B.
+
+ Last modified: _6/13/1997_
+
+ 3. How do I make "patch" produce a patch for one or two files? It seems to
+ work only with modules.
+
+ Patch is intended for producing patches of whole modules between
+ releases to be distributed to remote sites. Instead of "patch", you
+ can use the "diff" command with the '-c' context option:
+
+ cvs diff -c -r <rev/tag> -r <rev/tag> <file1> . . .
+
+ The patch command will be able to merge such a "diff" into the remote
+ source files.
+
+ If you configured CVS to use a version of "diff" that supports the
+ '-u' option, you can produce a more compact "patch" in "unidiff"
+ format. The latest revisions of the patch command can parse and apply
+ patches in "unidiff" format.
+
+ Last modified: _6/13/1997_
+
+ Category: /Commands_/release_re_rel/
+
+ " + "release", "re", "rel""
+
+ 1. What is "release" for?
+
+ To register that a module is no longer in use. It is intended to
+ reverse the effects of a "checkout" by adding a record to the history
+ file to balance the checkout record and by optionally allowing you to
+ delete the checked-out directory associated with the module name.
+
+ Last modified: _6/13/1997_
+
+ 2. Why can't I reverse a "cvs checkout path/name/subdir" with a "cvs
+ release path/name/subdir" without an "unknown module name"?
+
+ A simplistic implementation. (I can say this -- I wrote it.)
+
+ The "release" function was written for CVS 1.2 under the assumption
+ that the "module name" is a first class, unavoidable interface to the
+ Repository, allowing no way to retrieve anything other than by module
+ name. Though it is easier to program that way, many users of CVS
+ believe the modules support to be too primitive to allow such a
+ limitation.
+
+ Since "release" was written, other parts of CVS broke that assumption.
+ It needs to be revised.
+
+ Last modified: _6/13/1997_
+
+ 3. Why can't I "release" portions of a checked out directory? I should be
+ able to "release" any file or sub-directory within my working directory.
+
+ This isn't really a limitation in "release", per se. CVS doesn't try
+ to keep track of which files in which directories are "checked out"
+ and which are just lying there. You can delete directories and
+ "update" will not bring them back unless you add a special "-d"
+ option.
+
+ In other words, CVS doesn't keep track of how you adjust the partition
+ between files you consider part of your working set and files that
+ were checked out because they are part of the same module or
+ directory. And neither does "release".
+
+ In future CVS releases, "release" might become sophisticated enough to
+ handle both the reversal of a "checkout" and the deletion of random
+ portions of the working directory, but it isn't that way now.
+
+ Last modified: _6/13/1997_
+
+ 4. I removed the tree that I was about to start working on. How do I tell
+ cvs that I want to release it if I don't have it anymore?
+
+ See 3G.4.
+
+ Last modified: _6/13/1997_
+
+ 5. Why doesn't "release -d module" reverse a "checkout module"?
+
+ It does, if you are using "module" in a way that "release" expects: a
+ non-alias string in the left column of the "modules" database.
+
+ If "module" is really an alias, or if you are using a relative path in
+ the place of "module", or if you renamed the directory with the -d
+ option in the modules file or on the "checkout" command line, then the
+ current version of "release" won't work.
+
+ Future versions of "release" will probably fix most of these.
+
+ Last modified: _6/13/1997_
+
+ 6. Why can't I release a module renamed with "cvs checkout -d"?
+
+ The current version of "release" doesn't know how to track the
+ renaming option ('-d') of the "checkout" command. It will probably be
+ fixed in the future.
+
+ Last modified: _6/13/1997_
+
+ Category: /Commands_/remove_rm_delete/
+
+ " + "remove", "rm", "delete""
+
+ 1. What is "remove" for?
+
+ To remove a file from the working branch. It removes a file from the
+ main branch by placing it in an "Attic" directory.
+
+ Last modified: _6/13/1997_
+
+ 2. Why doesn't "remove" work on directories when it appears to try?
+
+ Oversight. It should be able to delete an empty directory, but you
+ still don't have a way to remember when it was there and when it
+ disappeared to allow the "-D " option to work.
+
+ You'll have to remove the working directory and the matching directory
+ in the Repository.
+
+ Note that you want to do a _cvs remove dir_ in the working directory,
+ do a cvs commit, and then do a _rmdir dir_ in the Repository.
+ (msusrtsp.mark at eds dot com)
+
+ Last modified: _12/18/1997_
+
+ 3. I don't like removing files. Is there another way to ignore them?
+
+ There's no reason to be hasty in using the "remove" command.
+
+ If there is a way to ignore files in your build procedures, I'd just
+ do that. Later, when you decide that the files are really ancient, you
+ can execute a "remove" command to clean up.
+
+ The CVS "ignore" concept can't ignore files already in CVS.
+
+ Last modified: _6/13/1997_
+
+ 4. I just removed a file. How do I resurrect it?
+
+ If you executed "remove", but haven't typed "commit" (you can tell
+ this by the 'R' notation that "update" prints next to the file), you
+ can execute "add" to reverse the "remove".
+
+ If you followed the "remove" with a "commit", you'll have to move it
+ back out of the Attic by hand:
+
+ I use something like this: (csh-like syntax)
+
+ set repos = `cat ./CVS/Repository`
+ mv $repos/Attic/filename,v $repos/filename,v
+
+ (If you use relative paths in your Repository files, that first line
+ becomes: set repos = $CVSROOT/`cat ./CVS/Repository`)
+
+ While a file is in the Attic, you can't "add" another file by the same
+ name. To add such a file you either have to move it by hand as in the
+ above, or delete it from the Attic.
+
+ The main reason for the Attic is to retain files with tags in them. If
+ you execute: "update -r <oldtag>", files with <oldtag> attached to
+ some revision will be taken from the normal Repository area and from
+ the Attic. That's why you can't "add" a file with the same name.
+ "remove" only moves a file off the main branch, it doesn't obliterate
+ it.
+
+ Last modified: _6/13/1997_
+
+ 5. Why doesn't "remove" delete the file? Instead, it prints an error
+ message and tells me to remove the file by hand.
+
+ Design choice. Unix software written within last decade, usually
+ requires an extra verification step, such as answering a question or
+ adding a flag on the command line. CVS currently requires that you
+ delete the file first unless you specify the '-f' (force) option,
+ which deletes the file before performing "cvs remove".
+
+ Last modified: _6/13/1997_
+
+ Category: /Commands_/rtag_rt_rfreeze/
+
+ " + "rtag", "rt", "rfreeze""
+
+ 1. What is "rtag" for?
+
+ To add a symbolic label (a "tag") to the last committed revisions of a
+ module directly in the Repository.
+
+ Last modified: _6/13/1997_
+
+ 2. Why use "rtag"? It assumes no one is changing the Repository.
+
+ Though the "tag" command is more useful in marking the revisions you
+ have in a particular working directory, "rtag" is much handier for
+ whole-Repository actions, which occur at major release boundaries.
+
+ Last modified: _6/13/1997_
+
+ 3. What revision does "rtag -r <tag1> <tag2>" actually put the tag on?
+
+ In short, the '-r' option is another way to select the revision to
+ tag. The revision is selected the same way for all commands that
+ accept a "-r <tag/rev>" option.
+
+ Depending on whether <tag1> is a <branch_tag>, or a non-branch <tag>
+ and on whether you use the '-b' option to "rtag", you get four
+ different results:
+
+ rtag -r <tag1> <tag2>
+
+ Adds the non-branch tag <tag2> to the same revision that the
+ non-branch tag <tag1> is attached to.
+
+ Example:
+ <tag1> --> TT1
+ <tag2> --> TT2
+ <file> --> Symbols: TT1:1.4
+ After --> Symbols: TT1:1.4,TT2:1.4
+
+ rtag -r <branch_tag1> <tag2>
+
+ Adds the non-branch tag <tag2> to the HEAD of (the highest revision
+ number on) the branch labelled with tag <branch_tag1>.
+
+ Example:
+ <branch_tag1> --> BR1
+ <tag2> --> TT2
+ <file> --> Symbols: BR1:1.2.0.2 (1.2.2.5 is HEAD)
+ After --> Symbols: BR1:1.2.0.2,TT2:1.2.2.5
+
+ If the branch tagged by <branch_tag1> has not been created, then the
+ tag shows up on the branch point revision:
+
+ Example:
+ <branch_tag1> --> BR1
+ <tag2> --> TT2
+ <file> --> Symbols: BR1:1.2.0.2 (No 1.2.X exists.)
+ After --> Symbols: BR1:1.2.0.2,TT2:1.2
+
+ rtag -b -r <tag1> <branch_tag2>
+
+ Adds the magic branch tag <branch_tag2> to the revision that the
+ non-branch tag <tag1> is attached to, preparing it to be a branch
+ point.
+
+ Example:
+ <tag1> --> TT1
+ <branch_tag2> --> BR2
+ <file> --> Symbol: TT1:1.4
+ After --> Symbol: TT1:1.4, BR2:1.4.0.2
+
+ rtag -b -r <branch_tag1> <branch_tag2>
+
+ Adds the magic branch tag <branch_tag2> to the revision at the HEAD of
+ (the highest revision number on) the branch labelled with
+ <branch_tag1>, preparing it to be a branch point.
+
+ Example:
+ <branch_tag1> --> BR1
+ <branch_tag2> --> BR2
+ <file> --> Symbol: BR1:1.2.0.2 (1.2.2.5 is HEAD)
+ After --> Symbol: BR1:1.2.0.2,BR2:1.2.2.5.0.2
+
+ If the branch tagged by <branch_tag1> has not been created, then the
+ tag shows up as a second branch off the same branch point revision:
+
+ Example:
+ <branch_tag1> --> BR1
+ <tag2> --> TT2
+ <file> --> Symbols: BR1:1.2.0.2 (No 1.2.X exists.)
+ After --> Symbols: BR1:1.2.0.2,TT2:1.2.0.4
+
+ In all four cases above, if <tag2> already exists on the file, you get
+ an error unless you specify the '-F' option.
+
+ In all four cases, if <tag1> does not exist on the file, <tag2> is not
+ added unless you specify the '-f' option.
+
+ Last modified: _6/13/1997_
+
+ 4. What happens if the tags are the same in "rtag -r <tag> <tag>"?
+
+ Again, there are four cases depending on whether <tag> is a branch
+ tag, or a non-branch tag and on whether you use the '-b' option to
+ "rtag":
+
+ rtag -r <tag> <tag>
+
+ Is a no-op. It does nothing even with '-F' specified.
+
+ If you add the '-f' option ("rtag -f -r <tag> <tag>"), then <tag> is
+ attached to the latest revision on the Main Branch if the file does
+ *not* already have <tag> on some revision.
+
+ If the <tag> is already on the file, using "rtag -f" is still a no-op.
+
+ rtag -r <branch_tag> <branch_tag>
+
+ Produces an error, since the <branch_tag> is already on some revision
+ of the file.
+
+ But, "rtag -F -r <branch_tag> <branch_tag>" turns the magic branch tag
+ into a non-branch tag.
+
+ Symbols: BR1:1.4.0.2 becomes Symbols: BR1:1.4
+
+ rtag -b -r <tag> <tag>
+
+ Produces an error, since the <tag> is already on the file.
+
+ But, "rtag -F -b -r <tag> <tag>" turns the non-branch tag into a magic
+ branch tag.
+
+ Symbols: BR1:1.4 becomes Symbols: BR1:1.4.0.2
+
+ rtag -b -r <branch_tag> <branch_tag>
+
+ Produces an error, since the <branch_tag> is already on the file.
+
+ But, "rtag -F -b -r <branch_tag> <branch_tag>" increments the branch
+ number. It essentially removes the branch and creates a new one by the
+ same name.
+
+ Symbols: BR1:1.2.0.4 becomes Symbols: BR1:1.2.0.6
+
+ Last modified: _6/13/1997_
+
+ 5. Why doesn't "rtag -b -r <branch_tag1> <branch_tag2>" rename or duplicate
+ a magic branch tag?
+
+ None of the "tag" or "rtag" options rename anything. They only apply
+ (or, with the '-F' option, move) tags to specific revisions in the
+ file.
+
+ See 3M.[3-4] above for details of how it works.
+
+ To rename a non-branch tag, see 3O.9. To rename a magic branch tag,
+ see 4D.5
+
+ Last modified: _6/13/1997_
+
+ Category: /Commands_/status_st_stat/
+
+ " + "status", "st", "stat""
+
+ 1. What is "status" for?
+
+ To display the status of files, including the revision and branch you
+ are working on and the existence of "sticky" information.
+
+ Last modified: _6/13/1997_
+
+ 2. Why does "status" limit the File: at the top to 17 characters?
+
+ Designed that way to line up with other data. You can find the whole
+ filename in the line beginning with "RCS version:", which is not
+ limited in length.
+
+ Last modified: _6/13/1997_
+
+ 3. Why does it print "Sticky" lines when the values are "(none)"?
+
+ Oversight. It should probably elide lines without information.
+
+ Last modified: _6/13/1997_
+
+ 4. Shouldn't the status "Needs Checkout" be "Needs Update"?
+
+ Probably.
+
+ [[Did this show up in CVS 1.4?]]
+
+ Last modified: _6/13/1997_
+
+ Category: /Commands_/tag_ta_freeze/
+
+ " + "tag", "ta", "freeze""
+
+ 1. What is "tag" for?
+
+ To add a symbolic label (a "tag") to the RCS files last checked out,
+ updated or committed in a working directory.
+
+ Last modified: _6/13/1997_
+
+ 2. What is the difference between "tag" and "rtag"?
+
+ The end result of both commands is that a <tag>, or symbolic name, is
+ attached to a single revision in each of a collection of files.
+
+ The differences lie in:
+
+ The collection of files they work on.
+
+ "rtag" works on the collection of files referred to by a "module" name
+ as defined in the "modules" file, or a relative path within the
+ Repository.
+
+ "tag" works on files and directories specified on the command line
+ within the user's working directory. (Default is '.')
+
+ Both commands recursively follow directory hierarchies within the
+ named files and directories.
+
+ The revisions they choose to tag.
+
+ "rtag" places a tag on the latest committed revision of each file on
+ the branch specified by the '-r' option. By default it tags the Main
+ Branch.
+
+ "tag" places a tag on the BASE (i.e. last checked out, updated or
+ committed) revision of each file found in the working directory. (The
+ BASE revision of a file is the one stored in the ./CVS/Entries file.)
+
+ A different set of command line options.
+
+ For example, "rtag" takes a "-r <oldtag>" option to retag an existing
+ tag. The "tag" command does not.
+
+ How it is logged.
+
+ Currently "rtag" records the <tag> and the module in the "history"
+ file, while "tag" does not.
+
+ Last modified: _6/13/1997_
+
+ 3. Why does "tag -b" not put a tag on the Branch Point revision? How do I
+ refer to the Branch Point?
+
+ This is probably an oversight, or a disbelief in the need for it. If
+ everything works perfectly, the "update -j" command will do the merge
+ you need and you don't need to check up on it by playing with the
+ branch point revision.
+
+ The '-b' option attaches a magic branch tag to allow CVS later to
+ figure out the branch point. The actual revision that <tag> is
+ attached to does not exist. References to the branch tag are
+ equivalent to references to the latest revision on the branch.
+
+ There is no way to refer to the branch point without adding a
+ non-branch tag. You might want to add non-branch tags as a habit and
+ add branch tags later, possibly immediate after adding the non-branch
+ tag. See 4C.3 on Creating a Branch.
+
+ Last modified: _6/13/1997_
+
+ 4. So "{r}tag" labels a bunch of files. What do you use a Tag for?
+
+ You use it to "checkout" the labeled collection of files as a single
+ object, referring to it by name.
+
+ Anywhere a revision number can be used a Tag can be used. In fact tags
+ are more useful because they draw a line through a collection of
+ files, marking a development milestone.
+
+ The way to think about a Tag is as a curve drawn through a matrix of
+ filename vs. revision number. Consider this:
+
+ Say we have 5 files (in some arbitrary modules, some may be in 2 or
+ more modules by name, some may be in 2 or more modules because of the
+ Repository tree structure) with the following revisions:
+
+ file1 file2 file3 file4 file5
+
+ 1.1 1.1 1.1 1.1 /--1.1* <-*- <tag>
+ 1.2*- 1.2 1.2 -1.2*-
+ 1.3 \- 1.3*- 1.3 / 1.3
+ 1.4 \ 1.4 / 1.4
+ \-1.5*- 1.5
+ 1.6
+
+ At some time in the past, the '*' versions were tagged. Think of the
+ <tag> as a handle attached to the curve drawn through the tagged
+ revisions. When you pull on the handle, you get all the tagged
+ revisions. Another way to look at it is that you draw a straight line
+ through the set of revisions you care about and shuffle the other
+ revisions accordingly. Like this:
+
+ file1 file2 file3 file4 file5
+
+ 1.1
+ 1.2
+ 1.1 1.3 _
+ 1.1 1.2 1.4 1.1 /
+ 1.2*----1.3*----1.5*----1.2*----1.1 (--- <-- Look here
+ 1.3 1.6 1.3 \_
+ 1.4 1.4
+ 1.5
+
+ I find that using these visual aids, it is much easier to understand
+ what a <tag> is and what it is useful for.
+
+ Last modified: _6/13/1997_
+
+ 5. How do I get "tag" and "rtag" to send mail the way "commit" does?
+
+ The "commit" command is supported by two files ("commitinfo" and
+ "loginfo") not used by other commands. To do logging the same way for
+ "tag" and "rtag" would require another file like loginfo, which
+ currently doesn't exist.
+
+ The "rtag" command requires a "module" entry, which can specify a
+ "tag" program using the "-t programname" option on the module line.
+
+ There is no equivalent support for "tag".
+
+ Last modified: _6/13/1997_
+
+ 6. Why can't "tag" handle the '-r' option that "rtag" takes?
+
+ Oversight. The answer is probably "Fixed in a Future Release."
+
+ Last modified: _6/13/1997_
+
+ 7. After a "tag <tag>" in my working directory, why doesn't "checkout -r
+ <tag>" somewhere else produce copies of my current files?
+
+ The only reason this would fail, other than misspelling the <tag>
+ string, is that you didn't "commit" your work before "tagging" it.
+ Only committed revisions may be tagged. Modified files are not marked
+ for later tagging.
+
+ Last modified: _6/13/1997_
+
+ 8. Why doesn't "tag" write a history record the way "rtag" does?
+
+ The "rtag" command was originally intended to place major "release"
+ tags onto modules. The "tag" functionality was developed to *move* the
+ more significant tag when slight changes to individual files sneaked
+ in after the release tag was stamped onto the Repository.
+
+ The significant event was the "rtag", which was recorded in the
+ "history" file for the "history -T" option to work.
+
+ It turns out that "tag" is generally more useful than "rtag", so the
+ model has changed. Future revisions of CVS will probably store both
+ kinds of tags in the history file.
+
+ Last modified: _6/13/1997_
+
+ 9. How do I rename a <tag>?
+
+ For a procedure to rename a branch tag, See section 4D.5 The following
+ covers only non-branch tags.
+
+ First, pick a <newtag> that is not in use. You could reuse (i.e. move)
+ an existing tag to the new revisions using the '-F' option, but that
+ will confuse matters when both tags are not already on a file. (It
+ will probably confuse "rtag -f" too.)
+
+ Use "rtag" to place <newtag> only on revisions attached to <oldtag> in
+ the whole Repository, then delete the old one.
+
+ cvs rtag -r <oldtag> <newtag> world
+ cvs rtag -d <oldtag> world.
+
+ You can also checkout or update your working directory to the <oldtag>
+ and "tag" rather than "rtag" the result. But that will take longer and
+ it has the chance of producing conflicts.
+
+ cvs update -r <oldtag>
+ cvs tag <newtag>
+ cvs tag -d <oldtag>
+ cvs update -A (or cvs update -r <previous_tag>)
+
+ Last modified: _6/13/1997_
+
+ Category: /Commands_/update_up_upd/
+
+ " + "update", "up", "upd""
+
+ 1. What is "update" for?
+
+ The "update" command is by far the most important command and is
+ probably also the most used command.
+
+ It has five purposes: (And many options.)
+
+ To display the status of your working files.
+
+ Though a plain "update" also displays the status, it does so after
+ possibly altering your working directory. To see the status of your
+ working files without changing anything, type:
+
+ cvs -n update {optional list of files}
+
+ To merge changes made by others to the branch you are working on
+ into your working files.
+
+ Each working directory is attached to a branch, usually the Main
+ branch. To merge changes made on your working branch since your last
+ checkout, update or commit, type:
+
+ cvs update {optional list of files}
+
+ To merge changes made on another branch into the branch you are
+ working on (your "working branch").
+
+ If you want to grab a whole branch, from the branch point, which is
+ assumed to be on the Main Branch, to the end of the branch, you type:
+
+ cvs update -j <branch_tag> {optional files}
+
+ If you want to grab the changes made between two tags or revisions,
+ you type:
+
+ cvs update -j <tag1> -j <tag2> {optional files}
+
+ (If you are working with a single file, the Tags could also be
+ revisions numbers. Unless you take great care to match revision
+ numbers across different files (a waste of time given the way Tags
+ work), using revision numbers in place of the Tags for multiple files
+ would be meaningless.)
+
+ To move your working directory to another branch.
+
+ A working directory is presumed to be attached to (or working on) a
+ particular branch, usually the Main branch. To alter what CVS believes
+ to be your working branch, you "move" to that branch.
+
+ To move to a tagged branch, type:
+
+ cvs update -r <branch_tag> {optional files}
+
+ To move to the Main Branch, type:
+
+ cvs update -A {optional files}
+
+ If you have modified files in your working directory, this is not a
+ clean move. CVS will attempt to merge the changes necessary to make it
+ look like you made the same changes to the new branch as you made in
+ the old one. But if you do this twice without resolving the merge
+ conflicts each time, you can lose work.
+
+ To retrieve old revisions of files.
+
+ This option is similar to 4 above but you are not restricted to using
+ a <branch_tag>. You may specify any revision or <tag> with '-r' and
+ get the specified revision or the tagged revision:
+
+ cvs update -r <tag/rev> {optional files}
+
+ Or you may specify any date with '-D':
+
+ cvs update -D <date> {optional files}
+
+ The '-p' option sends the revisions to standard output (normally your
+ terminal) rather than setting the "sticky" tag and changing the files.
+
+ Last modified: _6/13/1997_
+
+ 2. What do 'U', 'M' and 'C' mean when I type "update"? Are they different
+ for "cvs -n update"?
+
+ "cvs update" merges changes made to the Repository, since your last
+ "checkout", "update" or "commit", into your working files. You can
+ think of it as changing your BASE revision.
+
+ "cvs update" prints lines beginning with:
+
+ 'U' after replacing your unmodified file with a different
+ revision from the Repository.
+
+ 'M' for two different reasons:
+
+ for files you have modified that have not changed in the Repository.
+
+ after a merge, if it detected no conflicts.
+
+ 'C' after a merge, if it detected conflicts. See 2D.7 and 3P.6 for
+ more info on conflict resolution and "sticky conflicts."
+
+ "cvs -n update" shows what it *would* do, rather than doing it. Or,
+ another way of looking at it, "cvs -n update" displays the
+ relationship between your current BASE revisions (identified in your
+ ./CVS/Entries file) and the HEAD revisions (the latest revisions in
+ the Repository).
+
+ "cvs -n update" prints lines beginning with:
+
+ 'U' for files you have not modified that have changed in the
+ Repository.
+
+ 'M' for files you have modified that have not changed in the
+ Repository.
+
+ 'C' for files you have modified that have also been changed in the
+ Repository.
+
+ See 4C.6 for what the letters mean when merging in from another
+ branch. The output is almost the same for a normal update if you
+ consider the Repository as the branch and your working directory as
+ the "trunk".
+
+ Last modified: _6/13/1997_
+
+ 3. What's the difference between "update" and "checkout"?
+
+ See 3C.4 above.
+
+ Last modified: _6/13/1997_
+
+ 4. Why don't I get new files when I execute "update"?
+
+ There are six reasons for nothing to happen during an "update":
+
+ Nothing on your branch changed in the Repository.
+
+ If no one has committed anything to the branch you are working on
+ (normally the Main branch) since the last time you executed
+ "checkout", "update" or "commit", nothing will happen.
+
+ It's like shouting "xyzzy" or "plugh" in the wrong room.
+
+ You have a "sticky" non-branch <tag> or <date> attached to the
+ working files you are trying to "update".
+
+ At some time in the past you checked out or updated your directory
+ with the "-r <tag>" or "-D <date>" option. Until you do it again with
+ a different tag or date, or go back to the Main Branch with "update
+ -A", you will never again see any updates.
+
+ The ./CVS/Entries.Static file exists and you are expecting a new
+ file.
+
+ If your ./CVS administrative directory contains a file named
+ Entries.Static, no files will be checked out that aren't already in
+ the Entries or Entries.Static file.
+
+ You forgot to use the '-d' option and are looking for new
+ directories.
+
+ If you execute "update" without the '-d' option, it will not create
+ new directories that have been added to the Repository.
+
+ You typed "update" instead of "cvs update".
+
+ On most Unix systems, your disk caches are now furiously being flushed
+ by multiple update daemons, destroying performance and proving to
+ management that you need more CPU power. :-)
+
+ On HP systems you might be asked what package you want to install from
+ the "update server".
+
+ Someone removed (using "admin -o") your BASE revision (the revision
+ CVS thought you had in your working directory), then committed a
+ "replacement". CVS is now confused because the revision in the
+ Repository matches your BASE revision when the files themselves don't
+ match. See 3B.6.
+
+ Last modified: _6/13/1997_
+
+ 5. Why does "update" say 'M' both for plain modified files and for
+ successful (i.e. conflict-free) merges? Aren't they different?
+
+ A design choice. Yes, they are different internally, but that
+ shouldn't matter. Your files are in the same condition after the
+ "update" as they were before -- a "diff" will display only your
+ modifications. And you are expected to continue onward with parts two
+ and three of the normal development cycle: "emacs" (a synonym for
+ "edit" in most of the civilized world) and "commit".
+
+ Last modified: _6/13/1997_
+
+ 6. What's a "sticky conflict"? How does it know a conflict occurred?
+
+ When a "cvs update" (or an "update -j") creates a conflict, it prints
+ a 'C' and stores the timestamp of the file after the merge in a
+ special field in the ./CVS/Entries file.
+
+ This conflict indication implies that the merge command altered your
+ working file to contain conflict markers surrounding the overlapping
+ code segments. For example, say that
+
+
+ - Two developers acquire revision 1.2 of <file> via "checkout" or
+ "update".
+
+
+ - Developer A changes line 1 from "9999" to "5555", then commits the
+ file, creating revision 1.3.
+
+
+ - Developer B changes line 1 from "9999" to "7777", then tries to
+ commit the file, but is blocked because the file is not up to date.
+ Developer B then runs "update" and sees the conflict marker 'C'. The
+ beginning of the file would look like this:
+
+ <<<<<<< <file> The working <file> in question.
+ 7777 Change made to the working <file>.
+ =======
+ 5555 Change made in the first commit (1.3)
+ >>>>>>> 1.3 The revision created by the first commit.
+
+ The conflict is "sticky", which means that until the conflict is
+ cleared, the "update" command will continue to display the file's
+ status as 'C' and the "status" command will show the file's status as
+ "Unresolved Conflict".
+
+ Until the conflict is cleared, "commit" is blocked for this file.
+
+ The sticky conflict indicator can be cleared by:
+
+ Resolving the conflict by editing the file. Two things must happen
+ before the conflict is considered resolved:
+
+ The timestamp of the file must change. *and* The file must contain no
+ conflict markers. (The string searched for in the file is the regexp:
+ "^>>>>>>> ".)
+
+ After clearing the sticky conflict indicator, you may then commit the
+ file normally.
+
+ Removing the file and running "update". This throws away the local
+ changes and accepts the latest committed file on this branch. No
+ commit is needed.
+
+ Forcing the commit to happen by using "commit -f". This is probably
+ a mistake since there are few lines of real text that begin with
+ ">>>>>>> ".
+
+ Last modified: _6/13/1997_
+
+ 7. Is there a feature to tell me what I have changed, added and removed
+ without changing anything?
+
+ The command "cvs -n update" will do exactly that.
+
+ Last modified: _6/13/1997_
+
+ 8. Why were all my files deleted when I executed "update"?
+
+ You probably executed "update -r <tag>" some time ago, then removed
+ <tag> from the Repository files. "update -r <tag>" will delete a file
+ that doesn't contain <tag>.
+
+ A way to fix this is to "cd" into your working directory and type:
+
+ cvs update -A
+
+ If you don't want the latest revisions on the Main (or Vendor) Branch,
+ then decide what Tag (normal or branch) you want and type:
+
+ cvs update -r <the_tag_you_want>
+
+ Another way to make a file disappear is to execute "update -D <date>"
+ where <date> is before the date stamped onto the first revision in the
+ RCS file.
+
+ Last modified: _6/13/1997_
+
+ Category: /Past__Future_/
+
+ " Past & Future "
+
+ Category: /Past__Future_/Bugs_and_Patches/
+
+ " + Bugs and Patches"
+
+ 1. Why can't CVS handle deletion of directories?
+
+ An oversight, probably. [[Fixed in a future release?]]
+
+ Last modified: _6/13/1997_
+
+ 2. Why can't CVS handle the moving of sources from one place in the
+
+ directory hierarchy to another?
+
+ A "renaming database" has been proposed to track the history of
+ pathname changes in the Repository. A general solution is a difficult
+ problem. See 4B.8.
+
+ Last modified: _6/13/1997_
+
+ 3. When I typed "cvs update -D <date>", why did it check out all
+
+ sorts of ancient files from the Attic? Shouldn't it just create the
+ set of files and revisions that existed at that date?
+
+ This seems to be a bug, but is really the lack of any obvious place to
+ store the date when a file is "removed".
+
+ There are four ranges of dates that CVS has to deal with when trying
+ to determine what revision was available on <date>:
+
+ Dates before the earliest revision in the file.
+
+ Dates between any two revisions in the file.
+
+ Dates between the latest revision in the file and the date when the
+ file was moved to the Attic by "commit".
+
+ Dates after moving the file to the Attic.
+
+ Since the date when a file is moved to the Attic is not stored
+ anywhere, CVS can't tell the difference between #3 and #4. To avoid
+ not producing a file that should exist in case #3, it produces
+ extraneous files in case #4.
+
+ For the above reason, if you have removed files in the Attic, it is
+ better to use "-r <tag>, or even "-r HEAD" than to use a date spec.
+
+ If you must use "-D <date>", then you should either archive and delete
+ Attic files (losing some past history) or construct your Makefiles to
+ work with an explicit list of files and let the old source files stay
+ in the working directory. The contents of the revision-controlled
+ Makefile can then be considered to contain deletion "information".
+
+ Last modified: _6/13/1997_
+
+ 4. When I typed "cvs update -D <date>" in my branch, why did it screw up
+ all my files?
+
+ Currently, the internal routine ("version_ts") that looks up info
+ about a file, overrides both the tag and date if *either* the tag or
+ date is specified on the command line. If only the date is specified,
+ it should not override a branch tag, but it does.
+
+ In CVS 1.3, the documented "-D <branch_tag>:<date>" syntax only works
+ with the Main Branch and the Vendor Branch.
+
+ [[Is this fixed in CVS 1.4? This is one item I didn't check.]]
+
+ Last modified: _6/13/1997_
+
+ 5. When I executed "checkout" into an existing directory I got "No such
+ file or directory" errors. Why?
+
+ Though the man page says that "checkout" turns into an "update -d" in
+ directories that already exist, it is referring to directories that
+ already exist *and* were created by CVS.
+
+ When you try to run "checkout" on top of an existing directory
+ structure, some of which wasn't created by CVS, it will handle
+ directories and non-CVS files within directories already under CVS,
+ but it will display the above error on non-CVS files within non-CVS
+ directories.
+
+ Last modified: _6/13/1997_
+
+ 6. Why does "update" send all output to the terminal after 26 files have
+ been updated?
+
+ CVS uses the "tmpnam()" function to generate temporary file names. The
+ ANSI standard for the "tmpnam()" function says:
+
+ "The tmpnam function generates a different string each time it is
+ called, up to TMP_MAX times. If it is called more than TMP_MAX times,
+ the behavior is implementation defined."
+
+ Later it says that the value of "TMP_MAX shall be at least 25."
+
+ On some platforms, the above specification is taken literally by
+ turning "at least 25" into "exactly 26" and by doing something foolish
+ (i.e. "implementation defined") after that. Some systems return the
+ same name repeatedly, which causes one form of trouble. Others return
+ NULL or garbage, which causes a different form of trouble.
+
+ The broken systems appear to be cycling a single character through the
+ alphabet. SunOS cycles 3 characters through the alphabet, so it won't
+ cause trouble until 26 cubed or 17576 calls to "tmpnam()".
+
+ Since CVS doesn't depend on the exact format of the tmp files, the
+ workaround is to provide a "tmpnam()" that doesn't have a limit on the
+ number of calls to it.
+
+ Last modified: _6/13/1997_
+
+ 7. Why does the merge occasionally resurrect lines of code?
+
+ The diff3 program provided by GNU diff version 1.15 has a bug that
+ occasionally causes text to come back from the dead.
+
+ This is an old problem which you can avoid by upgrading to the latest
+ GNU "diffutils" package. If you were using GNU diff version 1.15 and
+ plan to upgrade to the latest GNU diff program, see the next question.
+
+ Last modified: _6/13/1997_
+
+ 8. Why does the merge fail when my "rcsmerge" program is configured to use
+ GNU diff version 2.1 or later?
+
+ A change in the overlap format was introduced in GNU diff3 between
+ versions 2.0 and 2.1 that causes RCS versions before 5.6.0.1 to fail
+ during a merge.
+
+ To get consistent rcsmerge behavior, you have four choices:
+
+ Go back to using GNU diff 1.15 or 2.0 with RCS versions 5.5 or 5.6.
+ If you want to use GNU diff 2.1 or later, you'll have to pick one of
+ the other three choices in this list.
+
+ Grab RCS version 5.6.0.1 from an FSF archive and set the DIFF3_A
+ macro to '1' as it tells you to in the Makefile:
+
+ #define DIFF3_A 1
+
+ Patch the RCS 5.6 source. Change line 84 in "merger.c" from:
+
+ DIFF3, "-am", "-L", label[0], "-L", label[1], to DIFF3, "-amE", "-L",
+ label[0], "-L", "", "-L", label[1],
+
+ Wait both for RCS version 5.7 to be released and for a new version
+ of CVS that can deal with it.
+
+ Last modified: _6/13/1997_
+
+ Category: /Past__Future_/Contributors/
+
+ " + Contributors"
+
+ 1. Who wrote CVS?
+
+ Brian Berliner <berliner@sun.com> converted a collection of scripts
+ written by Dick Grune <dick@cs.vu.nl> into a C program, then added all
+ sorts of features. He continues to maintain CVS.
+
+ Jeff Polk <polk@bsdi.com> wrote much of the code added between
+ revisions 1.2 and 1.3. Many others were involved at some level.
+
+ david d zuhn <zoo@armadillo.com> fixed a number of bugs, added some of
+ the new features, reworked the whole thing to be more portable, and
+ provided much of the energy to push CVS 1.4 out the door.
+
+ Jim Kingdon implemented CVS 1.5's remote repository access features,
+ fixed many bugs, and managed the release of version 1.5.
+
+ Take a look at the README and the ChangeLog files in the CVS sources
+ for more contributors.
+
+ Last modified: _6/13/1997_
+
+ 2. You didn't write all of this FAQ, did you?
+
+ In the original hunt for questions to answer (performed in Jan/Feb,
+ 1993), I polled hundreds of people and I rephrased all sorts of text
+ found on the net. Between 2/93 and 10/93, I released about 20
+ versions, with corrections and additions from the info-cvs mailing
+ list and private correspondence.
+
+ Between 10/93 and 10/94 I extracted frequently asked questions from
+ the 1200 mail messages to the info-cvs mailing list, turned them into
+ focused questions and tried to answer them.
+
+ 93/02/?? ~4000 lines 93/06/?? ~5000 lines 93/10/23 7839 lines 278K
+ 94/10/29 9856 lines 360K 95/05/09 9981 lines 365K
+
+ Because there are so many posers of questions, I will list only those
+ who contribute answers or help significantly with the content and
+ structure of this document.
+
+ If I used someone else's text verbatim, I mentioned it in the given
+ answer. The people whose email postings have added to this document or
+ who have added to my understanding are:
+
+ Brian Berliner <berliner@sun.com>, CVS maintainer. Paul Eggert
+ <eggert@twinsun.com>, RCS maintainer.
+
+ Gray Watson <gray@antaire.com> Per Cederqvist <ceder@signum.se> Pete
+ Clark <pclark@is.com>
+
+ all of whom have sent me copies of their tutorials and local CVS
+ documentation.
+
+ Additional contributors, who have sent me ideas, text, corrections and
+ support include (in alphabetical order):
+
+ Per Abrahamsen <amanda@iesd.auc.dk> Donald Amby
+ <amby@mixcom.mixcom.com> Mark D Baushke <mdb@cisco.com> Jim Blandy
+ <jimb@cyclic.com> Tom Cunningham <tomc@bouwsma,sps.mot.com> Graydon
+ Dodson <grdodson@lexmark.com> Joe Drumgoole
+ <joed@splatter.demon.co.uk> Don Dwiggins <dwig@markv.com> Bryant
+ Eastham <bryant@ced.utah.edu> Dan Franklin <dan@diamond.bbn.com>
+ Michael Ganzberger <ganzbergermd@ES.net> Steve Harris
+ <vsh%etnibsd@uunet.uu.net> Erik van Linstee
+ <linstee@dutecaj.et.tudelft.nl> Jeffrey M Loomis <jml@world.std.com>
+ Barry Margolin <barmar@near.net> Mark K. Mellis <mkm@ncd.com> Chris
+ Moore <Chris.Moore@src.bae.co.uk> Gary Oberbrunner <garyo@avs.com>
+ Steve Turner <stevet@carrier.sps.mot.com> Dave Wolfe
+ <dwolfe@pffft.sps.mot.com> Dale Woolridge <dwoolridge@cid.aes.doe.ca>
+
+ Please send corrections. If I forgot you, remind me and I'll add your
+ name to the list.
+
+ Last modified: _6/13/1997_
+
+ Category: /Past__Future_/Development/
+
+ " + Development"
+
+ 1. Where do I send bug reports?
+
+ First make sure it is a bug. Talk to your friends, coworkers and
+ anyone you know who uses CVS. Search this FAQ for related issues. Then
+ test it carefully. Try out variations to narrow down the problem. Make
+ sure it is repeatable. Look for workarounds so you can report them.
+
+ If you are still sure it's a bug and you tried to fix it, skip to the
+ next question. Otherwise, send a message to the info-cvs mailing list
+ containing one of the following:
+
+ If you have a good repeatable case and you think you know what is
+ going on, then describe the problem in detail. Include a workaround if
+ you have one.
+
+ If you have no idea what is going on, go ahead and send a question
+ to the info-cvs mailing list. Include any information you have
+ describing the symptoms.
+
+ Last modified: _6/13/1997_
+
+ 2. Where do I send fixes and patches?
+
+ First make sure the "fix" does something useful. Have someone review
+ your fix. Spend a bit of one person's time in a detailed analysis of
+ your vast idea before displaying a half-vast idea to hundreds of
+ people.
+
+ If you tried to fix it and the patch is small, include the patch in
+ your message. Make sure the patch is based on the latest released
+ version of CVS.
+
+ If you tried to fix it and the patch is large, you should think about
+ why it is so large. Did you add a generally useful feature, or did it
+ grow out of hand?
+
+ If you still believe it is solid, produce a patch file using the CVS
+ commands "patch" or "diff -c". [[You *are* keeping CVS under CVS,
+ right?]] The patch should be based on the latest released version of
+ CVS. Then use the "cvsbug" program (provided with the CVS sources) to
+ send it to the CVS maintainers. A self-contained patch that provides a
+ single useful feature or correction might show up independently in the
+ patches directory of the FTP archive.
+
+ If careful testing reveals an RCS bug rather than a CVS bug, you can
+ send bug reports to: rcs-bugs@cs.purdue.edu
+
+ Last modified: _6/13/1997_
+
+ 3. Where do I send ideas for future development?
+
+ If you have a bright idea, discuss it on the info-cvs mailing list. If
+ you have the time to implement something you can test, send the diffs
+ along too as described above.
+
+ Last modified: _6/13/1997_
+
+ 4. What plans are there for new features?
+
+
+
+A "rename" or "per-directory" database has been bandied about on
+the net for years. Many of the goals of the rename database have
+been achieved by the so-called "death support" in recent versions of
+CVS (such as 1.9). For more information on what may remain to be
+done, see item #189 in the TODO file of a development version of CVS.
+
+CVS version 1.5 supports remote repository access, but Paul
+Kunz has produced another version
+(rCVS) that also runs remotely. Note that as far as I know there
+are no advantages to rCVS over the remote CVS in CVS 1.5 and later,
+and the rCVS user community has migrated to remote CVS.
+rCVS is *not* a multisite CVS (see item #186 in TODO for more on
+multisite). For more on rCVS, see
+
+ftp://ftp.slac.stanford.edu/software/rcvs
+
+kingdon@cyclic.com
+
+ Last modified: _9/6/1997_
+
+ 5. I have some time and I'd like to help. What can I do for you?
+
+
+ You can review this document, correct errors and fill in any of
+ the incomplete sections.
+
+ You can write scripts or CVS add-ons and make them available by
+ web/FTP/etc.
+
+ You could work on the regression test suite (src/sanity.sh in the
+ CVS source distribution).
+
+ You can write specs for new features, fix bugs, review the
+ documentation or . . .
+
+ For more information, see the files HACKING and DEVEL-CVS in the
+ CVS source distribution or
+ http://www.cyclic.com/cyclic-pages/cvsdev.html
+
+ kingdon@cyclic.com
+
+ Last modified: _9/6/1997_
+
+ Category: /Past__Future_/Professional_Support/
+
+ " + Professional Support"
+
+ 1. Doesn't Cygnus support CVS?
+
+
+
+
+ Cygnus is a company that supports free software such as the GCC
+ compiler. They have never sold support for CVS, however. They
+ do use CVS internally and have contributed much code to CVS over
+ the years (for which CVS users should be grateful).
+
+ kingdon@cyclic.com
+
+ Last modified: _9/6/1997_
+
+ 2. What is Cyclic Software doing with CVS?
+
+
+Cyclic Software exists to provide support for CVS. For details such
+as prices and what this covers, see http://www.cyclic.com or ask
+info@cyclic.com.
+
+kingdon@cyclic.com
+
+ Last modified: _9/6/1997_
+
+ Category: /User_Tasks_/
+
+ " User Tasks "
+
+ Category: /User_Tasks_/Common_User_Tasks/
+
+ " + Common User Tasks"
+
+ 1. What is the absolute minimum I have to do to edit a file?
+
+ Tell your Repository Administrator to create a module covering the
+ directory or files you care about. You will be told that your module
+ name is <module>. Then type:
+
+ cvs checkout <module>
+ cd <module>
+ emacs <file> # Isn't Emacs a synonym for edit?
+ cvs commit <file>
+
+ If you don't use modules (in my opinion, a mistake), you can check out
+ a directory by substituting its relative path within the Repository
+ for <module> in the example above.
+
+ To work on a single file, you'll have to change "cd <module>" to "cd
+ `dirname <module>`".
+
+ Last modified: _6/13/1997_
+
+ 2. If I edit multiple files, must I type "commit" for each one?
+
+ No. You can commit a list of files and directories, including relative
+ paths into multiple directories. You can also commit every modified
+ file in the current directory or in all directories and subdirectories
+ from your current directory downward. See 3D.2.
+
+ Last modified: _6/13/1997_
+
+ 3. How do I get rid of the <module> directory that "checkout" created?
+
+ Change your directory to be the same as when you executed the
+ "checkout" command that created <module>.
+
+ If you want to get rid of the CVS control information, but leave the
+ files and directories, type:
+
+ cvs release <module>
+
+ If you want to obliterate the entire directory, type:
+
+ cvs release -d <module>
+
+ ("release -d" searches through the output of "cvs -n update" and
+ refuses to continue if the "update" command finds any modified files
+ or non-ignored foreign files. Foreign directories too.)
+
+ If you don't care about keeping "history", or checking for modified
+ and foreign files, you can just remove the whole directory. That's "rm
+ -rf <module>" under Unix.
+
+ Last modified: _6/13/1997_
+
+ 4. How do I find out what has changed since my last update?
+
+ There are many ways to answer this.
+
+ To find out what you've changed in your current working directory
+ since your last checkout, update or commit, type:
+
+ cvs diff
+
+ To find out what other people have added (to your branch) since you
+ last checked out or updated, type:
+
+ cvs diff -r BASE -r HEAD
+
+ To look at a revision history containing the comments for all changes,
+ you can use the "log" command.
+
+ You can also use "history" to trace a wide variety of events.
+
+ Last modified: _6/13/1997_
+
+ 5. I just created a new file. How do I add it to the Repository?
+
+ The "update" command will mark files CVS doesn't know about in your
+ working directory with a '?' indicator.
+
+ ? <file>
+
+ To add <file> to the Repository, type:
+
+ cvs add <file>
+ cvs commit <file>
+
+ See 3A.[2-5] and 4C.8 for branch and merge considerations.
+
+ Last modified: _6/13/1997_
+
+ 6. How do I merge changes made by others into my working directory?
+
+ If you are asking about other branches, see Section 4C on "Branching".
+ You will have to use the "update -j" command.
+
+ Retrieving changes made to the Repository on the *same* branch you are
+ working on is the main purpose of the "update" command. The "update"
+ command tries to merge work committed to the Repository by others
+ since you last executed "checkout", "update" or "commit" into your
+ working files.
+
+ For a single file, there are six possible results when you type the
+ "update" command:
+
+ If the file is lying in your working directory, but is not under
+ CVS, it will do nothing but print:
+
+ ? <file>
+
+ If neither you nor anyone else has committed changes to <file>,
+ since your last "checkout", "update" or "commit", "update" will print
+ nothing and do nothing.
+
+ If you have made no changes to a working file, but you or others
+ have committed changes to the Repository since your last "checkout",
+ "update" or "commit" of this working file, CVS will remove your
+ working file and replace it with a copy of the latest revision of that
+ file in the Repository. It will print:
+
+ U <file>
+
+ You might want to examine the changes (using the CVS "diff" command)
+ to see if they mesh with your own in related files.
+
+ If you have made changes to a working file, but no one has changed
+ your BASE revision (the revision you retrieved from the Repository in
+ your last "checkout", "update" or "commit"), "update" will print:
+
+ M <file>
+
+ Nothing changes. You were told that you have a modified file in your
+ directory.
+
+ If you have made changes to your working file and you or others have
+ committed changes to the Repository, but in different sections of the
+ file, CVS will merge the changes stored in the Repository since your
+ last "checkout", "update" or "commit" into your working file. "update"
+ will print:
+
+ RCS file: /Repository/module/<file> retrieving revision 1.X retrieving
+ revision 1.Y Merging differences between 1.X and 1.Y into <file> M
+ <file>
+
+ If you execute "diff" before and after this step, you should see the
+ same output, since both the base file and your working file changed in
+ parallel. This is one of the few times the otherwise nonsensical
+ phrase "same difference" means something.
+
+ If both you and those who committed files (since your last checkout,
+ update or commit) have made changes to the same section of a file, CVS
+ will merge the changes into your file as in #5 above, but it will
+ leave conflict indicators in the file. "update" will print:
+
+ RCS file: /Repository/module/<file> retrieving revision 1.X retrieving
+ revision 1.Y Merging differences between 1.X and 1.Y into <file>
+ rcsmerge warning: overlaps during merge
+ cvs update: conflicts found in <file>
+ C <file>
+
+ This is a "conflict". The file will contain markers surrounding the
+ overlapping text. The 'C' conflict indicator is sticky -- subsequent
+ "update" commands will continue to show a 'C' until you edit the file.
+
+ You must examine the overlaps with care and resolve the problem by
+ analyzing how to retain the features of both changes. See 2D.7 and
+ 3P.6 for more details on conflict resolution.
+
+ Last modified: _6/13/1997_
+
+ 7. How do I label a set of revisions so I can retrieve them later?
+
+ To "tag" the BASE revisions (the ones you last checked out, updated,
+ or committed) you should "cd" to the head of the working directory you
+ want to tag and type:
+
+ cvs tag <tag>
+
+ It recursively walks through your working directory tagging the BASE
+ revisions of all files.
+
+ To "tag" the latest revision on the Main branch in the Repository, you
+ can use the following from anywhere: (No "cd" is required -- it works
+ directly on the Repository.)
+
+ cvs rtag <tag> <module>
+
+ Last modified: _6/13/1997_
+
+ 8. How do I checkout an old release of a module, directory or file?
+
+ Module names and directories are simply ways to name sets of files.
+ Once the names are determined, there are 6 ways to specify which
+ revision of a particular file to check out:
+
+ By tag or symbolic name, via the "-r <tag>" option.
+
+ By date, via the "-D <date>" option.
+
+ By branch tag (a type of tag with a magic format), via the "-r
+ <branch_tag>" option.
+
+ By date within a branch, via the "-r <branch_tag>:<date>" option.
+
+ By an explicit branch revision number ("-r <rev>"), which refers to
+ the latest revision on the branch. This isn't really an "old"
+ revision, from the branch's perspective, but from the user's
+ perspective the whole branch might have been abandoned in the past.
+
+ An explicit revision number: "-r <rev>" Though this works, it is
+ almost useless for more than one file.
+
+ You type:
+
+ cvs checkout <option-specified-above> <module>
+ cd <module>
+
+ Last modified: _6/13/1997_
+
+ 9. What do I have to remember to do periodically?
+
+ You should execute "cvs -n update" fairly often to keep track of what
+ you and others have changed. It won't change anything -- it will just
+ give you a report.
+
+ Unless you are purposely delaying the inclusion of others' work, you
+ should execute "update" once in a while and resolve the conflicts. It
+ is not good to get too far out of sync with the rest of the developers
+ working on your branch.
+
+ It is assumed that your system administrators have arranged for editor
+ backup and Unix temp files (#* and .#*) to be deleted after a few
+ weeks. But you might want to look around for anything else that is
+ ignored or hidden. Try "cvs -n update -I !" to see all the ignored
+ files.
+
+ If you are the Repository Administrator, see 4B.16 on Administrator
+ responsibilities.
+
+ Last modified: _6/13/1997_
+
+ Category: /User_Tasks_/General_Questions/
+
+ " + General Questions"
+
+ 1. How do I see what CVS is trying to do?
+
+ The '-t' option on the main "cvs" command will display every external
+ command (mostly RCS commands and file deletions) it executes. When
+ combined with the '-n' option, which prevents the execution of any
+ command that might modify a file, you can see what it will do before
+ you let it fly. The '-t' option will *not* display every internal
+ action, only calls to external programs.
+
+ To see a harmless example, try typing:
+
+ cvs -nt update
+
+ Some systems offer a "trace" or "truss" command that will display all
+ system calls as they happen. This is a *very* low-level interface that
+ does not normally follow the execution of external commands, but it
+ can be useful.
+
+ The most complete answer is to read the source, compile it with the
+ '-g' option and step through it under a debugger.
+
+ Last modified: _6/13/1997_
+
+ 2. If I work with multiple modules, should I check them all out and commit
+ them occasionally? Is it OK to leave modules checked out?
+
+ The simple answers are "Yes."
+
+ There is no reason to remove working directories, other than to save
+ disk space. As long as you have committed the files you choose to make
+ public, your working directory is just like any other directory.
+
+ CVS doesn't care whether you leave modules checked out or not. The
+ advantage of leaving them checked out is that you can quickly visit
+ them to make and commit changes.
+
+ Last modified: _6/13/1997_
+
+ 3. What is a "sticky" tag? What makes it sticky? How do I loosen it?
+
+ When you execute "update -r <tag>", CVS remembers the <tag>. It has
+ become "sticky" in the sense that until you change it or remove it,
+ the tag is remembered and used in references to the file as if you had
+ typed "-r <tag>" on the command line.
+
+ It is most useful for a <branch_tag>, which is a sticky tag indicating
+ what branch you are working on.
+
+ A revision number ("-r <rev-number>") or date ("-D <date>") can also
+ become sticky when they are specified on the command line.
+
+ A sticky tag, revision or date remains until you specify another tag,
+ revision or date the same way. The "update -A" command moves back to
+ the Main branch, which has the side-effect of clearing all sticky
+ items on the updated files.
+
+ The "checkout" command creates sticky tags, revisions and dates the
+ same way "update" does.
+
+ Also, the '-k' option records a "sticky" keyword option that is used
+ in further "updates until "update -A" is specified.
+
+ Last modified: _6/13/1997_
+
+ 4. How do I get an old revision without updating the "sticky tag"?
+
+ Use the '-p' option to "pipe" data to standard output. The command
+ "update -p -r <tag/rev>" sends the selected revision to your standard
+ output (usually the terminal, unless redirected). The '-p' affects no
+ disk files, leaving a "sticky tag" unaltered and avoiding all other
+ side-effects of a normal "update".
+
+ If you want to save the result, you can redirect "stdout" to a file
+ using your shell's redirection capability. In most shells the
+ following command works:
+
+ cvs update -p -r <tag/rev> filename > diskfile
+
+ Last modified: _6/13/1997_
+
+ 5. What operations disregard sticky tags?
+
+ The functions that routinely disregard sticky tags are:
+
+ Those that work directly on the Repository or its administrative
+ files:
+
+ admin rtag log status remove history
+
+ Those that take Tags or revisions as arguments and ignore everything
+ else: (They also never *set* a sticky tag.)
+
+ rdiff import export
+
+ The "release" command itself ignores sticky tags, but it calls "cvs
+ -n update" (which *does* pay attention to a sticky tag) to figure out
+ what inconsistencies exist in the working directory. If no
+ discrepancies exist between the files you originally checked out
+ (possibly marked by a sticky tag) and what is there now, "release -d"
+ will delete them all.
+
+ The "tag" command works on the revision lying in the working
+ directory however it got there. That the revision lying there might
+ happen to have a sticky tag attached to it is not the "tag" command's
+ concern.
+
+ The main function that *does* read and write sticky tags is the
+ "update" command. You can avoid referring to or changing the sticky
+ tag by using the '-p' option, which sends files to your terminal,
+ touching nothing else.
+
+ The "checkout" command sets sticky tags when checking out a new module
+ and it acts like "update" when checking out a module into an existing
+ directory.
+
+ The "diff" and "commit" commands use the sticky tags, unless
+ overridden on the command line. They do not set sticky tags. Note that
+ you can only "commit" to a file checked out with a sticky tag, if the
+ tag identifies a branch.
+
+ There are really two types of sticky tags, one attached to individual
+ files (in the ./CVS/Entries file) and one attached to each directory
+ (in the ./CVS/Tag file). They can differ.
+
+ The "add" command registers the desire to add a new file. If the
+ "directory tag" (./CVS/Tag) file exists at the time of the "add", the
+ value stored in ./CVS/Tag becomes the "sticky tag" on the new file.
+ The file doesn't exist in the Repository until you "commit" it, but
+ the ./CVS/Entries file holds the sticky tag name from the time of the
+ "add" forward.
+
+ Last modified: _6/13/1997_
+
+ 6. Is there a way to avoid reverting my Emacs buffer after committing a
+ file? Is there a "cvs-mode" for Emacs?
+
+ See Section 4F.1
+
+ Last modified: _6/13/1997_
+
+ 7. How does conflict resolution work? What *really* happens if two of us
+ change the same file?
+
+ While editing files, there is no conflict. You are working on separate
+ copies of the file stored in the virtual "branch" represented by your
+ working directories. After one of you commits a file, the other may
+ not commit the same file until "update" has merged the earlier
+ committed changes into the later working file.
+
+ For example, say you both check out rev 1.2 of <file> and make change
+ to your working files. Your coworker commits revision 1.3. When you
+ try to commit your file, CVS says:
+
+ cvs commit: Up-to-date check failed for `<file>'
+
+ You must merge your coworker's changes into your working file by
+ typing:
+
+ cvs update <file>
+
+ which will produce the output described in 2B.6.
+
+ If a conflict occurs, the filename will be shown with a status of 'C'.
+ After you resolve any overlaps caused by the merging process, you may
+ then commit the file. See 3P.6 for info on "sticky conflicts".
+
+ Even if you get a simple 'M', you should examine the differences
+ before committing the file. A smooth, error-free text merge is still
+ no indication that the file is in proper shape. Compile and test it at
+ least.
+
+ The answer to two obvious questions is "Yes".
+
+ Yes, the first one who commits avoids the merge. Later developers have
+ to merge the earlier changes into their working files before
+ committing the merged result. Depending on how difficult the merge is
+ and how important the contending projects are, the order of commits
+ and updates might have to be carefully staged.
+
+ And yes, between the time you execute "update" and "commit" (while you
+ are fixing conflicts and testing the results) someone else may commit
+ another revision of <file>. You will have to execute "update" again to
+ merge the new work before committing. Most organizations don't have
+ this problem. If you do, you might consider splitting the file. Or
+ hiring a manager.
+
+ Last modified: _6/13/1997_
+
+ 8. How can I tell who has a module checked out?
+
+ If you "checkout" module names (not relative pathnames) and you use
+ the release command, the "history" command will display active
+ checkouts, who has them and where they were checked out. It is
+ advisory only; it can be circumvented by using the '-l' option on the
+ main "cvs" command.
+
+ Last modified: _6/13/1997_
+
+ 9. Where did the .#<file>.1.3 file in my working directory come from?
+
+ It was created during an "update" when CVS merged changes from the
+ Repository into your modified working file.
+
+ It serves the same purpose as any "backup" file: saving your bacon
+ often enough to be worth retaining. It is invaluable in recovering
+ when things go wrong.
+
+ Say Developers A (you) and B check out rev 1.3 of file <file>. You
+ both make changes -- different changes. B commits first, so <file>,v
+ in the Repository contains revisions up through 1.4.
+
+ At this point, there are 5 (yes, five) versions of the file of
+ interest to you:
+
+ Revision 1.3 (What you originally checked out.)
+
+ Revision 1.4 (What you need from developer B.)
+
+ Your old working file. (Before the update.)
+
+ Your new working file. (After the merge caused by "update".)
+
+ Revision 1.5 (Which you will commit shortly.)
+
+ In the case where your working file was not modified, #1 and #3 will
+ be the same, as will #2 and #4. In this degenerate case, there is no
+ need to create #5. The following assumes that your working file was
+ modified.
+
+ If the merge executed by the "update" caused no overlaps, and you
+ commit the file immediately, #4 and #5 will be the same. But you can
+ make arbitrary changes before committing, so the difference between #4
+ and #5 might be more than just the correction of overlaps. In general,
+ though, you don't need #4 after a commit.
+
+ But #3 (which is the one saved as ".#<file>.1.3") holds all of your
+ work, independent of B's work. It could represent a major effort that
+ you couldn't afford to lose. If you don't save it somewhere, the merge
+ makes #3 *disappear* under a potential blizzard of conflicts caused by
+ overlapping changes.
+
+ I have been saved a few times, and others I support have been saved
+ hundreds of times, by the ability to "diff <original file> <original
+ file with only my work added>", which can be done in the example above
+ by the Unix shell command:
+
+ cvs update -p -r 1.3 <file> | diff - .#<file>.1.3
+
+ The assumption is that the ".#" files will be useful far beyond the
+ "commit" point, but not forever. You are expected to run the "normal"
+ Unix cleanup script from "cron", which removes "#*" and ".#*" files
+ older than a some period chosen by your sysadmin, usually ranging from
+ 7 to 30 days.
+
+ A question was raised about the need for #3 after #5 has been
+ committed, under the assumption that you won't commit files until
+ everything is exactly as you like them.
+
+ This assumes perfect humans, which violates one of the Cardinal rules
+ of Software Engineering: Never assume any form of discipline on the
+ part of the users of software. If restrictions are not bound into the
+ software, then you, the toolsmith, have to arrange a recovery path.
+
+ In other words, I've seen every possible variety of screwup you can
+ imagine in #5. There is no way to make assumptions about what "should"
+ happen. I've seen #5 filled with zeros because of NFS failures, I've
+ seen emacs core dumps that leave #5 in an unreasonable state, I've
+ seen a foolish developer uppercase the whole file (with his "undo"
+ size set low so he couldn't undo it) and decide that it would be less
+ work to play with the uppercased file than to blow it away and start
+ over. I've even seen committed files with conflict markers still in
+ them, a sure sign of carelessness.
+
+ There are all sorts of scenarios where having #3 is incredibly useful.
+ You can move it back into place and try again.
+
+ Last modified: _6/13/1997_
+
+ 10. What is this "ignore" business? What is it ignoring?
+
+ The "update" and "import" commands use collections of Unix wildcards
+ to skip over files and directories matching any of those patterns.
+
+ You may add to the built-in ignore list by adding lines of
+ whitespace-separated wildcards to the following places: (They are read
+ in this order.)
+
+ In a file named "cvsignore" in $CVSROOT/CVSROOT.
+
+ A Repository Administrator uses this to add site-specific files and
+ patterns to the built-in ignore list.
+
+ In a file named ".cvsignore" in your home directory.
+
+ For user-specific files. For example, if you use "__" as your default
+ junk file prefix, you can put "__*" in your .cvsignore file.
+
+ People who play around exclusively in directory trees where the
+ Makefiles are generated by "imake" or "configure" might want to put
+ "Makefile" in their ignore list, since they are all generated and
+ usually don't end up in the Repository.
+
+ In the CVSIGNORE environment variable.
+
+ For session-specific files.
+
+ Via the '-I' option on "import" or "update" commands.
+
+ For this-command-only files.
+
+ In a file named ".cvsignore" within each directory.
+
+ The contents of a ".cvsignore" file in each directory is temporarily
+ added to the ignore list. This way you can ignore files that are
+ peculiar to that directory, such as executables and other generated
+ files without known wildcard patterns.
+
+ In any of the places listed above, a single '!' character nulls out
+ the ignore list. A Repository administrator can use this to override,
+ rather than enhance, the built-in ignore list. A user can choose to
+ override the system-wide ignore list. For example, if you place "! *.o
+ *.a" in your .cvsignore file, only *.o *.a files, plus any files a
+ local-directory .cvsignore file, are ignored.
+
+ A variant of the ignore-file scheme is used internally during
+ checkout. "Module names" found in the modules file (or on the
+ "checkout" command line) that begin with a '!' are ignored during
+ checkout. This is useful to permanently ignore (if the '!' path is in
+ the modules file) or temporarily ignore (if the '!' path is on the
+ command line) a sub-directory within a Repository hierarchy. For
+ example:
+
+ cvs checkout !gnu/emacs/tests gnu/emacs
+
+ would checkout the module (or relative path within $CVSROOT) named
+ "gnu/emacs", but ignore the "tests" directory within it.
+
+ Last modified: _6/13/1997_
+
+ 11. Is there a way to set user-specific configuration options?
+
+ User-specific configuration is available through use of a ".cvsrc"
+ file in your home directory.
+
+ CVS searches the first column of your ~/.cvsrc file for the cvs
+ command name you invoked. If the command is found, the rest of the
+ line is treated like a set of command line options, stuffed into the
+ command line before the arguments you actually typed.
+
+ For example, if you always want to see context diffs and you never
+ want to have to delete a file before you run "cvs remove", then you
+ should create a .cvsrc file containing the following:
+
+ diff -c
+ remove -f
+
+ which will add the given options to every invocation of the given
+ commands.
+
+ [[The rest of this will be removed someday, when CVS changes.]]
+
+ I would like to stop here with a comment that the command name to use
+ is the full, canonical one. But the command that the cvsrc support
+ uses is the string you typed on the command line, not the proper
+ command. So to get the full effect of the above example, you should
+ also add all the alternate command names:
+
+ di -c
+ dif -c
+ rm -f
+ delete -f
+
+ There are two other limitations that will probably be fixed when CVS
+ sprouts long option names:
+
+ It only affects options made available on the command line.
+
+ There is a limited number of short options. With long option names,
+ there is no problem. You can have as many long options as you like,
+ affecting anything that looks malleable.
+
+ The existing command line options do not come in on/off pairs, so
+ there is no easy way to override your ~/.cvsrc configuration for a
+ single invocation of a command.
+
+ Choosing a good set of long option pairs would fix this.
+
+ Last modified: _6/13/1997_
+
+ 12. Is it safe to interrupt CVS using Control-C?
+
+ It depends on what you mean by "safe". ("Ah," said Arthur, "this is
+ obviously some strange usage of the word *safe* that I wasn't
+ previously aware of." -- Hitchhiker's Guide to the Galaxy)
+
+ You won't hurt the underlying RCS files and if you are executing a
+ command that only *reads* data, you will have no cleanup to do.
+
+ But you may have to hit Control-C repeatedly to stop it. CVS uses the
+ Unix "system" routine which blocks signals in the CVS parent process.
+ A single Control-C during "system" will only halt the child process,
+ usually some form of RCS command.
+
+ If you don't hit another Control-C while the CVS process has control,
+ it is likely to continue onto the next task assuming that the earlier
+ one did its job. It is not enough to hit two Control-C's. You might
+ simply kill two child processes and not interrupt CVS at all.
+ Depending on the speed of your processor, your terminal and your
+ fingers, you might have to hit dozens of Control-C's to stop the damn
+ thing.
+
+ Executing a CVS command, such as "commit" or "tag" that writes to the
+ files is a different matter.
+
+ Since CVS is not a full-fledged database, with what database people
+ call "commit points", merely stopping the process will not back out
+ the "transaction" and place you back in the starting blocks. CVS has
+ no concept of an "atomic" transaction or of "backtracking", which
+ means that a command can be half-executed.
+
+ Hitting Control-C will usually leave lock files that you have to go
+ clean up in the Repository.
+
+ Example1:
+
+ If you interrupt a multi-file "commit" in the middle of
+ an RCS checkin, RCS will leave the file either fully
+ checked-in or in its original state. But CVS might have
+ been half-way through the list of files to commit. The
+ directory or module will be inconsistent.
+
+ To recover, you must remove the lock files, then decide
+ whether you want to back out or finish the job.
+
+ To back out, you'll have to apply the "admin -o"
+ command, very carefully, to remove the newly committed
+ revisions. This is usually a bad idea, but is
+ occasionally necessary.
+
+ To finish, you can simply retype the same commit command.
+ CVS will figure out what files are still modified and
+ commit them. It helps that RCS doesn't leave a file in an
+ intermediate state.
+
+ Example2:
+
+ If you interrupt a multi-file "tag" command, you have a
+ problem similar, but not equivalent, to interrupting a
+ "commit". The RCS file will still be consistent, but
+ unlike "commit", which only *adds* to the RCS file, "tag"
+ can *move* a tag and it doesn't keep a history of what
+ revision a tag used to be attached to.
+
+ Normally, you have little choice but to re-execute the
+ command and allow it to tag everything consistently.
+
+ You might be able to recover by carefully re-applying the
+ tags via the "cvs admin -N" command, but you'll still have
+ to dig up from outside sources the information you use to
+ determine what tag was on what revision in what file.
+ the Repository, or by using the equivalent: "cvs admin".
+
+ Halting a new "checkout" should cause no harm. If you don't want it,
+ "release" (or rm -rf) it. If you do want it, re-execute the command. A
+ repeated "checkout" from above a directory acts like a repeated
+ "update -d" within it.
+
+ Halting "update" half-way will give you an unpredictable collection of
+ files and revisions. To continue, you can rerun the update and it
+ should move you forward into in a known state. To back out, you'll
+ have to examine the output from the first "update" command, take a
+ look at each file that was modified and reconstruct the previous state
+ by editing the ./CVS/Entries file and by using "cvs admin". Good Luck.
+
+ Last modified: _6/13/1997_
+
+ 13. How do I turn off the "admin" command?
+
+ In the current revision, you'd have to edit the source code.
+
+ Last modified: _6/13/1997_
+
+ 14. How do I turn off the ability to disable history via "cvs -l"?
+
+ In the current revision, you'd have to edit the source code.
+
+ Last modified: _6/13/1997_
+
+ 15. How do I keep certain people from accessing certain directories?
+
+ If you don't try to run CVS set[ug]id, you can use Unix groups and
+ permissions to limit access to the Repository.
+
+ If you only want to limit "commit" commands, you can write a program
+ to put in the "commitinfo" file. In the "contrib" directory, there are
+ a few scripts that might help you out.
+
+ Last modified: _6/13/1997_
+
+ Category: /User_Tasks_/Getting_Started/
+
+ " + Getting Started"
+
+ 1. What is the first thing I have to know?
+
+ Your organization has most likely assigned one or more persons to
+ understand, baby-sit and administer the CVS programs and the data
+ Repository. I call these persons Repository Administrators. They
+ should have set up a Repository and "imported" files into it.
+
+ If you don't believe anyone has this responsibility, or you are just
+ testing CVS, then *you* are the Repository Administrator.
+
+ If you are a normal user of CVS ask your Repository Administrator what
+ module you should check out.
+
+ Then you can work.
+
+ If you *are* the Repository Administrator, you will want to read
+ everything you can get your hands on, including this FAQ. Source
+ control issues can be difficult, especially when you get to branches
+ and release planning. Expect to feel stupid for a few days/weeks.
+
+ No tool in the universe avoids the need for intelligent organization.
+ In other words, there are all sorts of related issues you will
+ probably have to learn. Don't expect to dive in without any
+ preparation, stuff your 300 Megabytes of sources into CVS and expect
+ to start working. If you don't prepare first, you will probably spend
+ a few sleepless nights.
+
+ Last modified: _6/13/1997_
+
+ 2. Where do I work?
+
+ Wherever you have disk space. That's one of the advantages of CVS: you
+ use the "checkout" command to copy files from the Repository to your
+ working directory, which can be anywhere you have the space.
+
+ Your local group might have conventions for where to work. Ask your
+ peers.
+
+ Last modified: _6/13/1997_
+
+ 3. What does CVS use from my environment?
+
+ You must set two environment variables. Some shells share these
+ variables with local shell variables using a different syntax. You'll
+ have to learn how your shell handles them.
+
+ Variable Value (or action)
+ --------- ---------------------
+ CVSROOT Absolute pathname of the head of your Repository.
+
+ PATH Normally set to a list of ':'-separated directory
+ pathnames searched to find executables. You must
+ make sure "cvs" is in one of the directories.
+
+ If your CVS was built with the RCSBIN directory set
+ to null (""), and you don't set the RCSBIN
+ variable mentioned below, then the RCS commands
+ also must be somewhere in your PATH.
+
+ Optional variables: (Used if set, but ignored otherwise.)
+
+ Variable Value (or action)
+ --------- ---------------------
+ CVSEDITOR The name of your favorite fast-start editor
+ program. You'll be kicked into your editor to
+ supply revision comments if you don't specify them
+ via -m "Log message" on the command line.
+
+ EDITOR Used if CVSEDITOR doesn't exist. If EDITOR
+ doesn't exist, CVS uses a configured constant,
+ usually, "vi".
+
+ CVSREAD Sets files to read-only on "checkout".
+
+ RCSBIN Changes where CVS finds the RCS commands.
+
+ CVSIGNORE Adds to the ignore list. See Section 2D.
+
+ Other variables used by CVS that are normally set upon login:
+
+ Variable Value (or action)
+ --------- ---------------------
+ LOGNAME Used to find the real user name.
+
+ USER Used to find the real user name if no LOGNAME.
+
+ HOME Used to determine your home directory, if set.
+ Otherwise LOGNAME/USER/getuid() are used to find
+ your home directory from the passwd file.
+
+ TMPDIR Used during import. It might also be used if your
+ platform's version of mktemp(3) is unusual, or
+ you have changed the source to use tmpnam(3).
+
+ Last modified: _6/13/1997_
+
+ 4. OK, I've been told that CVS is set up, my module is named "ralph" and I
+ have to start editing. What do I type?
+
+ cd <where you have some space to work>
+ cvs checkout ralph
+ cd ralph
+
+ And hack away.
+
+ Last modified: _6/13/1997_
+
+ 5. I have been using RCS for a while. Can I convert to CVS without losing
+ my revision history? How about converting from SCCS?
+
+ If you are asking such questions, you are not a mere user of CVS, but
+ one of its Administrators! You should take a look at Section 4A,
+ "Installing CVS" and Section 4B, "Setting up and Managing the
+ Repository".
+
+ Last modified: _6/13/1997_
+
+ Category: /User_Tasks_/Less_Common_User_Tas/
+
+ " + Less Common User Tasks"
+
+ 1. Can I create non-CVS sub-directories in my working directory?
+
+ Yes. Unless the directory exists in the Repository, "update" will skip
+ over them and print a '?' the way it does for files you forgot to add.
+ You can avoid seeing the '?' by adding the name of the foreign
+ directory to the ./.cvsignore file, just ask you can do with files.
+
+ If you explicitly mention a foreign directory on the "update" command
+ line, it will traverse the directory and waste a bit of time, but if
+ any directory or sub-directory lacks the ./CVS administrative
+ directory, CVS will print an error and abort.
+
+ Last modified: _6/13/1997_
+
+ 2. How do I add new sub-directories to the Repository?
+
+ The "add" command will work on directories. You type:
+
+ mkdir <dir>
+ cvs add <dir>
+
+ It will respond:
+
+ Directory /Repos/<dir> added to the repository
+
+ and will create both a matching directory in the Repository and a
+ ./CVS administrative directory within the local <dir> directory.
+
+ Last modified: _6/13/1997_
+
+ 3. How do I remove a file I don't need?
+
+ (See the questions in Section 4B on removing files from the
+ Repository.)
+
+ You type:
+
+ rm <file>
+ cvs remove <file>
+
+ CVS registers the file for removal. To complete the removal, you must
+ type:
+
+ cvs commit <file>
+
+ CVS moves the file to the Attic associated with your working
+ directory. Each directory in the Repository stores its deleted files
+ in an Attic sub-directory. A normal "checkout" doesn't look in the
+ Attic, but if you specify a tag, a date or a revision, the "checkout"
+ (or "update") command will retrieve files from the Attic with that
+ tag, date or revision.
+
+ Last modified: _6/13/1997_
+
+ 4. How do I rename a file?
+
+ CVS does not offer a way to rename a file in a way that CVS can track
+ later. See Section 4B for more information.
+
+ Here is the best (to some, the only acceptable) way to get the effect
+ of renaming, while preserving the change log:
+
+ Copy the RCS (",v") file directly in the Repository.
+
+ cp $CVSROOT/<odir>/<ofile>,v $CVSROOT/<ndir>/<nfile>,v
+
+ By duplicating the file, you will preserve the change history and the
+ ability to retrieve earlier revisions of the old file via the "-r
+ <tag/rev>" or "-D <date>" options to "checkout" and "update".
+
+ Remove the old file using CVS.
+
+ cd <working-dir>/<odir> rm <ofile>
+ cvs remove <ofile>
+ cvs commit <ofile>
+
+ This will move the <ofile> to the Attic associated with <odir>.
+
+ Retrieve <nfile> and remove all the Tags from it.
+
+ By stripping off all the old Tags, "checkout -r" and "update -r" won't
+ retrieve revisions Tagged before the renaming.
+
+ cd <working-dir>/<ndir>
+ cvs update <nfile>
+ cvs log <nfile> # Save the list of Tags
+ cvs tag -d <tag1> <nfile>
+ cvs tag -d <tag2> <nfile>
+ . . .
+
+ This technique can be used to rename files within one directory or
+ across different directories. You can apply this idea to directories
+ too, as long as you apply the above to each file and don't delete the
+ old directory.
+
+ Of course, you have to change your build system (e.g. Makefile) in
+ your <working-dir> to know about the name change.
+
+ Warning: Stripping the old tags from the copied file will allow "-r
+ <tag>" to do the right thing, but you will still have problems with
+ "-D <date>" because there is no place to store the "deletion time".
+ See 5B.3 for more details.
+
+ Last modified: _6/13/1997_
+
+ 5. How do I make sure that all the files and directories in my working
+ directory are really in the Repository?
+
+ A "cvs update", or "cvs -n update" (which won't modify your working
+ directory) will display foreign elements, which have no counterpart in
+ the Repository, preceded by a '?'. To register foreign directories,
+ you can use "cvs add". To register foreign files, you can use "cvs
+ add" followed by "cvs commit".
+
+ You could also checkout your module, or the Repository directory
+ associated with your working directory, a second time into another
+ work area and compare it to your working directory using the (non-CVS)
+ "diff -r" command.
+
+ By default many patterns of files are ignored. If you create a file
+ named "core" or a file ending in ".o", it is usually ignored. If you
+ really want to see all the files that aren't in the Repository, you
+ can use a special "ignore" pattern to say "ignore no files". Try
+ executing: (You may have to quote or backwhack (i.e. precede by '\')
+ the '!' in your shell.)
+
+ cvs -n update -I !
+
+ The above command will display not only the normal modified, update
+ and conflict indicators ('M', 'U', and 'C' respectively) on files
+ within the Repository, but it will also display each file not in the
+ Repository preceded by a '?' character.
+
+ The '-n' option will not allow "update" to alter your working
+ directory.
+
+ Last modified: _6/13/1997_
+
+ 6. How do I create a branch?
+
+ Type this in your working directory:
+
+ cvs tag -b <branch_tag>
+
+ and you will create a branch. No files have real branches in them yet,
+ but if you move onto the branch by typing:
+
+ cvs update -r <branch_tag>
+
+ and commit a file in the normal way:
+
+ cvs commit <file>
+
+ then a branch will be created in the underlying <file>,v file and the
+ new revision of <file> will appear only on that branch.
+
+ See Section 4C, on Branching.
+
+ Last modified: _6/13/1997_
+
+ 7. How do I modify the modules file? How about the other files in the
+ CVSROOT administrative area?
+
+ A module named "modules" has been provided in the default modules
+ file, so you can type:
+
+ cvs checkout modules
+ cd modules
+
+ Another module named CVSROOT has been provided in the default modules
+ file, covering all the administrative files. Type:
+
+ cvs checkout CVSROOT
+ cd CVSROOT
+
+ Then you can edit your files, followed by:
+
+ cvs commit
+
+ If you start with the provided template for the "modules" file, the
+ CVSROOT and the "modules" module will have the "mkmodules" program as
+ a "commit helper". After a file is committed to such a module,
+ "mkmodules" will convert a number of standard files (See 4B.2) in the
+ CVSROOT directory inside the Repository into a form that is usable by
+ CVS.
+
+ Last modified: _6/13/1997_
+
+ 8. How do I split a file into pieces, retaining revision histories?
+
+ If you and a coworker find yourselves repeatedly committing the same
+ file, but never for changes in the same area of the file, you might
+ want to split the file into two or more pieces. If you are both
+ changing the same section of code, splitting the file is of no use.
+ You should talk to each other instead.
+
+ If you decide to split the file, here's a suggestion. In many ways, it
+ is similar to multiple "renamings" as described in 2C.4 above.
+
+ Say you want to split <fileA>, which already in the Repository, into
+ three pieces, <fileA>, <fileB> and <fileC>.
+
+ Copy the RCS (",v") files directly in the Repository, creating the
+ new files, then bring readable copies of the new files into the
+ working directory via "update".
+
+ cp $CVSROOT/<path>/<fileA>,v $CVSROOT/<path>/<fileB>,v cp
+ $CVSROOT/<path>/<fileA>,v $CVSROOT/<path>/<fileC>,v
+ cvs update <fileB> <fileC>
+
+ Then remove all the <tags> from the new files by using:
+
+ cvs log <fileB> <fileC> # Save the list of <tag?>
+ cvs tag -d <tag1> <fileB> <fileC>
+ cvs tag -d <tag2> <fileB> <fileC>
+ . . .
+
+ Edit each file until it has the data you want in it. This is a
+ hand-editing job, not something CVS can handle. Then commit all the
+ files.
+
+ [From experience, I'd suggest making sure that only one copy of each
+ line of code exists among the three files, except for "include"
+ statements, which must be duplicated. And make sure the code
+ compiles.]
+
+ emacs <fileA> <fileB> <fileC>
+ cvs commit <fileA> <fileB> <fileC>
+
+ As in the "rename" case, by duplicating the files, you'll preserve the
+ change history and the ability to retrieve earlier revisions.
+
+ Of course, you have to alter your build system (e.g. Makefiles) to
+ take the new names and the change in contents into account.
+
+ Last modified: _6/13/1997_
+
+ Category: /What_is_CVS_/
+
+ " What is CVS? "
+
+ Category: /What_is_CVS_/How_does_CVS_differ_/
+
+ " + How does CVS differ from other, similar software?"
+
+ 1. How does CVS differ from RCS?
+
+ CVS uses RCS to do much of its work and absolutely all the work of
+ changing the underlying RCS files in the Repository.
+
+ RCS comprises a set of programs designed to keep track of changes to
+ individual files. Of course, it also allows you to refer to multiple
+ files on the command line, but they are handled by iterating over
+ individual files. There is no pretense of coordinated interaction
+ among groups of files.
+
+ CVS's main intent is to provide a set of grouping functions that allow
+ you to treat a collection of RCS files as a single object. Of course,
+ CVS also has to do a lot of iteration, but it tries its best to hide
+ that it is doing so. In addition, CVS has some truly group-oriented
+ facets, such as the modules file and the CVS administrative files that
+ refer to a whole directory or module.
+
+ One group aspect that can be a bit confusing is that a CVS branch is
+ not the same as an RCS branch. To support a CVS branch, CVS uses
+ "tags" (what RCS calls "symbols") and some local state, in addition to
+ RCS branches.
+
+ Other features offered by CVS that are not supported directly by RCS
+ are
+
+ Automatic determination of the state of a file, (e.g. modified,
+ up-to-date with the Repository, already tagged with the same string,
+ etc.) which helps in limiting the amount of displayed text you have to
+ wade through to figure out what changed and what to do next.
+
+ A copy-modify-merge scheme that avoids locking the files and allows
+ simultaneous development on a single file.
+
+ Serialization of commits. CVS requires you to merge all changes
+ committed (via "update") since you checked out your working copy of
+ the file. Although it is still possible to commit a file filled with
+ old data, it is less likely than when using raw RCS.
+
+ Relatively easy merging of releases from external Vendors.
+
+ Last modified: _6/13/1997_
+
+ 2. How does CVS differ from SCCS?
+
+ SCCS is much closer to RCS than to CVS, so some of the previous entry
+ applies.
+
+ You might want to take a look at Walter Tichy's papers on RCS, which
+ are referred to in the RCS man pages.
+
+ [[More info here?]]
+
+ Last modified: _6/13/1997_
+
+ 3. How does CVS differ from ClearCase?
+
+ ClearCase is a distributed client-server version control system.
+ ClearCase is a variant DSEE tools, formerly available on Apollo
+ platforms. The ClearCase tool set includes a few X-based interface
+ tools, a command-line interface, and C programmer API. It is currently
+ available on Sun, HP, SGI and OSF/1 platforms.
+
+ ClearCase uses a special Unix filesystem type, called "mvfs" for
+ "multi-version file system". Conceptually, mvfs adds another dimension
+ to a regular Unix filesystem. The new axis is used to store the
+ different versions of files and to provide a tree-hierarchical view of
+ a collection of objects that might be scattered across any number of
+ separate hosts on your local network.
+
+ Each user acquires a "view" into the file database by creating a
+ special mvfs mount point on their machine. Each view has a
+ "configuration spec" containing a set of selection rules that specify
+ the particular version of each file to make visible in that view. You
+ can think of a "view" as a work area in CVS, except that the files
+ don't really exist on your local disk until you modify them. This
+ technique conserves disk space because it doesn't keep private copies
+ of read-only files.
+
+ Another advantage is that a view is "transparent" in the sense that
+ all of the files in a "view" appear to be regular Unix files to other
+ tools and Unix system calls. An extended naming convention allows
+ access to particular versions of a file directly:
+ "test.cc@@/main/bugfix/3" identifies the third version of test.c on
+ the bugfix branch.
+
+ ClearCase supports both the copy-modify-merge model of CVS (by using
+ what are called "unreserved checkouts" and the checkin/checkout
+ development model with file locking. Directories are
+ version-controlled objects as well as files. A graphical merge tool is
+ provided. Like RCS, ClearCase supports branches, symbolic tags, and
+ delta compression. ASCII as well as binary files are supported, and
+ converters from RCS, SCCS, DSEE formats are also included.
+
+ A make-compatible build facility is provided that can identify common
+ object code and share it among developers. A build auditing feature
+ automatically records file dependencies by tracking every file that is
+ opened when producing a derived object, thus making explicit
+ dependency lists unnecessary. Pre- and post-event triggers are
+ available for most ClearCase operations to invoke user programs or
+ shell scripts. User-defined attributes can be assigned to any version
+ or object. Hyper-links between version controlled objects can record
+ their relationship.
+
+ For more information, contact:
+
+ Atria Software, Inc. 24 Prime Park Way Natick, MA 01760 info@atria.com
+
+ (508) 650-1193 (phone) (508) 650-1196 (fax)
+
+ Originally contributed by Steve Turner
+ Edited by the author of this FAQ.
+
+ Last modified: _6/13/1997_
+
+ 4. How does CVS differ from TeamWare/SparcWorks?
+
+ TeamWare is a configuration management tool from Sun Microsystems, a
+ part of SparcWorks. It uses the same copy and merge model as CVS. The
+ central abstraction is a workspace, which corresponds to either a CVS
+ branch or a checked out module. TeamWare allows you to manipulate
+ workspaces directly, including moving and merging code between
+ workspaces. You can put your workspace on tape and continue to work
+ with it at home, just like you can with CVS. TeamWare is built upon
+ and compatible with SCCS.
+
+ TeamWare provides both a command line interface and a graphical
+ interface. The CodeManager tool will display the project as a tree of
+ workspaces, and allows you to manipulate them with drag and drop. The
+ other tools are VersionTool that displays and manipulates a dag with a
+ version history of a single file, CheckPoint that will create symbolic
+ tags, MakeTool, a make compatible tool with a GUI, and FileMerge which
+ will interactively merge files when needed (like emerge for emacs). If
+ you have a sun, you can try /usr/old/mergetool for an old SunView
+ version of FileMerge.
+
+ Email: sunprosig@sun.com
+
+ Originally extracted from TeamWare
+ Marketing literature by Per Abrahamsen.
+ Edited by the author of this FAQ.
+
+ For more information, contact:
+
+ SunExpress, Inc. P.O. Box 4426 Bridgeton, MO 63044-9863 (800)873-7869
+
+ Last modified: _6/13/1997_
+
+ 5. How does CVS differ from Aegis?
+
+ Aegis appears to be a policy-setting tool that allows you to use other
+ sub-programs (make, RCS, etc.) to implement pieces of the imposed
+ policy.
+
+ The initial document seems to say that most Unix tools are inadequate
+ for use under Aegis.
+
+ It is not really similar to CVS and requires a different mindset.
+
+ [[Need more info here.]]
+
+ Last modified: _6/13/1997_
+
+ 6. How does CVS differ from Shapetools?
+
+ Shapetools includes a build mechanism (called Shape, not surprisingly)
+ that is aware of the version mechanism, and some dependency tracking.
+ It is based on a file system extension called Attributed File System,
+ which allows arbitrary-sized "attributes" to be associated with a
+ file. Files are version controlled in a manner similar to RCS.
+ Configurations are managed through the Shapefile, an extension of the
+ Makefile syntax and functionality. Shape includes version selection
+ rules to allow sophisticated selection of component versions in a
+ build.
+
+ Shapetools' concurrency control is pessimistic, in contrast to that of
+ CVS. Also, there's very limited support for branching and merging. It
+ has a built-in policy for transitioning a system from initial
+ development to production.
+
+ Contributed by Don Dwiggins
+
+ Last modified: _6/13/1997_
+
+ 7. How does CVS differ from TeamNet?
+
+ TeamNet is a configuration management tool from TeamOne.
+
+ For more information, contact:
+
+ TeamOne 710 Lakeway Drive, Ste 100 Sunnyvale, CA 94086 (800) 442-6650
+
+ Contributed by Steve Turner
+
+ Last modified: _6/13/1997_
+
+ 8. How does CVS differ from ProFrame?
+
+ ProFrame is a new system integration framework from IBM. ProFrame is
+ compliant with the CFI (CAD Framework Initiative) industry standards,
+ including the Scheme extension language.
+
+ ProFrame consists of three major components: (1) the Process Manager
+ that automates your local design methodology (2) the Design Data
+ Manager handles configuration management, and (3) Inter-tool
+ Communication to provide a communication path among tools running on
+ heterogeneous servers.
+
+ The Design Data Manager(2) is probably the appropriate component to
+ compare to CVS. The Design Data Manager provides version control with
+ checkin/checkout capability, configuration management, and data
+ dependency tracking. A graphical data selection interface is provided.
+ Using this interface, you may create and manipulate objects and
+ hierarchy structures, view the revision history for an object, and
+ view and assign attributes to a design object.
+
+ The ProFrame server currently runs only on RS6000, but clients may be
+ a wide variety of Unix platforms. Contact IBM for the latest platform
+ information.
+
+ For more information, contact:
+
+ IBM EDA Marketing and Sales P.O. Box 950, M/S P121 Poughkeepsie, NY
+ 12602 (800) 332-0066
+
+ Contributed by Steve Turner
+ [extracted from the ProFrame 1.1.0 datasheet]
+
+ Last modified: _6/13/1997_
+
+ 9. How does CVS differ from CaseWare/CM?
+
+ CaseWare/CM is a software configuration management product from
+ CaseWare, Inc. CaseWare/CM may be customized to support a wide variety
+ of methodologies, including various phases of the software lifecycle,
+ and different access rights for users.
+
+ A GUI is provided to view version histories and configurations. A
+ merge tools is also included. CaseWare supports type-specific
+ lifecycles, which allows different types of files to move through
+ different lifecycles. Also provided is a build facility to support
+ automatic dependency analysis, parallel, distributed, and remote
+ builds, and variant releases.
+
+ CaseWare/CM has been integrated with other CASE tools, including
+ FrameMaker, ALSYS Ada, CodeCenter/Object Center, HP SoftBench, and
+ Software Through Pictures. CaseWare also offers CaseWare/PT, a problem
+ tracking system to integrate change requests with configuration
+ management.
+
+ Multiple vendors and operating systems are supported.
+
+ For more information, contact:
+
+ CaseWare, Inc. 108 Pacifica, 2nd Floor Irvine, CA 92718-3332 (714)
+ 453-2200 (phone) (714) 453-2276 (fax)
+
+ Contributed by Steve Turner
+ [extracted from the CaseWare/CM data sheet]
+
+ Last modified: _6/13/1997_
+
+ 10. How does CVS differ from Sublime?
+
+ Produced by AT&T. Sablime uses SCCS as the underlying source code
+ control system. It uses some other control system (called sbcs I
+ think) for managing binary files. It uses lock, edit, comit, unlock
+ mechanism. It has a motif based GUI and curses based GUI (that works
+ only with ksh, not tcsh, or bash) to do more common tasks. It has even
+ a command line interface.
+
+ Changing source happens as a result of MR. A testing person or a
+ developer assigns an MR (modification request) to a group of people.
+ They are allowed to take out files under that MR and change them and
+ check them back in. You can set up dependencies between and MR and do
+ release management to say "I want the sources to include these MRs"
+ etc. It is a reasonably good maintanance system. It is bit heavy
+ weight though, and the interface is not too polished and does not work
+ on windows (though that may have changed). rama@savera.com
+
+ Last modified: _12/12/1997_
+
+ 11. How does CVS differ from PVCS?
+
+ PVCS works on single files like RCS and SCCS, CVS works on complete
+ subsystems. PVCS has a make utility (called a configuration builder),
+ CVS does not. PVCS has a GUI interface for Unix, DOS, OS/2, and MS
+ Windows.
+
+ Intersolv, Inc.
+ 1700 NW 167th Place
+ OR 97006
+
+ Contributed by Per Abrahamsen
+ [Extracted from Intersolv Marketing literature.]
+
+ Last modified: _6/13/1997_
+
+ 12. How does CVS differ from CMVC?
+
+ CMVC is an IBM Configuration Management and Version Control system.
+ (Though I'm not certain that's the right acronym expansion.) It runs
+ on Suns, HPs, RS6000s, OS/2 and Windows.
+
+ Other than revision control, it apparently has features to manage
+ releases, bug tracking and the connection between alterations and
+ reported bugs and feature requests. It is a client/server system,
+ based on a choice of commercial Relational Database systems, and it
+ provides a Motif or command line interface.
+
+ Unlike CVS, it uses a strict locking protocol to serialize source code
+ alterations.
+
+ Last modified: _6/13/1997_
+
+ Category: /What_is_CVS_/What_do_you_mean_by_/
+
+ " + What do you mean by . . .? (Definitions)"
+
+ 1. What are "The Repository", "$CVSROOT" and "CVSROOT"?
+
+ The Repository is a directory tree containing the CVS administrative
+ files and all the RCS files that constitute "imported" or "committed"
+ work. The Repository is kept in a shared area, separate from the
+ working areas of all developers.
+
+ Users of CVS must set their "CVSROOT" environment variable to the
+ absolute pathname of the head of the Repository. Most command line
+ interpreters replace an instance of "$CVSROOT" with the value of the
+ "CVSROOT" environment variable. By analogy, in this document
+ "$CVSROOT" is used as shorthand for "the absolute pathname of the
+ directory at the head of the Repository".
+
+ One of the things found in $CVSROOT is a directory named CVSROOT. It
+ contains all the "state", the administrative files, that CVS needs
+ during execution. The "modules", "history", "commitinfo", "loginfo"
+ and other files can be found there. See 4B.2 for more information
+ about CVSROOT files.
+
+ Last modified: _6/13/1997_
+
+ 2. What is an RCS file?
+
+ An RCS file is a text file containing the source text and the revision
+ history for all committed revisions of a source file. It is stored
+ separately from the working files, in a directory hierarchy, called
+ the Repository.
+
+ RCS is the "Revision Control System" that CVS uses to manage
+ individual files. RCS file names normally end in ",v", but that can be
+ altered (via the RCS -x option) to conform to file naming standards on
+ platforms with unusual filename limitations.
+
+ Last modified: _6/13/1997_
+
+ 3. What is a working file?
+
+ A working file is a disk file containing a checked-out copy of a
+ source file that earlier had been placed under CVS. If the working
+ file has been edited, the changes since the last committed revision
+ are invisible to other users of CVS.
+
+ Last modified: _6/13/1997_
+
+ 4. What is a working directory (or working area)?
+
+ A working directory is the place where you work and the place from
+ which you "commit" files.
+
+ The "checkout" command creates a tree of working directories, filling
+ them with working files. Each working directory contains a
+ sub-directory named ./CVS containing three administrative files, which
+ are created by "checkout" and are always present:
+
+ ./CVS/Entries
+ contains information about working files.
+
+ ./CVS/Repository
+ contains the location of the directory within the
+ Repository that was used to create the working directory.
+
+ ./CVS/Root
+ contains the value of $CVSROOT at the time you created
+ the working directory.
+
+ Other files may also appear in ./CVS depending on the state of your
+ working directory:
+
+ ./CVS/Tag
+ contains the "sticky tag" associated with the whole
+ directory. See 3A.2 for its main purpose.
+ [Created by "checkout" or "update" when using "-r <tag>".]
+ [Deleted by "checkout" or "update" when using '-A'.]
+
+ ./CVS/Entries.Static
+ contains a fixed list of working files. If this file
+ exists, an "update" doesn't automatically bring newly
+ added files out of the Repository.
+ [Created and maintained by hand.]
+
+ ./CVS/Checkin.prog
+ contains a program to run whenever anything in the
+ working directory is committed.
+ [Created by checkout if "-i <prog>" appears in the
+ modules file for the checked-out module.]
+
+ ./CVS/Update.prog
+ contains a program to run whenever anything in the
+ working directory is updated.
+ [Created by checkout if "-u <prog>" appears in the
+ modules file for the checked-out module.]
+
+ ./CVS/<file>,p ./CVS/<file>,t
+ contain (possibly zero-length) state information about an
+ "add" that has not been committed.
+ [Created by "add".]
+ [Deleted by "commit" or "remove".]
+
+ Last modified: _6/13/1997_
+
+ 5. What is "checking out"?
+
+ "Checking out" is the act of using the "checkout" command to copy a
+ particular revision from a set of RCS files into your working area.
+ You normally execute "checkout" only once per working directory (or
+ tree of working directories), maintaining them thereafter with the
+ "update" command.
+
+ See section 3C on the "checkout" command.
+
+ Last modified: _6/13/1997_
+
+ 6. What is a revision?
+
+ A "revision" is a version of a file that was "committed" ("checked
+ in", in RCS terms) some time in the past. CVS (and RCS) can retrieve
+ any file that was committed by specifying its revision number or its
+ "tag" ("symbolic name", in RCS terms).
+
+ In CVS, a "tag" is more useful than a revision number. It usually
+ marks a milestone in development represented by different revision
+ numbers in different files, all available as one "tagged" collection.
+
+ Sometimes the word "revision" is used as shorthand for "the file you
+ get if you retrieve (via "checkout" or "update") the given revision
+ from the Repository."
+
+ Last modified: _6/13/1997_
+
+ 7. What is a "Tag"?
+
+ A "Tag" is a symbolic name, a synonym or alias for a particular
+ revision number in a file. The CVS "tag" command places the same "Tag"
+ on all files in a working directory, allowing you to retrieve those
+ files by name in the future.
+
+ The CVS "Tag" is implemented by applying RCS "symbols" to each
+ individual file. The Tags on a file (or collection of files) may be
+ displayed using the "log" command.
+
+ Last modified: _6/13/1997_
+
+ 8. What are "HEAD" and "BASE"?
+
+ HEAD and BASE are built-in tags that don't show up in the "log" or
+ "status" listings. They are interpreted directly by CVS.
+
+ "HEAD" refers to the latest revision on the current branch in the
+ Repository. The current branch is either the main line of development,
+ or a branch in development created by placing a branch tag on a set of
+ files and checking out that branch.
+
+ "BASE" refers to the revision on the current branch you last checked
+ out, updated, or committed. If you have not modified your working
+ file, "BASE" is the committed revision matching it.
+
+ Most of the time BASE and HEAD refer to the same revision. They can
+ become different in two ways:
+
+ Someone else changed HEAD by committing a new revision of your file
+ to the Repository. You can pull BASE up to equal HEAD by executing
+ "update".
+
+ You moved BASE backward by executing "checkout" or "update" with the
+ option "-r <rev/tag>" or "-D <date>". CVS records a sticky tag and
+ moves your files to the specified earlier revision. You can clear the
+ sticky tag and pull BASE up to equal HEAD again by executing "update
+ -A".
+
+ Last modified: _6/13/1997_
+
+ 9. What is a Branch?
+
+ In general, a branch is any mechanism that allows one or more
+ developers to modify a file without affecting anyone other than those
+ working on the same branch.
+
+ There are four kinds of "branch" CVS can manage:
+
+ The Vendor Branch.
+
+ A single vendor branch is supported. The "import" command takes a
+ sequence of releases from a source code vendor (called a "vendor" even
+ if no money is involved), placing them on a special "Vendor" branch.
+ The Vendor branch is considered part of the "Main line" of
+ development, though it must be merged into locally modified files on
+ the RCS Main branch before the "import" is complete.
+
+ See Section 3H ("import").
+
+ Your Working directory.
+
+ A checked-out working directory, can be treated like a private branch.
+ No one but you can touch your files. You have complete control over
+ when you include work committed by others. However, you can't commit
+ or tag intermediate versions of your work.
+
+ A Development branch.
+
+ A group of developers can share changes among the group, without
+ affecting the Main line of development, by creating a branch. Only
+ those who have checked-out the branch see the changes committed to
+ that branch. This kind of branch is usually temporary, collapsing
+ (i.e. merge and forget) into the Main line when the project requiring
+ the branch is completed.
+
+ You can also create a private branch of this type, allowing an
+ individual to commit (and tag) intermediate revisions without changing
+ the Main line. It should be managed exactly like a Development Branch
+ -- collapsed into the Main line (or its parent branch, if that is not
+ the Main Branch) and forgotten when the work is done.
+
+ A Release branch.
+
+ At release time, a branch should be created marking what was released.
+ Later, small changes (sometimes called "patches") can be made to the
+ release without including everything else on the Main line of
+ development. You avoid forcing the customer to accept new, possibly
+ untested, features added since the release. This is also the way to
+ correct bugs found during testing in an environment where other
+ developers have continued to commit to the Main line while you are
+ testing and packaging the release.
+
+ Although the internal format of this type of branch (branch tag and
+ RCS branches) is the same as in a development branch, its purpose and
+ the way it is managed are different. The major difference is that a
+ Release branch is normally Permanent. Once you let a release out the
+ door to customers, or to the next stage of whatever process you are
+ using, you should retain forever the branch marking that release.
+
+ Since the branch is permanent, you cannot incorporate the branch fixes
+ into the Main line by "collapsing" (merging and forgetting) the
+ release branch. For large changes to many files on the release branch,
+ you will have to perform a branch merge using "update -j <rev> -j
+ <rev>". (See 4C.7)
+
+ The most common way to merge small changes back into Main line
+ development is to make the change in both places simultaneously. This
+ is faster than trying to perform a selective merge.
+
+ See 1D.12 (merges) and Section 4C, on Branching for more info.
+
+ Last modified: _6/13/1997_
+
+ 10. What is "the trunk"?
+
+ Another name for the RCS Main Branch. The RCS Main Branch is related,
+ but not equivalent, to both the CVS Main branch and what developers
+ consider to be the Main line of development. See 3H.3 and Section 4C
+ on Branching.
+
+ Last modified: _6/13/1997_
+
+ 11. What is a module?
+
+ In essence, a module is a name you hand to the "checkout" command to
+ retrieve one or more files to work on. It was originally intended to
+ be a simple, unique name in the "modules" file attached to a directory
+ or a subset of files within a directory.
+
+ The module idea is now a somewhat slippery concept that can be defined
+ in two different ways:
+ * A module is an argument to "checkout". There are three types:
+ 1. An entry in the modules file. A "module" name as described in
+ 'B.' below.
+ 2. A relative path to a directory or file in the Repository.
+ 3. A mixed-mode string of "modulename/relative-path". Everything
+ up to the first slash ('/') is looked up as a module. The
+ relative path is appended to the directory associated with
+ the module name and the resulting path is checked out as in
+ #2 above.
+ * A module is a unique (within the file) character string in the
+ first column of the modules file. There are five types:
+ 1. A name for a directory within the Repository that allows you
+ to ignore the parent directories above it.
+ Example:
+ emacs gnu/emacs
+ 2. A name for a subset of the files within such a directory.
+ Example:
+ ls unix/bin Makefile ls.c
+ The 2nd through Nth strings in the above can be files,
+ directories or module substitutions. No relative paths.
+ A module substitution occurs when you use a '&module-name'
+ reference. The module-name referred to is logically
+ substituted for the '&module-name' string.
+ 3. A relative pathname to a directory within the Repository
+ which, when checked out, creates an image of part of the
+ Repository structure in your current directory.
+ Example:
+ gnu/emacs -o /bin/emacs.helper gnu/emacs
+ The files checked out are exactly the same as the files
+ "checkout" would retrieve if the path weren't even in the
+ modules file. The only reason to put this kind of relative
+ pathname into the modules file is to hook one of the helper
+ functions onto it.
+ 4. A relative pathname to a single file within the Repository
+ which, when checked out, creates something you probably don't
+ want: It creates a directory by the name of the file and puts
+ the file in it.
+ Example:
+ gnu/emacs/Makefile -o /bin/emacs.helper gnu/emacs Makefile
+ The file checked out is the same as what you would get if you
+ handed the relative pathname to the "checkout" command. But
+ it puts it in a strange place. The only reason to do this is
+ to hook a helper function onto a specific file name.
+ 5. An alias consisting of a list of any of the above, including
+ other aliases, plus exceptions.
+ Example:
+ my_work -a emacs !emacs/tests gnu/bison unix/bin/ls.c
+ The exception "!emacs/test" above is functionally equivalent
+ to specifying "!emacs/tests" on the "checkout" command line.
+
+ Another way to look at it is that the modules file is simply another
+ way to "name" files. The hierarchical directory structure provides
+ another. You should use whatever turns out to be simplest for your
+ development group.
+
+ See 4G.2 for some specific ideas about how to use the modules file.
+
+ Last modified: _11/12/1997_
+
+ 12. What does "merge" mean?
+
+ A merge is a way of combining changes made in two independent copies
+ of a common starting file. Checking out an RCS revision produces a
+ file, so for the purposes of a merge "file" and "revision" are
+ equivalent. So, we can say there are always three "files" involved in
+ a merge:
+
+ The original, starting, "base" or "branch point" file.
+
+ A copy of the base file modified in one way.
+
+ Another copy of the base file modified in a different way.
+
+ Humans aren't very good at handling three things at once, so the
+ terminology dealing with merges can become strained. One way to think
+ about it is that all merges are performed by inserting the difference
+ between a base revision and a later revision (committed by someone
+ else) into your working file. Both the "later" revision and your
+ working file are presumed to have started life as a copy of the "base"
+ revision.
+
+ In CVS, there are three main types of "merge":
+
+ The "update" command automatically merges revisions committed by
+ others into your working file. In this case, the three files involved
+ in the merge are:
+
+ Base: The revision you originally checked out. Later: A revision
+ committed onto the current branch after you checked out the Base
+ revision. Working: Your working file. The one lying in the working
+ directory containing changes you have made.
+
+ The "update -j <branch_tag> {optional files}" command merges changes
+ made on the given branch into your working files, which is presumed to
+ be on the Main line of development.
+
+ See 4C.6
+
+ The "update -j <rev> -j <rev> {optional files}" command merges the
+ difference between two specified revisions into files in your working
+ directory. The two revisions <rev> are usually on the same branch and,
+ when updating multiple files, they are most useful when they are Tag
+ names rather than numeric revisions.
+
+ See 4C.7
+
+ Last modified: _6/13/1997_
+
+ Category: /What_is_CVS_/What_is_CVS_Whats_it/
+
+ " + What is CVS? What's it for? Why CVS?"
+
+ 1. What does CVS stand for? Can you describe it in one sentence?
+
+ "CVS" is an acronym for the "Concurrent Versions System".
+
+ CVS is a "Source Control" or "Revision Control" tool designed to keep
+ track of source changes made by groups of developers working on the
+ same files, allowing them to stay in sync with each other as each
+ individual chooses.
+
+ Last modified: _6/13/1997_
+
+ 2. What is CVS for? What does it do for me?
+
+ CVS is used to keep track of collections of files in a shared
+ directory called "The Repository". Each collection of files can be
+ given a "module" name, which is used to "checkout" that collection.
+
+ After checkout, files can be modified (using your favorite editor),
+ "committed" back into the Repository and compared against earlier
+ revisions. Collections of files can be "tagged" with a symbolic name
+ for later retrieval.
+
+ You can add new files, remove files you no longer want, ask for
+ information about sets of files in three different ways, produce patch
+ "diffs" from a base revision and merge the committed changes of other
+ developers into your working files.
+
+ Last modified: _6/13/1997_
+
+ 3. How does CVS work?
+
+ CVS saves its version-control information in RCS files stored in a
+ directory hierarchy, called the Repository, which is separate from the
+ user's working directory.
+
+ Files in the Repository are stored in a format dictated by the RCS
+ commands CVS uses to do much of its real work. RCS files are standard
+ byte-stream files with an internal format described by keywords stored
+ in the files themselves.
+
+ To begin work, you execute a "checkout" command, handing it a module
+ name or directory path (relative to the $CVSROOT variable) you want to
+ work on. CVS copies the latest revision of each file in the specified
+ module or directory out of the Repository and into a directory tree
+ created in your current directory. You may specify a particular branch
+ to work on by symbolic name if you don't want to work on the default
+ (main or trunk) branch.
+
+ You may then modify files in the new directory tree, build them into
+ output files and test the results. When you want to make your changes
+ available to other developers, you "commit" them back into the
+ Repository.
+
+ Other developers can check out the same files at the same time. To
+ merge the committed work of others into your working files you use the
+ "update" command. When your merged files build and test correctly, you
+ may commit the merged result. This method is referred to as
+ "copy-modify-merge", which does not require locks on the source files.
+
+ At any time, usually at some milestone, you can "tag" the committed
+ files, producing a symbolic name that can be handed to a future
+ "checkout" command. A special form of "tag" produces a branch in
+ development, as usually happens at "release" time.
+
+ When you no longer plan to modify or refer to your local copy of the
+ files, they can be removed.
+
+ Last modified: _6/13/1997_
+
+ 4. What is CVS useful for?
+
+ CVS is intended to handle source control for files in three major
+ situations:
+
+ Multiple developers working on the same files.
+
+ The major advantage of using CVS over the simpler tools like RCS or
+ SCCS is that it allows multiple developers to work on the same sources
+ at the same time.
+
+ The shared Repository provides a rendezvous for committed sources that
+ allows developers a fair amount of flexibility in how often to publish
+ (via the "commit" command) changes or include work committed by others
+ (via the "update" command).
+
+ Tracking a stream of releases from a source vendor.
+
+ If you are making changes to sources distributed by someone else, the
+ CVS feature, called the Vendor Branch, allows you to combine local
+ modifications with repeated vendor releases.
+
+ I have found this most useful when dealing with sources from three
+ major classes of source vendor:
+
+ Large companies who send you tapes full of the latest release (e.g.
+ Unix OS vendors, database companies).
+
+ Public Domain software which *always* requires work.
+
+ Pseudo-Public sources which may require work. (e.g. GNU programs, X,
+ CVS itself, etc.)
+
+ Branching development.
+
+ Aside from the "Vendor Branch", there are three kinds of "branches in
+ development" that CVS can support:
+
+ Your working directory can be treated as a private branch.
+
+ A Development branch can be shared by one or more developers.
+
+ At release time, a branch is usually created for bug fixes.
+
+ (See 1D.9 and Section 4C for more info on branches.)
+
+ CVS's branch support is a bit primitive, but it was designed to allow
+ you to create branches, work on them for while and merge them back
+ into the main line of development. You should also be able to merge
+ work performed on the main branch into the branch you are working on.
+ Arbitrary sharing and merging between branches is not currently
+ supported.
+
+ Last modified: _6/13/1997_
+
+ 5. What is CVS *not* useful for?
+
+ CVS is not a build system.
+
+ Though the structure of your Repository and modules file interact with
+ your build system (e.g. a tree of Makefiles), they are essentially
+ independent.
+
+ CVS does not dictate how you build anything. It merely stores files
+ for retrieval in a tree structure you devise.
+
+ CVS does not dictate how to use disk space in the checked out working
+ directories. If you require your Makefiles or build procedures to know
+ the relative positions of everything else, you wind up requiring the
+ entire Repository to be checked out. That's simply bad planning.
+
+ If you modularize your work, and construct a build system that will
+ share files (via links, mounts, VPATH in Makefiles, etc.), you can
+ arrange your disk usage however you like.
+
+ But you have to remember that *any* such system is a lot of work to
+ construct and maintain. 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.
+
+ Of course, you should use CVS to maintain the tools created to support
+ such a build system (scripts, Makefiles, etc).
+
+ CVS is not a substitute for management.
+
+ You and your project leaders are expected to plan what you are doing.
+ Everyone involved must be aware of schedules, merge points, branch
+ names, release dates and the range of procedures needed to build
+ products. (If you produce it and someone else uses it, it is a
+ product.) CVS can't cover for a failure to manage your project.
+
+ CVS is an instrument for making sources dance to your tune. But you
+ are the piper and the composer. No instrument plays itself or writes
+ its own music.
+
+ CVS is not a substitute for developer communication.
+
+ When faced with conflicts within a single file, most developers manage
+ to resolve them without too much effort. But a more general definition
+ of "conflict" includes problems too difficult to solve without
+ communication between developers.
+
+ CVS cannot determine when simultaneous changes within a single file,
+ or across a whole collection of files, will logically conflict with
+ one another. Its concept of a "conflict" is purely textual, arising
+ when two changes to the same base file are near enough to spook the
+ merge command into dropping conflict markers into the merged file.
+
+ CVS is not capable of figuring out distributed conflicts in program
+ logic. For example, if you change the arguments to function X defined
+ in file A and, at the same time, edit file B, adding new calls to
+ function X using the old arguments. You are outside the realm of CVS's
+ competence.
+
+ Acquire the habit of reading specs and talking to your peers.
+
+ CVS is not a configuration management system.
+
+ 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:
+
+ * Source control.
+ * Dependency tracking.
+ * Build systems (i.e. What to build and how to find
+ things during a build. What is shared? What is local?)
+ * Bug tracking.
+ * Automated Testing procedures.
+ * Release Engineering documentation and procedures.
+ * Tape Construction.
+ * Customer Installation.
+ * A way for users to run different versions of the same
+ software on the same host at the same time.
+
+ CVS provides only the first.
+
+ Last modified: _6/13/1997_
+
+ Category: /What_is_CVS_/Where_do_I_find_CVS_/
+
+ " + Where do I find CVS? Where can I find Help?"
+
+ 1. How do I get more information about CVS?
+
+ The first thing I would do is to read the Info file that comes with
+ the CVS sources under "doc". You can format and read the cvs.texinfo
+ file in two ways: 1. Use TeX to format it and a "dvips" command to
+ print it and 2. Install the cvs.info files that are created by the
+ Makefile and read them online using the Emacs "info-mode" or a
+ stand-alone "info" reader.
+
+ Then I'd run "cvsinit" to set up a Repository and read the man page
+ while trying out the commands.
+
+ Type "cvs -H" for general help or "cvs -H command" for
+ command-specific help.
+
+ For background, you can read the original CVS paper (in the source
+ tree, under "doc"). It describes the purpose of CVS and some of how it
+ was designed. Note that the emphasis of the document (especially on
+ multiple vendors providing the same sources) is somewhat out of date.
+
+ For more detailed information about "internals", read the man pages
+ for RCS. If you are a programmer, you can also read the source code to
+ CVS.
+
+ Other information and tutorials may be available in the "doc"
+ directory of the FTP archive described below.
+
+ For current information, and a fair amount of detail, join the
+ info-cvs mailing list described below.
+
+ Last modified: _6/13/1997_
+
+ 2. Is there an archive of CVS material?
+
+ An anonymous FTP area has been set up. It contains many of the CVS
+ files you might want, including extra documentation, patches and a
+ copy of the latest release.
+
+ ftp ftp.delos.com
+ >>> User: anonymous
+ >>> Passwd: <Your Internet address>
+ cd /pub/cvs
+ get README
+ get Index
+
+ The README has more (and more up-to-date) information. The Index
+ contains a terse list of what is in the archive.
+
+ A WWW home page is also available at http://www.delos.com/cvs.
+
+ Last modified: _6/13/1997_
+
+ 3. How do I get files out of the archive if I don't have FTP?
+
+ Use one of the FTP<->Email servers. These are the ones I've been told
+ about:
+
+ FTPMAIL service is available from the same host as the FTP server
+ described above. Send mail to "ftpmail@delos.com" containing "help" in
+ the body of the message. For example, on most Unix systems, you can
+ type:
+
+ echo help | Mail ftpmail@delos.com
+
+ The FTPMAIL server will respond with a document describing how to use
+ the server. If the "Mail" command doesn't exist on your system, try
+ "mailx", "/usr/ucb/mail" or "/bin/mail".
+
+ If you are on BITNET, use Princeton's BITFTP server. Type
+
+ echo 'send help' | Mail bitftp@pucc.princeton.edu
+
+ (It is likely that only BITNET addresses can use this one.)
+
+ Other possibilities I've heard of from the net: (Try the one closest
+ to you.)
+
+ ftpmail@decwrl.dec.com ftpmail@sunsite.unc.edu ftpmail@cs.arizona.edu
+ ftpmail@cs.uow.edu.au ftpmail@doc.ic.ac.uk
+
+ Last modified: _6/13/1997_
+
+ 4. How do I get a copy of the latest version of CVS?
+
+ The latest released version of CVS and all the programs it depends on
+ should be available through anonymous FTP on any FSF archive. The main
+ FSF archive is at "prep.ai.mit.edu". There are mirrors of the FSF
+ archive on UUNET and other large Internet sites.
+
+ Program(s) Suggested revision
+ ----------- -----------------------
+ CVS 1.5
+ RCS 5.7 (latest version available today)
+ GNU diff 2.7 (or later) [contained in diffutils-2.7]
+ GDBM 1.5 (or later) [optional]
+
+ The GNU version of diff is suggested by both the RCS and CVS
+ configuration instructions because it works better than the standard
+ version.
+
+ It is a good idea not to accept the versions of CVS, RCS or diff you
+ find lying on your system unless you have checked out their
+ provenance. Using inconsistent collections of tools can cause you more
+ trouble than you can probably afford.
+
+ The FTP archive mentioned above should contain the latest official
+ release of CVS, some official and unofficial patches and possibly
+ complete patched versions of CVS in use somewhere.
+
+ Last modified: _6/13/1997_
+
+ 5. Is there a mailing list devoted to CVS? How do I find it?
+
+ An Internet mailing list named "info-cvs" grew out of the private
+ mailing list used by the CVS 1.3 alpha testers in early 1992.
+ Throughout 1994, the list received an average of 100 messages per
+ month.
+
+ You can add yourself to the mailing list by sending an Email message
+ to:
+
+ info-cvs-request@prep.ai.mit.edu
+
+ (Don't forget the "-request" or you'll send a message to the whole
+ list, some of whom are capable of remote execution.)
+
+ Mail to the whole list should be sent to:
+
+ info-cvs@prep.ai.mit.edu
+
+ An archive of the mailing list is maintained in the FTP archive
+ mentioned above.
+
+ Last modified: _6/13/1997_
+
+ 6. What happened to the CVS Usenet newsgroup I heard about?
+
+
+ A Usenet newsgroup named "gnu.cvs.info" was announced in April
+ 1993, with an expected creation date of August, 1993. However,
+ nothing came of this.
+
+ If you want to discuss CVS on usenet, the correct group is
+ comp.software.config-mgmt (which also covers other configuration
+ management systems). Someday it might be possible to create a
+ comp.software.config-mgmt.cvs, but only if there is sufficient
+ CVS traffic on comp.software.config-mgmt.
+
+ kingdon@cyclic.com
+
+ Last modified: _9/6/1997_
+ _________________________________________________________________
+
+ [Add an answer to this category]
+
+ [Category /]
+ _________________________________________________________________
+
+ _Search the FAQ-O-Matic:_ ____________________ ______
+ [matching all words]
+ Or look for questions modified in the last: [7.] ____
+ _________________________________________________________________
+
+ The FAQ-O-Matic lives at http://gille.loria.fr:7000/cgi-bin/faqomatic.
+ The code was written by Jon Howell, and the content by folks from all
+ over the web.
diff --git a/contrib/cvs/HACKING b/contrib/cvs/HACKING
index 89f7399e0e08..a1b3d37dd305 100644
--- a/contrib/cvs/HACKING
+++ b/contrib/cvs/HACKING
@@ -28,6 +28,12 @@ foo (arg)
bar (arg);
baz (arg);
}
+ switch (c)
+ {
+ case 'A':
+ aflag = 1;
+ break;
+ }
}
The file cvs-format.el contains settings for emacs and the NEWS file
@@ -64,12 +70,13 @@ 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).
+Do not use arbitrary limits (such as PATH_MAX) except perhaps when the
+operating system or some external interface requires it. We spent a
+lot of time getting rid of them, and we don't want to put them back.
+If you find any that we missed, please report it as with other bugs.
+In most cases such code will create security holes (for example, for
+anonymous readonly access via the CVS protocol, or if a WWW cgi script
+passes client-supplied arguments to CVS).
Although this is a long-term goal, it also would be nice to move CVS
in the direction of reentrancy. This reduces the size of the data
@@ -145,7 +152,7 @@ context diffs or unidiffs for patches.
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.
-Submit changes to bug-cvs@prep.ai.mit.edu.
+Submit changes to bug-cvs@gnu.org.
Generally speaking if you follow the guidelines in this file you can
expect a yes or no answer about whether your patch is accepted. But
@@ -185,7 +192,7 @@ 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.
+subscribe; to do so send mail to bug-cvs-request@gnu.org.
Other CVS discussions take place on the info-cvs mailing list
(send mail to info-cvs-request@prep.ai.mit.edu to subscribe) or on
diff --git a/contrib/cvs/INSTALL b/contrib/cvs/INSTALL
index 56328345c867..c13948c4ace3 100644
--- a/contrib/cvs/INSTALL
+++ b/contrib/cvs/INSTALL
@@ -1,13 +1,106 @@
First, read the README file. If you're still happy...
+First you need to obtain and install the CVS executables. If you got
+a distribution which contains executables, consult the installation
+instructions for that distribution. If you got source code, do not
+panic. On many platforms building CVS from source code is a
+straightforward process requiring no programming knowledge. See the
+section BUILDING FROM SOURCE CODE at the end of this file, which
+includes a list of platforms which have been tested.
+
+-------------------------------------------------------------------------------
+
+1) Take a look at the CVS documentation, if desired. For most
+ purposes you want doc/cvs.texinfo, also known as _Version Management
+ with CVS_ by Per Cederqvist et al. Looking at it might be as simple
+ as "info cvs" but this will depend on your installation; see README
+ for more details.
+
+ See what CVS can do for you, and if it fits your environment (or can
+ possibly be made to fit your environment). If things look good,
+ continue on. Alternately, just give CVS a try first then figure out
+ what it is good for.
+
+2) Set the CVSROOT environment variable to where you want to put your
+ source repository. See the "Setting up the repository" section of
+ the Cederqvist manual for details, but the quick summary is just to
+ pick some directory. We'll use /src/master as an example. For
+ users of a POSIX shell (sh/bash/ksh) on unix, the following
+ commands can be placed in user's ~/.profile, ~/.bash_profile file;
+ or in the site-wide /etc/profile:
+
+ CVSROOT=/src/master; export CVSROOT
+
+ For C shell users on unix place the following commands in the
+ user's ~/.cshrc, ~/.login, or /etc/chsrc file:
+
+ setenv CVSROOT /src/master
+
+ For Windows users, supposing the repository will be in
+ d:\src\master, place the following line in c:\autoexec.bat. On
+ Windows 95, autoexec.bat might not already exist. In that case,
+ just create a new file containing the following line.
+
+ set CVSROOT=:local:d:\src\master
+
+ If these environment variables are not already set in your current
+ shell, set them now by typing the above line at the command prompt
+ (or source the login script you just edited).
+ The instructions for the remaining steps assume that you have set
+ the CVSROOT environment variable.
+
+3) Create the master source repository. Again, the details are in
+ the "Setting up the repository" section of cvs.texinfo; the
+ one-line summary is:
+
+ $ cvs init
+
+ In this and subsequent examples we use "$" to indicate the command
+ prompt; do not type the "$".
+
+4) It might be a good idea to jump right in and put some sources or
+ documents directly under CVS control. From within the top-level
+ directory of your source tree, run the following commands:
+
+ $ cvs import -m "test distribution" ccvs CVS_DIST CVS-TEST
+
+ (Those last three items are, respectively, a repository location, a
+ "vendor tag", and a "release tag". You don't need to understand
+ them yet, but read the section "Starting new projects" in the
+ Cederqvist manual for details).
+
+5) Having done step 4, one should be able to checkout a fresh copy of the
+ sources you just imported and hack away at the sources with the
+ following command:
+
+ $ cd
+ $ cvs checkout ccvs
+
+ This will make the directory "ccvs" in your current directory and
+ populate it with the appropriate files and directories.
+
+6) You may wish to customize the various administrative files, in particular
+ modules. See the Cederqvist manual for details.
+
+7) Read the NEWS file to see what's new.
+
+8) Hack away.
+
+-------------------------------------------------------------------------------
+
+BUILDING FROM SOURCE CODE
+
+Tested platforms
+
CVS has been tested on the following platforms. The most recent
version of CVS reported to have been tested is indicated, but more
recent versions of CVS probably will work too. Please send updates to
-this list to bug-cvs@prep.ai.mit.edu (doing so in the form of a diff
-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.
+this list to bug-cvs@gnu.org (doing so in the form of a diff
+to this file, or at least exact suggested text, is encouraged).
+"tested" means, at a minimum, that CVS compiles and appears to work on
+simple (manual) testing. In many cases it also means "make check"
+and/or "make remotecheck" passes, but we don't try to list the
+platforms for which that is true.
Alpha:
DEC Alpha running OSF/1 version 1.3 using cc (about 1.4A2)
@@ -15,6 +108,7 @@ Alpha:
DEC Alpha running OSF/1 version 2.1 (about 1.4A2)
DEC Alpha running OSF/1 version 3.0 (1.5.95) (footnote 7)
DEC Alpha running OSF/1 version 3.2 (1.9)
+ DEC Alpha running Digital UNIX v4.0C using gcc 2.7.2.2 (1.9.14)
DEC Alpha running VMS 6.2 (1.8.85 client-only)
Cray:
J90 (CVS 970215 snapshot)
@@ -22,10 +116,11 @@ Cray:
HPPA:
HP 9000/710 running HP-UX 8.07A using gcc (about 1.4A2)
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)
HPPA 9000/735 running HP-UX A.09.05 (1.8.87)
+ HPPA running HP-UX 10.01 (1.7)
+ HPPA running HP-UX 10.20 using gcc 2.7.2.2 (1.9.14)
NextSTEP 3.3 (1.7)
i386 family:
Solaris 2.4 using gcc (about 1.4A2)
@@ -33,17 +128,23 @@ i386 family:
Unixware 2.1 (1.8.86)
ISC 4.0.1 (1.8.87)
Linux (kernel 1.2.x) (1.8.86)
+ Linux (kernel 2.0.x, RedHat 4.2) (1.9)
BSDI 2.0 (1.4.93) (footnote 5)
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)
+ Sequent Dynix/PTX 4.1.4 (1.9.20 or so + patches)
Lynx 2.3.0 080695 (1.6.86) (footnote 9)
Windows NT 3.51 (1.8.86 client; 1.8.3 local)
+ Windows NT 3.51 service pack 4 (1.9)
+ Windows NT 3.51 service pack 5 (1.9) -- DOES NOT WORK (footnote 11)
Windows NT 4.0 (1.9 client and local)
- Windows 95 (1.8.86 client and local)
- QNX 4 (1.7 + obvious patches)
+ Windows 95 (1.9 client and local)
+ QNX (1.9.1 + patches for strippath() and va_list)
OS/2 Version 3 using IBM C/C++ Tools 2.01 (1.8.86 + patches, client)
+ OS/2 Version 3 using EMX 0.9c (1.9.10 + patches, client)
+ OS/2 Version 3 using Watcom version ? (? - has this been tested?)
m68k:
Sun 3 running SunOS 4.1.1_U1 w/ bundled K&R /usr/5bin/cc (1.8.86+)
NextSTEP 3.3p1 (1.8.87)
@@ -57,6 +158,7 @@ MIPS:
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 using gcc 2.7.2 (1.8.87)
+ SGI running Irix 6.2 using SGI MIPSpro 6.2 and beta 7.2 compilers (1.9)
SGI running Irix-6.2 (1.9.8)
Siemens-Nixdorf RM600 running SINIX-Y (1.6)
PowerPC or RS/6000:
@@ -64,13 +166,15 @@ PowerPC or RS/6000:
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)
+ Lynx 2.5 (1.9) (footnote 10)
SPARC:
- Sun SPARC running SunOS 4.1.x (1.8.87)
+ Sun SPARC running SunOS 4.1.x using gcc 2.7.2.1 (1.9.14)
Sun SPARCstation 10 running Solaris 2.3 using gcc and cc (about 1.4A2)
Sun SPARCstation running Solaris 2.4 using gcc and cc (about 1.5.91)
Sun SPARC running Solaris 2.5 (1.8.87)
+ Sun SPARC running Solaris 2.5.1 using gcc 2.7.2.2 (1.9.14)
NextSTEP 3.3 (1.7)
- Sun SparcClassing running Linux 2.0.17, gcc 2.7.2 (1.8.87)
+ Sun SPARC 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).
@@ -117,11 +221,19 @@ VAX:
So after running configure I had to undef HAVE_DIRENT_H and
define HAVE_SYS_DIR_H.
+(footnote 10)
+ Had to compile with "make LIBS=-lbsd" (to get gethostbyname
+ and getservbyname).
+
+(footnote 11)
+ when I do a `cvs init' I get this message:
+ ci: 'RCS/loginfo,v' is not a regular file
+ ci: RCS/loginfo,v: Invalid argument
+ cvs [init aborted]: failed to checkin n:/safe/CVSROOT/loginfo
+
-------------------------------------------------------------------------------
-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):
+Building from source code under Unix:
1) Run "configure":
@@ -148,23 +260,8 @@ distribution, then skip to step 5):
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. 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. 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.
+ Unlike previous versions of CVS, you do not need to install RCS
+ or GNU diff.
NOTE: The configure program will cache the results of the previous
configure execution. If you need to re-run configure from scratch, you
@@ -221,11 +318,8 @@ distribution, then skip to step 5):
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.
- 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.
+2) Edit src/options.h. The defaults should be reasonable, and in fact
+ if you are lazy you can safely skip this step.
3) Try to build it:
@@ -257,65 +351,6 @@ distribution, then skip to step 5):
Depending on your installation's configuration, you may need to be
root to do this.
-5) Take a look at the CVS documentation.
-
- $ man cvs
-
- and
-
- $ info cvs
-
- See what it can do for you, and if it fits your environment (or can
- possibly be made to fit your environment). If things look good,
- continue on...
-
-6) Set up the master source repository. See the "Setting up the repository"
- section of cvs.texinfo for details; the one-line summary is (if you
- are putting the repository in /src/master):
- $ cvs -d /src/master init
-
-7) Have all users of the CVS system set the CVSROOT environment
- variable appropriately to reflect the placement of your source
- repository. If the above example is used, the following commands
- can be placed in user's ~/.profile, ~/.bash_profile file; or in the
- site-wide /etc/profile:
-
- CVSROOT=/src/master; export CVSROOT
-
- for sh/bash/ksh users, or place the following commands in the user's
- ~/.cshrc, ~/.login, or /etc/chsrc file:
-
- setenv CVSROOT /src/master
-
- for csh/tcsh users. If these environment variables are not already set
- in your current shell, set them now (or source the login script you
- just edited). You will need to have the CVSROOT environment variable
- set to continue on to the next step.
-
-8) It might be a good idea to jump right in and put the CVS distribution
- directly under CVS control. From within the top-level directory of the
- CVS distribution (the one that contains this README file) do the
- following commands:
-
- $ make distclean
- $ cvs import -m 'CVS 1.6 distribution' cvs CVS_DIST CVS-1_6
-
-9) Having done step 8, one should be able to checkout a fresh copy of the
- CVS distribution and hack away at the sources with the following command:
-
- $ cd
- $ cvs checkout cvs
-
- This will make the directory "cvs" in your current directory and
- populate it with the appropriate CVS files and directories.
-
-10) You may wish to customize the various administrative files, in particular
- modules. See cvs.texinfo for details.
-
-11) Read the NEWS file to see what's new.
-
-12) Hack away.
-
-------------------------------------------------------------------------------
Detailed information about your interaction with "configure":
@@ -351,13 +386,30 @@ behaviour:
appear to be.
-------------------------------------------------------------------------------
-Installation under Windows NT:
+
+Building from source code under Windows NT/95:
You may find interesting information in windows-NT/README.
-1) Using Microsoft Visual C++ version 2.1, open the project `cvsnt.mak',
- in the top directory of the CVS distribution.
+1) Using Microsoft Visual C++ 5.x, open the project `cvsnt.dsp',
+ in the top directory of the CVS distribution. If you have an older
+ version of Visual C++, take a look at windows-NT/README.
2) Choose "Build cvs.exe" from the "Project" menu.
-3) MSVC will place the executable file cvs.exe in WinDebug, or whatever
+3) MSVC will place the executable file cvs.exe in WinRel, or whatever
your target directory is.
+
+-------------------------------------------------------------------------------
+
+Building from source code under other platforms:
+
+For OS/2, see os2/README and emx/README.
+
+For VMS, see README.VMS
+
+For Macintosh, see macintosh/README.MacCVS
+
+For a Java client, see jCVS (which is a separate package from CVS
+itself, but which might be preferable to the Macintosh port mentioned
+above, for example).
+
-------------------------------------------------------------------------------
diff --git a/contrib/cvs/MINOR-BUGS b/contrib/cvs/MINOR-BUGS
index ba6fb1821111..9eb0e7b5f537 100644
--- a/contrib/cvs/MINOR-BUGS
+++ b/contrib/cvs/MINOR-BUGS
@@ -45,8 +45,8 @@ particular reason to think the bug is fixed -kingdon, Sep 96).
...
I claim that CVS dirs should be ignored.
- (I don't *think* this always happens; is "-I !" getting picked up somewhere
- something like that? -kingdon, Sep 96)
+ (This reportedly happens if "cvs add CVS" (or "cvs add *")
+ is followed by "cvs status", in client/server mode - CVS 1.9).
* On remote checkout, files don't have the right time/date stamps in
the CVS/Entries files. Doesn't look like the C/S protocol has any
diff --git a/contrib/cvs/Makefile.in b/contrib/cvs/Makefile.in
index 491097e4279f..ff75cfba5b46 100644
--- a/contrib/cvs/Makefile.in
+++ b/contrib/cvs/Makefile.in
@@ -89,12 +89,12 @@ DISTFILES = \
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 \
+ cvsnt.mak cvsnt.dsp \
.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 zlib src
+USOURCE_SUBDIRS = lib zlib diff src
# All other subdirs:
SUBDIRS = ${USOURCE_SUBDIRS} man doc contrib tools \
windows-NT os2 emx macintosh vms
@@ -188,18 +188,21 @@ saber:
check:
cd lib ; $(MAKE) $(FLAGS_TO_PASS)
cd zlib ; $(MAKE) $(FLAGS_TO_PASS)
+ cd diff ; $(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 diff ; $(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 diff ; $(MAKE) $(FLAGS_TO_PASS)
cd src ; $(MAKE) $(FLAGS_TO_PASS) installcheck
.PHONY: lint
@@ -239,7 +242,7 @@ spec:
echo > .fname cvs-`cat .version`
rm -f `cat .fname`.spec
sed < $(top_srcdir)/cvs.spec \
- -e 's/@VERSION@/'`cat .version`'/' \
+ -e 's/@VERSION@/'`cat .version`'/g' \
> `cat .fname`.spec
diff --git a/contrib/cvs/NEWS b/contrib/cvs/NEWS
index b2827cfd21a4..5e746fe6fe12 100644
--- a/contrib/cvs/NEWS
+++ b/contrib/cvs/NEWS
@@ -1,5 +1,30 @@
Changes since 1.9:
+* One can now authenticate and encrypt using the GSSAPI network
+security interface. For details see the description of :gserver: in
+CVSROOT, and the -a global option.
+
+* All access to RCS files is now implemented internally rather than by
+calling RCS programs. The main user-visible consequence of this is
+that there is no need to worry about making sure that CVS finds the
+correct version of RCS. The -b global option and the RCSBIN setting
+in CVSROOT/config are still accepted but don't do anything. The
+$RCSBIN internal variable in administrative files is no longer
+accepted.
+
+* There is a new syntax, "cvs admin -orev1::rev2", which collapses the
+revisions between rev1 and rev2 without deleting rev1 or rev2
+themselves.
+
+* There is a new administrative file CVSROOT/config which allows one
+to specify miscellaneous aspects of CVS configuration. Currently
+supported here:
+
+ - SystemAuth, allows you to prevent pserver from checking for system
+ usernames/passwords.
+
+For more information see the "config" section of cvs.texinfo.
+
* When setting up the pserver server, one now must specify the
allowable CVSROOT directories in inetd.conf. See the Password
authentication server section of cvs.texinfo for details. Note that
@@ -21,10 +46,9 @@ repository from the cvspass file.
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.
+cvs.texinfo for details, including a discussion of security issues.
+Note that the requirement that read-only users be able to create locks
+and write the history file still applies.
* The "checkout" command now creates a CVS directory at the top level
of the new working directory, in addition to CVS directories created
diff --git a/contrib/cvs/PROJECTS b/contrib/cvs/PROJECTS
index 4e20f8b883af..b46eb2ab64f2 100644
--- a/contrib/cvs/PROJECTS
+++ b/contrib/cvs/PROJECTS
@@ -46,13 +46,6 @@ are actually more appropriate for this list.
(and modify) indexes. This becomes very apparent with files
with several hundred revisions.
-* A RCS "library", so CVS could operate on RCS files directly.
-
- 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. (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
diff --git a/contrib/cvs/README b/contrib/cvs/README
index 977ddcb480e7..e6c436ba16df 100644
--- a/contrib/cvs/README
+++ b/contrib/cvs/README
@@ -164,7 +164,7 @@ 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).
+bug-cvs know (as described in the Cederqvist manual).
Mark D. Baushke <mdb@cisco.com>
Per Cederqvist <ceder@signum.se>
diff --git a/contrib/cvs/TESTS b/contrib/cvs/TESTS
index 39a38a9292ee..fa9697f43ad6 100644
--- a/contrib/cvs/TESTS
+++ b/contrib/cvs/TESTS
@@ -134,3 +134,12 @@ unnecessary baggage. The only dependency would be on tcl (that is,
wish).
* perl or python or <any other serious contenders here?>
+
+It is worth thinking about how to:
+
+a. include spaces in arguments which we pass to the program under
+test (sanity.sh dotest cannot do this; see test rcs-9 for a
+workaround).
+
+b. pass stdin to the program under test (sanity.sh, again, handles
+this by bypassing dotest).
diff --git a/contrib/cvs/TODO b/contrib/cvs/TODO
index 7a9a8166c9db..cddd580845ca 100644
--- a/contrib/cvs/TODO
+++ b/contrib/cvs/TODO
@@ -1,10 +1,14 @@
+The "TODO" file! -*-Indented-Text-*-
+
22. Catch signals for cleanup when "add"ing files.
24. Insist on a log message.
(If done, this should be configurable via commitinfo or some new
config file -kingdon, Jun 1995).
-30. Add "patch" program option to the modules database.
+30. Add "rdiff" program option to the modules database (and "diff"
+too?). (perhaps should think a little harder about what this is
+trying to accomplish and what the best way is -kingdon, Jul 1997).
31. Think hard about ^C recovery.
@@ -16,7 +20,9 @@
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.
+ track of what has been merged is a pain. Take a look at PRCS 1.2.
+ PRCS 1.0 was particularly bad the way it handled the "invisible
+ state", but 1.2 is significantly better.
45. Consider enhancing the "rdiff" and "tag" (rtag??) command support in
the module database -- they seem hard to use since these commands
@@ -45,9 +51,6 @@
63. The "import" and vendor support commands (co -j) need to be documented
better.
-64. Need to greatly increase the performance of an initial checkout.
- [[ it got better, then we added functionality, making it worse again ]]
-
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.
@@ -57,8 +60,8 @@
73. Consider an option (in .cvsrc?) to automatically add files that are new
and specified to commit.
-79. Might be nice to have some sort of interface to TFS and tagged
- revisions.
+79. Might be nice to have some sort of interface to Sun's Translucent
+ (?) File System and tagged revisions.
82. Maybe the import stuff should allow an arbitrary revision to be
specified.
@@ -66,8 +69,10 @@
84. Improve the documentation about administration of the repository and
how to add/remove files and the use of symbolic links.
-85. Add revision controlled symbolic links to CVS using one of the tag
- fields in the RCS file.
+85. Make symbolic links a valid thing to put under version control.
+ Perhaps use one of the tag fields in the RCS file? Note that we
+ can only support symlinks that are relative and within the scope of
+ the sources being controlled.
92. Look into this:
After a bit of soul searching via dbx, I realized my sin was that I'd
@@ -130,11 +135,12 @@
113. The "cvs update" command should tee its output to a log file in ".".
(why? What is wrong with piping stdout to "tee"? -kingdon, Jun 1995)
-119. Consider an option to have import checkout the RCS or SCCS files
- 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).
+119. When importing a directory tree that is under SCCS/RCS control,
+ consider an option to have import checkout the SCCS/RCS files if
+ necessary. (This is if someone wants to import something which
+ is in RCS or SCCS without preserving the history, but makes sure
+ they do get the latest versions. It isn't clear to me how useful
+ that is -kingdon, June 1996).
122. If Name_Repository fails, it currently causes CVS to die completely. It
should instead return NULL and have the caller do something reasonable
@@ -142,6 +148,7 @@
-kingdon, June 1996).
123. Add a flag to import to not build vendor branches for local code.
+ (See `importb' tests in src/sanity.sh for more details).
124. Anyway, I thought you might want to add something like the following
to the cvs man pages:
@@ -157,8 +164,6 @@
127. Look at *info files; they should all be quiet if the files are not
there. Should be able to point at a RCS directory and go.
-128. When I tag a file, the message tells me that I'm tagging a directory.
-
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.
@@ -184,10 +189,14 @@
variable to limit the amount of sources that need to be duplicated for
sites with giant source trees and no disk space.
-141. Import should accept modules as its directory argument.
+141. Import should accept modules as its directory argument. If we're
+ going to implement this, we should think hard about how modules
+ might be expanded and how to handle those cases.
143. Update the documentation to show that the source repository is
- something far away from the files that you work on.
+ something far away from the files that you work on. (People who
+ come from an RCS background are used to their `repository' being
+ _very_ close to their working directory.)
144. Have cvs checkout look for the environment variable CVSPREFIX
(or CVSMODPREFIX or some such). If it's set, then when looking
@@ -227,14 +236,42 @@
.#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:
- Maybe there should be an option to cvs admin that allows a user to
- change the Repository file with some degree of error checking?
+149. Maybe there should be an option to cvs admin that allows a user to
+ change the Repository/Root file with some degree of error checking?
Something like "cvs admin reposmv /old/path /new/pretty/path". Before
it does the replace it check to see that the files
/new/pretty/path/<dir>/<files> exist.
+ The obvious cases are where one moves the repository to another
+ machine or directory. But there are other cases, like where the
+ user might want to change from :pserver: to :ext:, use a different
+ server (if there are two server machines which share the
+ repository using a networked file system), etc.
+
+ The status quo is a bit of a mess (as of, say, CVS 1.9). It is
+ that the -d global option has two moderately different uses. One
+ is to use a totally different repository (in which case we'd
+ probably want to give an error if it disagreed with CVS/Root, as
+ CVS 1.8 and earlier did). The other is the "reposmv"
+ functionality above (in which the two repositories really are the
+ same, and we want to update the CVS/Root files). A related issue
+ is that the fact that CVS only sets and looks at the CVS/Root
+ file in the directory where CVS is run; it doesn't do anything
+ about CVS/Root files in subdirectories.
+
+ Note also RELATIVE_REPOS in options.h; it needs to be set for
+ changing CVS/Root (not CVS/Repository) to be sufficient in the
+ case where the directory has changed.
+
+ This whole area is a rather bad pile of individual decisions which
+ accumulated over time, some of them probably bad decisions with
+ hindsight. But we didn't get into this mess overnight, and we're
+ not going to get out of it overnight (that is, we need to come up
+ with a replacement behavior, document what parts of the status
+ quo are deprecated, probably circulate some unofficial patches, &c).
+
+ (this item originally added 2 Feb 1992 but revised since).
+
150. I have a customer request for a way to specify log message per
file, non-interactively before the commit, such that a single, fully
recursive commit prompts for one commit message, and concatenates the
@@ -256,8 +293,9 @@
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)
+ message (see comment in commit.c at call to start_server). Also
+ would clean up the kludge for what to do with the message from
+ do_editor if the up-to-date check fails (see commit.c client code).
I'm not sure about the part above about having commit prompt
for an overall message--part of the point is having commit
@@ -270,30 +308,41 @@
incompatibility between client/server (per-tree) and
non-client/server (per-directory).
+ A few interesting issues with this: (1) if you do a cvs update or
+ some other operation which changes the working directory, do you
+ need to run "cvs message" again (it would, of course, bring up
+ the old message which you could accept)? Probably yes, after all
+ merging in some conflicts might change the situation. (2) How do
+ you change the stored messages if you change your mind before the
+ commit (probably run "cvs message" again, as hinted in (1))?
+
151. Also, is there a flag I am missing that allows replacing Ulrtx_Build
by Ultrix_build? I.E. I would like a tag replacement to be a one step
operation rather than a two step "cvs rtag -r Ulrtx_Build Ultrix_Build"
- followed by "cvs trag -d Ulrtx_Build"
+ followed by "cvs rtag -d Ulrtx_Build"
152. The "cvs -n" option does not work as one would expect for all the
commands. In particular, for "commit" and "import", where one would
also like to see what it would do, without actually doing anything.
-153. There should be some command (maybe I just haven't figured
- out which one...) to import a source directory which is already
- RCS-administered without losing all prior RCS gathered data. Thus, it
- would have to examine the RCS files and choose a starting version and
- branch higher than previous ones used.
+153. There should be some command (maybe I just haven't figured out
+ which one...) to import a source directory which is already
+ RCS-administered without losing all prior RCS gathered data.
+ Thus, it would have to examine the RCS files and choose a
+ starting version and branch higher than previous ones used.
+ (Check out rcs-to-cvs and see if it addresses this issue.)
154. When committing the modules file, a pre-commit check should be done to
verify the validity of the new modules file before allowing it to be
committed.
155. The options for "cvs history" are mutually exclusive, even though
- useful queries can be done if they are not, as in specifying both a
- module and a tag. A workaround is to specify the module, then run the
- output through grep to only display lines that begin with T, which are
- tag lines.
+ useful queries can be done if they are not, as in specifying both
+ a module and a tag. A workaround is to specify the module, then
+ run the output through grep to only display lines that begin with
+ T, which are tag lines. (Better perhaps if we redesign the whole
+ "history" business -- check out doc/cvs.texinfo for the entire
+ rant.)
156. Also, how hard would it be to allow continuation lines in the
{commit,rcs,log}info files? It would probably be useful with all of
@@ -313,9 +362,6 @@
revision was already locked by the user as well, thus moving the lock
forward after the commit.
-161. The date parser included with CVS (lib/getdate.y) does not support
- such RCS-supported dates as "1992/03/07". It probably should.
-
163. The rtag/tag commands should have an option that removes the specified
tag from any file that is in the attic. This allows one to re-use a
tag (like "Mon", "Tue", ...) all the time and still have it tag the
@@ -385,10 +431,12 @@
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?
+changes from tag "foo" to tag "bar". "cvs log -rfoo:bar" doesn't cut
+it, because it erroneously shows the changes associated with the
+change from the revision before foo to foo. I'm not sure that is ever
+a useful or logical behavior ("cvs diff -r foo -r bar" gets this
+right), but is compatibility an issue? See
+http://www.cyclic.com/cvs/unoff-log.txt for an unofficial patch.
183. "cvs status" should report on Entries.Static flag and CVS/Tag (how?
maybe a "cvs status -d" to give directory status?). There should also
@@ -420,3 +468,326 @@ modifying it), but even as to the general idea, I don't have a clear
idea about whether it would be good (see what I mean about the need
for better documentation? I work on CVS full-time, and even I don't
understand the state of the art on this subject).
+
+186. There is a frequent discussion of multisite features.
+
+* There may be some overlap with the client/server CVS, which is good
+especially when there is a single developer at each location. But by
+"multisite" I mean something in which each site is more autonomous, to
+one extent or another.
+
+* Vendor branches are the closest thing that CVS currently has for
+multisite features. They have fixable drawbacks (such as poor
+handling of added and removed files), and more fundamental drawbacks
+(when you import a vendor branch, you are importing a set of files,
+not importing any knowledge of their version history outside the
+current repository).
+
+* One approach would be to require checkins (or other modifications to
+the repository) to succeed at a write quorum of sites (51%) before
+they are allowed to complete. To work well, the network should be
+reliable enough that one can typically get to that many sites. When a
+server which has been out of touch reconnects, it would want to update
+its data before doing anything else. Any of the servers can service
+all requests locally, except perhaps for a check that they are
+up-to-date. The way this differs from a run-of-the-mill distributed
+database is that if one only allows reversible operations via this
+mechanism (exclude "cvs admin -o", "cvs tag -d", &c), then each site
+can back up the others, such that failures at one site, including
+something like deleting all the sources, can be recovered from. Thus
+the sites need not trust each other as much as for many shared
+databases, and the system may be resilient to many types of
+organizational failures. Sometimes I call this design the
+"CVScluster" design.
+
+* Another approach is a master/slave one. Checkins happen at the
+master site, and slave sites need to check whether their local
+repository is up to date before relying on its information.
+
+* Another approach is to have each site own a particular branch. This
+one is the most tolerant of flaky networks; if checkins happen at each
+site independently there is no particular problem. The big question
+is whether merges happen only manually, as with existing CVS branches,
+or whether there is a feature whereby there are circumstances in which
+merges from one branch to the other happen automatically (for example,
+the case in which the branches have not diverged). This might be a
+legitimate question to ask even quite aside from multisite features.
+
+One additional random tidbit is to note that Eric Raymond has some
+interest in this sort of thing. The item "Cooperative distributed
+freeware development" on http://www.ccil.org/~esr/ has a very brief
+introduction to what he is thinking about.
+
+187. Might want to separate out usage error messages and help
+messages. The problem now is that if you specify an invalid option,
+for example, the error message is lost among all the help text. In
+the new regime, the error message would be followed by a one-line
+message directing people to the appropriate help option ("cvs -H
+<command>" or "cvs --help-commands" or whatever, according to the
+situation). I'm not sure whether this change would be controversial
+(as defined in HACKING), so there might be a need for further
+discussion or other actions other than just coding.
+
+188. Option parsing and .cvsrc has at least one notable limitation.
+If you want to set a global option only for some CVS commands, there
+is no way to do it (for example, if one wants to set -q only for
+"rdiff"). I am told that the "popt" package from RPM
+(http://www.rpm.org) could solve this and other problems (for example,
+if the syntax of option stuff in .cvsrc is similar to RPM, that would
+be great from a user point of view). It would at least be worth a
+look (it also provides a cleaner API than getopt_long).
+
+Another issue which may or may not be related is the issue of
+overriding .cvsrc from the command line. The cleanest solution might
+be to have options in mutually exclusive sets (-l/-R being a current
+example, but --foo/--no-foo is a better way to name such options). Or
+perhaps there is some better solution.
+
+189. Renaming files and directories is a frequently discussed topic.
+
+Some of the problems with the status quo:
+
+a. "cvs annotate" cannot operate on both the old and new files in a
+single run. You need to run it twice, once for the new name and once
+for the old name.
+
+b. "cvs diff" (or "cvs diff -N") shows a rename as a removal of the
+old file and an addition of the new one. Some people would like to
+see the differences between the file contents (but then how would we
+indicate the fact that the file has been renamed? Certainly the
+notion that "patch(1)" has of renames is as a removal and addition).
+
+c. "cvs log" should be able to show the changes between two
+tags/dates, even in the presence of adds/removes/renames (I'm not sure
+what the status quo is on this; see also item #182).
+
+d. Renaming directories is way too hard.
+
+Implementations:
+
+It is perhaps premature to try to design implementation details
+without answering some of the above questions about desired behaviors
+but several general implementations get mentioned.
+
+i. No fundamental changes (for example, a "cvs rename" command which
+operated on directories could still implement the current recommended
+practice for renaming directories, which is to rename each of the
+files contained therein via an add and a remove). One thing to note
+that the status quo gets right is proper merges, even with adds and
+removals (Well, mostly right at least. There are a *LOT* of different
+cases; see the testsuite for some of them).
+
+ii. Rename database. In this scheme the files in the repository
+would have some arbitrary name, and then a separate rename database
+would indicate the current correspondence between the filename in the
+working directory and the actual storage. As far as I know this has
+never been designed in detail for CVS.
+
+iii. A modest change in which the RCS files would contain some
+information such as "renamed from X" or "renamed to Y". That is, this
+would be generally similar to the log messages which are suggested
+when one renames via an add and a removal, but would be
+computer-parseable. I don't think anyone has tried to flesh out any
+details here either.
+
+It is interesting to note that in solution ii. version numbers in the
+"new file" start where the "old file" left off, while in solutions
+i. and iii., version numbers restart from 1.1 each time a file is
+renamed. Except perhaps in the case where we rename a file from foo
+to bar and then back to foo. I'll shut up now.
+
+Regardless of the method we choose, we need to address how renames
+affect existing CVS behaviors. For example, what happens when you
+rename a file on a branch but not the trunk and then try to merge the
+two? What happens when you rename a file on one branch and delete it
+on another and try to merge the two?
+
+Ideally, we'd come up with a way to parameterize the problem and
+simply write up a lookup table to determine the correct behavior.
+
+190. The meaning of the -q and -Q global options is very ad hoc;
+there is no clear definition of which messages are suppressed by them
+and which are not. Here is a classification of the current meanings
+of -q; I don't know whether anyone has done a similar investigation of
+-Q:
+
+ a. The "warm fuzzies" printed upon entering each directory (for
+ example, "cvs update: Updating sdir"). The need for these messages
+ may be decreased now that most of CVS uses ->fullname instead of
+ ->file in messages (a project which is *still* not 100% complete,
+ alas). However, the issue of whether CVS can offer status as it
+ runs is an important one. Of course from the command line it is
+ hard to do this well and one ends up with options like -q. But
+ think about emacs, jCVS, or other environments which could flash you
+ the latest status line so you can see whether the system is working
+ or stuck.
+
+ b. Other cases where the message just offers information (rather
+ than an error) and might be considered unnecessarily verbose. These
+ have a certain point to them, although it isn't really clear whether
+ it should be the same option as the warm fuzzies or whether it is
+ worth the conceptual hair:
+
+ add.c: scheduling %s `%s' for addition (may be an issue)
+ modules.c: %s %s: Executing '%s' (I can see how that might be noise,
+ but...)
+ remove.c: scheduling `%s' for removal (analogous to the add.c one)
+ update.c: Checking out %s (hmm, that message is a bit on the noisy side...)
+ (but the similar message in annotate is not affected by -q).
+
+ c. Suppressing various error messages. This is almost surely
+ bogus.
+
+ commit.c: failed to remove tag `%s' from `%s' (Questionable.
+ Rationale might be that we already printed another message
+ elsewhere but why would it be necessary to avoid
+ the extra message in such an uncommon case?)
+ commit.c: failed to check out `%s' (likewise; this one seems to be a
+ vestige from before RCS_checkout was internal. Take a look at how
+ RCS_checkout handles errors)
+ commit.c: failed to commit dead revision for `%s' (likewise)
+ remove.c: file `%s' still in working directory (see below about rm
+ -f analogy)
+ remove.c: nothing known about `%s' (looks dubious to me, especially in
+ the case where the user specified it explicitly).
+ remove.c: removed `%s' (seems like an obscure enough case that I fail
+ to see the appeal of being cryptically concise here).
+ remove.c: file `%s' already scheduled for removal (now it is starting
+ to look analogous to the infamous rm -f option).
+ rtag.c: cannot find tag `%s' in `%s' (more rm -f like behavior)
+ rtag.c: failed to remove tag `%s' from `%s' (ditto)
+ tag.c: failed to remove tag %s from %s (see above about whether RCS_*
+ has already printed an error message).
+ tag.c: couldn't tag added but un-commited file `%s' (more rm -f
+ like behavior)
+ tag.c: skipping removed but un-commited file `%s' (ditto)
+ tag.c: cannot find revision control file for `%s' (ditto, but at first
+ glance seems even worse, as this would seem to be a "can't happen"
+ condition)
+
+191. Storing RCS files, especially binary files, takes rather more
+space than it could, typically.
+ - The virtue of the status quo is that it is simple to implement.
+ Of course it is also simplest in terms of dealing with compatibility.
+ - Just storing the revisions as separate gzipped files is a common
+ technique. It also is pretty simple (no new algorithms, CVS
+ already has zlib around). Of course for some files (such as files
+ which are already compressed) the gzip step won't help, but
+ something which can at least sometimes avoid rewriting the entire
+ RCS file for each new revision would, I would think, be a big
+ speedup for large files.
+ - Josh MacDonald has written a tool called xdelta which produces
+ differences (that is, sufficient information to transform the old
+ to the new) which looks for common sequences of bytes, like RCS
+ currently does, but which is not based on lines. This seems to do
+ quite well for some kinds of files (e.g. FrameMaker documents,
+ text files), and not as well for others (anything which is already
+ compressed, executables). xdelta 1.10 also is faster than GNU diff.
+ - Karl Fogel has thought some about using a difference technique
+ analogous to fractal compression (see the comp.compression FAQ for
+ more on fractal compression, including at least one patent to
+ watch for; I don't know how analogous Karl's ideas are to the
+ techniques described there).
+ - Quite possibly want some documented interface by which a site can
+ plug in their choice of external difference programs (with the
+ ability to choose the program based on filename, magic numbers,
+ or some such).
+
+192. "cvs update" using an absolute pathname does not work if the
+working directory is not a CVS-controlled directory with the correct
+CVSROOT. For example, the following will fail:
+
+ cd /tmp
+ cvs -d /repos co foo
+ cd /
+ cvs update /tmp/foo
+
+It is possible to read the CVSROOT from the administrative files in
+the directory specified by the absolute pathname argument to update.
+In that case, the last command above would be equivalent to:
+
+ cd /tmp/foo
+ cvs update .
+
+This can be problematic, however, if we ask CVS to update two
+directories with different CVSROOTs. Currently, CVS has no way of
+changing CVSROOT mid-stream. Consider the following:
+
+ cd /tmp
+ cvs -d /repos1 co foo
+ cvs -d /repos2 co bar
+ cd /
+ cvs update /tmp/foo /tmp/bar
+
+To make that example work, we need to think hard about:
+
+ - where and when CVSROOT-related variables get set
+ - who caches said variables for later use
+ - how the remote protocol should be extended to handle sending a new
+ repository mid-stream
+ - how the client should maintain connections to a variety of servers
+ in a single invocation.
+
+Because those issues are hairy, I suspect that having a change in
+CVSROOT be an error would be a better move.
+
+193. The client relies on timestamps to figure out whether a file is
+(maybe) modified. If something goes awry, then it ends up sending
+entire files to the server to be checked, and this can be quite slow
+especially over a slow network. A couple of things that can happen:
+(a) other programs, like make, use timestamps, so one ends up needing
+to do "touch foo" and otherwise messing with timestamps, (b) changing
+the timezone offset (e.g. summer vs. winter or moving a machine)
+should work on unix, but there may be problems with non-unix.
+
+Possible solutions:
+
+ a. Store a checksum for each file in CVS/Entries or some such
+ place. What to do about hash collisions is interesting: using a
+ checksum, like MD5, large enough to "never" have collisions
+ probably works in practice (of course, if there is a collision then
+ all hell breaks loose because that code path was not tested, but
+ given the tiny, tiny probability of that I suppose this is only an
+ aesthetic issue).
+
+ b. I'm not thinking of others, except storing the whole file in
+ CVS/Base, and I'm sure using twice the disk space would be
+ unpopular.
+
+194. CVS does not separate the "metadata" from the actual revision
+history; it stores them both in the RCS files. Metadata means tags
+and header information such as the number of the head revision.
+Storing the metadata separately could speed up "cvs tag" enormously,
+which is a big problem for large repositories. It could also probably
+make CVS's locking much less in the way (see comment in do_recursion
+about "two-pass design").
+
+195. Many people using CVS over a slow link are interested in whether
+the remote protocol could be any more efficient with network
+bandwidth. This item is about one aspect of that--how the server
+sends a new version of a file the client has a different version of,
+or vice versa.
+
+a. Cases in which the status quo already sends a diff. For most text
+files, this is probably already close to optimal. For binary files,
+and anomalous text files, it might be worth looking into other
+difference algorithms (see item #191).
+
+b. Cases in which the status quo does not send a diff (e.g. "cvs
+commit").
+
+b1. With some frequency, people suggest rsync or a similar algorithm
+(see ftp://samba.anu.edu.au/pub/rsync/). This could speed things up,
+and in some ways involves the most minimal changes to the default CVS
+paradigm. There are some downsides though: (1) there is an extra
+network turnaround, (2) the algorithm is not as efficient with network
+bandwidth as difference type programs (it transmits a fair bit of data
+to discover what a difference program discovers locally).
+
+b2. If one is willing to require that users use "cvs edit" before
+editing a file on the client side (in some cases, a development
+environment like emacs can make this fairly easy), then the Modified
+request in the protocol could be extended to allow the client to just
+send differences instead of entire files. In the degenerate case
+(e.g. "cvs diff" without arguments) the required network traffic is
+reduced to zero, and the client need not even contact the server.
diff --git a/contrib/cvs/acconfig.h b/contrib/cvs/acconfig.h
index 8bbda6ff3b2e..21c5fe7449aa 100644
--- a/contrib/cvs/acconfig.h
+++ b/contrib/cvs/acconfig.h
@@ -1,6 +1,9 @@
/* Define if you have MIT Kerberos version 4 available. */
#undef HAVE_KERBEROS
+/* Define if you have GSSAPI with MIT Kerberos version 5 available. */
+#undef HAVE_GSSAPI
+
/* Define if you want CVS to be able to be a remote repository client. */
#undef CLIENT_SUPPORT
@@ -16,3 +19,20 @@
/* Define if you have the connect function. */
#undef HAVE_CONNECT
+
+/* Define if you have memchr (always for CVS). */
+#undef HAVE_MEMCHR
+
+/* Define if you have strchr (always for CVS). */
+#undef HAVE_STRCHR
+
+/* Define if utime requires write access to the file (true on Windows,
+ but not Unix). */
+#undef UTIME_EXPECTS_WRITABLE
+
+/* Define if setmode is required when writing binary data to stdout. */
+#undef USE_SETMODE_STDOUT
+
+/* Define if the diff library should use setmode for binary files.
+ FIXME: Why two different macros for setmode? */
+#undef HAVE_SETMODE
diff --git a/contrib/cvs/config.h.in b/contrib/cvs/config.h.in
index ce5ee499762d..a49219093463 100644
--- a/contrib/cvs/config.h.in
+++ b/contrib/cvs/config.h.in
@@ -7,6 +7,9 @@
#undef _ALL_SOURCE
#endif
+/* Define if the closedir function returns void instead of int. */
+#undef CLOSEDIR_VOID
+
/* Define to empty if the keyword does not work. */
#undef const
@@ -16,12 +19,18 @@
/* Define if you support file names longer than 14 characters. */
#undef HAVE_LONG_FILE_NAMES
+/* Define if your struct stat has st_blksize. */
+#undef HAVE_ST_BLKSIZE
+
/* Define if you have <sys/wait.h> that is POSIX.1 compatible. */
#undef HAVE_SYS_WAIT_H
/* Define if utime(file, NULL) sets file's timestamp to the present. */
#undef HAVE_UTIME_NULL
+/* Define if you have <vfork.h>. */
+#undef HAVE_VFORK_H
+
/* Define if on MINIX. */
#undef _MINIX
@@ -56,9 +65,15 @@
/* Define to `int' if <sys/types.h> doesn't define. */
#undef uid_t
+/* Define vfork as fork if vfork does not work. */
+#undef vfork
+
/* Define if you have MIT Kerberos version 4 available. */
#undef HAVE_KERBEROS
+/* Define if you have GSSAPI with MIT Kerberos version 5 available. */
+#undef HAVE_GSSAPI
+
/* Define if you want CVS to be able to be a remote repository client. */
#undef CLIENT_SUPPORT
@@ -75,6 +90,23 @@
/* Define if you have the connect function. */
#undef HAVE_CONNECT
+/* Define if you have memchr (always for CVS). */
+#undef HAVE_MEMCHR
+
+/* Define if you have strchr (always for CVS). */
+#undef HAVE_STRCHR
+
+/* Define if utime requires write access to the file (true on Windows,
+ but not Unix). */
+#undef UTIME_EXPECTS_WRITABLE
+
+/* Define if setmode is required when writing binary data to stdout. */
+#undef USE_SETMODE_STDOUT
+
+/* Define if the diff library should use setmode for binary files.
+ FIXME: Why two different macros for setmode? */
+#undef HAVE_SETMODE
+
/* Define if you have the crypt function. */
#undef HAVE_CRYPT
@@ -138,9 +170,6 @@
/* 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
@@ -162,6 +191,9 @@
/* Define if you have the <io.h> header file. */
#undef HAVE_IO_H
+/* Define if you have the <limits.h> header file. */
+#undef HAVE_LIMITS_H
+
/* Define if you have the <memory.h> header file. */
#undef HAVE_MEMORY_H
@@ -180,6 +212,9 @@
/* Define if you have the <sys/dir.h> header file. */
#undef HAVE_SYS_DIR_H
+/* Define if you have the <sys/file.h> header file. */
+#undef HAVE_SYS_FILE_H
+
/* Define if you have the <sys/ndir.h> header file. */
#undef HAVE_SYS_NDIR_H
@@ -207,6 +242,9 @@
/* Define if you have the crypt library (-lcrypt). */
#undef HAVE_LIBCRYPT
+/* Define if you have the gen library (-lgen). */
+#undef HAVE_LIBGEN
+
/* Define if you have the inet library (-linet). */
#undef HAVE_LIBINET
diff --git a/contrib/cvs/configure b/contrib/cvs/configure
index 660c226c5e6d..f79a25dfe563 100755
--- a/contrib/cvs/configure
+++ b/contrib/cvs/configure
@@ -14,6 +14,8 @@ ac_default_prefix=/usr/local
ac_help="$ac_help
--with-krb4=value set default \$(KRB4) from value"
ac_help="$ac_help
+ --with-gssapi=value GSSAPI directory"
+ac_help="$ac_help
--enable-encryption enable encryption support"
ac_help="$ac_help
--enable-client include code for running as a remote client (default)
@@ -610,7 +612,7 @@ else
yes;
#endif
EOF
-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
+if { ac_try='${CC-cc} -E conftest.c'; { (eval echo configure:616: \"$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
@@ -663,13 +665,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 667 "configure"
+#line 669 "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:673: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }
+{ (eval echo configure:675: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }
ac_err=`grep -v '^ *+' conftest.out`
if test -z "$ac_err"; then
:
@@ -678,13 +680,13 @@ else
rm -rf conftest*
CPP="${CC-cc} -E -traditional-cpp"
cat > conftest.$ac_ext <<EOF
-#line 682 "configure"
+#line 684 "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:688: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }
+{ (eval echo configure:690: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }
ac_err=`grep -v '^ *+' conftest.out`
if test -z "$ac_err"; then
:
@@ -706,7 +708,7 @@ echo "$ac_t""$CPP" 1>&6
echo $ac_n "checking for AIX""... $ac_c" 1>&6
cat > conftest.$ac_ext <<EOF
-#line 710 "configure"
+#line 712 "configure"
#include "confdefs.h"
#ifdef _AIX
yes
@@ -733,12 +735,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 737 "configure"
+#line 739 "configure"
#include "confdefs.h"
#include <minix/config.h>
EOF
ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out"
-{ (eval echo configure:742: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }
+{ (eval echo configure:744: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }
ac_err=`grep -v '^ *+' conftest.out`
if test -z "$ac_err"; then
rm -rf conftest*
@@ -845,11 +847,11 @@ else
ac_cv_c_cross=yes
else
cat > conftest.$ac_ext <<EOF
-#line 849 "configure"
+#line 851 "configure"
#include "confdefs.h"
main(){return(0);}
EOF
-{ (eval echo configure:853: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }
+{ (eval echo configure:855: \"$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
@@ -868,7 +870,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 872 "configure"
+#line 874 "configure"
#include "confdefs.h"
int main() { return 0; }
@@ -918,7 +920,7 @@ ccp = (char const *const *) p;
; return 0; }
EOF
-if { (eval echo configure:922: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then
+if { (eval echo configure:924: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then
rm -rf conftest*
ac_cv_c_const=yes
else
@@ -1199,7 +1201,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 1203 "configure"
+#line 1205 "configure"
#include "confdefs.h"
#include <stdlib.h>
#include <stdarg.h>
@@ -1207,7 +1209,7 @@ else
#include <float.h>
EOF
ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out"
-{ (eval echo configure:1211: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }
+{ (eval echo configure:1213: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }
ac_err=`grep -v '^ *+' conftest.out`
if test -z "$ac_err"; then
rm -rf conftest*
@@ -1222,7 +1224,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 1226 "configure"
+#line 1228 "configure"
#include "confdefs.h"
#include <string.h>
EOF
@@ -1240,7 +1242,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 1244 "configure"
+#line 1246 "configure"
#include "confdefs.h"
#include <stdlib.h>
EOF
@@ -1261,7 +1263,7 @@ if test "$cross_compiling" = yes; then
:
else
cat > conftest.$ac_ext <<EOF
-#line 1265 "configure"
+#line 1267 "configure"
#include "confdefs.h"
#include <ctype.h>
#define ISLOWER(c) ('a' <= (c) && (c) <= 'z')
@@ -1272,7 +1274,7 @@ if (XOR (islower (i), ISLOWER (i)) || toupper (i) != TOUPPER (i)) exit(2);
exit (0); }
EOF
-{ (eval echo configure:1276: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }
+{ (eval echo configure:1278: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }
if test -s conftest && (./conftest; exit) 2>/dev/null; then
:
else
@@ -1292,6 +1294,7 @@ EOF
fi
for ac_hdr in errno.h unistd.h string.h memory.h utime.h fcntl.h ndbm.h \
+ limits.h sys/file.h \
sys/param.h sys/select.h sys/time.h sys/timeb.h \
io.h direct.h sys/bsdtypes.h sys/resource.h
do
@@ -1301,12 +1304,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 1305 "configure"
+#line 1308 "configure"
#include "confdefs.h"
#include <$ac_hdr>
EOF
ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out"
-{ (eval echo configure:1310: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }
+{ (eval echo configure:1313: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }
ac_err=`grep -v '^ *+' conftest.out`
if test -z "$ac_err"; then
rm -rf conftest*
@@ -1335,7 +1338,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 1339 "configure"
+#line 1342 "configure"
#include "confdefs.h"
#include <sys/types.h>
#include <sys/wait.h>
@@ -1352,7 +1355,7 @@ wait (&s);
s = WIFEXITED (s) ? WEXITSTATUS (s) : 1;
; return 0; }
EOF
-if { (eval echo configure:1356: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then
+if { (eval echo configure:1359: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then
rm -rf conftest*
ac_cv_header_sys_wait_h=yes
else
@@ -1376,7 +1379,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 1380 "configure"
+#line 1383 "configure"
#include "confdefs.h"
#include <sys/types.h>
#include <sys/stat.h>
@@ -1431,7 +1434,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 1435 "configure"
+#line 1438 "configure"
#include "confdefs.h"
#include <sys/types.h>
#include <sys/time.h>
@@ -1441,7 +1444,7 @@ int t() {
struct tm *tp;
; return 0; }
EOF
-if { (eval echo configure:1445: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then
+if { (eval echo configure:1448: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then
rm -rf conftest*
ac_cv_header_time=yes
else
@@ -1469,7 +1472,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 1473 "configure"
+#line 1476 "configure"
#include "confdefs.h"
#include <sys/types.h>
#include <$ac_hdr>
@@ -1478,7 +1481,7 @@ int t() {
DIR *dirp = 0;
; return 0; }
EOF
-if { (eval echo configure:1482: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then
+if { (eval echo configure:1485: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then
rm -rf conftest*
eval "ac_cv_header_dirent_$ac_safe=yes"
else
@@ -1509,7 +1512,7 @@ else
ac_save_LIBS="$LIBS"
LIBS="-ldir $LIBS"
cat > conftest.$ac_ext <<EOF
-#line 1513 "configure"
+#line 1516 "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
@@ -1521,7 +1524,7 @@ int t() {
opendir()
; return 0; }
EOF
-if { (eval echo configure:1525: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
+if { (eval echo configure:1528: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
rm -rf conftest*
eval "ac_cv_lib_$ac_lib_var=yes"
else
@@ -1548,7 +1551,7 @@ else
ac_save_LIBS="$LIBS"
LIBS="-lx $LIBS"
cat > conftest.$ac_ext <<EOF
-#line 1552 "configure"
+#line 1555 "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
@@ -1560,7 +1563,7 @@ int t() {
opendir()
; return 0; }
EOF
-if { (eval echo configure:1564: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
+if { (eval echo configure:1567: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
rm -rf conftest*
eval "ac_cv_lib_$ac_lib_var=yes"
else
@@ -1585,7 +1588,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 1589 "configure"
+#line 1592 "configure"
#include "confdefs.h"
#include <sys/types.h>
#include <signal.h>
@@ -1603,7 +1606,7 @@ int t() {
int i;
; return 0; }
EOF
-if { (eval echo configure:1607: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then
+if { (eval echo configure:1610: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then
rm -rf conftest*
ac_cv_type_signal=void
else
@@ -1625,7 +1628,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 1629 "configure"
+#line 1632 "configure"
#include "confdefs.h"
#include <sys/types.h>
EOF
@@ -1658,7 +1661,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 1662 "configure"
+#line 1665 "configure"
#include "confdefs.h"
#include <sys/types.h>
#if STDC_HEADERS
@@ -1689,7 +1692,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 1693 "configure"
+#line 1696 "configure"
#include "confdefs.h"
#include <sys/types.h>
#if STDC_HEADERS
@@ -1720,7 +1723,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 1724 "configure"
+#line 1727 "configure"
#include "confdefs.h"
#include <sys/types.h>
#if STDC_HEADERS
@@ -1746,14 +1749,47 @@ EOF
fi
-for ac_func in getwd mkdir rename strdup strstr dup2 strerror valloc waitpid vasprintf strtoul
+echo $ac_n "checking for st_blksize in struct stat""... $ac_c" 1>&6
+if eval "test \"`echo '$''{'ac_cv_struct_st_blksize'+set}'`\" = set"; then
+ echo $ac_n "(cached) $ac_c" 1>&6
+else
+ cat > conftest.$ac_ext <<EOF
+#line 1758 "configure"
+#include "confdefs.h"
+#include <sys/types.h>
+#include <sys/stat.h>
+int main() { return 0; }
+int t() {
+struct stat s; s.st_blksize;
+; return 0; }
+EOF
+if { (eval echo configure:1767: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then
+ rm -rf conftest*
+ ac_cv_struct_st_blksize=yes
+else
+ rm -rf conftest*
+ ac_cv_struct_st_blksize=no
+fi
+rm -f conftest*
+
+fi
+
+echo "$ac_t""$ac_cv_struct_st_blksize" 1>&6
+if test $ac_cv_struct_st_blksize = yes; then
+ cat >> confdefs.h <<\EOF
+#define HAVE_ST_BLKSIZE 1
+EOF
+
+fi
+
+for ac_func in mkdir rename 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 1757 "configure"
+#line 1793 "configure"
#include "confdefs.h"
/* System header to define __stub macros and hopefully few prototypes,
which can conflict with char $ac_func(); below. */
@@ -1777,7 +1813,7 @@ $ac_func();
; return 0; }
EOF
-if { (eval echo configure:1781: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
+if { (eval echo configure:1817: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
rm -rf conftest*
eval "ac_cv_func_$ac_func=yes"
else
@@ -1797,14 +1833,14 @@ fi
done
-for ac_func in fchmod fsync ftime mktemp putenv vfork vprintf ftruncate timezone getpagesize initgroups fchdir sigaction sigprocmask sigvec sigsetmask sigblock tempnam tzset readlink wait3
+for ac_func in fchmod fsync ftime mktemp putenv 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"
+#line 1844 "configure"
#include "confdefs.h"
/* System header to define __stub macros and hopefully few prototypes,
which can conflict with char $ac_func(); below. */
@@ -1828,7 +1864,7 @@ $ac_func();
; return 0; }
EOF
-if { (eval echo configure:1832: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
+if { (eval echo configure:1868: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
rm -rf conftest*
eval "ac_cv_func_$ac_func=yes"
else
@@ -1851,6 +1887,245 @@ fi
done
+cat >> confdefs.h <<\EOF
+#define HAVE_STRCHR 1
+EOF
+
+cat >> confdefs.h <<\EOF
+#define HAVE_MEMCHR 1
+EOF
+
+
+ac_safe=`echo "vfork.h" | tr './\055' '___'`
+echo $ac_n "checking for vfork.h""... $ac_c" 1>&6
+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 1906 "configure"
+#include "confdefs.h"
+#include <vfork.h>
+EOF
+ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out"
+{ (eval echo configure:1911: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }
+ac_err=`grep -v '^ *+' conftest.out`
+if test -z "$ac_err"; then
+ rm -rf conftest*
+ eval "ac_cv_header_$ac_safe=yes"
+else
+ echo "$ac_err" >&5
+ rm -rf conftest*
+ eval "ac_cv_header_$ac_safe=no"
+fi
+rm -f conftest*
+fi
+if eval "test \"`echo '$ac_cv_header_'$ac_safe`\" = yes"; then
+ echo "$ac_t""yes" 1>&6
+ cat >> confdefs.h <<\EOF
+#define HAVE_VFORK_H 1
+EOF
+
+else
+ echo "$ac_t""no" 1>&6
+fi
+
+echo $ac_n "checking for working vfork""... $ac_c" 1>&6
+if eval "test \"`echo '$''{'ac_cv_func_vfork'+set}'`\" = set"; then
+ echo $ac_n "(cached) $ac_c" 1>&6
+else
+ if test "$cross_compiling" = yes; then
+ echo $ac_n "checking for vfork""... $ac_c" 1>&6
+if eval "test \"`echo '$''{'ac_cv_func_vfork'+set}'`\" = set"; then
+ echo $ac_n "(cached) $ac_c" 1>&6
+else
+ cat > conftest.$ac_ext <<EOF
+#line 1943 "configure"
+#include "confdefs.h"
+/* System header to define __stub macros and hopefully few prototypes,
+ which can conflict with char vfork(); 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 vfork();
+
+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_vfork) || defined (__stub___vfork)
+choke me
+#else
+vfork();
+#endif
+
+; return 0; }
+EOF
+if { (eval echo configure:1967: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
+ rm -rf conftest*
+ eval "ac_cv_func_vfork=yes"
+else
+ rm -rf conftest*
+ eval "ac_cv_func_vfork=no"
+fi
+rm -f conftest*
+
+fi
+if eval "test \"`echo '$ac_cv_func_'vfork`\" = yes"; then
+ echo "$ac_t""yes" 1>&6
+ :
+else
+ echo "$ac_t""no" 1>&6
+fi
+
+else
+cat > conftest.$ac_ext <<EOF
+#line 1986 "configure"
+#include "confdefs.h"
+/* Thanks to Paul Eggert for this test. */
+#include <stdio.h>
+#include <sys/types.h>
+#include <sys/stat.h>
+#ifdef HAVE_UNISTD_H
+#include <unistd.h>
+#endif
+#ifdef HAVE_VFORK_H
+#include <vfork.h>
+#endif
+/* On some sparc systems, changes by the child to local and incoming
+ argument registers are propagated back to the parent.
+ The compiler is told about this with #include <vfork.h>,
+ but some compilers (e.g. gcc -O) don't grok <vfork.h>.
+ Test for this by using a static variable whose address
+ is put into a register that is clobbered by the vfork. */
+static
+#ifdef __cplusplus
+sparc_address_test (int arg)
+#else
+sparc_address_test (arg) int arg;
+#endif
+{
+ static pid_t child;
+ if (!child) {
+ child = vfork ();
+ if (child < 0)
+ perror ("vfork");
+ if (!child) {
+ arg = getpid();
+ write(-1, "", 0);
+ _exit (arg);
+ }
+ }
+}
+main() {
+ pid_t parent = getpid ();
+ pid_t child;
+
+ sparc_address_test ();
+
+ child = vfork ();
+
+ if (child == 0) {
+ /* Here is another test for sparc vfork register problems.
+ This test uses lots of local variables, at least
+ as many local variables as main has allocated so far
+ including compiler temporaries. 4 locals are enough for
+ gcc 1.40.3 on a Solaris 4.1.3 sparc, but we use 8 to be safe.
+ A buggy compiler should reuse the register of parent
+ for one of the local variables, since it will think that
+ parent can't possibly be used any more in this routine.
+ Assigning to the local variable will thus munge parent
+ in the parent process. */
+ pid_t
+ p = getpid(), p1 = getpid(), p2 = getpid(), p3 = getpid(),
+ p4 = getpid(), p5 = getpid(), p6 = getpid(), p7 = getpid();
+ /* Convince the compiler that p..p7 are live; otherwise, it might
+ use the same hardware register for all 8 local variables. */
+ if (p != p1 || p != p2 || p != p3 || p != p4
+ || p != p5 || p != p6 || p != p7)
+ _exit(1);
+
+ /* On some systems (e.g. IRIX 3.3),
+ vfork doesn't separate parent from child file descriptors.
+ If the child closes a descriptor before it execs or exits,
+ this munges the parent's descriptor as well.
+ Test for this by closing stdout in the child. */
+ _exit(close(fileno(stdout)) != 0);
+ } else {
+ int status;
+ struct stat st;
+
+ while (wait(&status) != child)
+ ;
+ exit(
+ /* Was there some problem with vforking? */
+ child < 0
+
+ /* Did the child fail? (This shouldn't happen.) */
+ || status
+
+ /* Did the vfork/compiler bug occur? */
+ || parent != getpid()
+
+ /* Did the file descriptor bug occur? */
+ || fstat(fileno(stdout), &st) != 0
+ );
+ }
+}
+EOF
+{ (eval echo configure:2079: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }
+if test -s conftest && (./conftest; exit) 2>/dev/null; then
+ ac_cv_func_vfork=yes
+else
+ ac_cv_func_vfork=no
+fi
+fi
+rm -fr conftest*
+fi
+
+echo "$ac_t""$ac_cv_func_vfork" 1>&6
+if test $ac_cv_func_vfork = no; then
+ cat >> confdefs.h <<\EOF
+#define vfork fork
+EOF
+
+fi
+
+echo $ac_n "checking whether closedir returns void""... $ac_c" 1>&6
+if eval "test \"`echo '$''{'ac_cv_func_closedir_void'+set}'`\" = set"; then
+ echo $ac_n "(cached) $ac_c" 1>&6
+else
+ if test "$cross_compiling" = yes; then
+ ac_cv_func_closedir_void=yes
+else
+cat > conftest.$ac_ext <<EOF
+#line 2105 "configure"
+#include "confdefs.h"
+#include <sys/types.h>
+#include <$ac_header_dirent>
+int closedir(); main() { exit(closedir(opendir(".")) != 0); }
+EOF
+{ (eval echo configure:2111: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }
+if test -s conftest && (./conftest; exit) 2>/dev/null; then
+ ac_cv_func_closedir_void=no
+else
+ ac_cv_func_closedir_void=yes
+fi
+fi
+rm -fr conftest*
+fi
+
+echo "$ac_t""$ac_cv_func_closedir_void" 1>&6
+if test $ac_cv_func_closedir_void = yes; then
+ cat >> confdefs.h <<\EOF
+#define CLOSEDIR_VOID 1
+EOF
+
+fi
+
+
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
@@ -1863,7 +2138,7 @@ else
ac_save_LIBS="$LIBS"
LIBS="-lsec $LIBS"
cat > conftest.$ac_ext <<EOF
-#line 1867 "configure"
+#line 2142 "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
@@ -1875,7 +2150,7 @@ int t() {
getspnam()
; return 0; }
EOF
-if { (eval echo configure:1879: \"$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_lib_$ac_lib_var=yes"
else
@@ -1906,7 +2181,7 @@ 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 1910 "configure"
+#line 2185 "configure"
#include "confdefs.h"
/* System header to define __stub macros and hopefully few prototypes,
which can conflict with char $ac_func(); below. */
@@ -1930,7 +2205,7 @@ $ac_func();
; return 0; }
EOF
-if { (eval echo configure:1934: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
+if { (eval echo configure:2209: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
rm -rf conftest*
eval "ac_cv_func_$ac_func=yes"
else
@@ -1957,53 +2232,6 @@ else
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 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; }
-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_re_exec) || defined (__stub___re_exec)
-choke me
-#else
-re_exec();
-#endif
-
-; return 0; }
-EOF
-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
- rm -rf conftest*
- eval "ac_cv_func_re_exec=no"
-fi
-rm -f conftest*
-
-fi
-if eval "test \"`echo '$ac_cv_func_'re_exec`\" = yes"; then
- echo "$ac_t""yes" 1>&6
- :
-else
- echo "$ac_t""no" 1>&6
-LIBOBJS="$LIBOBJS regex.o"
-fi
-
echo $ac_n "checking whether utime accepts a null argument""... $ac_c" 1>&6
if eval "test \"`echo '$''{'ac_cv_func_utime_null'+set}'`\" = set"; then
echo $ac_n "(cached) $ac_c" 1>&6
@@ -2014,7 +2242,7 @@ if test "$cross_compiling" = yes; then
ac_cv_func_utime_null=no
else
cat > conftest.$ac_ext <<EOF
-#line 2018 "configure"
+#line 2246 "configure"
#include "confdefs.h"
#include <sys/types.h>
#include <sys/stat.h>
@@ -2025,7 +2253,7 @@ exit(!(stat ("conftestdata", &s) == 0 && utime("conftestdata", (long *)0) == 0
&& t.st_mtime - s.st_mtime < 120));
}
EOF
-{ (eval echo configure:2029: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }
+{ (eval echo configure:2257: \"$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
@@ -2089,7 +2317,7 @@ else
ccvs_cv_sys_working_fnmatch=no
else
cat > conftest.$ac_ext <<EOF
-#line 2093 "configure"
+#line 2321 "configure"
#include "confdefs.h"
#include <fnmatch.h>
@@ -2101,7 +2329,7 @@ main ()
? 0 : 1);
}
EOF
-{ (eval echo configure:2105: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }
+{ (eval echo configure:2333: \"$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
@@ -2126,7 +2354,7 @@ 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 2130 "configure"
+#line 2358 "configure"
#include "confdefs.h"
/* System header to define __stub macros and hopefully few prototypes,
which can conflict with char connect(); below. */
@@ -2150,7 +2378,7 @@ connect();
; return 0; }
EOF
-if { (eval echo configure:2154: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
+if { (eval echo configure:2382: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
rm -rf conftest*
eval "ac_cv_func_connect=yes"
else
@@ -2175,7 +2403,7 @@ else
ac_save_LIBS="$LIBS"
LIBS="-lnsl_s $LIBS"
cat > conftest.$ac_ext <<EOF
-#line 2179 "configure"
+#line 2407 "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
@@ -2187,7 +2415,7 @@ int t() {
printf()
; return 0; }
EOF
-if { (eval echo configure:2191: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
+if { (eval echo configure:2419: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
rm -rf conftest*
eval "ac_cv_lib_$ac_lib_var=yes"
else
@@ -2222,7 +2450,7 @@ else
ac_save_LIBS="$LIBS"
LIBS="-lnsl $LIBS"
cat > conftest.$ac_ext <<EOF
-#line 2226 "configure"
+#line 2454 "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
@@ -2234,7 +2462,7 @@ int t() {
printf()
; return 0; }
EOF
-if { (eval echo configure:2238: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
+if { (eval echo configure:2466: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
rm -rf conftest*
eval "ac_cv_lib_$ac_lib_var=yes"
else
@@ -2269,7 +2497,7 @@ else
ac_save_LIBS="$LIBS"
LIBS="-lsocket $LIBS"
cat > conftest.$ac_ext <<EOF
-#line 2273 "configure"
+#line 2501 "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
@@ -2281,7 +2509,7 @@ int t() {
connect()
; return 0; }
EOF
-if { (eval echo configure:2285: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
+if { (eval echo configure:2513: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
rm -rf conftest*
eval "ac_cv_lib_$ac_lib_var=yes"
else
@@ -2316,7 +2544,7 @@ else
ac_save_LIBS="$LIBS"
LIBS="-linet $LIBS"
cat > conftest.$ac_ext <<EOF
-#line 2320 "configure"
+#line 2548 "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
@@ -2328,7 +2556,7 @@ int t() {
connect()
; return 0; }
EOF
-if { (eval echo configure:2332: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
+if { (eval echo configure:2560: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
rm -rf conftest*
eval "ac_cv_lib_$ac_lib_var=yes"
else
@@ -2375,8 +2603,11 @@ 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"
+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 2611 "configure"
#include "confdefs.h"
#include <krb.h>
int main() { return 0; }
@@ -2384,16 +2615,14 @@ int t() {
int i;
; return 0; }
EOF
-if { (eval echo configure:2388: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
+if { (eval echo configure:2619: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
rm -rf conftest*
- krb_h=yes krb_incdir=
+ krb_h=yes krb_incdir=$KRB4/include
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"
+ CFLAGS=$hold_cflags
+ cat > conftest.$ac_ext <<EOF
+#line 2626 "configure"
#include "confdefs.h"
#include <krb.h>
int main() { return 0; }
@@ -2401,20 +2630,36 @@ int t() {
int i;
; return 0; }
EOF
-if { (eval echo configure:2405: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
+if { (eval echo configure:2634: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
rm -rf conftest*
- krb_h=yes krb_incdir=$KRB4/include
+ krb_h=yes krb_incdir=
fi
rm -f conftest*
- CFLAGS=$hold_cflags
- fi
fi
rm -f conftest*
+ CFLAGS=$hold_cflags
+else
+ cat > conftest.$ac_ext <<EOF
+#line 2646 "configure"
+#include "confdefs.h"
+#include <krb.h>
+int main() { return 0; }
+int t() {
+int i;
+; return 0; }
+EOF
+if { (eval echo configure:2654: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
+ rm -rf conftest*
+ krb_h=yes krb_incdir=
+fi
+rm -f conftest*
+
+fi
if test -z "$krb_h"; then
cat > conftest.$ac_ext <<EOF
-#line 2418 "configure"
+#line 2663 "configure"
#include "confdefs.h"
#include <krb.h>
int main() { return 0; }
@@ -2422,7 +2667,7 @@ int t() {
int i;
; return 0; }
EOF
-if { (eval echo configure:2426: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
+if { (eval echo configure:2671: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
rm -rf conftest*
krb_h=yes krb_incdir=
else
@@ -2431,7 +2676,7 @@ else
hold_cflags=$CFLAGS
CFLAGS="$CFLAGS -I$KRB4/include/kerberosIV"
cat > conftest.$ac_ext <<EOF
-#line 2435 "configure"
+#line 2680 "configure"
#include "confdefs.h"
#include <krb.h>
int main() { return 0; }
@@ -2439,7 +2684,7 @@ int t() {
int i;
; return 0; }
EOF
-if { (eval echo configure:2443: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
+if { (eval echo configure:2688: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
rm -rf conftest*
krb_h=yes krb_incdir=$KRB4/include/kerberosIV
fi
@@ -2453,9 +2698,14 @@ rm -f conftest*
fi
echo "$ac_t""$krb_h" 1>&6
+includeopt=
+
if test -n "$krb_h"; then
krb_lib=
- echo $ac_n "checking for -lkrb""... $ac_c" 1>&6
+ if test "$cross_compiling" != yes && test -r $KRB4/lib/libkrb.a; then
+ hold_ldflags=$LDFLAGS
+ LDFLAGS="-L${KRB4}/lib $LDFLAGS"
+ 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
@@ -2463,7 +2713,7 @@ else
ac_save_LIBS="$LIBS"
LIBS="-lkrb $LIBS"
cat > conftest.$ac_ext <<EOF
-#line 2467 "configure"
+#line 2717 "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
@@ -2475,7 +2725,46 @@ int t() {
printf()
; return 0; }
EOF
-if { (eval echo configure:2479: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
+if { (eval echo configure:2729: \"$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=${KRB4}/lib
+else
+ echo "$ac_t""no" 1>&6
+LDFLAGS=$hold_ldflags
+ # Using open here instead of printf so we don't
+ # get confused by the cached value for printf from above.
+ echo $ac_n "checking for -lkrb""... $ac_c" 1>&6
+ac_lib_var=`echo krb'_'open | 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 2756 "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 open();
+
+int main() { return 0; }
+int t() {
+open()
+; return 0; }
+EOF
+if { (eval echo configure:2768: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
rm -rf conftest*
eval "ac_cv_lib_$ac_lib_var=yes"
else
@@ -2491,11 +2780,51 @@ if eval "test \"`echo '$ac_cv_lib_'$ac_lib_var`\" = yes"; then
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
+fi
+
+ LDFLAGS=$hold_ldflags
+ else
+ 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 2798 "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:2810: \"$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
+fi
+
+ fi
if test -n "$krb_lib"; then
cat >> confdefs.h <<\EOF
#define HAVE_KERBEROS 1
@@ -2516,7 +2845,7 @@ else
ac_save_LIBS="$LIBS"
LIBS="-ldes $LIBS"
cat > conftest.$ac_ext <<EOF
-#line 2520 "configure"
+#line 2849 "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
@@ -2528,7 +2857,7 @@ int t() {
printf()
; return 0; }
EOF
-if { (eval echo configure:2532: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
+if { (eval echo configure:2861: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
rm -rf conftest*
eval "ac_cv_lib_$ac_lib_var=yes"
else
@@ -2549,7 +2878,6 @@ fi
LDFLAGS=$hold_ldflags
if test -n "$krb_incdir"; then
includeopt="${includeopt} -I$krb_incdir"
-
fi
fi
fi
@@ -2560,7 +2888,7 @@ 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 2564 "configure"
+#line 2892 "configure"
#include "confdefs.h"
/* System header to define __stub macros and hopefully few prototypes,
which can conflict with char $ac_func(); below. */
@@ -2584,7 +2912,7 @@ $ac_func();
; return 0; }
EOF
-if { (eval echo configure:2588: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
+if { (eval echo configure:2916: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
rm -rf conftest*
eval "ac_cv_func_$ac_func=yes"
else
@@ -2607,6 +2935,102 @@ fi
done
+GSSAPI=/usr/cygnus/kerbnet
+
+# Check whether --with-gssapi or --without-gssapi was given.
+if test "${with_gssapi+set}" = set; then
+ withval="$with_gssapi"
+ GSSAPI=$withval
+fi
+echo "default place for GSSAPI is $GSSAPI"
+
+
+echo $ac_n "checking for gssapi.h""... $ac_c" 1>&6
+hold_cppflags=$CPPFLAGS
+CPPFLAGS="$CPPFLAGS -I$GSSAPI/include "
+ac_safe=`echo "gssapi/gssapi.h" | tr './\055' '___'`
+echo $ac_n "checking for gssapi/gssapi.h""... $ac_c" 1>&6
+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 2958 "configure"
+#include "confdefs.h"
+#include <gssapi/gssapi.h>
+EOF
+ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out"
+{ (eval echo configure:2963: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }
+ac_err=`grep -v '^ *+' conftest.out`
+if test -z "$ac_err"; then
+ rm -rf conftest*
+ eval "ac_cv_header_$ac_safe=yes"
+else
+ echo "$ac_err" >&5
+ rm -rf conftest*
+ eval "ac_cv_header_$ac_safe=no"
+fi
+rm -f conftest*
+fi
+if eval "test \"`echo '$ac_cv_header_'$ac_safe`\" = yes"; then
+ echo "$ac_t""yes" 1>&6
+ cat >> confdefs.h <<\EOF
+#define HAVE_GSSAPI 1
+EOF
+
+ LIBS="$LIBS -L$GSSAPI/lib -lgssapi_krb5 -lkrb5 -lcrypto -lcom_err"
+ includeopt="${includeopt} -I$GSSAPI/include"
+ # This is necessary on Irix 5.3, in order to link against libkrb5 --
+ # there, an_to_ln.o refers to things defined only in -lgen.
+ echo $ac_n "checking for -lgen""... $ac_c" 1>&6
+ac_lib_var=`echo gen'_'compile | 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="-lgen $LIBS"
+cat > conftest.$ac_ext <<EOF
+#line 2993 "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 compile();
+
+int main() { return 0; }
+int t() {
+compile()
+; return 0; }
+EOF
+if { (eval echo configure:3005: \"$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 gen | tr 'abcdefghijklmnopqrstuvwxyz' 'ABCDEFGHIJKLMNOPQRSTUVWXYZ'`
+ cat >> confdefs.h <<EOF
+#define $ac_tr_lib 1
+EOF
+
+ LIBS="-lgen $LIBS"
+
+else
+ echo "$ac_t""no" 1>&6
+fi
+
+else
+ echo "$ac_t""no" 1>&6
+fi
+
+CPPFLAGS=$hold_cppflags
+
# Check whether --enable-encryption or --disable-encryption was given.
if test "${enable_encryption+set}" = set; then
enableval="$enable_encryption"
@@ -2631,7 +3055,7 @@ 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 2635 "configure"
+#line 3059 "configure"
#include "confdefs.h"
/* System header to define __stub macros and hopefully few prototypes,
which can conflict with char gethostname(); below. */
@@ -2655,7 +3079,7 @@ gethostname();
; return 0; }
EOF
-if { (eval echo configure:2659: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
+if { (eval echo configure:3083: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
rm -rf conftest*
eval "ac_cv_func_gethostname=yes"
else
@@ -2732,7 +3156,7 @@ else
ac_save_LIBS="$LIBS"
LIBS="-lcrypt $LIBS"
cat > conftest.$ac_ext <<EOF
-#line 2736 "configure"
+#line 3160 "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
@@ -2744,7 +3168,7 @@ int t() {
crypt()
; return 0; }
EOF
-if { (eval echo configure:2748: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
+if { (eval echo configure:3172: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
rm -rf conftest*
eval "ac_cv_lib_$ac_lib_var=yes"
else
@@ -2775,7 +3199,7 @@ 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 2779 "configure"
+#line 3203 "configure"
#include "confdefs.h"
/* System header to define __stub macros and hopefully few prototypes,
which can conflict with char $ac_func(); below. */
@@ -2799,7 +3223,7 @@ $ac_func();
; return 0; }
EOF
-if { (eval echo configure:2803: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
+if { (eval echo configure:3227: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then
rm -rf conftest*
eval "ac_cv_func_$ac_func=yes"
else
@@ -2830,6 +3254,50 @@ EOF
fi
fi # enable_server
+echo $ac_n "checking for cygwin32""... $ac_c" 1>&6
+if eval "test \"`echo '$''{'ccvs_cv_sys_cygwin32'+set}'`\" = set"; then
+ echo $ac_n "(cached) $ac_c" 1>&6
+else
+ cat > conftest.$ac_ext <<EOF
+#line 3263 "configure"
+#include "confdefs.h"
+
+int main() { return 0; }
+int t() {
+return __CYGWIN32__;
+; return 0; }
+EOF
+if { (eval echo configure:3271: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then
+ rm -rf conftest*
+ ccvs_cv_sys_cygwin32=yes
+else
+ rm -rf conftest*
+ ccvs_cv_sys_cygwin32=no
+fi
+rm -f conftest*
+
+fi
+
+echo "$ac_t""$ccvs_cv_sys_cygwin32" 1>&6
+if test $ccvs_cv_sys_cygwin32 = yes; then
+ LIBOBJS="$LIBOBJS fncase.o"
+ LIBS="$LIBS -ladvapi32"
+
+ cat >> confdefs.h <<\EOF
+#define UTIME_EXPECTS_WRITABLE 1
+EOF
+
+
+ cat >> confdefs.h <<\EOF
+#define USE_SETMODE_STDOUT 1
+EOF
+
+ cat >> confdefs.h <<\EOF
+#define HAVE_SETMODE 1
+EOF
+
+fi
+
test -f src/options.h && (
echo "configure: warning: saving ./src/options.h in ./src/options.h-SAVED" 1>&2
echo "configure: warning: You may wish to check that local options have not been lost." 1>&2
@@ -2924,7 +3392,7 @@ done
ac_given_srcdir=$srcdir
ac_given_INSTALL="$INSTALL"
-trap 'rm -fr `echo "Makefile lib/Makefile src/Makefile zlib/Makefile doc/Makefile \
+trap 'rm -fr `echo "Makefile lib/Makefile src/Makefile zlib/Makefile diff/Makefile doc/Makefile \
man/Makefile tools/Makefile tools/pcl-cvs/Makefile \
contrib/Makefile contrib/elib/Makefile \
windows-NT/Makefile windows-NT/SCC/Makefile \
@@ -2972,12 +3440,13 @@ s%@csh_path@%$csh_path%g
s%@LIBOBJS@%$LIBOBJS%g
s%@KRB4@%$KRB4%g
s%@includeopt@%$includeopt%g
+s%@GSSAPI@%$GSSAPI%g
CEOF
EOF
cat >> $CONFIG_STATUS <<EOF
-CONFIG_FILES=\${CONFIG_FILES-"Makefile lib/Makefile src/Makefile zlib/Makefile doc/Makefile \
+CONFIG_FILES=\${CONFIG_FILES-"Makefile lib/Makefile src/Makefile zlib/Makefile diff/Makefile doc/Makefile \
man/Makefile tools/Makefile tools/pcl-cvs/Makefile \
contrib/Makefile contrib/elib/Makefile \
windows-NT/Makefile windows-NT/SCC/Makefile \
diff --git a/contrib/cvs/configure.in b/contrib/cvs/configure.in
index 2b1b8ec52830..292958ddcd56 100644
--- a/contrib/cvs/configure.in
+++ b/contrib/cvs/configure.in
@@ -10,8 +10,8 @@ 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.
+dnl Makefile.in files. Rumor has it that autoconf 2.7
+dnl introduced --bindir but the point is that 2.10 has it.
AC_CONFIG_HEADER(config.h src/options.h)
AC_PROG_CC
@@ -50,6 +50,7 @@ fi
AC_HEADER_STDC
AC_CHECK_HEADERS(errno.h unistd.h string.h memory.h utime.h fcntl.h ndbm.h \
+ limits.h sys/file.h \
sys/param.h sys/select.h sys/time.h sys/timeb.h \
io.h direct.h sys/bsdtypes.h sys/resource.h)
AC_HEADER_SYS_WAIT
@@ -61,8 +62,33 @@ 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 vasprintf strtoul)
-AC_CHECK_FUNCS(fchmod fsync ftime mktemp putenv vfork vprintf ftruncate timezone getpagesize initgroups fchdir sigaction sigprocmask sigvec sigsetmask sigblock tempnam tzset readlink wait3)
+AC_STRUCT_ST_BLKSIZE
+AC_REPLACE_FUNCS(mkdir rename strstr dup2 strerror valloc waitpid vasprintf strtoul)
+AC_CHECK_FUNCS(fchmod fsync ftime mktemp putenv vprintf ftruncate timezone getpagesize initgroups fchdir sigaction sigprocmask sigvec sigsetmask sigblock tempnam tzset readlink wait3)
+
+dnl
+dnl The CVS coding standard (as specified in HACKING) is that if it exists
+dnl in SunOS4 and ANSI, we use it. CVS itself, of course, therefore doesn't
+dnl need HAVE_* defines for such functions, but diff wants them.
+dnl
+AC_DEFINE(HAVE_STRCHR)
+AC_DEFINE(HAVE_MEMCHR)
+
+dnl
+dnl AC_FUNC_VFORK is rather baroque. It seems to be rather more picky
+dnl than, say, the Single Unix Specification (version 2), which simplifies
+dnl a lot of cases by saying that the child process can't set any variables
+dnl (thus avoiding problems with register allocation) or call any functions
+dnl (thus avoiding problems with whether file descriptors are shared).
+dnl It would be nice if we could just write to the Single Unix Specification.
+dnl I think the only way to do redirection this way is by doing it in the
+dnl parent, and then undoing it afterwards (analogous to windows-NT/run.c).
+dnl That would appear to have a race condition if the user hits ^C (or
+dnl some other signal) at the wrong time, as main_cleanup will try to use
+dnl stdout/stderr. So maybe we are stuck with AC_FUNC_VFORK.
+dnl
+AC_FUNC_VFORK
+AC_FUNC_CLOSEDIR_VOID
dnl
dnl Look for shadow password files before we go ahead and set getspnam.
@@ -84,7 +110,24 @@ else
fi
AC_MSG_RESULT([$found])
-AC_CHECK_FUNC(re_exec, :, LIBOBJS="$LIBOBJS regex.o")
+dnl We always use CVS's regular expression matcher.
+dnl This is because:
+dnl (1) If memory serves, the syntax of the regular expressions
+dnl handled by re_exec is not consistent from system to system, which
+dnl is a Bad Thing because CVS passes this syntax out to the user.
+dnl We might have better luck with the POSIX interface, if we really
+dnl want to look for a system-supplied matcher.
+dnl (2) It is necessary to make _sure_ that we get a regex.h and regex.c
+dnl that match each other. In particular, rx and the CVS/emacs
+dnl regex.c have a different "struct re_pattern_buffer" and so using
+dnl the system regex.h and our regex.c, or vice versa, will tend to
+dnl cause a core dump.
+dnl (3) Just as a random data point, CVS uses re_exec (a BSD interface);
+dnl libdiff uses re_compile_pattern (a GNU interface, I think). Diff
+dnl should probably be fixed to have the caller (CVS) supply the regexp
+dnl matching.
+dnl
+dnl AC_CHECK_FUNC(re_exec, :, LIBOBJS="$LIBOBJS regex.o")
AC_FUNC_UTIME_NULL
AC_SYS_LONG_FILE_NAMES
@@ -139,6 +182,10 @@ fi])
dnl
dnl set $(KRB4) from --with-krb4=value -- WITH_KRB4
dnl
+dnl If you change this, keep in mind that some systems have a bogus
+dnl libkrb in the system libraries, so --with-krb4=value needs to
+dnl override the system -lkrb.
+dnl
KRB4=/usr/kerberos
define(WITH_KRB4,[
AC_ARG_WITH([krb4],
@@ -151,15 +198,19 @@ WITH_KRB4
krb_h=
AC_MSG_CHECKING([for krb.h])
-AC_TRY_LINK([#include <krb.h>],[int i;],
- [krb_h=yes krb_incdir=],
- [if test "$cross_compiling" != yes && test -r $KRB4/include/krb.h; then
- hold_cflags=$CFLAGS
- CFLAGS="$CFLAGS -I$KRB4/include"
- AC_TRY_LINK([#include <krb.h>],[int i;],
- [krb_h=yes krb_incdir=$KRB4/include])
- CFLAGS=$hold_cflags
- fi])
+if test "$cross_compiling" != yes && test -r $KRB4/include/krb.h; then
+ hold_cflags=$CFLAGS
+ CFLAGS="$CFLAGS -I$KRB4/include"
+ AC_TRY_LINK([#include <krb.h>],[int i;],
+ [krb_h=yes krb_incdir=$KRB4/include],
+ [CFLAGS=$hold_cflags
+ AC_TRY_LINK([#include <krb.h>],[int i;],
+ [krb_h=yes krb_incdir=])])
+ CFLAGS=$hold_cflags
+else
+ AC_TRY_LINK([#include <krb.h>],[int i;],
+ [krb_h=yes krb_incdir=])
+fi
if test -z "$krb_h"; then
AC_TRY_LINK([#include <krb.h>],[int i;],
[krb_h=yes krb_incdir=],
@@ -173,12 +224,22 @@ if test -z "$krb_h"; then
fi
AC_MSG_RESULT($krb_h)
+includeopt=
+AC_SUBST(includeopt)
if test -n "$krb_h"; then
krb_lib=
- AC_CHECK_LIB(krb,printf,[krb_lib=yes krb_libdir=],
- [if test "$cross_compiling" != yes && test -r $KRB4/lib/libkrb.a; then
- krb_lib=yes krb_libdir=$KRB4/lib
- fi])
+ if test "$cross_compiling" != yes && test -r $KRB4/lib/libkrb.a; then
+ hold_ldflags=$LDFLAGS
+ LDFLAGS="-L${KRB4}/lib $LDFLAGS"
+ AC_CHECK_LIB(krb,printf,[krb_lib=yes krb_libdir=${KRB4}/lib],
+ [LDFLAGS=$hold_ldflags
+ # Using open here instead of printf so we don't
+ # get confused by the cached value for printf from above.
+ AC_CHECK_LIB(krb,open,[krb_lib=yes krb_libdir=])])
+ LDFLAGS=$hold_ldflags
+ else
+ AC_CHECK_LIB(krb,printf,[krb_lib=yes krb_libdir=])
+ fi
if test -n "$krb_lib"; then
AC_DEFINE(HAVE_KERBEROS)
test -n "${krb_libdir}" && LIBS="${LIBS} -L${krb_libdir}"
@@ -192,13 +253,37 @@ if test -n "$krb_h"; then
LDFLAGS=$hold_ldflags
if test -n "$krb_incdir"; then
includeopt="${includeopt} -I$krb_incdir"
- AC_SUBST(includeopt)
fi
fi
fi
AC_CHECK_FUNCS(krb_get_err_text)
dnl
+dnl Use --with-gssapi=DIR to enable GSSAPI support.
+dnl
+GSSAPI=/usr/cygnus/kerbnet
+define(WITH_GSSAPI,[
+AC_ARG_WITH([gssapi],
+ [ --with-gssapi=value GSSAPI directory],
+ [GSSAPI=$withval],
+)dnl
+echo "default place for GSSAPI is $GSSAPI"
+AC_SUBST(GSSAPI)])dnl
+WITH_GSSAPI
+
+AC_MSG_CHECKING([for gssapi.h])
+hold_cppflags=$CPPFLAGS
+CPPFLAGS="$CPPFLAGS -I$GSSAPI/include "
+AC_CHECK_HEADER(gssapi/gssapi.h,
+ [AC_DEFINE(HAVE_GSSAPI)
+ LIBS="$LIBS -L$GSSAPI/lib -lgssapi_krb5 -lkrb5 -lcrypto -lcom_err"
+ includeopt="${includeopt} -I$GSSAPI/include"
+ # This is necessary on Irix 5.3, in order to link against libkrb5 --
+ # there, an_to_ln.o refers to things defined only in -lgen.
+ AC_CHECK_LIB(gen, compile)])
+CPPFLAGS=$hold_cppflags
+
+dnl
dnl Use --with-encryption to turn on encryption support
dnl
AC_ARG_ENABLE(encryption,
@@ -255,6 +340,29 @@ if test "$ac_cv_func_crypt" = yes; then
fi
fi # enable_server
+dnl On cygwin32, we configure like a Unix system, but we use the
+dnl Windows support code in lib/fncase.c to handle the case
+dnl insensitive file system. We also need some support libraries. We
+dnl do this at the end so that the new libraries are added at the end
+dnl of LIBS.
+AC_CACHE_CHECK(for cygwin32, ccvs_cv_sys_cygwin32,
+[AC_TRY_COMPILE([], [return __CYGWIN32__;],
+ccvs_cv_sys_cygwin32=yes, ccvs_cv_sys_cygwin32=no)])
+if test $ccvs_cv_sys_cygwin32 = yes; then
+ LIBOBJS="$LIBOBJS fncase.o"
+ LIBS="$LIBS -ladvapi32"
+
+ dnl On Windows you can only change file times if you can write to
+ dnl the file. cygwin32 should really handle this for us, but as of
+ dnl January 1998 it doesn't.
+ AC_DEFINE(UTIME_EXPECTS_WRITABLE)
+
+ dnl On Windows we must use setmode to change between binary and text
+ dnl mode.
+ AC_DEFINE(USE_SETMODE_STDOUT)
+ AC_DEFINE(HAVE_SETMODE)
+fi
+
test -f src/options.h && (
AC_MSG_WARN(saving ./src/options.h in ./src/options.h-SAVED)
AC_MSG_WARN(You may wish to check that local options have not been lost.)
@@ -262,7 +370,7 @@ test -f src/options.h && (
cp ./src/options.h ./src/options.h-SAVED
)
-AC_OUTPUT(Makefile lib/Makefile src/Makefile zlib/Makefile doc/Makefile \
+AC_OUTPUT(Makefile lib/Makefile src/Makefile zlib/Makefile diff/Makefile doc/Makefile \
man/Makefile tools/Makefile tools/pcl-cvs/Makefile \
contrib/Makefile contrib/elib/Makefile \
windows-NT/Makefile windows-NT/SCC/Makefile \
diff --git a/contrib/cvs/contrib/ChangeLog b/contrib/cvs/contrib/ChangeLog
index 0c45efae9236..3db22a5604b4 100644
--- a/contrib/cvs/contrib/ChangeLog
+++ b/contrib/cvs/contrib/ChangeLog
@@ -1,3 +1,39 @@
+Thu Aug 7 22:42:23 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * pvcs_to_rcs: Remove RCS keywords. Remove $Log and move the data
+ to this ChangeLog (below). Add paragraph that David Martin
+ emailed along with the script.
+
+ Revision 1.6 1997/03/07 16:21:28 divad
+ Need to explicitly state archive name in PVCS get command for
+ those cases where the case of the workfile and the case of the
+ archive file are different (OS/2)
+
+ Revision 1.5 1997/03/07 00:31:04 divad
+ Added capitalized extensions and framemaker files as binaries;
+ also overriding any path specification for workfiles at PVCS
+ checkout (most annoying).
+
+ Revision 1.4 1997/03/06 21:04:55 divad
+ Added \n to the end of each comment line to prevent multi-line
+ comments for a single revision from "merging"
+
+ Revision 1.3 1997/03/06 19:50:25 divad
+ Corrected bug in binary extensions; correcting processing
+ comment strings with double quotes
+
+ Revision 1.2 1997/03/06 17:29:10 divad
+ Provided list of extensions (rather than using Unix file
+ command) to determine which files are binary; also printing
+ version label as they are applied
+
+ Revision 1.1 1997/02/26 00:04:29 divad
+ Perl script to convert pvcs archives to rcs archives
+
+ * README: mention pvcs_to_rcs.
+ * pvcs_to_rcs: New file. This is the file as I got it from David
+ Martin. Will be checking in the tweaks shortly.
+
17 May 1997 Jim Kingdon
* listen2.c: Failed attempt at making this do what it was
diff --git a/contrib/cvs/contrib/README b/contrib/cvs/contrib/README
index 900b0c75f749..223b759b0c7f 100644
--- a/contrib/cvs/contrib/README
+++ b/contrib/cvs/contrib/README
@@ -86,6 +86,10 @@ An attempt at a table of Contents for this directory:
into RCS files, retaining the info contained in the
SCCS file (like dates, author, and log message).
Contributed by Ken Cox <kenstir@viewlogic.com>.
+ pvcs_to_rcs A perl script that can convert (some) PVCS histories
+ into RCS files, retaining the info contained in the
+ PVCS history. See the comments at the start of the
+ file for more details.
intro.doc A user's view of what you need to know to get
started with CVS.
Contributed by <Steven.Pemberton@cwi.nl>.
diff --git a/contrib/cvs/contrib/pvcs_to_rcs b/contrib/cvs/contrib/pvcs_to_rcs
new file mode 100644
index 000000000000..7d526d81ad21
--- /dev/null
+++ b/contrib/cvs/contrib/pvcs_to_rcs
@@ -0,0 +1,439 @@
+#! /opt/bin/perl5
+#
+# Beware of the fact that this script was not written to handle
+# branches in the PVCS archives, but it might work nontheless. I have
+# a specific addition in this latest version that would not be
+# globally useful: automatically making Framemaker files binary with
+# -kb (regardless of the file extension).
+# ---------------------------------
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+
+###########################################################################
+# FUNCTION:
+# To recursively walk through a PVCS archive directory tree (archives
+# located in VCS/ or vcs/ subdirectories) and convert them to RCS archives.
+# The RCS archive name is the PVCS workfile name with ",v" appended.
+#
+# SYNTAX:
+# The calling syntax is:
+# pvcs_to_rcs [-l]
+#
+# where -l indicates the operation is to be performed only in the current
+# directory (no recursion)
+#
+# EXAMPLE:
+# pvcs_to_rcs
+#
+# Would walk through every VCS or vcs subdir starting at the current directory,
+# and produce corresponding RCS archives one level above the VCS or vcs subdir.
+#
+# NOTES:
+# * This script does not perform any error checking or logging of any kind
+# (i.e. USE AT YOUR OWN RISK)
+# * This script was developed using perl-5.003 on a Sun Solaris 2.5 machine
+# and executed from a csh
+# * PVCS archives in VCS/ or vcs/ subdirectories are left intact
+# * RCS archives are processed in the VCS/ or vcs/ subdirectories and
+# are moved (forcibly) up one level upon completion of the conversion
+# * This script has *not* been tested with PVCS archives with branches,
+# although the only thing I believe that might need to be changed
+# is the ORDER of revision processing (e.g. you can't checkin 1.2.4.1 if
+# you haven't yet checked in 1.2).
+# * All revisions are saved with correct "metadata" (i.e. check-in date,
+# author, and log message). Any blank log message is replaced with
+# "no comment". This is because RCS does not allow non-interactive
+# checkin of a new revision without a comment string.
+# * Revision numbers are incremented by 1 during the conversion (since
+# RCS does not allow revision 1.0).
+# * Version labels are assigned to the appropriate (incremented) revision
+# numbers. PVCS allows spaces and periods in version labels while RCS
+# does not. A global search and replace converts " " and "." to "_"
+# There may be other cases that ought to be added.
+# * Any workfile within the VCS/ or vcs/ will be deleted (or overwritten)
+# since it is used in the checkout of each revision
+# * Locks on PVCS archives should be removed (or the workfiles should be
+# checked-in) prior to conversion, although the script will blaze through
+# the archive nonetheless (But you would lose any checked out revision(s))
+# * The -kb option is added to the RCS archive for workfiles with the following
+# extensions: .bin .out .btl .rom .a07 .lib .exe .tco .obj .t8u .c8u .o .lku
+#########################################################################
+
+require("getcwd.pl");
+
+#NOTE: Each possible binary extension is delimited by '.'
+$bin_ext =
+".bin.out.btl.rom.a07.lib.exe.tco.obj.t8u.c8u.o.lku.BIN.OUT.BTL.ROM.A07.LIB.EXE.TCO.OBJ
+.T8U.C8U.O.LKU.";
+
+# the main procedure that is run once in each directory
+sub execdir
+{
+ $curlevel= $curlevel +1;
+
+#local sets the variables directory and prev directory local to the procedure
+
+ local($dir,$prevdir)=@_;
+
+#change into the directory to be processed
+
+ chdir($dir);
+
+#open the current directory for listing
+
+ opendir(CURDIR,".");
+
+#initialize the list of filenames
+
+ local(@filenames);
+
+#set filenames equal to directory listing
+
+ @filenames = readdir(CURDIR);
+
+#clean up by closing the directory
+
+ closedir(CURDIR);
+
+#initialize a list for any subdirectories
+ local(@subdirs);
+
+#begin a for loop to execute on each filename in the list @filename
+ for (@filenames)
+
+ {
+#if the file is a directory...
+ if (-d $_)
+ {
+#include it in @subdir
+ push(@subdirs,$_);
+ }
+ }
+
+#for loop of subdirs
+ for (@subdirs)
+#if not a parent directory, run execdir on each sub dir
+ {
+ if (($_ ne '.') and ($_ ne '..') and ($maxlevel > $curlevel))
+ {
+ &execdir($_,$dir);
+ }
+ }
+
+#save the current directory
+ $cd = &getcwd;
+
+#Print output header for each directory
+ print("Directory: $cd\n");
+
+#determine the last directory in this path (to only process vcs or VCS)
+ $_ = $cd;
+ $num_dirs = split /\//;
+ @dirs = @_;
+ $last_dir = $dirs[$num_dirs-1];
+# print"Last directory is $last_dir\n";
+
+#shell redirection: output from command in @ARGV is put in $output
+# $output = `@ARGV`;
+#begin a for loop to execute on each filename in the list @filename
+ for (@filenames)
+ {
+ if ( (-f $_) and ($_ ne '.') and ($_ ne '..') and ($maxlevel > $curlevel)
+ and ( ( $last_dir eq 'vcs' ) or ( $last_dir eq 'VCS' ) ) )
+ {
+ $got_archivefile = 0;
+ $got_workfile = 0;
+ $got_version_labels = 0;
+ $got_description = 0;
+ $got_rev_count = 0;
+
+ $file = $_;
+ $abs_file = $cd . "/" . $file;
+ print("Converting $abs_file...\n");
+ $vlog_output = `vlog $_`;
+ $_ = $vlog_output;
+# Split the cvs status output into individual lines
+ @vlog_strings = split /\n/;
+ $num_vlog_strings = @vlog_strings;
+ $_ = $vlog_string[0];
+ if ( /^vlog: warning/ )
+ {
+ print("$abs_file is NOT a valid PVCS archive!!!\n");
+ }
+ elsif( $vlog_output )
+ {
+
+# Collect all vlog output into appropriate variables
+
+ $num = 0;
+ while( $num < $num_vlog_strings )
+ {
+# print("$vlog_strings[$num]\n");
+
+ $_ = $vlog_strings[$num];
+
+ if( ( /^Workfile:\s*/ ) && (!$got_workfile ) )
+ {
+ $got_workfile = 1;
+# get the string to the right of the above search (with any path stripped)
+ $workfile = $';
+ $_=$workfile;
+ $num_fields = split /\//;
+ if ( $num_fields > 1 )
+ {
+ $workfile = $_[$num_fields - 1 ];
+ }
+# print"Workfile is $workfile\n";
+ }
+
+ elsif( ( /^Archive:\s*/ ) && (!$got_archivefile ) )
+ {
+ $got_archivefile = 1;
+# get the string to the right of the above search (with any path stripped)
+ $archivefile = $';
+ $_=$archivefile;
+ $num_fields = split /\//;
+ if ( $num_fields > 1 )
+ {
+ $archivefile = $_[$num_fields - 1 ];
+ }
+# print"Archive is $archivefile\n";
+ }
+
+ elsif ( ( /^Rev count:\s*/ ) && (!$got_rev_count ) )
+ {
+ $got_rev_count = 1;
+# get the string to the right of the above search
+ $rev_count = $';
+ print"Revision count is $rev_count\n";
+ }
+
+ elsif ( ( /^Version labels:\s*/ ) && (!$got_version_labels ) )
+ {
+ $got_version_labels = 1;
+ $first_vl = $num+1;
+ }
+
+ elsif ( ( /^Description:\s*/ ) && (!$got_description ) )
+ {
+ $got_description = 1;
+ $description = "\"" . $vlog_strings[$num+1] . "\"";
+# print"Description is $description\n";
+ $last_vl = $num - 1;
+ }
+
+ elsif ( /^Rev\s*/ ) # get all the revision information at once
+ {
+ $rev_index = 0;
+ while ( $rev_index < $rev_count )
+ {
+ $_=$vlog_strings[$num];
+ /^Rev\s*/;
+ $rev_num[$rev_index] = $';
+ $_=$vlog_strings[$num+1];
+ if ( /^Locked\s*/ )
+ {
+ $num += 1;
+ }
+ $_=$vlog_strings[$num+1];
+ /^Checked in:\s*/;
+ $checked_in[$rev_index] = "\"" . $' . "\"";
+ $_=$vlog_strings[$num+3];
+ /^Author id:\s*/;
+ split;
+ $author[$rev_index] = "\"" . $_[2] . "\"";
+ $relative_comment_index = 0;
+ $comment_string = "";
+ while( ( $vlog_strings[$num+4+$relative_comment_index] ne
+ "-----------------------------------" ) &&
+ ( $vlog_strings[$num+4+$relative_comment_index] ne
+ "===================================" ) )
+ {
+# We need the \n added for multi-line comments. There is no effect for
+# single-line comments since RCS inserts the \n if it doesn't exist already
+ $comment_string = $comment_string .
+$vlog_strings[$num+4+$relative_comment_index] . "\n";
+ $relative_comment_index += 1;
+ }
+# Convert any double quotes to an escaped double quote
+ $comment_string =~ s/\"/\\\"/g;
+ $comment[$rev_index] = "\"" . $comment_string . "\"";
+ $num += ( 5 + $relative_comment_index );
+ $rev_index += 1;
+ }
+ $num -= 1; #although there should be nothing left for this to matter
+ }
+
+ $num += 1;
+
+ }
+
+# Loop through each version label, checking for need to relabel ' ' with '_'.
+ $num_version_labels = $last_vl - $first_vl + 1;
+ print"Version label count is $num_version_labels\n";
+ for( $i = $first_vl; $i <= $last_vl; $i += 1 )
+ {
+# print("$vlog_strings[$i]\n");
+ $label_index = $i - $first_vl;
+ $_=$vlog_strings[$i];
+ split /\"/;
+ $label = @_[1];
+ $_=@_[2];
+ split;
+ $label_revision[$label_index] = @_[1];
+
+# Create RCS revision numbers corresponding to PVCS version numbers by
+# adding 1 to the revision number (# after last .)
+ $rcs_rev = &pvcs_to_rcs_rev_number( $label_revision[$label_index]);
+ $label_revision[ $label_index ] = $rcs_rev;
+# replace ' ' with '_', if needed
+ $_=$label;
+ $new_label[$label_index] = $label;
+ $new_label[$label_index] =~ s/ /_/g;
+ $new_label[$label_index] =~ s/\./_/g;
+ $new_label[$label_index] = "\"" . $new_label[$label_index] . "\"";
+# print"Label $new_label[$label_index] is for revision
+$label_revision[$label_index]\n";
+ }
+
+# Create RCS revision numbers corresponding to PVCS version numbers by
+# adding 1 to the revision number (# after last .)
+
+ for( $i = 0; $i < $rev_count; $i += 1 )
+ {
+ $rcs_rev_num[ $i ] = &pvcs_to_rcs_rev_number( $rev_num[ $i ] );
+# print"PVCS is $rev_num[ $i ]; RCS is $rcs_rev_num[ $i ]\n"
+ }
+
+# Create RCS archive and check in all revisions, then label.
+# PVCS vlog lists revisions last-revision-first; reverse that ordering
+ $first_time = 1;
+
+ for( $i = $rev_count - 1; $i >= 0; $i -= 1 )
+ {
+ print "get -r$rev_num[$i] $archivefile\\($workfile\\)\n";
+# $vcs_output = `vcs -u -r$rev_num[$i] $file`;
+ $get_output = `get -r$rev_num[$i] $archivefile\\($workfile\\)`;
+ if( $first_time )
+ {
+ $first_time = 0;
+ $file_output = `file $workfile`;
+# If an empty comment is specified, RCS will not check in the file;
+# check for this case. (but an empty -t- description is fine - go figure!)
+# Since RCS will pause and ask for a comment if one is not given,
+# substitute a dummy comment "no comment".
+ if ( $comment[$i] eq "\"\"" )
+ {
+ $ci_command = "ci -f -r$rcs_rev_num[$i] -d$checked_in[$i] -w$author[$i]
+-t-$description -m\"no comment\" $workfile";
+ }
+ else
+ {
+ $ci_command = "ci -f -r$rcs_rev_num[$i] -d$checked_in[$i] -w$author[$i]
+-t-$description -m$comment[$i] $workfile";
+ }
+ print "$ci_command\n";
+ $ci_output = `$ci_command`;
+
+# Also check here whether this file ought to be "binary"
+ $_=$file_output;
+ split;
+ if( $_[1] eq "Frame" )
+ {
+ print"Binary attribute -kb added (file type is Frame)\n";
+ $rcs_output = `rcs -kb $workfile,v`;
+ }
+ else
+ {
+ $_=$workfile;
+ $num_fields = split /\./;
+ if ( $num_fields > 1 )
+ {
+ $ext = "." . $_[$num_fields - 1] . ".";
+ if ( ( index $bin_ext, $ext ) > - 1 )
+ {
+ print"Binary attribute -kb added (file type is $ext)\n";
+ $rcs_output = `rcs -kb $workfile,v`;
+ }
+ }
+ }
+ }
+ else
+ {
+ $rcs_output = `rcs -l $workfile`;
+# If an empty comment is specified, RCS will not check in the file;
+# check for this case. (but an empty -t- description is fine - go figure!)
+ if ( $comment[$i] eq "\"\"" )
+ {
+ $ci_command = "ci -f -r$rcs_rev_num[$i] -d$checked_in[$i] -w$author[$i]
+-m\"no comment\" $workfile";
+ }
+ else
+ {
+ $ci_command = "ci -f -r$rcs_rev_num[$i] -d$checked_in[$i] -w$author[$i]
+-m$comment[$i] $workfile";
+ }
+ print "$ci_command\n";
+ $ci_output = `$ci_command`;
+ }
+ }
+# Attach version labels
+ for( $i = $num_version_labels - 1; $i >= 0; $i -= 1 )
+ {
+# print "rcs -n$new_label[$i]:$label_revision[$i] $workfile\n";
+ $rcs_output = `rcs -n$new_label[$i]:$label_revision[$i] $workfile`;
+ print "Version label $new_label[$i] added to revision $label_revision[$i]\n";
+ }
+
+# Move archive file up one directory level (above vcs/ or VCS/)
+ $mv_output = `mv -f $workfile",v" ..`;
+ }
+ }
+ }
+
+#print the output to STDOUT
+# print("$output");
+
+ $curlevel=$curlevel - 1;
+ if ($dir ne $prevdir)
+ {
+ chdir('..');
+ }
+}
+
+sub pvcs_to_rcs_rev_number
+{
+ local($input, $num_fields, @rev_string, $return_rev_num, $i);
+
+ $input = @_[0];
+ $_ = $input;
+ $num_fields = split /\./;
+ @rev_string = @_;
+ @rev_string[$num_fields-1] += 1;
+ $return_rev_num = @rev_string[ 0 ];
+ for( $i = 1; $i < $num_fields; $i += 1 )
+ {
+ $return_rev_num = $return_rev_num . "." . @rev_string[ $i ];
+ }
+ return $return_rev_num;
+}
+
+##MAIN program: checks to see if there are command line parameters
+if ($#ARGV > 2) {
+
+#if not then end and print help message
+die "Usage: pvcsns [-l]\n"};
+$curlevel=0-1;$maxlevel=10000;
+
+if (@ARGV[0] eq "-l") {$maxlevel=1;shift @ARGV;}
+
+#start the whole thing
+&execdir(".",".");
+
diff --git a/contrib/cvs/diff/ChangeLog b/contrib/cvs/diff/ChangeLog
new file mode 100644
index 000000000000..34aa7077b8c4
--- /dev/null
+++ b/contrib/cvs/diff/ChangeLog
@@ -0,0 +1,202 @@
+Fri Jan 16 14:58:19 1998 Larry Jones <larry.jones@sdrc.com>
+
+ * diff.c, diff3.c: Plug memory leaks.
+
+Thu Jan 15 13:36:46 1998 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * Makefile.in (installdirs): New rule, for when ../Makefile
+ recurses into this directory (bug reported by W. L. Estes).
+
+Tue Nov 11 10:48:19 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * diff.c (diff_run): Change #ifdef on HAVE_SETMODE to #if to match
+ the other uses (fixes compilation error on unix).
+
+ * diff.c (diff_run): Don't set stdout to binary mode.
+
+Mon, 10 Nov 1997 Jim Kingdon
+
+ * diff.c (run_diff): Open outfile in binary mode if --binary.
+
+Thu Nov 6 12:42:12 1997 Karl Fogel <kfogel@floss.red-bean.com>
+ and Paul Eggert <eggert@twinsun.com>
+
+ * analyze.c: applied Paul Eggert's patch to fix the diff3 merge
+ bug described in ccvs/doc/DIFFUTILS-2.7-BUG:
+ (shift_boundaries): new var `inhibit_hunk_merge'; use it to
+ control something important that I don't quite understand, but
+ Paul apparently does, so that's okay.
+
+Sat Nov 1 14:17:57 1997 Michael L.H. Brouwer <michael@thi.nl>
+
+ * Makefile.in: Add call to ranlib to build a table of contents for
+ the library since some systems seem to require this.
+
+1997-10-28 Jim Kingdon
+
+ * .cvsignore: Add files du jour for Visual C++, vc50.pdb and vc50.idb.
+
+ * system.h: Define HAVE_TIME_H.
+ * dir.c [_WIN32]: Define CLOSEDIR_VOID.
+
+1997-10-18 Jim Kingdon
+
+ * build_diff.com: Add diff3.c
+
+Fri Sep 26 14:24:42 1997 Tim Pierce <twp@twp.tezcat.com>
+
+ * diff.c (diff_run): Save old value of optind before calling
+ getopt_long, then restore before returning. Eventually it would
+ be nice if diff_run were fully reentrant.
+
+ New diff3 library for CVS.
+ * Makefile.in (SOURCES): Add diff3.c.
+ (OBJECTS): Add diff3.o.
+ * diff3.c: New file, copied from diffutils-2.7. See diffutils for
+ earlier ChangeLogs. Undefine initialize_main macro. Remove <signal.h>.
+ (diff3_run): Renamed from main(). Add `outfile' argument. Remove
+ SIGCLD handling; we do not fork. Save optind and reset to 0
+ before calling getopt_long; restore after option processing done.
+ (read_diff): Use diff_run with a temporary output file,
+ instead of forking a diff subprocess and reading from a pipe.
+ Change DIFF_PROGRAM to "diff"; this argument is now used only for
+ diagnostic reporting.
+ (xmalloc, xrealloc): Removed.
+ (diff_program): Removed.
+ (diff_program_name): Made extern, so it may be used in other
+ library calls like `error'.
+ (initialize_main): New function.
+
+ Namespace munging. util.c defines both fatal() and
+ perror_with_exit(), but these cannot be used to abort diff3: both
+ attempt to longjmp() to a buffer set in diff.c, used only by
+ diff_run. This is an awful solution, but necessary until the code
+ can be cleaned up. (These functions do not *have* to be renamed,
+ since both are declared static to diff3.c and should not clash
+ with libdiff.a, but it reduces potential confusion.)
+ * diff3.c (diff3_fatal): Renamed from fatal.
+ (diff3_perror_with_exit): Renamed from perror_with_exit.
+
+ Eliminate exit calls.
+ (try_help): Change from `void' to `int'. Return, do not exit.
+ (diff3_fatal, diff3_perror_with_exit, process_diff): Change `exit'
+ to DIFF3_ABORT.
+ (diff3_run): Initialize jump buffer for nonlocal exits. Change
+ exit calls to returns. Change `perror_with_exit' to
+ `perror_with_name' and add a return. Change `fatal' to
+ `diff_error' and add a return. The reasoning is that we shouldn't
+ rely on setjmp/longjmp any more than necessary.
+
+ Redirect stdout.
+ (check_output): Renamed from check_stdout. Take stream argument
+ instead of blindly checking stdout. Do not close stream, but
+ merely fflush it.
+ (diff3_run): Initialize outstream, and close when done. Pass this
+ stream (instead of stdout) to output_diff3_edscript,
+ output_diff3_merge, and output_diff3.
+
+Thu Sep 25 14:34:22 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * util.c (begin_output, finish_output): If PR_PROGRAM is not
+ defined (VMS), just give a fatal error if --paginate specified.
+
+ * Makefile.in (DISTFILES): Add ChangeLog build_diff.com
+ Makefile.in.
+ * build_diff.com: New file.
+
+Wed Sep 24 10:27:00 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * Makefile.in: Also set top_srcdir. Needed to make today's other
+ Makefile.in change work.
+
+ * .cvsignore: New file.
+
+ * Makefile.in (COMPILE): Add -I options for srcdir (perhaps
+ unneeded) and change -I option for lib to use top_srcdir (needed
+ to avoid mixups with CVS's regex.h vs. the system one).
+
+Sun Sep 21 19:44:42 1997 Jim Kingdon <kingdon@harvey.cyclic.com>
+
+ * Makefile.in (util.o): Change util.c to $<, needed for srcdir.
+
+Sat Sep 20 12:06:41 1997 Tim Pierce <twp@twp.tezcat.com>
+
+ New diff library for CVS, based on diffutils-2.7. See diffutils
+ for earlier ChangeLogs.
+ * Makefile.in, analyze.c, cmpbuf.c, cmpbuf.h, config.hin,
+ context.c, diagmeet.note, diff.c, diff.h, dir.c, ed.c, ifdef.c,
+ io.c, normal.c, side.c, stamp-h.in, system.h, util.c, version.c:
+ New files.
+ (COMPILE): Add -I../lib, so we can get getopt.h.
+
+ * Makefile.in: Removed anything not related to libdiff.a.
+ (dist-dir): New target, copied from ../lib/Makefile.in.
+ (DISTFILES): New variable.
+ (SOURCES): Renamed from `srcs'.
+ (OBJECTS): Renamed from `libdiff_o'.
+ (Makefile): Changed dependencies to reflect
+ new, shallow config directory structure.
+ (stamp-h.in, config.h.in, config.h, stamp-h): Removed.
+ * stamp-h.in, config.h.in: Removed.
+
+ * system.h: Remove dup2 macro (provided by ../lib/dup2.c).
+ Include stdlib.h if STDC_HEADERS is defined (not just
+ HAVE_STDLIB_H).
+
+Sat Sep 20 05:32:18 1997 Tim Pierce <twp@twp.tezcat.com>
+
+ Diff librarification.
+
+ * diff.c (diff_run): New function, renamed from `main'.
+ Initialize `outfile' based on the value of the new `out' filename
+ argument.
+ (initialize_main): New function.
+ * system.h: Removed initialize_main macro.
+ * diffmain.c: New file.
+ * Makefile.in (diff): Added diffmain.o.
+ (libdiff): New target.
+ (AR, libdiff_o): New variables. libdiff_o does not include
+ xmalloc.o, fnmatch.o, getopt.o, getopt1.o, regex.o or error.o,
+ because these functions are already present in CVS. It will take
+ some work to make this more general-purpose.
+
+ Redirect standard output.
+ * util.c: Redirect stdout to outfile: change all naked `printf'
+ and `putchar' statements to `fprintf (outfile)' and `putc (...,
+ outfile)' throughout. This should permit redirecting diff output
+ by changing `outfile' just once in `diff_run'.
+ (output_in_progress): New variable.
+ (begin_output, finish_output): Use `output_in_progress', rather than
+ `outfile', as a semaphore to avoid reentrancy problems.
+ (finish_output): Close `outfile' only if paginate_flag is set.
+ * diff.c (check_output): New function, was check_stdout. Take a
+ `file' argument, and flush it instead of closing it.
+ (diff_run): Change check_stdout to check_output.
+ (compare_files): Fflush outfile, not stdout.
+
+ Eliminate exit statements.
+ * diff.h: Include setjmp.h.
+ (diff_abort_buf): New variable.
+ (DIFF_ABORT): New macro.
+ * diff.c (diff_run): Change all `exit' statements to `return'.
+ Set up diff_abort_buf, so we can abort diff without
+ terminating (for libdiff.a).
+ (try_help): Return int instead of void; do not exit.
+ * util.c (fatal): Use DIFF_ABORT instead of exit.
+ (pfatal_with_name): Use DIFF_ABORT instead of exit.
+
+ Namespace cleanup (rudimentary). Strictly speaking, this is not
+ necessary to make diff into a library. However, namespace
+ clashes between diff and CVS must be resolved immediately, since
+ CVS is the first application targeted for use with difflib.
+
+ * analyze.c, diff.c, diff.h, util.c (diff_error): Renamed from `error'.
+
+ * version.c, diff.c, diff.h, cmp.c, diff3.c, sdiff.c
+ (diff_version_string): Renamed from version_string.
+ * diff.c, util.c, diff.h, diff3.c, error.c (diff_program_name):
+ Renamed from program_name.
+
+ * util.c (xmalloc, xrealloc): Removed.
+ * Makefile.in (diff_o): Added error.o and xmalloc.o.
+
diff --git a/contrib/cvs/diff/Makefile.in b/contrib/cvs/diff/Makefile.in
new file mode 100644
index 000000000000..333d4d9251d0
--- /dev/null
+++ b/contrib/cvs/diff/Makefile.in
@@ -0,0 +1,104 @@
+# Makefile for GNU DIFF
+# Copyright (C) 1988,1989,1991,1992,1993,1994,1997 Free Software Foundation, Inc.
+#
+# This file is part of GNU DIFF.
+#
+# GNU DIFF is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+#
+# GNU DIFF is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with GNU DIFF; see the file COPYING. If not, write to
+# the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.
+
+#### Start of system configuration section. ####
+
+srcdir = @srcdir@
+top_srcdir = @top_srcdir@
+VPATH = @srcdir@
+subdir = diff
+
+CC = @CC@
+AR = ar
+
+CPPFLAGS = @CPPFLAGS@
+DEFS = @DEFS@
+RANLIB = @RANLIB@
+CFLAGS = @CFLAGS@
+
+prefix = @prefix@
+exec_prefix = @exec_prefix@
+
+PR_PROGRAM = /bin/pr
+
+#### End of system configuration section. ####
+
+SHELL = /bin/sh
+
+# The source files for all of the programs.
+SOURCES = diff.c diff3.c analyze.c cmpbuf.c cmpbuf.h io.c context.c ed.c \
+ normal.c ifdef.c util.c dir.c version.c diff.h side.c system.h
+OBJECTS = diff.o diff3.o analyze.o cmpbuf.o dir.o io.o util.o \
+ context.o ed.o ifdef.o normal.o side.o version.o
+DISTFILES = $(SOURCES) ChangeLog build_diff.com Makefile.in
+
+all: libdiff.a
+
+# $(top_srcdir)/lib is so we don't get the system-supplied headers for
+# functions that we supply ourselves in lib. $(srcdir) is perhaps not
+# necessary if we assume the unix compiler behavior whereby "" looks
+# in the directory containing the .c file first.
+# -I. is probably unnecessary (I don't think we generate any .h files).
+# -I.. is for config.h.
+COMPILE = $(CC) -c $(CPPFLAGS) $(DEFS) \
+ -I. -I.. -I$(srcdir) -I$(top_srcdir)/lib $(CFLAGS)
+
+.c.o:
+ $(COMPILE) $<
+
+libdiff libdiff.a: $(OBJECTS)
+ $(AR) cr libdiff.a $(OBJECTS)
+ -$(RANLIB) libdiff.a
+
+$(OBJECTS): diff.h system.h
+analyze.o cmpbuf.o: cmpbuf.h
+
+util.o: util.c
+ $(COMPILE) -DPR_PROGRAM=\"$(PR_PROGRAM)\" $<
+
+install: all
+
+installdirs:
+ @: nothing to do for installdirs
+.PHONY: installdirs
+
+TAGS: $(SOURCES)
+ etags $(SOURCES)
+
+clean:
+ rm -f *.o *.a core
+
+mostlyclean: clean
+
+distclean: clean
+ rm -f TAGS tags Makefile
+
+realclean: distclean
+
+Makefile: Makefile.in ../config.status
+ cd .. && CONFIG_FILES=$(subdir)/$@ CONFIG_HEADERS= ./config.status
+
+dist-dir:
+ mkdir ${DISTDIR}
+ for i in ${DISTFILES}; do \
+ ln $(srcdir)/$${i} ${DISTDIR}; \
+ done
+
+# Prevent GNU make v3 from overflowing arg limit on SysV.
+.NOEXPORT:
diff --git a/contrib/cvs/diff/analyze.c b/contrib/cvs/diff/analyze.c
new file mode 100644
index 000000000000..0bda3cf77231
--- /dev/null
+++ b/contrib/cvs/diff/analyze.c
@@ -0,0 +1,1087 @@
+/* Analyze file differences for GNU DIFF.
+ Copyright (C) 1988, 1989, 1992, 1993, 1997 Free Software Foundation, Inc.
+
+This file is part of GNU DIFF.
+
+GNU DIFF is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 2, or (at your option)
+any later version.
+
+GNU DIFF is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GNU DIFF; see the file COPYING. If not, write to
+the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA. */
+
+/* The basic algorithm is described in:
+ "An O(ND) Difference Algorithm and its Variations", Eugene Myers,
+ Algorithmica Vol. 1 No. 2, 1986, pp. 251-266;
+ see especially section 4.2, which describes the variation used below.
+ Unless the --minimal option is specified, this code uses the TOO_EXPENSIVE
+ heuristic, by Paul Eggert, to limit the cost to O(N**1.5 log N)
+ at the price of producing suboptimal output for large inputs with
+ many differences.
+
+ The basic algorithm was independently discovered as described in:
+ "Algorithms for Approximate String Matching", E. Ukkonen,
+ Information and Control Vol. 64, 1985, pp. 100-118. */
+
+#include "diff.h"
+#include "cmpbuf.h"
+
+extern int no_discards;
+
+static int *xvec, *yvec; /* Vectors being compared. */
+static int *fdiag; /* Vector, indexed by diagonal, containing
+ 1 + the X coordinate of the point furthest
+ along the given diagonal in the forward
+ search of the edit matrix. */
+static int *bdiag; /* Vector, indexed by diagonal, containing
+ the X coordinate of the point furthest
+ along the given diagonal in the backward
+ search of the edit matrix. */
+static int too_expensive; /* Edit scripts longer than this are too
+ expensive to compute. */
+
+#define SNAKE_LIMIT 20 /* Snakes bigger than this are considered `big'. */
+
+struct partition
+{
+ int xmid, ymid; /* Midpoints of this partition. */
+ int lo_minimal; /* Nonzero if low half will be analyzed minimally. */
+ int hi_minimal; /* Likewise for high half. */
+};
+
+static int diag PARAMS((int, int, int, int, int, struct partition *));
+static struct change *add_change PARAMS((int, int, int, int, struct change *));
+static struct change *build_reverse_script PARAMS((struct file_data const[]));
+static struct change *build_script PARAMS((struct file_data const[]));
+static void briefly_report PARAMS((int, struct file_data const[]));
+static void compareseq PARAMS((int, int, int, int, int));
+static void discard_confusing_lines PARAMS((struct file_data[]));
+static void shift_boundaries PARAMS((struct file_data[]));
+
+/* Find the midpoint of the shortest edit script for a specified
+ portion of the two files.
+
+ Scan from the beginnings of the files, and simultaneously from the ends,
+ doing a breadth-first search through the space of edit-sequence.
+ When the two searches meet, we have found the midpoint of the shortest
+ edit sequence.
+
+ If MINIMAL is nonzero, find the minimal edit script regardless
+ of expense. Otherwise, if the search is too expensive, use
+ heuristics to stop the search and report a suboptimal answer.
+
+ Set PART->(XMID,YMID) to the midpoint (XMID,YMID). The diagonal number
+ XMID - YMID equals the number of inserted lines minus the number
+ of deleted lines (counting only lines before the midpoint).
+ Return the approximate edit cost; this is the total number of
+ lines inserted or deleted (counting only lines before the midpoint),
+ unless a heuristic is used to terminate the search prematurely.
+
+ Set PART->LEFT_MINIMAL to nonzero iff the minimal edit script for the
+ left half of the partition is known; similarly for PART->RIGHT_MINIMAL.
+
+ This function assumes that the first lines of the specified portions
+ of the two files do not match, and likewise that the last lines do not
+ match. The caller must trim matching lines from the beginning and end
+ of the portions it is going to specify.
+
+ If we return the "wrong" partitions,
+ the worst this can do is cause suboptimal diff output.
+ It cannot cause incorrect diff output. */
+
+static int
+diag (xoff, xlim, yoff, ylim, minimal, part)
+ int xoff, xlim, yoff, ylim, minimal;
+ struct partition *part;
+{
+ int *const fd = fdiag; /* Give the compiler a chance. */
+ int *const bd = bdiag; /* Additional help for the compiler. */
+ int const *const xv = xvec; /* Still more help for the compiler. */
+ int const *const yv = yvec; /* And more and more . . . */
+ int const dmin = xoff - ylim; /* Minimum valid diagonal. */
+ int const dmax = xlim - yoff; /* Maximum valid diagonal. */
+ int const fmid = xoff - yoff; /* Center diagonal of top-down search. */
+ int const bmid = xlim - ylim; /* Center diagonal of bottom-up search. */
+ int fmin = fmid, fmax = fmid; /* Limits of top-down search. */
+ int bmin = bmid, bmax = bmid; /* Limits of bottom-up search. */
+ int c; /* Cost. */
+ int odd = (fmid - bmid) & 1; /* True if southeast corner is on an odd
+ diagonal with respect to the northwest. */
+
+ fd[fmid] = xoff;
+ bd[bmid] = xlim;
+
+ for (c = 1;; ++c)
+ {
+ int d; /* Active diagonal. */
+ int big_snake = 0;
+
+ /* Extend the top-down search by an edit step in each diagonal. */
+ fmin > dmin ? fd[--fmin - 1] = -1 : ++fmin;
+ fmax < dmax ? fd[++fmax + 1] = -1 : --fmax;
+ for (d = fmax; d >= fmin; d -= 2)
+ {
+ int x, y, oldx, tlo = fd[d - 1], thi = fd[d + 1];
+
+ if (tlo >= thi)
+ x = tlo + 1;
+ else
+ x = thi;
+ oldx = x;
+ y = x - d;
+ while (x < xlim && y < ylim && xv[x] == yv[y])
+ ++x, ++y;
+ if (x - oldx > SNAKE_LIMIT)
+ big_snake = 1;
+ fd[d] = x;
+ if (odd && bmin <= d && d <= bmax && bd[d] <= x)
+ {
+ part->xmid = x;
+ part->ymid = y;
+ part->lo_minimal = part->hi_minimal = 1;
+ return 2 * c - 1;
+ }
+ }
+
+ /* Similarly extend the bottom-up search. */
+ bmin > dmin ? bd[--bmin - 1] = INT_MAX : ++bmin;
+ bmax < dmax ? bd[++bmax + 1] = INT_MAX : --bmax;
+ for (d = bmax; d >= bmin; d -= 2)
+ {
+ int x, y, oldx, tlo = bd[d - 1], thi = bd[d + 1];
+
+ if (tlo < thi)
+ x = tlo;
+ else
+ x = thi - 1;
+ oldx = x;
+ y = x - d;
+ while (x > xoff && y > yoff && xv[x - 1] == yv[y - 1])
+ --x, --y;
+ if (oldx - x > SNAKE_LIMIT)
+ big_snake = 1;
+ bd[d] = x;
+ if (!odd && fmin <= d && d <= fmax && x <= fd[d])
+ {
+ part->xmid = x;
+ part->ymid = y;
+ part->lo_minimal = part->hi_minimal = 1;
+ return 2 * c;
+ }
+ }
+
+ if (minimal)
+ continue;
+
+ /* Heuristic: check occasionally for a diagonal that has made
+ lots of progress compared with the edit distance.
+ If we have any such, find the one that has made the most
+ progress and return it as if it had succeeded.
+
+ With this heuristic, for files with a constant small density
+ of changes, the algorithm is linear in the file size. */
+
+ if (c > 200 && big_snake && heuristic)
+ {
+ int best;
+
+ best = 0;
+ for (d = fmax; d >= fmin; d -= 2)
+ {
+ int dd = d - fmid;
+ int x = fd[d];
+ int y = x - d;
+ int v = (x - xoff) * 2 - dd;
+ if (v > 12 * (c + (dd < 0 ? -dd : dd)))
+ {
+ if (v > best
+ && xoff + SNAKE_LIMIT <= x && x < xlim
+ && yoff + SNAKE_LIMIT <= y && y < ylim)
+ {
+ /* We have a good enough best diagonal;
+ now insist that it end with a significant snake. */
+ int k;
+
+ for (k = 1; xv[x - k] == yv[y - k]; k++)
+ if (k == SNAKE_LIMIT)
+ {
+ best = v;
+ part->xmid = x;
+ part->ymid = y;
+ break;
+ }
+ }
+ }
+ }
+ if (best > 0)
+ {
+ part->lo_minimal = 1;
+ part->hi_minimal = 0;
+ return 2 * c - 1;
+ }
+
+ best = 0;
+ for (d = bmax; d >= bmin; d -= 2)
+ {
+ int dd = d - bmid;
+ int x = bd[d];
+ int y = x - d;
+ int v = (xlim - x) * 2 + dd;
+ if (v > 12 * (c + (dd < 0 ? -dd : dd)))
+ {
+ if (v > best
+ && xoff < x && x <= xlim - SNAKE_LIMIT
+ && yoff < y && y <= ylim - SNAKE_LIMIT)
+ {
+ /* We have a good enough best diagonal;
+ now insist that it end with a significant snake. */
+ int k;
+
+ for (k = 0; xv[x + k] == yv[y + k]; k++)
+ if (k == SNAKE_LIMIT - 1)
+ {
+ best = v;
+ part->xmid = x;
+ part->ymid = y;
+ break;
+ }
+ }
+ }
+ }
+ if (best > 0)
+ {
+ part->lo_minimal = 0;
+ part->hi_minimal = 1;
+ return 2 * c - 1;
+ }
+ }
+
+ /* Heuristic: if we've gone well beyond the call of duty,
+ give up and report halfway between our best results so far. */
+ if (c >= too_expensive)
+ {
+ int fxybest, fxbest;
+ int bxybest, bxbest;
+
+ fxbest = bxbest = 0; /* Pacify `gcc -Wall'. */
+
+ /* Find forward diagonal that maximizes X + Y. */
+ fxybest = -1;
+ for (d = fmax; d >= fmin; d -= 2)
+ {
+ int x = min (fd[d], xlim);
+ int y = x - d;
+ if (ylim < y)
+ x = ylim + d, y = ylim;
+ if (fxybest < x + y)
+ {
+ fxybest = x + y;
+ fxbest = x;
+ }
+ }
+
+ /* Find backward diagonal that minimizes X + Y. */
+ bxybest = INT_MAX;
+ for (d = bmax; d >= bmin; d -= 2)
+ {
+ int x = max (xoff, bd[d]);
+ int y = x - d;
+ if (y < yoff)
+ x = yoff + d, y = yoff;
+ if (x + y < bxybest)
+ {
+ bxybest = x + y;
+ bxbest = x;
+ }
+ }
+
+ /* Use the better of the two diagonals. */
+ if ((xlim + ylim) - bxybest < fxybest - (xoff + yoff))
+ {
+ part->xmid = fxbest;
+ part->ymid = fxybest - fxbest;
+ part->lo_minimal = 1;
+ part->hi_minimal = 0;
+ }
+ else
+ {
+ part->xmid = bxbest;
+ part->ymid = bxybest - bxbest;
+ part->lo_minimal = 0;
+ part->hi_minimal = 1;
+ }
+ return 2 * c - 1;
+ }
+ }
+}
+
+/* Compare in detail contiguous subsequences of the two files
+ which are known, as a whole, to match each other.
+
+ The results are recorded in the vectors files[N].changed_flag, by
+ storing a 1 in the element for each line that is an insertion or deletion.
+
+ The subsequence of file 0 is [XOFF, XLIM) and likewise for file 1.
+
+ Note that XLIM, YLIM are exclusive bounds.
+ All line numbers are origin-0 and discarded lines are not counted.
+
+ If MINIMAL is nonzero, find a minimal difference no matter how
+ expensive it is. */
+
+static void
+compareseq (xoff, xlim, yoff, ylim, minimal)
+ int xoff, xlim, yoff, ylim, minimal;
+{
+ int * const xv = xvec; /* Help the compiler. */
+ int * const yv = yvec;
+
+ /* Slide down the bottom initial diagonal. */
+ while (xoff < xlim && yoff < ylim && xv[xoff] == yv[yoff])
+ ++xoff, ++yoff;
+ /* Slide up the top initial diagonal. */
+ while (xlim > xoff && ylim > yoff && xv[xlim - 1] == yv[ylim - 1])
+ --xlim, --ylim;
+
+ /* Handle simple cases. */
+ if (xoff == xlim)
+ while (yoff < ylim)
+ files[1].changed_flag[files[1].realindexes[yoff++]] = 1;
+ else if (yoff == ylim)
+ while (xoff < xlim)
+ files[0].changed_flag[files[0].realindexes[xoff++]] = 1;
+ else
+ {
+ int c;
+ struct partition part;
+
+ /* Find a point of correspondence in the middle of the files. */
+
+ c = diag (xoff, xlim, yoff, ylim, minimal, &part);
+
+ if (c == 1)
+ {
+ /* This should be impossible, because it implies that
+ one of the two subsequences is empty,
+ and that case was handled above without calling `diag'.
+ Let's verify that this is true. */
+ abort ();
+#if 0
+ /* The two subsequences differ by a single insert or delete;
+ record it and we are done. */
+ if (part.xmid - part.ymid < xoff - yoff)
+ files[1].changed_flag[files[1].realindexes[part.ymid - 1]] = 1;
+ else
+ files[0].changed_flag[files[0].realindexes[part.xmid]] = 1;
+#endif
+ }
+ else
+ {
+ /* Use the partitions to split this problem into subproblems. */
+ compareseq (xoff, part.xmid, yoff, part.ymid, part.lo_minimal);
+ compareseq (part.xmid, xlim, part.ymid, ylim, part.hi_minimal);
+ }
+ }
+}
+
+/* Discard lines from one file that have no matches in the other file.
+
+ A line which is discarded will not be considered by the actual
+ comparison algorithm; it will be as if that line were not in the file.
+ The file's `realindexes' table maps virtual line numbers
+ (which don't count the discarded lines) into real line numbers;
+ this is how the actual comparison algorithm produces results
+ that are comprehensible when the discarded lines are counted.
+
+ When we discard a line, we also mark it as a deletion or insertion
+ so that it will be printed in the output. */
+
+static void
+discard_confusing_lines (filevec)
+ struct file_data filevec[];
+{
+ unsigned int f, i;
+ char *discarded[2];
+ int *equiv_count[2];
+ int *p;
+
+ /* Allocate our results. */
+ p = (int *) xmalloc ((filevec[0].buffered_lines + filevec[1].buffered_lines)
+ * (2 * sizeof (int)));
+ for (f = 0; f < 2; f++)
+ {
+ filevec[f].undiscarded = p; p += filevec[f].buffered_lines;
+ filevec[f].realindexes = p; p += filevec[f].buffered_lines;
+ }
+
+ /* Set up equiv_count[F][I] as the number of lines in file F
+ that fall in equivalence class I. */
+
+ p = (int *) xmalloc (filevec[0].equiv_max * (2 * sizeof (int)));
+ equiv_count[0] = p;
+ equiv_count[1] = p + filevec[0].equiv_max;
+ bzero (p, filevec[0].equiv_max * (2 * sizeof (int)));
+
+ for (i = 0; i < filevec[0].buffered_lines; ++i)
+ ++equiv_count[0][filevec[0].equivs[i]];
+ for (i = 0; i < filevec[1].buffered_lines; ++i)
+ ++equiv_count[1][filevec[1].equivs[i]];
+
+ /* Set up tables of which lines are going to be discarded. */
+
+ discarded[0] = xmalloc (sizeof (char)
+ * (filevec[0].buffered_lines
+ + filevec[1].buffered_lines));
+ discarded[1] = discarded[0] + filevec[0].buffered_lines;
+ bzero (discarded[0], sizeof (char) * (filevec[0].buffered_lines
+ + filevec[1].buffered_lines));
+
+ /* Mark to be discarded each line that matches no line of the other file.
+ If a line matches many lines, mark it as provisionally discardable. */
+
+ for (f = 0; f < 2; f++)
+ {
+ unsigned int end = filevec[f].buffered_lines;
+ char *discards = discarded[f];
+ int *counts = equiv_count[1 - f];
+ int *equivs = filevec[f].equivs;
+ unsigned int many = 5;
+ unsigned int tem = end / 64;
+
+ /* Multiply MANY by approximate square root of number of lines.
+ That is the threshold for provisionally discardable lines. */
+ while ((tem = tem >> 2) > 0)
+ many *= 2;
+
+ for (i = 0; i < end; i++)
+ {
+ int nmatch;
+ if (equivs[i] == 0)
+ continue;
+ nmatch = counts[equivs[i]];
+ if (nmatch == 0)
+ discards[i] = 1;
+ else if (nmatch > many)
+ discards[i] = 2;
+ }
+ }
+
+ /* Don't really discard the provisional lines except when they occur
+ in a run of discardables, with nonprovisionals at the beginning
+ and end. */
+
+ for (f = 0; f < 2; f++)
+ {
+ unsigned int end = filevec[f].buffered_lines;
+ register char *discards = discarded[f];
+
+ for (i = 0; i < end; i++)
+ {
+ /* Cancel provisional discards not in middle of run of discards. */
+ if (discards[i] == 2)
+ discards[i] = 0;
+ else if (discards[i] != 0)
+ {
+ /* We have found a nonprovisional discard. */
+ register int j;
+ unsigned int length;
+ unsigned int provisional = 0;
+
+ /* Find end of this run of discardable lines.
+ Count how many are provisionally discardable. */
+ for (j = i; j < end; j++)
+ {
+ if (discards[j] == 0)
+ break;
+ if (discards[j] == 2)
+ ++provisional;
+ }
+
+ /* Cancel provisional discards at end, and shrink the run. */
+ while (j > i && discards[j - 1] == 2)
+ discards[--j] = 0, --provisional;
+
+ /* Now we have the length of a run of discardable lines
+ whose first and last are not provisional. */
+ length = j - i;
+
+ /* If 1/4 of the lines in the run are provisional,
+ cancel discarding of all provisional lines in the run. */
+ if (provisional * 4 > length)
+ {
+ while (j > i)
+ if (discards[--j] == 2)
+ discards[j] = 0;
+ }
+ else
+ {
+ register unsigned int consec;
+ unsigned int minimum = 1;
+ unsigned int tem = length / 4;
+
+ /* MINIMUM is approximate square root of LENGTH/4.
+ A subrun of two or more provisionals can stand
+ when LENGTH is at least 16.
+ A subrun of 4 or more can stand when LENGTH >= 64. */
+ while ((tem = tem >> 2) > 0)
+ minimum *= 2;
+ minimum++;
+
+ /* Cancel any subrun of MINIMUM or more provisionals
+ within the larger run. */
+ for (j = 0, consec = 0; j < length; j++)
+ if (discards[i + j] != 2)
+ consec = 0;
+ else if (minimum == ++consec)
+ /* Back up to start of subrun, to cancel it all. */
+ j -= consec;
+ else if (minimum < consec)
+ discards[i + j] = 0;
+
+ /* Scan from beginning of run
+ until we find 3 or more nonprovisionals in a row
+ or until the first nonprovisional at least 8 lines in.
+ Until that point, cancel any provisionals. */
+ for (j = 0, consec = 0; j < length; j++)
+ {
+ if (j >= 8 && discards[i + j] == 1)
+ break;
+ if (discards[i + j] == 2)
+ consec = 0, discards[i + j] = 0;
+ else if (discards[i + j] == 0)
+ consec = 0;
+ else
+ consec++;
+ if (consec == 3)
+ break;
+ }
+
+ /* I advances to the last line of the run. */
+ i += length - 1;
+
+ /* Same thing, from end. */
+ for (j = 0, consec = 0; j < length; j++)
+ {
+ if (j >= 8 && discards[i - j] == 1)
+ break;
+ if (discards[i - j] == 2)
+ consec = 0, discards[i - j] = 0;
+ else if (discards[i - j] == 0)
+ consec = 0;
+ else
+ consec++;
+ if (consec == 3)
+ break;
+ }
+ }
+ }
+ }
+ }
+
+ /* Actually discard the lines. */
+ for (f = 0; f < 2; f++)
+ {
+ char *discards = discarded[f];
+ unsigned int end = filevec[f].buffered_lines;
+ unsigned int j = 0;
+ for (i = 0; i < end; ++i)
+ if (no_discards || discards[i] == 0)
+ {
+ filevec[f].undiscarded[j] = filevec[f].equivs[i];
+ filevec[f].realindexes[j++] = i;
+ }
+ else
+ filevec[f].changed_flag[i] = 1;
+ filevec[f].nondiscarded_lines = j;
+ }
+
+ free (discarded[0]);
+ free (equiv_count[0]);
+}
+
+/* Adjust inserts/deletes of identical lines to join changes
+ as much as possible.
+
+ We do something when a run of changed lines include a
+ line at one end and have an excluded, identical line at the other.
+ We are free to choose which identical line is included.
+ `compareseq' usually chooses the one at the beginning,
+ but usually it is cleaner to consider the following identical line
+ to be the "change". */
+
+int inhibit;
+
+static void
+shift_boundaries (filevec)
+ struct file_data filevec[];
+{
+ int f;
+ int inhibit_hunk_merge = horizon_lines != context;
+
+ for (f = 0; f < 2; f++)
+ {
+ char *changed = filevec[f].changed_flag;
+ char const *other_changed = filevec[1-f].changed_flag;
+ int const *equivs = filevec[f].equivs;
+ int i = 0;
+ int j = 0;
+ int i_end = filevec[f].buffered_lines;
+
+ while (1)
+ {
+ int runlength, start, corresponding;
+
+ /* Scan forwards to find beginning of another run of changes.
+ Also keep track of the corresponding point in the other file. */
+
+ while (i < i_end && changed[i] == 0)
+ {
+ while (other_changed[j++])
+ continue;
+ i++;
+ }
+
+ if (i == i_end)
+ break;
+
+ start = i;
+
+ /* Find the end of this run of changes. */
+
+ while (changed[++i])
+ continue;
+ while (other_changed[j])
+ j++;
+
+ do
+ {
+ /* Record the length of this run of changes, so that
+ we can later determine whether the run has grown. */
+ runlength = i - start;
+
+ if (! inhibit_hunk_merge)
+ {
+ /* Move the changed region back, so long as the
+ previous unchanged line matches the last changed one.
+ This merges with previous changed regions. */
+
+ while (start && equivs[start - 1] == equivs[i - 1])
+ {
+ changed[--start] = 1;
+ changed[--i] = 0;
+ while (changed[start - 1])
+ start--;
+ while (other_changed[--j])
+ continue;
+ }
+ }
+
+ /* Set CORRESPONDING to the end of the changed run, at the last
+ point where it corresponds to a changed run in the other file.
+ CORRESPONDING == I_END means no such point has been found. */
+ corresponding = other_changed[j - 1] ? i : i_end;
+
+ /* Shift the changed region forward, so long as the
+ first changed line matches the following unchanged one,
+ but if INHIBIT_HUNK_MERGE is 1 do not shift if
+ this would merge with another changed region.
+ Do this second, so that if there are no merges,
+ the changed region is moved forward as far as possible. */
+
+ while (i != i_end && equivs[start] == equivs[i]
+ && ! (inhibit_hunk_merge & other_changed[j + 1]))
+ {
+ changed[start++] = 0;
+ changed[i++] = 1;
+ while (changed[i])
+ i++;
+ while (other_changed[++j])
+ corresponding = i;
+ }
+ }
+ while (runlength != i - start);
+
+ /* If possible, move the fully-merged run of changes
+ back to a corresponding run in the other file. */
+
+ while (corresponding < i)
+ {
+ changed[--start] = 1;
+ changed[--i] = 0;
+ while (other_changed[--j])
+ continue;
+ }
+ }
+ }
+}
+
+/* Cons an additional entry onto the front of an edit script OLD.
+ LINE0 and LINE1 are the first affected lines in the two files (origin 0).
+ DELETED is the number of lines deleted here from file 0.
+ INSERTED is the number of lines inserted here in file 1.
+
+ If DELETED is 0 then LINE0 is the number of the line before
+ which the insertion was done; vice versa for INSERTED and LINE1. */
+
+static struct change *
+add_change (line0, line1, deleted, inserted, old)
+ int line0, line1, deleted, inserted;
+ struct change *old;
+{
+ struct change *new = (struct change *) xmalloc (sizeof (struct change));
+
+ new->line0 = line0;
+ new->line1 = line1;
+ new->inserted = inserted;
+ new->deleted = deleted;
+ new->link = old;
+ return new;
+}
+
+/* Scan the tables of which lines are inserted and deleted,
+ producing an edit script in reverse order. */
+
+static struct change *
+build_reverse_script (filevec)
+ struct file_data const filevec[];
+{
+ struct change *script = 0;
+ char *changed0 = filevec[0].changed_flag;
+ char *changed1 = filevec[1].changed_flag;
+ int len0 = filevec[0].buffered_lines;
+ int len1 = filevec[1].buffered_lines;
+
+ /* Note that changedN[len0] does exist, and contains 0. */
+
+ int i0 = 0, i1 = 0;
+
+ while (i0 < len0 || i1 < len1)
+ {
+ if (changed0[i0] || changed1[i1])
+ {
+ int line0 = i0, line1 = i1;
+
+ /* Find # lines changed here in each file. */
+ while (changed0[i0]) ++i0;
+ while (changed1[i1]) ++i1;
+
+ /* Record this change. */
+ script = add_change (line0, line1, i0 - line0, i1 - line1, script);
+ }
+
+ /* We have reached lines in the two files that match each other. */
+ i0++, i1++;
+ }
+
+ return script;
+}
+
+/* Scan the tables of which lines are inserted and deleted,
+ producing an edit script in forward order. */
+
+static struct change *
+build_script (filevec)
+ struct file_data const filevec[];
+{
+ struct change *script = 0;
+ char *changed0 = filevec[0].changed_flag;
+ char *changed1 = filevec[1].changed_flag;
+ int i0 = filevec[0].buffered_lines, i1 = filevec[1].buffered_lines;
+
+ /* Note that changedN[-1] does exist, and contains 0. */
+
+ while (i0 >= 0 || i1 >= 0)
+ {
+ if (changed0[i0 - 1] || changed1[i1 - 1])
+ {
+ int line0 = i0, line1 = i1;
+
+ /* Find # lines changed here in each file. */
+ while (changed0[i0 - 1]) --i0;
+ while (changed1[i1 - 1]) --i1;
+
+ /* Record this change. */
+ script = add_change (i0, i1, line0 - i0, line1 - i1, script);
+ }
+
+ /* We have reached lines in the two files that match each other. */
+ i0--, i1--;
+ }
+
+ return script;
+}
+
+/* If CHANGES, briefly report that two files differed. */
+static void
+briefly_report (changes, filevec)
+ int changes;
+ struct file_data const filevec[];
+{
+ if (changes)
+ message (no_details_flag ? "Files %s and %s differ\n"
+ : "Binary files %s and %s differ\n",
+ filevec[0].name, filevec[1].name);
+}
+
+/* Report the differences of two files. DEPTH is the current directory
+ depth. */
+int
+diff_2_files (filevec, depth)
+ struct file_data filevec[];
+ int depth;
+{
+ int diags;
+ int i;
+ struct change *e, *p;
+ struct change *script;
+ int changes;
+
+
+ /* If we have detected that either file is binary,
+ compare the two files as binary. This can happen
+ only when the first chunk is read.
+ Also, --brief without any --ignore-* options means
+ we can speed things up by treating the files as binary. */
+
+ if (read_files (filevec, no_details_flag & ~ignore_some_changes))
+ {
+ /* Files with different lengths must be different. */
+ if (filevec[0].stat.st_size != filevec[1].stat.st_size
+ && (filevec[0].desc < 0 || S_ISREG (filevec[0].stat.st_mode))
+ && (filevec[1].desc < 0 || S_ISREG (filevec[1].stat.st_mode)))
+ changes = 1;
+
+ /* Standard input equals itself. */
+ else if (filevec[0].desc == filevec[1].desc)
+ changes = 0;
+
+ else
+ /* Scan both files, a buffer at a time, looking for a difference. */
+ {
+ /* Allocate same-sized buffers for both files. */
+ size_t buffer_size = buffer_lcm (STAT_BLOCKSIZE (filevec[0].stat),
+ STAT_BLOCKSIZE (filevec[1].stat));
+ for (i = 0; i < 2; i++)
+ filevec[i].buffer = xrealloc (filevec[i].buffer, buffer_size);
+
+ for (;; filevec[0].buffered_chars = filevec[1].buffered_chars = 0)
+ {
+ /* Read a buffer's worth from both files. */
+ for (i = 0; i < 2; i++)
+ if (0 <= filevec[i].desc)
+ while (filevec[i].buffered_chars != buffer_size)
+ {
+ int r = read (filevec[i].desc,
+ filevec[i].buffer
+ + filevec[i].buffered_chars,
+ buffer_size - filevec[i].buffered_chars);
+ if (r == 0)
+ break;
+ if (r < 0)
+ pfatal_with_name (filevec[i].name);
+ filevec[i].buffered_chars += r;
+ }
+
+ /* If the buffers differ, the files differ. */
+ if (filevec[0].buffered_chars != filevec[1].buffered_chars
+ || (filevec[0].buffered_chars != 0
+ && memcmp (filevec[0].buffer,
+ filevec[1].buffer,
+ filevec[0].buffered_chars) != 0))
+ {
+ changes = 1;
+ break;
+ }
+
+ /* If we reach end of file, the files are the same. */
+ if (filevec[0].buffered_chars != buffer_size)
+ {
+ changes = 0;
+ break;
+ }
+ }
+ }
+
+ briefly_report (changes, filevec);
+ }
+ else
+ {
+ /* Allocate vectors for the results of comparison:
+ a flag for each line of each file, saying whether that line
+ is an insertion or deletion.
+ Allocate an extra element, always zero, at each end of each vector. */
+
+ size_t s = filevec[0].buffered_lines + filevec[1].buffered_lines + 4;
+ filevec[0].changed_flag = xmalloc (s);
+ bzero (filevec[0].changed_flag, s);
+ filevec[0].changed_flag++;
+ filevec[1].changed_flag = filevec[0].changed_flag
+ + filevec[0].buffered_lines + 2;
+
+ /* Some lines are obviously insertions or deletions
+ because they don't match anything. Detect them now, and
+ avoid even thinking about them in the main comparison algorithm. */
+
+ discard_confusing_lines (filevec);
+
+ /* Now do the main comparison algorithm, considering just the
+ undiscarded lines. */
+
+ xvec = filevec[0].undiscarded;
+ yvec = filevec[1].undiscarded;
+ diags = filevec[0].nondiscarded_lines + filevec[1].nondiscarded_lines + 3;
+ fdiag = (int *) xmalloc (diags * (2 * sizeof (int)));
+ bdiag = fdiag + diags;
+ fdiag += filevec[1].nondiscarded_lines + 1;
+ bdiag += filevec[1].nondiscarded_lines + 1;
+
+ /* Set TOO_EXPENSIVE to be approximate square root of input size,
+ bounded below by 256. */
+ too_expensive = 1;
+ for (i = filevec[0].nondiscarded_lines + filevec[1].nondiscarded_lines;
+ i != 0; i >>= 2)
+ too_expensive <<= 1;
+ too_expensive = max (256, too_expensive);
+
+ files[0] = filevec[0];
+ files[1] = filevec[1];
+
+ compareseq (0, filevec[0].nondiscarded_lines,
+ 0, filevec[1].nondiscarded_lines, no_discards);
+
+ free (fdiag - (filevec[1].nondiscarded_lines + 1));
+
+ /* Modify the results slightly to make them prettier
+ in cases where that can validly be done. */
+
+ shift_boundaries (filevec);
+
+ /* Get the results of comparison in the form of a chain
+ of `struct change's -- an edit script. */
+
+ if (output_style == OUTPUT_ED)
+ script = build_reverse_script (filevec);
+ else
+ script = build_script (filevec);
+
+ /* Set CHANGES if we had any diffs.
+ If some changes are ignored, we must scan the script to decide. */
+ if (ignore_blank_lines_flag || ignore_regexp_list)
+ {
+ struct change *next = script;
+ changes = 0;
+
+ while (next && changes == 0)
+ {
+ struct change *this, *end;
+ int first0, last0, first1, last1, deletes, inserts;
+
+ /* Find a set of changes that belong together. */
+ this = next;
+ end = find_change (next);
+
+ /* Disconnect them from the rest of the changes, making them
+ a hunk, and remember the rest for next iteration. */
+ next = end->link;
+ end->link = 0;
+
+ /* Determine whether this hunk is really a difference. */
+ analyze_hunk (this, &first0, &last0, &first1, &last1,
+ &deletes, &inserts);
+
+ /* Reconnect the script so it will all be freed properly. */
+ end->link = next;
+
+ if (deletes || inserts)
+ changes = 1;
+ }
+ }
+ else
+ changes = (script != 0);
+
+ if (no_details_flag)
+ briefly_report (changes, filevec);
+ else
+ {
+ if (changes || ! no_diff_means_no_output)
+ {
+ /* Record info for starting up output,
+ to be used if and when we have some output to print. */
+ setup_output (files[0].name, files[1].name, depth);
+
+ switch (output_style)
+ {
+ case OUTPUT_CONTEXT:
+ print_context_script (script, 0);
+ break;
+
+ case OUTPUT_UNIFIED:
+ print_context_script (script, 1);
+ break;
+
+ case OUTPUT_ED:
+ print_ed_script (script);
+ break;
+
+ case OUTPUT_FORWARD_ED:
+ pr_forward_ed_script (script);
+ break;
+
+ case OUTPUT_RCS:
+ print_rcs_script (script);
+ break;
+
+ case OUTPUT_NORMAL:
+ print_normal_script (script);
+ break;
+
+ case OUTPUT_IFDEF:
+ print_ifdef_script (script);
+ break;
+
+ case OUTPUT_SDIFF:
+ print_sdiff_script (script);
+ }
+
+ finish_output ();
+ }
+ }
+
+ free (filevec[0].undiscarded);
+
+ free (filevec[0].changed_flag - 1);
+
+ for (i = 1; i >= 0; --i)
+ free (filevec[i].equivs);
+
+ for (i = 0; i < 2; ++i)
+ free (filevec[i].linbuf + filevec[i].linbuf_base);
+
+ for (e = script; e; e = p)
+ {
+ p = e->link;
+ free (e);
+ }
+
+ if (! ROBUST_OUTPUT_STYLE (output_style))
+ for (i = 0; i < 2; ++i)
+ if (filevec[i].missing_newline)
+ {
+ diff_error ("No newline at end of file %s", filevec[i].name, "");
+ changes = 2;
+ }
+ }
+
+ if (filevec[0].buffer != filevec[1].buffer)
+ free (filevec[0].buffer);
+ free (filevec[1].buffer);
+
+ return changes;
+}
diff --git a/contrib/cvs/diff/cmpbuf.c b/contrib/cvs/diff/cmpbuf.c
new file mode 100644
index 000000000000..e95a8f98ed9d
--- /dev/null
+++ b/contrib/cvs/diff/cmpbuf.c
@@ -0,0 +1,40 @@
+/* Buffer primitives for comparison operations.
+ Copyright (C) 1993 Free Software Foundation, Inc.
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 2, or (at your option)
+ any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ 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. */
+
+#include "system.h"
+#include "cmpbuf.h"
+
+/* Least common multiple of two buffer sizes A and B. */
+
+size_t
+buffer_lcm (a, b)
+ size_t a, b;
+{
+ size_t m, n, r;
+
+ /* Yield reasonable values if buffer sizes are zero. */
+ if (!a)
+ return b ? b : 8 * 1024;
+ if (!b)
+ return a;
+
+ /* n = gcd (a, b) */
+ for (m = a, n = b; (r = m % n) != 0; m = n, n = r)
+ continue;
+
+ return a/n * b;
+}
diff --git a/contrib/cvs/diff/cmpbuf.h b/contrib/cvs/diff/cmpbuf.h
new file mode 100644
index 000000000000..e3852b7bd4f4
--- /dev/null
+++ b/contrib/cvs/diff/cmpbuf.h
@@ -0,0 +1,20 @@
+/* Buffer primitives for comparison operations.
+ Copyright (C) 1993 Free Software Foundation, Inc.
+
+This file is part of GNU DIFF.
+
+GNU DIFF is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 2, or (at your option)
+any later version.
+
+GNU DIFF is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GNU DIFF; see the file COPYING. If not, write to
+the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA. */
+
+size_t buffer_lcm PARAMS((size_t, size_t));
diff --git a/contrib/cvs/diff/context.c b/contrib/cvs/diff/context.c
new file mode 100644
index 000000000000..14f950c52699
--- /dev/null
+++ b/contrib/cvs/diff/context.c
@@ -0,0 +1,468 @@
+/* Context-format output routines for GNU DIFF.
+ Copyright (C) 1988,1989,1991,1992,1993,1994 Free Software Foundation, Inc.
+
+This file is part of GNU DIFF.
+
+GNU DIFF is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 2, or (at your option)
+any later version.
+
+GNU DIFF is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GNU DIFF; see the file COPYING. If not, write to
+the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA. */
+
+#include "diff.h"
+
+static struct change *find_hunk PARAMS((struct change *));
+static void find_function PARAMS((struct file_data const *, int, char const **, size_t *));
+static void mark_ignorable PARAMS((struct change *));
+static void pr_context_hunk PARAMS((struct change *));
+static void pr_unidiff_hunk PARAMS((struct change *));
+static void print_context_label PARAMS ((char const *, struct file_data *, char const *));
+static void print_context_number_range PARAMS((struct file_data const *, int, int));
+static void print_unidiff_number_range PARAMS((struct file_data const *, int, int));
+
+/* Last place find_function started searching from. */
+static int find_function_last_search;
+
+/* The value find_function returned when it started searching there. */
+static int find_function_last_match;
+
+/* Print a label for a context diff, with a file name and date or a label. */
+
+static void
+print_context_label (mark, inf, label)
+ char const *mark;
+ struct file_data *inf;
+ char const *label;
+{
+ if (label)
+ fprintf (outfile, "%s %s\n", mark, label);
+ else
+ {
+ char const *ct = ctime (&inf->stat.st_mtime);
+ if (!ct)
+ ct = "?\n";
+ /* See Posix.2 section 4.17.6.1.4 for this format. */
+ fprintf (outfile, "%s %s\t%s", mark, inf->name, ct);
+ }
+}
+
+/* Print a header for a context diff, with the file names and dates. */
+
+void
+print_context_header (inf, unidiff_flag)
+ struct file_data inf[];
+ int unidiff_flag;
+{
+ if (unidiff_flag)
+ {
+ print_context_label ("---", &inf[0], file_label[0]);
+ print_context_label ("+++", &inf[1], file_label[1]);
+ }
+ else
+ {
+ print_context_label ("***", &inf[0], file_label[0]);
+ print_context_label ("---", &inf[1], file_label[1]);
+ }
+}
+
+/* Print an edit script in context format. */
+
+void
+print_context_script (script, unidiff_flag)
+ struct change *script;
+ int unidiff_flag;
+{
+ if (ignore_blank_lines_flag || ignore_regexp_list)
+ mark_ignorable (script);
+ else
+ {
+ struct change *e;
+ for (e = script; e; e = e->link)
+ e->ignore = 0;
+ }
+
+ find_function_last_search = - files[0].prefix_lines;
+ find_function_last_match = find_function_last_search - 1;
+
+ if (unidiff_flag)
+ print_script (script, find_hunk, pr_unidiff_hunk);
+ else
+ print_script (script, find_hunk, pr_context_hunk);
+}
+
+/* Print a pair of line numbers with a comma, translated for file FILE.
+ If the second number is not greater, use the first in place of it.
+
+ Args A and B are internal line numbers.
+ We print the translated (real) line numbers. */
+
+static void
+print_context_number_range (file, a, b)
+ struct file_data const *file;
+ int a, b;
+{
+ int trans_a, trans_b;
+ translate_range (file, a, b, &trans_a, &trans_b);
+
+ /* Note: we can have B < A in the case of a range of no lines.
+ In this case, we should print the line number before the range,
+ which is B. */
+ if (trans_b > trans_a)
+ fprintf (outfile, "%d,%d", trans_a, trans_b);
+ else
+ fprintf (outfile, "%d", trans_b);
+}
+
+/* Print a portion of an edit script in context format.
+ HUNK is the beginning of the portion to be printed.
+ The end is marked by a `link' that has been nulled out.
+
+ Prints out lines from both files, and precedes each
+ line with the appropriate flag-character. */
+
+static void
+pr_context_hunk (hunk)
+ struct change *hunk;
+{
+ int first0, last0, first1, last1, show_from, show_to, i;
+ struct change *next;
+ char const *prefix;
+ char const *function;
+ size_t function_length;
+ FILE *out;
+
+ /* Determine range of line numbers involved in each file. */
+
+ analyze_hunk (hunk, &first0, &last0, &first1, &last1, &show_from, &show_to);
+
+ if (!show_from && !show_to)
+ return;
+
+ /* Include a context's width before and after. */
+
+ i = - files[0].prefix_lines;
+ first0 = max (first0 - context, i);
+ first1 = max (first1 - context, i);
+ last0 = min (last0 + context, files[0].valid_lines - 1);
+ last1 = min (last1 + context, files[1].valid_lines - 1);
+
+ /* If desired, find the preceding function definition line in file 0. */
+ function = 0;
+ if (function_regexp_list)
+ find_function (&files[0], first0, &function, &function_length);
+
+ begin_output ();
+ out = outfile;
+
+ /* If we looked for and found a function this is part of,
+ include its name in the header of the diff section. */
+ fprintf (out, "***************");
+
+ if (function)
+ {
+ fprintf (out, " ");
+ fwrite (function, 1, min (function_length - 1, 40), out);
+ }
+
+ fprintf (out, "\n*** ");
+ print_context_number_range (&files[0], first0, last0);
+ fprintf (out, " ****\n");
+
+ if (show_from)
+ {
+ next = hunk;
+
+ for (i = first0; i <= last0; i++)
+ {
+ /* Skip past changes that apply (in file 0)
+ only to lines before line I. */
+
+ while (next && next->line0 + next->deleted <= i)
+ next = next->link;
+
+ /* Compute the marking for line I. */
+
+ prefix = " ";
+ if (next && next->line0 <= i)
+ /* The change NEXT covers this line.
+ If lines were inserted here in file 1, this is "changed".
+ Otherwise it is "deleted". */
+ prefix = (next->inserted > 0 ? "!" : "-");
+
+ print_1_line (prefix, &files[0].linbuf[i]);
+ }
+ }
+
+ fprintf (out, "--- ");
+ print_context_number_range (&files[1], first1, last1);
+ fprintf (out, " ----\n");
+
+ if (show_to)
+ {
+ next = hunk;
+
+ for (i = first1; i <= last1; i++)
+ {
+ /* Skip past changes that apply (in file 1)
+ only to lines before line I. */
+
+ while (next && next->line1 + next->inserted <= i)
+ next = next->link;
+
+ /* Compute the marking for line I. */
+
+ prefix = " ";
+ if (next && next->line1 <= i)
+ /* The change NEXT covers this line.
+ If lines were deleted here in file 0, this is "changed".
+ Otherwise it is "inserted". */
+ prefix = (next->deleted > 0 ? "!" : "+");
+
+ print_1_line (prefix, &files[1].linbuf[i]);
+ }
+ }
+}
+
+/* Print a pair of line numbers with a comma, translated for file FILE.
+ If the second number is smaller, use the first in place of it.
+ If the numbers are equal, print just one number.
+
+ Args A and B are internal line numbers.
+ We print the translated (real) line numbers. */
+
+static void
+print_unidiff_number_range (file, a, b)
+ struct file_data const *file;
+ int a, b;
+{
+ int trans_a, trans_b;
+ translate_range (file, a, b, &trans_a, &trans_b);
+
+ /* Note: we can have B < A in the case of a range of no lines.
+ In this case, we should print the line number before the range,
+ which is B. */
+ if (trans_b <= trans_a)
+ fprintf (outfile, trans_b == trans_a ? "%d" : "%d,0", trans_b);
+ else
+ fprintf (outfile, "%d,%d", trans_a, trans_b - trans_a + 1);
+}
+
+/* Print a portion of an edit script in unidiff format.
+ HUNK is the beginning of the portion to be printed.
+ The end is marked by a `link' that has been nulled out.
+
+ Prints out lines from both files, and precedes each
+ line with the appropriate flag-character. */
+
+static void
+pr_unidiff_hunk (hunk)
+ struct change *hunk;
+{
+ int first0, last0, first1, last1, show_from, show_to, i, j, k;
+ struct change *next;
+ char const *function;
+ size_t function_length;
+ FILE *out;
+
+ /* Determine range of line numbers involved in each file. */
+
+ analyze_hunk (hunk, &first0, &last0, &first1, &last1, &show_from, &show_to);
+
+ if (!show_from && !show_to)
+ return;
+
+ /* Include a context's width before and after. */
+
+ i = - files[0].prefix_lines;
+ first0 = max (first0 - context, i);
+ first1 = max (first1 - context, i);
+ last0 = min (last0 + context, files[0].valid_lines - 1);
+ last1 = min (last1 + context, files[1].valid_lines - 1);
+
+ /* If desired, find the preceding function definition line in file 0. */
+ function = 0;
+ if (function_regexp_list)
+ find_function (&files[0], first0, &function, &function_length);
+
+ begin_output ();
+ out = outfile;
+
+ fprintf (out, "@@ -");
+ print_unidiff_number_range (&files[0], first0, last0);
+ fprintf (out, " +");
+ print_unidiff_number_range (&files[1], first1, last1);
+ fprintf (out, " @@");
+
+ /* If we looked for and found a function this is part of,
+ include its name in the header of the diff section. */
+
+ if (function)
+ {
+ putc (' ', out);
+ fwrite (function, 1, min (function_length - 1, 40), out);
+ }
+ putc ('\n', out);
+
+ next = hunk;
+ i = first0;
+ j = first1;
+
+ while (i <= last0 || j <= last1)
+ {
+
+ /* If the line isn't a difference, output the context from file 0. */
+
+ if (!next || i < next->line0)
+ {
+ putc (tab_align_flag ? '\t' : ' ', out);
+ print_1_line (0, &files[0].linbuf[i++]);
+ j++;
+ }
+ else
+ {
+ /* For each difference, first output the deleted part. */
+
+ k = next->deleted;
+ while (k--)
+ {
+ putc ('-', out);
+ if (tab_align_flag)
+ putc ('\t', out);
+ print_1_line (0, &files[0].linbuf[i++]);
+ }
+
+ /* Then output the inserted part. */
+
+ k = next->inserted;
+ while (k--)
+ {
+ putc ('+', out);
+ if (tab_align_flag)
+ putc ('\t', out);
+ print_1_line (0, &files[1].linbuf[j++]);
+ }
+
+ /* We're done with this hunk, so on to the next! */
+
+ next = next->link;
+ }
+ }
+}
+
+/* Scan a (forward-ordered) edit script for the first place that more than
+ 2*CONTEXT unchanged lines appear, and return a pointer
+ to the `struct change' for the last change before those lines. */
+
+static struct change *
+find_hunk (start)
+ struct change *start;
+{
+ struct change *prev;
+ int top0, top1;
+ int thresh;
+
+ do
+ {
+ /* Compute number of first line in each file beyond this changed. */
+ top0 = start->line0 + start->deleted;
+ top1 = start->line1 + start->inserted;
+ prev = start;
+ start = start->link;
+ /* Threshold distance is 2*CONTEXT between two non-ignorable changes,
+ but only CONTEXT if one is ignorable. */
+ thresh = ((prev->ignore || (start && start->ignore))
+ ? context
+ : 2 * context + 1);
+ /* It is not supposed to matter which file we check in the end-test.
+ If it would matter, crash. */
+ if (start && start->line0 - top0 != start->line1 - top1)
+ abort ();
+ } while (start
+ /* Keep going if less than THRESH lines
+ elapse before the affected line. */
+ && start->line0 < top0 + thresh);
+
+ return prev;
+}
+
+/* Set the `ignore' flag properly in each change in SCRIPT.
+ It should be 1 if all the lines inserted or deleted in that change
+ are ignorable lines. */
+
+static void
+mark_ignorable (script)
+ struct change *script;
+{
+ while (script)
+ {
+ struct change *next = script->link;
+ int first0, last0, first1, last1, deletes, inserts;
+
+ /* Turn this change into a hunk: detach it from the others. */
+ script->link = 0;
+
+ /* Determine whether this change is ignorable. */
+ analyze_hunk (script, &first0, &last0, &first1, &last1, &deletes, &inserts);
+ /* Reconnect the chain as before. */
+ script->link = next;
+
+ /* If the change is ignorable, mark it. */
+ script->ignore = (!deletes && !inserts);
+
+ /* Advance to the following change. */
+ script = next;
+ }
+}
+
+/* Find the last function-header line in FILE prior to line number LINENUM.
+ This is a line containing a match for the regexp in `function_regexp'.
+ Store the address of the line text into LINEP and the length of the
+ line into LENP.
+ Do not store anything if no function-header is found. */
+
+static void
+find_function (file, linenum, linep, lenp)
+ struct file_data const *file;
+ int linenum;
+ char const **linep;
+ size_t *lenp;
+{
+ int i = linenum;
+ int last = find_function_last_search;
+ find_function_last_search = i;
+
+ while (--i >= last)
+ {
+ /* See if this line is what we want. */
+ struct regexp_list *r;
+ char const *line = file->linbuf[i];
+ size_t len = file->linbuf[i + 1] - line;
+
+ for (r = function_regexp_list; r; r = r->next)
+ if (0 <= re_search (&r->buf, line, len, 0, len, 0))
+ {
+ *linep = line;
+ *lenp = len;
+ find_function_last_match = i;
+ return;
+ }
+ }
+ /* If we search back to where we started searching the previous time,
+ find the line we found last time. */
+ if (find_function_last_match >= - file->prefix_lines)
+ {
+ i = find_function_last_match;
+ *linep = file->linbuf[i];
+ *lenp = file->linbuf[i + 1] - *linep;
+ return;
+ }
+ return;
+}
diff --git a/contrib/cvs/diff/diagmeet.note b/contrib/cvs/diff/diagmeet.note
new file mode 100644
index 000000000000..8f7242c7356a
--- /dev/null
+++ b/contrib/cvs/diff/diagmeet.note
@@ -0,0 +1,71 @@
+Here is a comparison matrix which shows a case in which
+it is possible for the forward and backward scan in `diag'
+to meet along a nonzero length of diagonal simultaneous
+(so that bdiag[d] and fdiag[d] are not equal)
+even though there is no snake on that diagonal at the meeting point.
+
+
+ 85 1 1 1 159 1 1 17
+ 1 2 3 4
+60
+ 1 2
+1
+ 2 2 3 4
+71
+ 3 3 4 5
+85
+ 4 3 4 5
+17
+ 5 4 5
+1
+ 6 4 5 6
+183
+ 7 5 6 7
+10
+ 8 6 7
+1
+ 9 6 7 8
+12
+ 7 8 9 10
+13
+ 10 8 9 10
+14
+ 10 9 10
+17
+ 10 10
+1
+ 10 9 10
+1
+ 8 10 10 10
+183
+ 8 7 9 9 9
+10
+ 7 6 8 9 8 8
+1
+ 6 5 7 7
+1
+ 5 6 6
+1
+ 5 5 5
+50
+ 5 4 4 4
+1
+ 4 3 3
+85
+ 5 4 3 2 2
+1
+ 2 1
+17
+ 5 4 3 2 1 1
+1
+ 1 0
+ 85 1 1 1 159 1 1 17
+
+
+
+
+
+
+
+
+
diff --git a/contrib/cvs/diff/diff.c b/contrib/cvs/diff/diff.c
new file mode 100644
index 000000000000..c0e37d7d4212
--- /dev/null
+++ b/contrib/cvs/diff/diff.c
@@ -0,0 +1,1214 @@
+/* GNU DIFF entry routine.
+ Copyright (C) 1988, 1989, 1992, 1993, 1994, 1997 Free Software Foundation, Inc.
+
+This file is part of GNU DIFF.
+
+GNU DIFF is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 2, or (at your option)
+any later version.
+
+GNU DIFF is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GNU DIFF; see the file COPYING. If not, write to
+the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA. */
+
+/* GNU DIFF was written by Mike Haertel, David Hayes,
+ Richard Stallman, Len Tower, and Paul Eggert. */
+
+#define GDIFF_MAIN
+#include "diff.h"
+#include <signal.h>
+#include "getopt.h"
+#include "fnmatch.h"
+
+#ifndef DEFAULT_WIDTH
+#define DEFAULT_WIDTH 130
+#endif
+
+#ifndef GUTTER_WIDTH_MINIMUM
+#define GUTTER_WIDTH_MINIMUM 3
+#endif
+
+/* diff.c has a real initialize_main function. */
+#ifdef initialize_main
+#undef initialize_main
+#endif
+
+static char const *filetype PARAMS((struct stat const *));
+static char *option_list PARAMS((char **, int));
+static int add_exclude_file PARAMS((char const *));
+static int ck_atoi PARAMS((char const *, int *));
+static int compare_files PARAMS((char const *, char const *, char const *, char const *, int));
+static int specify_format PARAMS((char **, char *));
+static void add_exclude PARAMS((char const *));
+static void add_regexp PARAMS((struct regexp_list **, char const *));
+static void specify_style PARAMS((enum output_style));
+static int try_help PARAMS((char const *));
+static void check_output PARAMS((FILE *));
+static void usage PARAMS((void));
+static void initialize_main PARAMS((int *, char ***));
+
+/* Nonzero for -r: if comparing two directories,
+ compare their common subdirectories recursively. */
+
+static int recursive;
+
+/* For debugging: don't do discard_confusing_lines. */
+
+int no_discards;
+
+#if HAVE_SETMODE
+/* I/O mode: nonzero only if using binary input/output. */
+static int binary_I_O;
+#endif
+
+/* Return a string containing the command options with which diff was invoked.
+ Spaces appear between what were separate ARGV-elements.
+ There is a space at the beginning but none at the end.
+ If there were no options, the result is an empty string.
+
+ Arguments: OPTIONVEC, a vector containing separate ARGV-elements, and COUNT,
+ the length of that vector. */
+
+static char *
+option_list (optionvec, count)
+ char **optionvec; /* Was `vector', but that collides on Alliant. */
+ int count;
+{
+ int i;
+ size_t length = 0;
+ char *result;
+
+ for (i = 0; i < count; i++)
+ length += strlen (optionvec[i]) + 1;
+
+ result = xmalloc (length + 1);
+ result[0] = 0;
+
+ for (i = 0; i < count; i++)
+ {
+ strcat (result, " ");
+ strcat (result, optionvec[i]);
+ }
+
+ return result;
+}
+
+/* Convert STR to a positive integer, storing the result in *OUT.
+ If STR is not a valid integer, return -1 (otherwise 0). */
+static int
+ck_atoi (str, out)
+ char const *str;
+ int *out;
+{
+ char const *p;
+ for (p = str; *p; p++)
+ if (*p < '0' || *p > '9')
+ return -1;
+
+ *out = atoi (optarg);
+ return 0;
+}
+
+/* Keep track of excluded file name patterns. */
+
+static char const **exclude;
+static int exclude_alloc, exclude_count;
+
+int
+excluded_filename (f)
+ char const *f;
+{
+ int i;
+ for (i = 0; i < exclude_count; i++)
+ if (fnmatch (exclude[i], f, 0) == 0)
+ return 1;
+ return 0;
+}
+
+static void
+add_exclude (pattern)
+ char const *pattern;
+{
+ if (exclude_alloc <= exclude_count)
+ exclude = (char const **)
+ (exclude_alloc == 0
+ ? xmalloc ((exclude_alloc = 64) * sizeof (*exclude))
+ : xrealloc (exclude, (exclude_alloc *= 2) * sizeof (*exclude)));
+
+ exclude[exclude_count++] = pattern;
+}
+
+static int
+add_exclude_file (name)
+ char const *name;
+{
+ struct file_data f;
+ char *p, *q, *lim;
+
+ f.name = optarg;
+ f.desc = (strcmp (optarg, "-") == 0
+ ? STDIN_FILENO
+ : open (optarg, O_RDONLY, 0));
+ if (f.desc < 0 || fstat (f.desc, &f.stat) != 0)
+ return -1;
+
+ sip (&f, 1);
+ slurp (&f);
+
+ for (p = f.buffer, lim = p + f.buffered_chars; p < lim; p = q)
+ {
+ q = (char *) memchr (p, '\n', lim - p);
+ if (!q)
+ q = lim;
+ *q++ = 0;
+ add_exclude (p);
+ }
+
+ return close (f.desc);
+}
+
+/* The numbers 129- that appear in the fourth element of some entries
+ tell the big switch in `diff_run' how to process those options. */
+
+static struct option const longopts[] =
+{
+ {"ignore-blank-lines", 0, 0, 'B'},
+ {"context", 2, 0, 'C'},
+ {"ifdef", 1, 0, 'D'},
+ {"show-function-line", 1, 0, 'F'},
+ {"speed-large-files", 0, 0, 'H'},
+ {"ignore-matching-lines", 1, 0, 'I'},
+ {"label", 1, 0, 'L'},
+ {"file-label", 1, 0, 'L'}, /* An alias, no longer recommended */
+ {"new-file", 0, 0, 'N'},
+ {"entire-new-file", 0, 0, 'N'}, /* An alias, no longer recommended */
+ {"unidirectional-new-file", 0, 0, 'P'},
+ {"starting-file", 1, 0, 'S'},
+ {"initial-tab", 0, 0, 'T'},
+ {"width", 1, 0, 'W'},
+ {"text", 0, 0, 'a'},
+ {"ascii", 0, 0, 'a'}, /* An alias, no longer recommended */
+ {"ignore-space-change", 0, 0, 'b'},
+ {"minimal", 0, 0, 'd'},
+ {"ed", 0, 0, 'e'},
+ {"forward-ed", 0, 0, 'f'},
+ {"ignore-case", 0, 0, 'i'},
+ {"paginate", 0, 0, 'l'},
+ {"print", 0, 0, 'l'}, /* An alias, no longer recommended */
+ {"rcs", 0, 0, 'n'},
+ {"show-c-function", 0, 0, 'p'},
+ {"brief", 0, 0, 'q'},
+ {"recursive", 0, 0, 'r'},
+ {"report-identical-files", 0, 0, 's'},
+ {"expand-tabs", 0, 0, 't'},
+ {"version", 0, 0, 'v'},
+ {"ignore-all-space", 0, 0, 'w'},
+ {"exclude", 1, 0, 'x'},
+ {"exclude-from", 1, 0, 'X'},
+ {"side-by-side", 0, 0, 'y'},
+ {"unified", 2, 0, 'U'},
+ {"left-column", 0, 0, 129},
+ {"suppress-common-lines", 0, 0, 130},
+ {"sdiff-merge-assist", 0, 0, 131},
+ {"old-line-format", 1, 0, 132},
+ {"new-line-format", 1, 0, 133},
+ {"unchanged-line-format", 1, 0, 134},
+ {"line-format", 1, 0, 135},
+ {"old-group-format", 1, 0, 136},
+ {"new-group-format", 1, 0, 137},
+ {"unchanged-group-format", 1, 0, 138},
+ {"changed-group-format", 1, 0, 139},
+ {"horizon-lines", 1, 0, 140},
+ {"help", 0, 0, 141},
+ {"binary", 0, 0, 142},
+ {0, 0, 0, 0}
+};
+
+int
+diff_run (argc, argv, out)
+ int argc;
+ char *argv[];
+ char *out;
+{
+ int val;
+ int c;
+ int prev = -1;
+ int width = DEFAULT_WIDTH;
+ int show_c_function = 0;
+ int optind_old;
+
+ /* Do our initializations. */
+ initialize_main (&argc, &argv);
+
+ /* Decode the options. */
+
+ optind_old = optind;
+ optind = 0;
+ while ((c = getopt_long (argc, argv,
+ "0123456789abBcC:dD:efF:hHiI:lL:nNpPqrsS:tTuU:vwW:x:X:y",
+ longopts, 0)) != EOF)
+ {
+ switch (c)
+ {
+ /* All digits combine in decimal to specify the context-size. */
+ case '1':
+ case '2':
+ case '3':
+ case '4':
+ case '5':
+ case '6':
+ case '7':
+ case '8':
+ case '9':
+ case '0':
+ if (context == -1)
+ context = 0;
+ /* If a context length has already been specified,
+ more digits allowed only if they follow right after the others.
+ Reject two separate runs of digits, or digits after -C. */
+ else if (prev < '0' || prev > '9')
+ fatal ("context length specified twice");
+
+ context = context * 10 + c - '0';
+ break;
+
+ case 'a':
+ /* Treat all files as text files; never treat as binary. */
+ always_text_flag = 1;
+ break;
+
+ case 'b':
+ /* Ignore changes in amount of white space. */
+ ignore_space_change_flag = 1;
+ ignore_some_changes = 1;
+ ignore_some_line_changes = 1;
+ break;
+
+ case 'B':
+ /* Ignore changes affecting only blank lines. */
+ ignore_blank_lines_flag = 1;
+ ignore_some_changes = 1;
+ break;
+
+ case 'C': /* +context[=lines] */
+ case 'U': /* +unified[=lines] */
+ if (optarg)
+ {
+ if (context >= 0)
+ fatal ("context length specified twice");
+
+ if (ck_atoi (optarg, &context))
+ fatal ("invalid context length argument");
+ }
+
+ /* Falls through. */
+ case 'c':
+ /* Make context-style output. */
+ specify_style (c == 'U' ? OUTPUT_UNIFIED : OUTPUT_CONTEXT);
+ break;
+
+ case 'd':
+ /* Don't discard lines. This makes things slower (sometimes much
+ slower) but will find a guaranteed minimal set of changes. */
+ no_discards = 1;
+ break;
+
+ case 'D':
+ /* Make merged #ifdef output. */
+ specify_style (OUTPUT_IFDEF);
+ {
+ int i, err = 0;
+ static char const C_ifdef_group_formats[] =
+ "#ifndef %s\n%%<#endif /* not %s */\n%c#ifdef %s\n%%>#endif /* %s */\n%c%%=%c#ifndef %s\n%%<#else /* %s */\n%%>#endif /* %s */\n";
+ char *b = xmalloc (sizeof (C_ifdef_group_formats)
+ + 7 * strlen(optarg) - 14 /* 7*"%s" */
+ - 8 /* 5*"%%" + 3*"%c" */);
+ sprintf (b, C_ifdef_group_formats,
+ optarg, optarg, 0,
+ optarg, optarg, 0, 0,
+ optarg, optarg, optarg);
+ for (i = 0; i < 4; i++)
+ {
+ err |= specify_format (&group_format[i], b);
+ b += strlen (b) + 1;
+ }
+ if (err)
+ diff_error ("conflicting #ifdef formats", 0, 0);
+ }
+ break;
+
+ case 'e':
+ /* Make output that is a valid `ed' script. */
+ specify_style (OUTPUT_ED);
+ break;
+
+ case 'f':
+ /* Make output that looks vaguely like an `ed' script
+ but has changes in the order they appear in the file. */
+ specify_style (OUTPUT_FORWARD_ED);
+ break;
+
+ case 'F':
+ /* Show, for each set of changes, the previous line that
+ matches the specified regexp. Currently affects only
+ context-style output. */
+ add_regexp (&function_regexp_list, optarg);
+ break;
+
+ case 'h':
+ /* Split the files into chunks of around 1500 lines
+ for faster processing. Usually does not change the result.
+
+ This currently has no effect. */
+ break;
+
+ case 'H':
+ /* Turn on heuristics that speed processing of large files
+ with a small density of changes. */
+ heuristic = 1;
+ break;
+
+ case 'i':
+ /* Ignore changes in case. */
+ ignore_case_flag = 1;
+ ignore_some_changes = 1;
+ ignore_some_line_changes = 1;
+ break;
+
+ case 'I':
+ /* Ignore changes affecting only lines that match the
+ specified regexp. */
+ add_regexp (&ignore_regexp_list, optarg);
+ ignore_some_changes = 1;
+ break;
+
+ case 'l':
+ /* Pass the output through `pr' to paginate it. */
+ paginate_flag = 1;
+#if !defined(SIGCHLD) && defined(SIGCLD)
+#define SIGCHLD SIGCLD
+#endif
+#ifdef SIGCHLD
+ /* Pagination requires forking and waiting, and
+ System V fork+wait does not work if SIGCHLD is ignored. */
+ signal (SIGCHLD, SIG_DFL);
+#endif
+ break;
+
+ case 'L':
+ /* Specify file labels for `-c' output headers. */
+ if (!file_label[0])
+ file_label[0] = optarg;
+ else if (!file_label[1])
+ file_label[1] = optarg;
+ else
+ fatal ("too many file label options");
+ break;
+
+ case 'n':
+ /* Output RCS-style diffs, like `-f' except that each command
+ specifies the number of lines affected. */
+ specify_style (OUTPUT_RCS);
+ break;
+
+ case 'N':
+ /* When comparing directories, if a file appears only in one
+ directory, treat it as present but empty in the other. */
+ entire_new_file_flag = 1;
+ break;
+
+ case 'p':
+ /* Make context-style output and show name of last C function. */
+ show_c_function = 1;
+ add_regexp (&function_regexp_list, "^[_a-zA-Z$]");
+ break;
+
+ case 'P':
+ /* When comparing directories, if a file appears only in
+ the second directory of the two,
+ treat it as present but empty in the other. */
+ unidirectional_new_file_flag = 1;
+ break;
+
+ case 'q':
+ no_details_flag = 1;
+ break;
+
+ case 'r':
+ /* When comparing directories,
+ recursively compare any subdirectories found. */
+ recursive = 1;
+ break;
+
+ case 's':
+ /* Print a message if the files are the same. */
+ print_file_same_flag = 1;
+ break;
+
+ case 'S':
+ /* When comparing directories, start with the specified
+ file name. This is used for resuming an aborted comparison. */
+ dir_start_file = optarg;
+ break;
+
+ case 't':
+ /* Expand tabs to spaces in the output so that it preserves
+ the alignment of the input files. */
+ tab_expand_flag = 1;
+ break;
+
+ case 'T':
+ /* Use a tab in the output, rather than a space, before the
+ text of an input line, so as to keep the proper alignment
+ in the input line without changing the characters in it. */
+ tab_align_flag = 1;
+ break;
+
+ case 'u':
+ /* Output the context diff in unidiff format. */
+ specify_style (OUTPUT_UNIFIED);
+ break;
+
+ case 'v':
+ printf ("diff - GNU diffutils version %s\n", diff_version_string);
+ return 0;
+
+ case 'w':
+ /* Ignore horizontal white space when comparing lines. */
+ ignore_all_space_flag = 1;
+ ignore_some_changes = 1;
+ ignore_some_line_changes = 1;
+ break;
+
+ case 'x':
+ add_exclude (optarg);
+ break;
+
+ case 'X':
+ if (add_exclude_file (optarg) != 0)
+ pfatal_with_name (optarg);
+ break;
+
+ case 'y':
+ /* Use side-by-side (sdiff-style) columnar output. */
+ specify_style (OUTPUT_SDIFF);
+ break;
+
+ case 'W':
+ /* Set the line width for OUTPUT_SDIFF. */
+ if (ck_atoi (optarg, &width) || width <= 0)
+ fatal ("column width must be a positive integer");
+ break;
+
+ case 129:
+ sdiff_left_only = 1;
+ break;
+
+ case 130:
+ sdiff_skip_common_lines = 1;
+ break;
+
+ case 131:
+ /* sdiff-style columns output. */
+ specify_style (OUTPUT_SDIFF);
+ sdiff_help_sdiff = 1;
+ break;
+
+ case 132:
+ case 133:
+ case 134:
+ specify_style (OUTPUT_IFDEF);
+ if (specify_format (&line_format[c - 132], optarg) != 0)
+ diff_error ("conflicting line format", 0, 0);
+ break;
+
+ case 135:
+ specify_style (OUTPUT_IFDEF);
+ {
+ int i, err = 0;
+ for (i = 0; i < sizeof (line_format) / sizeof (*line_format); i++)
+ err |= specify_format (&line_format[i], optarg);
+ if (err)
+ diff_error ("conflicting line format", 0, 0);
+ }
+ break;
+
+ case 136:
+ case 137:
+ case 138:
+ case 139:
+ specify_style (OUTPUT_IFDEF);
+ if (specify_format (&group_format[c - 136], optarg) != 0)
+ diff_error ("conflicting group format", 0, 0);
+ break;
+
+ case 140:
+ if (ck_atoi (optarg, &horizon_lines) || horizon_lines < 0)
+ fatal ("horizon must be a nonnegative integer");
+ break;
+
+ case 141:
+ usage ();
+ check_output (stdout);
+ return 0;
+
+ case 142:
+ /* Use binary I/O when reading and writing data.
+ On Posix hosts, this has no effect. */
+#if HAVE_SETMODE
+ binary_I_O = 1;
+# if 0
+ /* Because this code is leftover from pre-library days,
+ there is no way to set stdout back to the default mode
+ when we are done. As it turns out, I think the only
+ parts of CVS that pass out == NULL, and thus cause diff
+ to write to stdout, are "cvs diff" and "cvs rdiff". So
+ I'm not going to worry about this too much yet. */
+ setmode (STDOUT_FILENO, O_BINARY);
+# else
+ if (out == NULL)
+ error (0, 0, "warning: did not set stdout to binary mode");
+# endif
+#endif
+ break;
+
+ default:
+ return try_help (0);
+ }
+ prev = c;
+ }
+
+ if (argc - optind != 2)
+ return try_help (argc - optind < 2 ? "missing operand" : "extra operand");
+
+ {
+ /*
+ * We maximize first the half line width, and then the gutter width,
+ * according to the following constraints:
+ * 1. Two half lines plus a gutter must fit in a line.
+ * 2. If the half line width is nonzero:
+ * a. The gutter width is at least GUTTER_WIDTH_MINIMUM.
+ * b. If tabs are not expanded to spaces,
+ * a half line plus a gutter is an integral number of tabs,
+ * so that tabs in the right column line up.
+ */
+ int t = tab_expand_flag ? 1 : TAB_WIDTH;
+ int off = (width + t + GUTTER_WIDTH_MINIMUM) / (2*t) * t;
+ sdiff_half_width = max (0, min (off - GUTTER_WIDTH_MINIMUM, width - off)),
+ sdiff_column2_offset = sdiff_half_width ? off : width;
+ }
+
+ if (show_c_function && output_style != OUTPUT_UNIFIED)
+ specify_style (OUTPUT_CONTEXT);
+
+ if (output_style != OUTPUT_CONTEXT && output_style != OUTPUT_UNIFIED)
+ context = 0;
+ else if (context == -1)
+ /* Default amount of context for -c. */
+ context = 3;
+
+ if (output_style == OUTPUT_IFDEF)
+ {
+ /* Format arrays are char *, not char const *,
+ because integer formats are temporarily modified.
+ But it is safe to assign a constant like "%=" to a format array,
+ since "%=" does not format any integers. */
+ int i;
+ for (i = 0; i < sizeof (line_format) / sizeof (*line_format); i++)
+ if (!line_format[i])
+ line_format[i] = "%l\n";
+ if (!group_format[OLD])
+ group_format[OLD]
+ = group_format[UNCHANGED] ? group_format[UNCHANGED] : "%<";
+ if (!group_format[NEW])
+ group_format[NEW]
+ = group_format[UNCHANGED] ? group_format[UNCHANGED] : "%>";
+ if (!group_format[UNCHANGED])
+ group_format[UNCHANGED] = "%=";
+ if (!group_format[CHANGED])
+ group_format[CHANGED] = concat (group_format[OLD],
+ group_format[NEW], "");
+ }
+
+ no_diff_means_no_output =
+ (output_style == OUTPUT_IFDEF ?
+ (!*group_format[UNCHANGED]
+ || (strcmp (group_format[UNCHANGED], "%=") == 0
+ && !*line_format[UNCHANGED]))
+ : output_style == OUTPUT_SDIFF ? sdiff_skip_common_lines : 1);
+
+ switch_string = option_list (argv + 1, optind - 1);
+
+ if (out == NULL)
+ outfile = stdout;
+ else
+ {
+#if HAVE_SETMODE
+ /* A diff which is full of ^Z and such isn't going to work
+ very well in text mode. */
+ if (binary_I_O)
+ outfile = fopen (out, "wb");
+ else
+#endif
+ outfile = fopen (out, "w");
+ if (outfile == NULL)
+ {
+ perror_with_name ("could not open output file");
+ return 2;
+ }
+ }
+
+ /* Set the jump buffer, so that diff may abort execution without
+ terminating the process. */
+ if ((val = setjmp (diff_abort_buf)) != 0)
+ {
+ optind = optind_old;
+ if (outfile != stdout)
+ fclose (outfile);
+ return val;
+ }
+
+ val = compare_files (0, argv[optind], 0, argv[optind + 1], 0);
+
+ /* Print any messages that were saved up for last. */
+ print_message_queue ();
+
+ free (switch_string);
+
+ optind = optind_old;
+ check_output (outfile);
+ if (outfile != stdout)
+ if (fclose (outfile) != 0)
+ perror ("close error on output file");
+ return val;
+}
+
+/* Add the compiled form of regexp PATTERN to REGLIST. */
+
+static void
+add_regexp (reglist, pattern)
+ struct regexp_list **reglist;
+ char const *pattern;
+{
+ struct regexp_list *r;
+ char const *m;
+
+ r = (struct regexp_list *) xmalloc (sizeof (*r));
+ bzero (r, sizeof (*r));
+ r->buf.fastmap = xmalloc (256);
+ m = re_compile_pattern (pattern, strlen (pattern), &r->buf);
+ if (m != 0)
+ diff_error ("%s: %s", pattern, m);
+
+ /* Add to the start of the list, since it's easier than the end. */
+ r->next = *reglist;
+ *reglist = r;
+}
+
+static int
+try_help (reason)
+ char const *reason;
+{
+ if (reason)
+ diff_error ("%s", reason, 0);
+ diff_error ("Try `%s --help' for more information.", diff_program_name, 0);
+ return 2;
+}
+
+static void
+check_output (file)
+ FILE *file;
+{
+ if (ferror (file) || fflush (file) != 0)
+ fatal ("write error");
+}
+
+static char const * const option_help[] = {
+"-i --ignore-case Consider upper- and lower-case to be the same.",
+"-w --ignore-all-space Ignore all white space.",
+"-b --ignore-space-change Ignore changes in the amount of white space.",
+"-B --ignore-blank-lines Ignore changes whose lines are all blank.",
+"-I RE --ignore-matching-lines=RE Ignore changes whose lines all match RE.",
+#if HAVE_SETMODE
+"--binary Read and write data in binary mode.",
+#endif
+"-a --text Treat all files as text.\n",
+"-c -C NUM --context[=NUM] Output NUM (default 2) lines of copied context.",
+"-u -U NUM --unified[=NUM] Output NUM (default 2) lines of unified context.",
+" -NUM Use NUM context lines.",
+" -L LABEL --label LABEL Use LABEL instead of file name.",
+" -p --show-c-function Show which C function each change is in.",
+" -F RE --show-function-line=RE Show the most recent line matching RE.",
+"-q --brief Output only whether files differ.",
+"-e --ed Output an ed script.",
+"-n --rcs Output an RCS format diff.",
+"-y --side-by-side Output in two columns.",
+" -w NUM --width=NUM Output at most NUM (default 130) characters per line.",
+" --left-column Output only the left column of common lines.",
+" --suppress-common-lines Do not output common lines.",
+"-DNAME --ifdef=NAME Output merged file to show `#ifdef NAME' diffs.",
+"--GTYPE-group-format=GFMT Similar, but format GTYPE input groups with GFMT.",
+"--line-format=LFMT Similar, but format all input lines with LFMT.",
+"--LTYPE-line-format=LFMT Similar, but format LTYPE input lines with LFMT.",
+" LTYPE is `old', `new', or `unchanged'. GTYPE is LTYPE or `changed'.",
+" GFMT may contain:",
+" %< lines from FILE1",
+" %> lines from FILE2",
+" %= lines common to FILE1 and FILE2",
+" %[-][WIDTH][.[PREC]]{doxX}LETTER printf-style spec for LETTER",
+" LETTERs are as follows for new group, lower case for old group:",
+" F first line number",
+" L last line number",
+" N number of lines = L-F+1",
+" E F-1",
+" M L+1",
+" LFMT may contain:",
+" %L contents of line",
+" %l contents of line, excluding any trailing newline",
+" %[-][WIDTH][.[PREC]]{doxX}n printf-style spec for input line number",
+" Either GFMT or LFMT may contain:",
+" %% %",
+" %c'C' the single character C",
+" %c'\\OOO' the character with octal code OOO\n",
+"-l --paginate Pass the output through `pr' to paginate it.",
+"-t --expand-tabs Expand tabs to spaces in output.",
+"-T --initial-tab Make tabs line up by prepending a tab.\n",
+"-r --recursive Recursively compare any subdirectories found.",
+"-N --new-file Treat absent files as empty.",
+"-P --unidirectional-new-file Treat absent first files as empty.",
+"-s --report-identical-files Report when two files are the same.",
+"-x PAT --exclude=PAT Exclude files that match PAT.",
+"-X FILE --exclude-from=FILE Exclude files that match any pattern in FILE.",
+"-S FILE --starting-file=FILE Start with FILE when comparing directories.\n",
+"--horizon-lines=NUM Keep NUM lines of the common prefix and suffix.",
+"-d --minimal Try hard to find a smaller set of changes.",
+"-H --speed-large-files Assume large files and many scattered small changes.\n",
+"-v --version Output version info.",
+"--help Output this help.",
+0
+};
+
+static void
+usage ()
+{
+ char const * const *p;
+
+ printf ("Usage: %s [OPTION]... FILE1 FILE2\n\n", diff_program_name);
+ for (p = option_help; *p; p++)
+ printf (" %s\n", *p);
+ printf ("\nIf FILE1 or FILE2 is `-', read standard input.\n");
+}
+
+static int
+specify_format (var, value)
+ char **var;
+ char *value;
+{
+ int err = *var ? strcmp (*var, value) : 0;
+ *var = value;
+ return err;
+}
+
+static void
+specify_style (style)
+ enum output_style style;
+{
+ if (output_style != OUTPUT_NORMAL
+ && output_style != style)
+ diff_error ("conflicting specifications of output style", 0, 0);
+ output_style = style;
+}
+
+static char const *
+filetype (st)
+ struct stat const *st;
+{
+ /* See Posix.2 section 4.17.6.1.1 and Table 5-1 for these formats.
+ To keep diagnostics grammatical, the returned string must start
+ with a consonant. */
+
+ if (S_ISREG (st->st_mode))
+ {
+ if (st->st_size == 0)
+ return "regular empty file";
+ /* Posix.2 section 5.14.2 seems to suggest that we must read the file
+ and guess whether it's C, Fortran, etc., but this is somewhat useless
+ and doesn't reflect historical practice. We're allowed to guess
+ wrong, so we don't bother to read the file. */
+ return "regular file";
+ }
+ if (S_ISDIR (st->st_mode)) return "directory";
+
+ /* other Posix.1 file types */
+#ifdef S_ISBLK
+ if (S_ISBLK (st->st_mode)) return "block special file";
+#endif
+#ifdef S_ISCHR
+ if (S_ISCHR (st->st_mode)) return "character special file";
+#endif
+#ifdef S_ISFIFO
+ if (S_ISFIFO (st->st_mode)) return "fifo";
+#endif
+
+ /* other Posix.1b file types */
+#ifdef S_TYPEISMQ
+ if (S_TYPEISMQ (st)) return "message queue";
+#endif
+#ifdef S_TYPEISSEM
+ if (S_TYPEISSEM (st)) return "semaphore";
+#endif
+#ifdef S_TYPEISSHM
+ if (S_TYPEISSHM (st)) return "shared memory object";
+#endif
+
+ /* other popular file types */
+ /* S_ISLNK is impossible with `fstat' and `stat'. */
+#ifdef S_ISSOCK
+ if (S_ISSOCK (st->st_mode)) return "socket";
+#endif
+
+ return "weird file";
+}
+
+/* Compare two files (or dirs) with specified names
+ DIR0/NAME0 and DIR1/NAME1, at level DEPTH in directory recursion.
+ (if DIR0 is 0, then the name is just NAME0, etc.)
+ This is self-contained; it opens the files and closes them.
+
+ Value is 0 if files are the same, 1 if different,
+ 2 if there is a problem opening them. */
+
+static int
+compare_files (dir0, name0, dir1, name1, depth)
+ char const *dir0, *dir1;
+ char const *name0, *name1;
+ int depth;
+{
+ struct file_data inf[2];
+ register int i;
+ int val;
+ int same_files;
+ int failed = 0;
+ char *free0 = 0, *free1 = 0;
+
+ /* If this is directory comparison, perhaps we have a file
+ that exists only in one of the directories.
+ If so, just print a message to that effect. */
+
+ if (! ((name0 != 0 && name1 != 0)
+ || (unidirectional_new_file_flag && name1 != 0)
+ || entire_new_file_flag))
+ {
+ char const *name = name0 == 0 ? name1 : name0;
+ char const *dir = name0 == 0 ? dir1 : dir0;
+ message ("Only in %s: %s\n", dir, name);
+ /* Return 1 so that diff_dirs will return 1 ("some files differ"). */
+ return 1;
+ }
+
+ bzero (inf, sizeof (inf));
+
+ /* Mark any nonexistent file with -1 in the desc field. */
+ /* Mark unopened files (e.g. directories) with -2. */
+
+ inf[0].desc = name0 == 0 ? -1 : -2;
+ inf[1].desc = name1 == 0 ? -1 : -2;
+
+ /* Now record the full name of each file, including nonexistent ones. */
+
+ if (name0 == 0)
+ name0 = name1;
+ if (name1 == 0)
+ name1 = name0;
+
+ inf[0].name = dir0 == 0 ? name0 : (free0 = dir_file_pathname (dir0, name0));
+ inf[1].name = dir1 == 0 ? name1 : (free1 = dir_file_pathname (dir1, name1));
+
+ /* Stat the files. Record whether they are directories. */
+
+ for (i = 0; i <= 1; i++)
+ {
+ if (inf[i].desc != -1)
+ {
+ int stat_result;
+
+ if (i && filename_cmp (inf[i].name, inf[0].name) == 0)
+ {
+ inf[i].stat = inf[0].stat;
+ stat_result = 0;
+ }
+ else if (strcmp (inf[i].name, "-") == 0)
+ {
+ inf[i].desc = STDIN_FILENO;
+ stat_result = fstat (STDIN_FILENO, &inf[i].stat);
+ if (stat_result == 0 && S_ISREG (inf[i].stat.st_mode))
+ {
+ off_t pos = lseek (STDIN_FILENO, (off_t) 0, SEEK_CUR);
+ if (pos == -1)
+ stat_result = -1;
+ else
+ {
+ if (pos <= inf[i].stat.st_size)
+ inf[i].stat.st_size -= pos;
+ else
+ inf[i].stat.st_size = 0;
+ /* Posix.2 4.17.6.1.4 requires current time for stdin. */
+ time (&inf[i].stat.st_mtime);
+ }
+ }
+ }
+ else
+ stat_result = stat (inf[i].name, &inf[i].stat);
+
+ if (stat_result != 0)
+ {
+ perror_with_name (inf[i].name);
+ failed = 1;
+ }
+ else
+ {
+ inf[i].dir_p = S_ISDIR (inf[i].stat.st_mode) && inf[i].desc != 0;
+ if (inf[1 - i].desc == -1)
+ {
+ inf[1 - i].dir_p = inf[i].dir_p;
+ inf[1 - i].stat.st_mode = inf[i].stat.st_mode;
+ }
+ }
+ }
+ }
+
+ if (! failed && depth == 0 && inf[0].dir_p != inf[1].dir_p)
+ {
+ /* If one is a directory, and it was specified in the command line,
+ use the file in that dir with the other file's basename. */
+
+ int fnm_arg = inf[0].dir_p;
+ int dir_arg = 1 - fnm_arg;
+ char const *fnm = inf[fnm_arg].name;
+ char const *dir = inf[dir_arg].name;
+ char const *p = filename_lastdirchar (fnm);
+ char const *filename = inf[dir_arg].name
+ = dir_file_pathname (dir, p ? p + 1 : fnm);
+
+ if (strcmp (fnm, "-") == 0)
+ fatal ("can't compare - to a directory");
+
+ if (stat (filename, &inf[dir_arg].stat) != 0)
+ {
+ perror_with_name (filename);
+ failed = 1;
+ }
+ else
+ inf[dir_arg].dir_p = S_ISDIR (inf[dir_arg].stat.st_mode);
+ }
+
+ if (failed)
+ {
+
+ /* If either file should exist but does not, return 2. */
+
+ val = 2;
+
+ }
+ else if ((same_files = inf[0].desc != -1 && inf[1].desc != -1
+ && 0 < same_file (&inf[0].stat, &inf[1].stat))
+ && no_diff_means_no_output)
+ {
+ /* The two named files are actually the same physical file.
+ We know they are identical without actually reading them. */
+
+ val = 0;
+ }
+ else if (inf[0].dir_p & inf[1].dir_p)
+ {
+ if (output_style == OUTPUT_IFDEF)
+ fatal ("-D option not supported with directories");
+
+ /* If both are directories, compare the files in them. */
+
+ if (depth > 0 && !recursive)
+ {
+ /* But don't compare dir contents one level down
+ unless -r was specified. */
+ message ("Common subdirectories: %s and %s\n",
+ inf[0].name, inf[1].name);
+ val = 0;
+ }
+ else
+ {
+ val = diff_dirs (inf, compare_files, depth);
+ }
+
+ }
+ else if ((inf[0].dir_p | inf[1].dir_p)
+ || (depth > 0
+ && (! S_ISREG (inf[0].stat.st_mode)
+ || ! S_ISREG (inf[1].stat.st_mode))))
+ {
+ /* Perhaps we have a subdirectory that exists only in one directory.
+ If so, just print a message to that effect. */
+
+ if (inf[0].desc == -1 || inf[1].desc == -1)
+ {
+ if ((inf[0].dir_p | inf[1].dir_p)
+ && recursive
+ && (entire_new_file_flag
+ || (unidirectional_new_file_flag && inf[0].desc == -1)))
+ val = diff_dirs (inf, compare_files, depth);
+ else
+ {
+ char const *dir = (inf[0].desc == -1) ? dir1 : dir0;
+ /* See Posix.2 section 4.17.6.1.1 for this format. */
+ message ("Only in %s: %s\n", dir, name0);
+ val = 1;
+ }
+ }
+ else
+ {
+ /* We have two files that are not to be compared. */
+
+ /* See Posix.2 section 4.17.6.1.1 for this format. */
+ message5 ("File %s is a %s while file %s is a %s\n",
+ inf[0].name, filetype (&inf[0].stat),
+ inf[1].name, filetype (&inf[1].stat));
+
+ /* This is a difference. */
+ val = 1;
+ }
+ }
+ else if ((no_details_flag & ~ignore_some_changes)
+ && inf[0].stat.st_size != inf[1].stat.st_size
+ && (inf[0].desc == -1 || S_ISREG (inf[0].stat.st_mode))
+ && (inf[1].desc == -1 || S_ISREG (inf[1].stat.st_mode)))
+ {
+ message ("Files %s and %s differ\n", inf[0].name, inf[1].name);
+ val = 1;
+ }
+ else
+ {
+ /* Both exist and neither is a directory. */
+
+ /* Open the files and record their descriptors. */
+
+ if (inf[0].desc == -2)
+ if ((inf[0].desc = open (inf[0].name, O_RDONLY, 0)) < 0)
+ {
+ perror_with_name (inf[0].name);
+ failed = 1;
+ }
+ if (inf[1].desc == -2)
+ if (same_files)
+ inf[1].desc = inf[0].desc;
+ else if ((inf[1].desc = open (inf[1].name, O_RDONLY, 0)) < 0)
+ {
+ perror_with_name (inf[1].name);
+ failed = 1;
+ }
+
+#if HAVE_SETMODE
+ if (binary_I_O)
+ for (i = 0; i <= 1; i++)
+ if (0 <= inf[i].desc)
+ setmode (inf[i].desc, O_BINARY);
+#endif
+
+ /* Compare the files, if no error was found. */
+
+ val = failed ? 2 : diff_2_files (inf, depth);
+
+ /* Close the file descriptors. */
+
+ if (inf[0].desc >= 0 && close (inf[0].desc) != 0)
+ {
+ perror_with_name (inf[0].name);
+ val = 2;
+ }
+ if (inf[1].desc >= 0 && inf[0].desc != inf[1].desc
+ && close (inf[1].desc) != 0)
+ {
+ perror_with_name (inf[1].name);
+ val = 2;
+ }
+ }
+
+ /* Now the comparison has been done, if no error prevented it,
+ and VAL is the value this function will return. */
+
+ if (val == 0 && !inf[0].dir_p)
+ {
+ if (print_file_same_flag)
+ message ("Files %s and %s are identical\n",
+ inf[0].name, inf[1].name);
+ }
+ else
+ fflush (outfile);
+
+ if (free0)
+ free (free0);
+ if (free1)
+ free (free1);
+
+ return val;
+}
+
+/* Initialize status variables and flag variables used in libdiff,
+ to permit repeated calls to diff_run. */
+
+static void
+initialize_main (argcp, argvp)
+ int *argcp;
+ char ***argvp;
+{
+ /* These variables really must be reset each time diff_run is called. */
+ output_style = OUTPUT_NORMAL;
+ context = -1;
+ file_label[0] = NULL;
+ file_label[1] = NULL;
+ diff_program_name = (*argvp)[0];
+ outfile = NULL;
+
+ /* Reset these also, just for safety's sake. (If one invocation turns
+ on ignore_case_flag, it must be turned off before diff_run is called
+ again. But it is possible to make many diffs before encountering
+ such a problem. */
+ recursive = 0;
+ no_discards = 0;
+#if HAVE_SETMODE
+ binary_I_O = 0;
+#endif
+ no_diff_means_no_output = 0;
+ always_text_flag = 0;
+ horizon_lines = 0;
+ ignore_space_change_flag = 0;
+ ignore_all_space_flag = 0;
+ ignore_blank_lines_flag = 0;
+ ignore_some_line_changes = 0;
+ ignore_some_changes = 0;
+ ignore_case_flag = 0;
+ function_regexp_list = NULL;
+ ignore_regexp_list = NULL;
+ no_details_flag = 0;
+ print_file_same_flag = 0;
+ tab_align_flag = 0;
+ tab_expand_flag = 0;
+ dir_start_file = NULL;
+ entire_new_file_flag = 0;
+ unidirectional_new_file_flag = 0;
+ paginate_flag = 0;
+ bzero (group_format, sizeof (group_format));
+ bzero (line_format, sizeof (line_format));
+ sdiff_help_sdiff = 0;
+ sdiff_left_only = 0;
+ sdiff_skip_common_lines = 0;
+ sdiff_half_width = 0;
+ sdiff_column2_offset = 0;
+ switch_string = NULL;
+ heuristic = 0;
+ bzero (files, sizeof (files));
+}
diff --git a/contrib/cvs/diff/diff.h b/contrib/cvs/diff/diff.h
new file mode 100644
index 000000000000..fba26a7bf076
--- /dev/null
+++ b/contrib/cvs/diff/diff.h
@@ -0,0 +1,345 @@
+/* Shared definitions for GNU DIFF
+ Copyright (C) 1988, 89, 91, 92, 93, 97 Free Software Foundation, Inc.
+
+This file is part of GNU DIFF.
+
+GNU DIFF is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 2, or (at your option)
+any later version.
+
+GNU DIFF is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GNU DIFF; see the file COPYING. If not, write to
+the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA. */
+
+#include "system.h"
+#include <stdio.h>
+#include <setjmp.h>
+#include "regex.h"
+
+#define TAB_WIDTH 8
+
+/* Variables for command line options */
+
+#ifndef GDIFF_MAIN
+#define EXTERN extern
+#else
+#define EXTERN
+#endif
+
+enum output_style {
+ /* Default output style. */
+ OUTPUT_NORMAL,
+ /* Output the differences with lines of context before and after (-c). */
+ OUTPUT_CONTEXT,
+ /* Output the differences in a unified context diff format (-u). */
+ OUTPUT_UNIFIED,
+ /* Output the differences as commands suitable for `ed' (-e). */
+ OUTPUT_ED,
+ /* Output the diff as a forward ed script (-f). */
+ OUTPUT_FORWARD_ED,
+ /* Like -f, but output a count of changed lines in each "command" (-n). */
+ OUTPUT_RCS,
+ /* Output merged #ifdef'd file (-D). */
+ OUTPUT_IFDEF,
+ /* Output sdiff style (-y). */
+ OUTPUT_SDIFF
+};
+
+/* True for output styles that are robust,
+ i.e. can handle a file that ends in a non-newline. */
+#define ROBUST_OUTPUT_STYLE(S) ((S) != OUTPUT_ED && (S) != OUTPUT_FORWARD_ED)
+
+EXTERN enum output_style output_style;
+
+/* Nonzero if output cannot be generated for identical files. */
+EXTERN int no_diff_means_no_output;
+
+/* Number of lines of context to show in each set of diffs.
+ This is zero when context is not to be shown. */
+EXTERN int context;
+
+/* Consider all files as text files (-a).
+ Don't interpret codes over 0177 as implying a "binary file". */
+EXTERN int always_text_flag;
+
+/* Number of lines to keep in identical prefix and suffix. */
+EXTERN int horizon_lines;
+
+/* Ignore changes in horizontal white space (-b). */
+EXTERN int ignore_space_change_flag;
+
+/* Ignore all horizontal white space (-w). */
+EXTERN int ignore_all_space_flag;
+
+/* Ignore changes that affect only blank lines (-B). */
+EXTERN int ignore_blank_lines_flag;
+
+/* 1 if lines may match even if their contents do not match exactly.
+ This depends on various options. */
+EXTERN int ignore_some_line_changes;
+
+/* 1 if files may match even if their contents are not byte-for-byte identical.
+ This depends on various options. */
+EXTERN int ignore_some_changes;
+
+/* Ignore differences in case of letters (-i). */
+EXTERN int ignore_case_flag;
+
+/* File labels for `-c' output headers (-L). */
+EXTERN char *file_label[2];
+
+struct regexp_list
+{
+ struct re_pattern_buffer buf;
+ struct regexp_list *next;
+};
+
+/* Regexp to identify function-header lines (-F). */
+EXTERN struct regexp_list *function_regexp_list;
+
+/* Ignore changes that affect only lines matching this regexp (-I). */
+EXTERN struct regexp_list *ignore_regexp_list;
+
+/* Say only whether files differ, not how (-q). */
+EXTERN int no_details_flag;
+
+/* Report files compared that match (-s).
+ Normally nothing is output when that happens. */
+EXTERN int print_file_same_flag;
+
+/* Output the differences with exactly 8 columns added to each line
+ so that any tabs in the text line up properly (-T). */
+EXTERN int tab_align_flag;
+
+/* Expand tabs in the output so the text lines up properly
+ despite the characters added to the front of each line (-t). */
+EXTERN int tab_expand_flag;
+
+/* In directory comparison, specify file to start with (-S).
+ All file names less than this name are ignored. */
+EXTERN char *dir_start_file;
+
+/* If a file is new (appears in only one dir)
+ include its entire contents (-N).
+ Then `patch' would create the file with appropriate contents. */
+EXTERN int entire_new_file_flag;
+
+/* If a file is new (appears in only the second dir)
+ include its entire contents (-P).
+ Then `patch' would create the file with appropriate contents. */
+EXTERN int unidirectional_new_file_flag;
+
+/* Pipe each file's output through pr (-l). */
+EXTERN int paginate_flag;
+
+enum line_class {
+ /* Lines taken from just the first file. */
+ OLD,
+ /* Lines taken from just the second file. */
+ NEW,
+ /* Lines common to both files. */
+ UNCHANGED,
+ /* A hunk containing both old and new lines (line groups only). */
+ CHANGED
+};
+
+/* Line group formats for old, new, unchanged, and changed groups. */
+EXTERN char *group_format[CHANGED + 1];