diff options
| author | peter <peter@FreeBSD.org> | 1998-01-26 03:09:57 +0000 |
|---|---|---|
| committer | peter <peter@FreeBSD.org> | 1998-01-26 03:09:57 +0000 |
| commit | e6e45661e44f15cb8c5c6f063080509bd910b98d (patch) | |
| tree | a9812ba7ade0fde6f62c1626b45d522ba104c314 /contrib/cvs | |
| parent | 571cfa0005d94d99d1341bf8ab02be04d4df5f9f (diff) | |
| download | FreeBSD-src-e6e45661e44f15cb8c5c6f063080509bd910b98d.zip FreeBSD-src-e6e45661e44f15cb8c5c6f063080509bd910b98d.tar.gz | |
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.
Diffstat (limited to 'contrib/cvs')
122 files changed, 44690 insertions, 8121 deletions
diff --git a/contrib/cvs/BUGS b/contrib/cvs/BUGS index 6f482b6..58be27c 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 af4807f..6ff5bd1 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 fe8a863..b91b9ba 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 c7fcdd7..20912dd 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 89f7399..a1b3d37 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 5632834..c13948c 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 ba6fb18..9eb0e7b 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 491097e..ff75cfb 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 b2827cf..5e746fe 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 4e20f8b..b46eb2a 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 977ddcb..e6c436b 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 39a38a9..fa9697f 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 7a9a816..cddd580 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 8bbda6f..21c5fe7 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 ce5ee49..a492190 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 660c226..f79a25d 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 2b1b8ec..292958d 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 0c45efa..3db22a5 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 900b0c7..223b759 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 0000000..7d526d8 --- /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 0000000..34aa707 --- /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 0000000..333d4d9 --- /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 0000000..0bda3cf --- /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 0000000..e95a8f9 --- /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 0000000..e3852b7 --- /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 0000000..14f950c --- /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 0000000..8f7242c --- /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 0000000..c0e37d7 --- /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 0000000..fba26a7 --- /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]; + +/* Line formats for old, new, and unchanged lines. */ +EXTERN char *line_format[UNCHANGED + 1]; + +/* If using OUTPUT_SDIFF print extra information to help the sdiff filter. */ +EXTERN int sdiff_help_sdiff; + +/* Tell OUTPUT_SDIFF to show only the left version of common lines. */ +EXTERN int sdiff_left_only; + +/* Tell OUTPUT_SDIFF to not show common lines. */ +EXTERN int sdiff_skip_common_lines; + +/* The half line width and column 2 offset for OUTPUT_SDIFF. */ +EXTERN unsigned sdiff_half_width; +EXTERN unsigned sdiff_column2_offset; + +/* String containing all the command options diff received, + with spaces between and at the beginning but none at the end. + If there were no options given, this string is empty. */ +EXTERN char * switch_string; + +/* Nonzero means use heuristics for better speed. */ +EXTERN int heuristic; + +/* Name of program the user invoked (for error messages). */ +EXTERN char *diff_program_name; + +/* Jump buffer for nonlocal exits. */ +EXTERN jmp_buf diff_abort_buf; +#define DIFF_ABORT(retval) longjmp(diff_abort_buf, retval) + +/* The result of comparison is an "edit script": a chain of `struct change'. + Each `struct change' represents one place where some lines are deleted + and some are inserted. + + 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. */ + +struct change +{ + struct change *link; /* Previous or next edit command */ + int inserted; /* # lines of file 1 changed here. */ + int deleted; /* # lines of file 0 changed here. */ + int line0; /* Line number of 1st deleted line. */ + int line1; /* Line number of 1st inserted line. */ + char ignore; /* Flag used in context.c */ +}; + +/* Structures that describe the input files. */ + +/* Data on one input file being compared. */ + +struct file_data { + int desc; /* File descriptor */ + char const *name; /* File name */ + struct stat stat; /* File status from fstat() */ + int dir_p; /* nonzero if file is a directory */ + + /* Buffer in which text of file is read. */ + char * buffer; + /* Allocated size of buffer. */ + size_t bufsize; + /* Number of valid characters now in the buffer. */ + size_t buffered_chars; + + /* Array of pointers to lines in the file. */ + char const **linbuf; + + /* linbuf_base <= buffered_lines <= valid_lines <= alloc_lines. + linebuf[linbuf_base ... buffered_lines - 1] are possibly differing. + linebuf[linbuf_base ... valid_lines - 1] contain valid data. + linebuf[linbuf_base ... alloc_lines - 1] are allocated. */ + int linbuf_base, buffered_lines, valid_lines, alloc_lines; + + /* Pointer to end of prefix of this file to ignore when hashing. */ + char const *prefix_end; + + /* Count of lines in the prefix. + There are this many lines in the file before linbuf[0]. */ + int prefix_lines; + + /* Pointer to start of suffix of this file to ignore when hashing. */ + char const *suffix_begin; + + /* Vector, indexed by line number, containing an equivalence code for + each line. It is this vector that is actually compared with that + of another file to generate differences. */ + int *equivs; + + /* Vector, like the previous one except that + the elements for discarded lines have been squeezed out. */ + int *undiscarded; + + /* Vector mapping virtual line numbers (not counting discarded lines) + to real ones (counting those lines). Both are origin-0. */ + int *realindexes; + + /* Total number of nondiscarded lines. */ + int nondiscarded_lines; + + /* Vector, indexed by real origin-0 line number, + containing 1 for a line that is an insertion or a deletion. + The results of comparison are stored here. */ + char *changed_flag; + + /* 1 if file ends in a line with no final newline. */ + int missing_newline; + + /* 1 more than the maximum equivalence value used for this or its + sibling file. */ + int equiv_max; +}; + +/* Describe the two files currently being compared. */ + +EXTERN struct file_data files[2]; + +/* Stdio stream to output diffs to. */ + +EXTERN FILE *outfile; + +/* Declare various functions. */ + +/* analyze.c */ +int diff_2_files PARAMS((struct file_data[], int)); + +/* context.c */ +void print_context_header PARAMS((struct file_data[], int)); +void print_context_script PARAMS((struct change *, int)); + +/* diff.c */ +int excluded_filename PARAMS((char const *)); + +/* dir.c */ +int diff_dirs PARAMS((struct file_data const[], int (*) PARAMS((char const *, char const *, char const *, char const *, int)), int)); + +/* ed.c */ +void print_ed_script PARAMS((struct change *)); +void pr_forward_ed_script PARAMS((struct change *)); + +/* ifdef.c */ +void print_ifdef_script PARAMS((struct change *)); + +/* io.c */ +int read_files PARAMS((struct file_data[], int)); +int sip PARAMS((struct file_data *, int)); +void slurp PARAMS((struct file_data *)); + +/* normal.c */ +void print_normal_script PARAMS((struct change *)); + +/* rcs.c */ +void print_rcs_script PARAMS((struct change *)); + +/* side.c */ +void print_sdiff_script PARAMS((struct change *)); + +/* util.c */ +VOID *xmalloc PARAMS((size_t)); +VOID *xrealloc PARAMS((VOID *, size_t)); +char *concat PARAMS((char const *, char const *, char const *)); +char *dir_file_pathname PARAMS((char const *, char const *)); +int change_letter PARAMS((int, int)); +int line_cmp PARAMS((char const *, char const *)); +int translate_line_number PARAMS((struct file_data const *, int)); +struct change *find_change PARAMS((struct change *)); +struct change *find_reverse_change PARAMS((struct change *)); +void analyze_hunk PARAMS((struct change *, int *, int *, int *, int *, int *, int *)); +void begin_output PARAMS((void)); +void debug_script PARAMS((struct change *)); +void diff_error PARAMS((char const *, char const *, char const *)); +void fatal PARAMS((char const *)); +void finish_output PARAMS((void)); +void message PARAMS((char const *, char const *, char const *)); +void message5 PARAMS((char const *, char const *, char const *, char const *, char const *)); +void output_1_line PARAMS((char const *, char const *, char const *, char const *)); +void perror_with_name PARAMS((char const *)); +void pfatal_with_name PARAMS((char const *)); +void print_1_line PARAMS((char const *, char const * const *)); +void print_message_queue PARAMS((void)); +void print_number_range PARAMS((int, struct file_data *, int, int)); +void print_script PARAMS((struct change *, struct change * (*) PARAMS((struct change *)), void (*) PARAMS((struct change *)))); +void setup_output PARAMS((char const *, char const *, int)); +void translate_range PARAMS((struct file_data const *, int, int, int *, int *)); + +/* version.c */ +extern char const diff_version_string[]; diff --git a/contrib/cvs/diff/diff3.c b/contrib/cvs/diff/diff3.c new file mode 100644 index 0000000..533214c --- /dev/null +++ b/contrib/cvs/diff/diff3.c @@ -0,0 +1,1809 @@ +/* Three way file comparison program (diff3) for Project GNU. + Copyright (C) 1988, 1989, 1992, 1993, 1994, 1997 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. */ + +/* Written by Randy Smith */ +/* Librarification by Tim Pierce */ + +#include "system.h" +#include <stdio.h> +#include <setjmp.h> +#include "getopt.h" + +/* diff3.c has a real initialize_main function. */ +#ifdef initialize_main +#undef initialize_main +#endif + +extern char const diff_version_string[]; + +/* + * Internal data structures and macros for the diff3 program; includes + * data structures for both diff3 diffs and normal diffs. + */ + +/* Different files within a three way diff. */ +#define FILE0 0 +#define FILE1 1 +#define FILE2 2 + +/* + * A three way diff is built from two two-way diffs; the file which + * the two two-way diffs share is: + */ +#define FILEC FILE2 + +/* + * Different files within a two way diff. + * FC is the common file, FO the other file. + */ +#define FO 0 +#define FC 1 + +/* The ranges are indexed by */ +#define START 0 +#define END 1 + +enum diff_type { + ERROR, /* Should not be used */ + ADD, /* Two way diff add */ + CHANGE, /* Two way diff change */ + DELETE, /* Two way diff delete */ + DIFF_ALL, /* All three are different */ + DIFF_1ST, /* Only the first is different */ + DIFF_2ND, /* Only the second */ + DIFF_3RD /* Only the third */ +}; + +/* Two way diff */ +struct diff_block { + int ranges[2][2]; /* Ranges are inclusive */ + char **lines[2]; /* The actual lines (may contain nulls) */ + size_t *lengths[2]; /* Line lengths (including newlines, if any) */ + struct diff_block *next; +}; + +/* Three way diff */ + +struct diff3_block { + enum diff_type correspond; /* Type of diff */ + int ranges[3][2]; /* Ranges are inclusive */ + char **lines[3]; /* The actual lines (may contain nulls) */ + size_t *lengths[3]; /* Line lengths (including newlines, if any) */ + struct diff3_block *next; +}; + +/* + * Access the ranges on a diff block. + */ +#define D_LOWLINE(diff, filenum) \ + ((diff)->ranges[filenum][START]) +#define D_HIGHLINE(diff, filenum) \ + ((diff)->ranges[filenum][END]) +#define D_NUMLINES(diff, filenum) \ + (D_HIGHLINE (diff, filenum) - D_LOWLINE (diff, filenum) + 1) + +/* + * Access the line numbers in a file in a diff by relative line + * numbers (i.e. line number within the diff itself). Note that these + * are lvalues and can be used for assignment. + */ +#define D_RELNUM(diff, filenum, linenum) \ + ((diff)->lines[filenum][linenum]) +#define D_RELLEN(diff, filenum, linenum) \ + ((diff)->lengths[filenum][linenum]) + +/* + * And get at them directly, when that should be necessary. + */ +#define D_LINEARRAY(diff, filenum) \ + ((diff)->lines[filenum]) +#define D_LENARRAY(diff, filenum) \ + ((diff)->lengths[filenum]) + +/* + * Next block. + */ +#define D_NEXT(diff) ((diff)->next) + +/* + * Access the type of a diff3 block. + */ +#define D3_TYPE(diff) ((diff)->correspond) + +/* + * Line mappings based on diffs. The first maps off the top of the + * diff, the second off of the bottom. + */ +#define D_HIGH_MAPLINE(diff, fromfile, tofile, lineno) \ + ((lineno) \ + - D_HIGHLINE ((diff), (fromfile)) \ + + D_HIGHLINE ((diff), (tofile))) + +#define D_LOW_MAPLINE(diff, fromfile, tofile, lineno) \ + ((lineno) \ + - D_LOWLINE ((diff), (fromfile)) \ + + D_LOWLINE ((diff), (tofile))) + +/* + * General memory allocation function. + */ +#define ALLOCATE(number, type) \ + (type *) xmalloc ((number) * sizeof (type)) + +/* Options variables for flags set on command line. */ + +/* If nonzero, treat all files as text files, never as binary. */ +static int always_text; + +/* If nonzero, write out an ed script instead of the standard diff3 format. */ +static int edscript; + +/* If nonzero, in the case of overlapping diffs (type DIFF_ALL), + preserve the lines which would normally be deleted from + file 1 with a special flagging mechanism. */ +static int flagging; + +/* Number of lines to keep in identical prefix and suffix. */ +static int horizon_lines = 10; + +/* Use a tab to align output lines (-T). */ +static int tab_align_flag; + +/* If nonzero, do not output information for overlapping diffs. */ +static int simple_only; + +/* If nonzero, do not output information for non-overlapping diffs. */ +static int overlap_only; + +/* If nonzero, show information for DIFF_2ND diffs. */ +static int show_2nd; + +/* If nonzero, include `:wq' at the end of the script + to write out the file being edited. */ +static int finalwrite; + +/* If nonzero, output a merged file. */ +static int merge; + +extern char *diff_program_name; + +static char *read_diff PARAMS((char const *, char const *, char **)); +static char *scan_diff_line PARAMS((char *, char **, size_t *, char *, int)); +static enum diff_type process_diff_control PARAMS((char **, struct diff_block *)); +static int compare_line_list PARAMS((char * const[], size_t const[], char * const[], size_t const[], int)); +static int copy_stringlist PARAMS((char * const[], size_t const[], char *[], size_t[], int)); +static int dotlines PARAMS((FILE *, struct diff3_block *, int)); +static int output_diff3_edscript PARAMS((FILE *, struct diff3_block *, int const[3], int const[3], char const *, char const *, char const *)); +static int output_diff3_merge PARAMS((FILE *, FILE *, struct diff3_block *, int const[3], int const[3], char const *, char const *, char const *)); +static size_t myread PARAMS((int, char *, size_t)); +static struct diff3_block *create_diff3_block PARAMS((int, int, int, int, int, int)); +static struct diff3_block *make_3way_diff PARAMS((struct diff_block *, struct diff_block *)); +static struct diff3_block *reverse_diff3_blocklist PARAMS((struct diff3_block *)); +static struct diff3_block *using_to_diff3_block PARAMS((struct diff_block *[2], struct diff_block *[2], int, int, struct diff3_block const *)); +static struct diff_block *process_diff PARAMS((char const *, char const *, struct diff_block **, char **)); +static void check_output PARAMS((FILE *)); +static void diff3_fatal PARAMS((char const *)); +static void output_diff3 PARAMS((FILE *, struct diff3_block *, int const[3], int const[3])); +static void diff3_perror_with_exit PARAMS((char const *)); +static int try_help PARAMS((char const *)); +static void undotlines PARAMS((FILE *, int, int, int)); +static void usage PARAMS((void)); +static void initialize_main PARAMS((int *, char ***)); +static void free_diff_blocks PARAMS((struct diff_block *)); +static void free_diff3_blocks PARAMS((struct diff3_block *)); + +/* Functions provided in libdiff.a or other external sources. */ +int diff_run PARAMS((int, char **, char *)); +VOID *xmalloc PARAMS((size_t)); +VOID *xrealloc PARAMS((VOID *, size_t)); +void perror_with_name PARAMS((char const *)); +void diff_error PARAMS((char const *, char const *, char const *)); + +/* Permit non-local exits from diff3. */ +static jmp_buf diff3_abort_buf; +#define DIFF3_ABORT(retval) longjmp(diff3_abort_buf, retval) + +static struct option const longopts[] = +{ + {"text", 0, 0, 'a'}, + {"show-all", 0, 0, 'A'}, + {"ed", 0, 0, 'e'}, + {"show-overlap", 0, 0, 'E'}, + {"label", 1, 0, 'L'}, + {"merge", 0, 0, 'm'}, + {"initial-tab", 0, 0, 'T'}, + {"overlap-only", 0, 0, 'x'}, + {"easy-only", 0, 0, '3'}, + {"version", 0, 0, 'v'}, + {"help", 0, 0, 129}, + {0, 0, 0, 0} +}; + +/* + * Main program. Calls diff twice on two pairs of input files, + * combines the two diffs, and outputs them. + */ +int +diff3_run (argc, argv, outfile) + int argc; + char **argv; + char *outfile; +{ + int c, i; + int mapping[3]; + int rev_mapping[3]; + int incompat = 0; + int conflicts_found; + int status; + struct diff_block *thread0, *thread1, *last_block; + char *content0, *content1; + struct diff3_block *diff3; + int tag_count = 0; + char *tag_strings[3]; + char *commonname; + char **file; + struct stat statb; + int optind_old; + FILE *outstream; + + initialize_main (&argc, &argv); + + optind_old = optind; + optind = 0; + while ((c = getopt_long (argc, argv, "aeimvx3AEL:TX", longopts, 0)) != EOF) + { + switch (c) + { + case 'a': + always_text = 1; + break; + case 'A': + show_2nd = 1; + flagging = 1; + incompat++; + break; + case 'x': + overlap_only = 1; + incompat++; + break; + case '3': + simple_only = 1; + incompat++; + break; + case 'i': + finalwrite = 1; + break; + case 'm': + merge = 1; + break; + case 'X': + overlap_only = 1; + /* Falls through */ + case 'E': + flagging = 1; + /* Falls through */ + case 'e': + incompat++; + break; + case 'T': + tab_align_flag = 1; + break; + case 'v': + printf ("diff3 - GNU diffutils version %s\n", diff_version_string); + return 0; + case 129: + usage (); + check_output (stdout); + return 0; + case 'L': + /* Handle up to three -L options. */ + if (tag_count < 3) + { + tag_strings[tag_count++] = optarg; + break; + } + return try_help ("Too many labels were given. The limit is 3."); + default: + return try_help (0); + } + } + + edscript = incompat & ~merge; /* -AeExX3 without -m implies ed script. */ + show_2nd |= ~incompat & merge; /* -m without -AeExX3 implies -A. */ + flagging |= ~incompat & merge; + + if (incompat > 1 /* Ensure at most one of -AeExX3. */ + || finalwrite & merge /* -i -m would rewrite input file. */ + || (tag_count && ! flagging)) /* -L requires one of -AEX. */ + return try_help ("incompatible options"); + + if (argc - optind != 3) + return try_help (argc - optind < 3 ? "missing operand" : "extra operand"); + + file = &argv[optind]; + + optind = optind_old; + + for (i = tag_count; i < 3; i++) + tag_strings[i] = file[i]; + + /* Always compare file1 to file2, even if file2 is "-". + This is needed for -mAeExX3. Using the file0 as + the common file would produce wrong results, because if the + file0-file1 diffs didn't line up with the file0-file2 diffs + (which is entirely possible since we don't use diff's -n option), + diff3 might report phantom changes from file1 to file2. */ + + if (strcmp (file[2], "-") == 0) + { + /* Sigh. We've got standard input as the last arg. We can't + call diff twice on stdin. Use the middle arg as the common + file instead. */ + if (strcmp (file[0], "-") == 0 || strcmp (file[1], "-") == 0) + { + diff_error ("%s", "`-' specified for more than one input file", 0); + return 2; + } + mapping[0] = 0; + mapping[1] = 2; + mapping[2] = 1; + } + else + { + /* Normal, what you'd expect */ + mapping[0] = 0; + mapping[1] = 1; + mapping[2] = 2; + } + + for (i = 0; i < 3; i++) + rev_mapping[mapping[i]] = i; + + for (i = 0; i < 3; i++) + if (strcmp (file[i], "-") != 0) + { + if (stat (file[i], &statb) < 0) + { + perror_with_name (file[i]); + return 2; + } + else if (S_ISDIR(statb.st_mode)) + { + fprintf (stderr, "%s: %s: Is a directory\n", + diff_program_name, file[i]); + return 2; + } + } + + if (outfile == NULL) + outstream = stdout; + else + { + outstream = fopen (outfile, "w"); + if (outstream == 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. */ + status = setjmp (diff3_abort_buf); + if (status != 0) + return status; + + commonname = file[rev_mapping[FILEC]]; + thread1 = process_diff (file[rev_mapping[FILE1]], commonname, &last_block, + &content1); + if (thread1) + for (i = 0; i < 2; i++) + { + horizon_lines = max (horizon_lines, D_NUMLINES (thread1, i)); + horizon_lines = max (horizon_lines, D_NUMLINES (last_block, i)); + } + thread0 = process_diff (file[rev_mapping[FILE0]], commonname, &last_block, + &content0); + diff3 = make_3way_diff (thread0, thread1); + if (edscript) + conflicts_found + = output_diff3_edscript (outstream, diff3, mapping, rev_mapping, + tag_strings[0], tag_strings[1], tag_strings[2]); + else if (merge) + { + if (! freopen (file[rev_mapping[FILE0]], "r", stdin)) + diff3_perror_with_exit (file[rev_mapping[FILE0]]); + conflicts_found + = output_diff3_merge (stdin, outstream, diff3, mapping, rev_mapping, + tag_strings[0], tag_strings[1], tag_strings[2]); + if (ferror (stdin)) + diff3_fatal ("read error"); + } + else + { + output_diff3 (outstream, diff3, mapping, rev_mapping); + conflicts_found = 0; + } + + free(content0); + free(content1); + free_diff_blocks(thread0); + free_diff_blocks(thread1); + free_diff3_blocks(diff3); + + check_output (outstream); + if (outstream != stdout) + if (fclose (outstream) != 0) + perror ("close error on output file"); + return conflicts_found; +} + +static int +try_help (reason) + char const *reason; +{ + if (reason) + fprintf (stderr, "%s: %s\n", diff_program_name, reason); + fprintf (stderr, "%s: Try `%s --help' for more information.\n", + diff_program_name, diff_program_name); + return 2; +} + +static void +check_output (stream) + FILE *stream; +{ + if (ferror (stream) || fflush (stream) != 0) + diff3_fatal ("write error"); +} + +/* + * Explain, patiently and kindly, how to use this program. + */ +static void +usage () +{ + printf ("Usage: %s [OPTION]... MYFILE OLDFILE YOURFILE\n\n", diff_program_name); + + printf ("%s", "\ + -e --ed Output unmerged changes from OLDFILE to YOURFILE into MYFILE.\n\ + -E --show-overlap Output unmerged changes, bracketing conflicts.\n\ + -A --show-all Output all changes, bracketing conflicts.\n\ + -x --overlap-only Output overlapping changes.\n\ + -X Output overlapping changes, bracketing them.\n\ + -3 --easy-only Output unmerged nonoverlapping changes.\n\n"); + printf ("%s", "\ + -m --merge Output merged file instead of ed script (default -A).\n\ + -L LABEL --label=LABEL Use LABEL instead of file name.\n\ + -i Append `w' and `q' commands to ed scripts.\n\ + -a --text Treat all files as text.\n\ + -T --initial-tab Make tabs line up by prepending a tab.\n\n"); + printf ("%s", "\ + -v --version Output version info.\n\ + --help Output this help.\n\n"); + printf ("If a FILE is `-', read standard input.\n"); +} + +/* + * Routines that combine the two diffs together into one. The + * algorithm used follows: + * + * File2 is shared in common between the two diffs. + * Diff02 is the diff between 0 and 2. + * Diff12 is the diff between 1 and 2. + * + * 1) Find the range for the first block in File2. + * a) Take the lowest of the two ranges (in File2) in the two + * current blocks (one from each diff) as being the low + * water mark. Assign the upper end of this block as + * being the high water mark and move the current block up + * one. Mark the block just moved over as to be used. + * b) Check the next block in the diff that the high water + * mark is *not* from. + * + * *If* the high water mark is above + * the low end of the range in that block, + * + * mark that block as to be used and move the current + * block up. Set the high water mark to the max of + * the high end of this block and the current. Repeat b. + * + * 2) Find the corresponding ranges in File0 (from the blocks + * in diff02; line per line outside of diffs) and in File1. + * Create a diff3_block, reserving space as indicated by the ranges. + * + * 3) Copy all of the pointers for file2 in. At least for now, + * do memcmp's between corresponding strings in the two diffs. + * + * 4) Copy all of the pointers for file0 and 1 in. Get what you + * need from file2 (when there isn't a diff block, it's + * identical to file2 within the range between diff blocks). + * + * 5) If the diff blocks you used came from only one of the two + * strings of diffs, then that file (i.e. the one other than + * the common file in that diff) is the odd person out. If you used + * diff blocks from both sets, check to see if files 0 and 1 match: + * + * Same number of lines? If so, do a set of memcmp's (if a + * memcmp matches; copy the pointer over; it'll be easier later + * if you have to do any compares). If they match, 0 & 1 are + * the same. If not, all three different. + * + * Then you do it again, until you run out of blocks. + * + */ + +/* + * This routine makes a three way diff (chain of diff3_block's) from two + * two way diffs (chains of diff_block's). It is assumed that each of + * the two diffs passed are onto the same file (i.e. that each of the + * diffs were made "to" the same file). The three way diff pointer + * returned will have numbering FILE0--the other file in diff02, + * FILE1--the other file in diff12, and FILEC--the common file. + */ +static struct diff3_block * +make_3way_diff (thread0, thread1) + struct diff_block *thread0, *thread1; +{ +/* + * This routine works on the two diffs passed to it as threads. + * Thread number 0 is diff02, thread number 1 is diff12. The USING + * array is set to the base of the list of blocks to be used to + * construct each block of the three way diff; if no blocks from a + * particular thread are to be used, that element of the using array + * is set to 0. The elements LAST_USING array are set to the last + * elements on each of the using lists. + * + * The HIGH_WATER_MARK is set to the highest line number in the common file + * described in any of the diffs in either of the USING lists. The + * HIGH_WATER_THREAD names the thread. Similarly the BASE_WATER_MARK + * and BASE_WATER_THREAD describe the lowest line number in the common file + * described in any of the diffs in either of the USING lists. The + * HIGH_WATER_DIFF is the diff from which the HIGH_WATER_MARK was + * taken. + * + * The HIGH_WATER_DIFF should always be equal to LAST_USING + * [HIGH_WATER_THREAD]. The OTHER_DIFF is the next diff to check for + * higher water, and should always be equal to + * CURRENT[HIGH_WATER_THREAD ^ 0x1]. The OTHER_THREAD is the thread + * in which the OTHER_DIFF is, and hence should always be equal to + * HIGH_WATER_THREAD ^ 0x1. + * + * The variable LAST_DIFF is kept set to the last diff block produced + * by this routine, for line correspondence purposes between that diff + * and the one currently being worked on. It is initialized to + * ZERO_DIFF before any blocks have been created. + */ + + struct diff_block + *using[2], + *last_using[2], + *current[2]; + + int + high_water_mark; + + int + high_water_thread, + base_water_thread, + other_thread; + + struct diff_block + *high_water_diff, + *other_diff; + + struct diff3_block + *result, + *tmpblock, + **result_end; + + struct diff3_block const *last_diff3; + + static struct diff3_block const zero_diff3; + + /* Initialization */ + result = 0; + result_end = &result; + current[0] = thread0; current[1] = thread1; + last_diff3 = &zero_diff3; + + /* Sniff up the threads until we reach the end */ + + while (current[0] || current[1]) + { + using[0] = using[1] = last_using[0] = last_using[1] = 0; + + /* Setup low and high water threads, diffs, and marks. */ + if (!current[0]) + base_water_thread = 1; + else if (!current[1]) + base_water_thread = 0; + else + base_water_thread = + (D_LOWLINE (current[0], FC) > D_LOWLINE (current[1], FC)); + + high_water_thread = base_water_thread; + + high_water_diff = current[high_water_thread]; + +#if 0 + /* low and high waters start off same diff */ + base_water_mark = D_LOWLINE (high_water_diff, FC); +#endif + + high_water_mark = D_HIGHLINE (high_water_diff, FC); + + /* Make the diff you just got info from into the using class */ + using[high_water_thread] + = last_using[high_water_thread] + = high_water_diff; + current[high_water_thread] = high_water_diff->next; + last_using[high_water_thread]->next = 0; + + /* And mark the other diff */ + other_thread = high_water_thread ^ 0x1; + other_diff = current[other_thread]; + + /* Shuffle up the ladder, checking the other diff to see if it + needs to be incorporated. */ + while (other_diff + && D_LOWLINE (other_diff, FC) <= high_water_mark + 1) + { + + /* Incorporate this diff into the using list. Note that + this doesn't take it off the current list */ + if (using[other_thread]) + last_using[other_thread]->next = other_diff; + else + using[other_thread] = other_diff; + last_using[other_thread] = other_diff; + + /* Take it off the current list. Note that this following + code assumes that other_diff enters it equal to + current[high_water_thread ^ 0x1] */ + current[other_thread] = current[other_thread]->next; + other_diff->next = 0; + + /* Set the high_water stuff + If this comparison is equal, then this is the last pass + through this loop; since diff blocks within a given + thread cannot overlap, the high_water_mark will be + *below* the range_start of either of the next diffs. */ + + if (high_water_mark < D_HIGHLINE (other_diff, FC)) + { + high_water_thread ^= 1; + high_water_diff = other_diff; + high_water_mark = D_HIGHLINE (other_diff, FC); + } + + /* Set the other diff */ + other_thread = high_water_thread ^ 0x1; + other_diff = current[other_thread]; + } + + /* The using lists contain a list of all of the blocks to be + included in this diff3_block. Create it. */ + + tmpblock = using_to_diff3_block (using, last_using, + base_water_thread, high_water_thread, + last_diff3); + + if (!tmpblock) + diff3_fatal ("internal error: screwup in format of diff blocks"); + + /* Put it on the list. */ + *result_end = tmpblock; + result_end = &tmpblock->next; + + /* Set up corresponding lines correctly. */ + last_diff3 = tmpblock; + } + return result; +} + +/* + * using_to_diff3_block: + * This routine takes two lists of blocks (from two separate diff + * threads) and puts them together into one diff3 block. + * It then returns a pointer to this diff3 block or 0 for failure. + * + * All arguments besides using are for the convenience of the routine; + * they could be derived from the using array. + * LAST_USING is a pair of pointers to the last blocks in the using + * structure. + * LOW_THREAD and HIGH_THREAD tell which threads contain the lowest + * and highest line numbers for File0. + * last_diff3 contains the last diff produced in the calling routine. + * This is used for lines mappings which would still be identical to + * the state that diff ended in. + * + * A distinction should be made in this routine between the two diffs + * that are part of a normal two diff block, and the three diffs that + * are part of a diff3_block. + */ +static struct diff3_block * +using_to_diff3_block (using, last_using, low_thread, high_thread, last_diff3) + struct diff_block + *using[2], + *last_using[2]; + int low_thread, high_thread; + struct diff3_block const *last_diff3; +{ + int low[2], high[2]; + struct diff3_block *result; + struct diff_block *ptr; + int d, i; + + /* Find the range in the common file. */ + int lowc = D_LOWLINE (using[low_thread], FC); + int highc = D_HIGHLINE (last_using[high_thread], FC); + + /* Find the ranges in the other files. + If using[d] is null, that means that the file to which that diff + refers is equivalent to the common file over this range. */ + + for (d = 0; d < 2; d++) + if (using[d]) + { + low[d] = D_LOW_MAPLINE (using[d], FC, FO, lowc); + high[d] = D_HIGH_MAPLINE (last_using[d], FC, FO, highc); + } + else + { + low[d] = D_HIGH_MAPLINE (last_diff3, FILEC, FILE0 + d, lowc); + high[d] = D_HIGH_MAPLINE (last_diff3, FILEC, FILE0 + d, highc); + } + + /* Create a block with the appropriate sizes */ + result = create_diff3_block (low[0], high[0], low[1], high[1], lowc, highc); + + /* Copy information for the common file. + Return with a zero if any of the compares failed. */ + + for (d = 0; d < 2; d++) + for (ptr = using[d]; ptr; ptr = D_NEXT (ptr)) + { + int result_offset = D_LOWLINE (ptr, FC) - lowc; + + if (!copy_stringlist (D_LINEARRAY (ptr, FC), + D_LENARRAY (ptr, FC), + D_LINEARRAY (result, FILEC) + result_offset, + D_LENARRAY (result, FILEC) + result_offset, + D_NUMLINES (ptr, FC))) + return 0; + } + + /* Copy information for file d. First deal with anything that might be + before the first diff. */ + + for (d = 0; d < 2; d++) + { + struct diff_block *u = using[d]; + int lo = low[d], hi = high[d]; + + for (i = 0; + i + lo < (u ? D_LOWLINE (u, FO) : hi + 1); + i++) + { + D_RELNUM (result, FILE0 + d, i) = D_RELNUM (result, FILEC, i); + D_RELLEN (result, FILE0 + d, i) = D_RELLEN (result, FILEC, i); + } + + for (ptr = u; ptr; ptr = D_NEXT (ptr)) + { + int result_offset = D_LOWLINE (ptr, FO) - lo; + int linec; + + if (!copy_stringlist (D_LINEARRAY (ptr, FO), + D_LENARRAY (ptr, FO), + D_LINEARRAY (result, FILE0 + d) + result_offset, + D_LENARRAY (result, FILE0 + d) + result_offset, + D_NUMLINES (ptr, FO))) + return 0; + + /* Catch the lines between here and the next diff */ + linec = D_HIGHLINE (ptr, FC) + 1 - lowc; + for (i = D_HIGHLINE (ptr, FO) + 1 - lo; + i < (D_NEXT (ptr) ? D_LOWLINE (D_NEXT (ptr), FO) : hi + 1) - lo; + i++) + { + D_RELNUM (result, FILE0 + d, i) = D_RELNUM (result, FILEC, linec); + D_RELLEN (result, FILE0 + d, i) = D_RELLEN (result, FILEC, linec); + linec++; + } + } + } + + /* Set correspond */ + if (!using[0]) + D3_TYPE (result) = DIFF_2ND; + else if (!using[1]) + D3_TYPE (result) = DIFF_1ST; + else + { + int nl0 = D_NUMLINES (result, FILE0); + int nl1 = D_NUMLINES (result, FILE1); + + if (nl0 != nl1 + || !compare_line_list (D_LINEARRAY (result, FILE0), + D_LENARRAY (result, FILE0), + D_LINEARRAY (result, FILE1), + D_LENARRAY (result, FILE1), + nl0)) + D3_TYPE (result) = DIFF_ALL; + else + D3_TYPE (result) = DIFF_3RD; + } + + return result; +} + +/* + * This routine copies pointers from a list of strings to a different list + * of strings. If a spot in the second list is already filled, it + * makes sure that it is filled with the same string; if not it + * returns 0, the copy incomplete. + * Upon successful completion of the copy, it returns 1. + */ +static int +copy_stringlist (fromptrs, fromlengths, toptrs, tolengths, copynum) + char * const fromptrs[]; + char *toptrs[]; + size_t const fromlengths[]; + size_t tolengths[]; + int copynum; +{ + register char * const *f = fromptrs; + register char **t = toptrs; + register size_t const *fl = fromlengths; + register size_t *tl = tolengths; + + while (copynum--) + { + if (*t) + { if (*fl != *tl || memcmp (*f, *t, *fl)) return 0; } + else + { *t = *f ; *tl = *fl; } + + t++; f++; tl++; fl++; + } + return 1; +} + +/* + * Create a diff3_block, with ranges as specified in the arguments. + * Allocate the arrays for the various pointers (and zero them) based + * on the arguments passed. Return the block as a result. + */ +static struct diff3_block * +create_diff3_block (low0, high0, low1, high1, low2, high2) + register int low0, high0, low1, high1, low2, high2; +{ + struct diff3_block *result = ALLOCATE (1, struct diff3_block); + int numlines; + + D3_TYPE (result) = ERROR; + D_NEXT (result) = 0; + + /* Assign ranges */ + D_LOWLINE (result, FILE0) = low0; + D_HIGHLINE (result, FILE0) = high0; + D_LOWLINE (result, FILE1) = low1; + D_HIGHLINE (result, FILE1) = high1; + D_LOWLINE (result, FILE2) = low2; + D_HIGHLINE (result, FILE2) = high2; + + /* Allocate and zero space */ + numlines = D_NUMLINES (result, FILE0); + if (numlines) + { + D_LINEARRAY (result, FILE0) = ALLOCATE (numlines, char *); + D_LENARRAY (result, FILE0) = ALLOCATE (numlines, size_t); + bzero (D_LINEARRAY (result, FILE0), (numlines * sizeof (char *))); + bzero (D_LENARRAY (result, FILE0), (numlines * sizeof (size_t))); + } + else + { + D_LINEARRAY (result, FILE0) = 0; + D_LENARRAY (result, FILE0) = 0; + } + + numlines = D_NUMLINES (result, FILE1); + if (numlines) + { + D_LINEARRAY (result, FILE1) = ALLOCATE (numlines, char *); + D_LENARRAY (result, FILE1) = ALLOCATE (numlines, size_t); + bzero (D_LINEARRAY (result, FILE1), (numlines * sizeof (char *))); + bzero (D_LENARRAY (result, FILE1), (numlines * sizeof (size_t))); + } + else + { + D_LINEARRAY (result, FILE1) = 0; + D_LENARRAY (result, FILE1) = 0; + } + + numlines = D_NUMLINES (result, FILE2); + if (numlines) + { + D_LINEARRAY (result, FILE2) = ALLOCATE (numlines, char *); + D_LENARRAY (result, FILE2) = ALLOCATE (numlines, size_t); + bzero (D_LINEARRAY (result, FILE2), (numlines * sizeof (char *))); + bzero (D_LENARRAY (result, FILE2), (numlines * sizeof (size_t))); + } + else + { + D_LINEARRAY (result, FILE2) = 0; + D_LENARRAY (result, FILE2) = 0; + } + + /* Return */ + return result; +} + +/* + * Compare two lists of lines of text. + * Return 1 if they are equivalent, 0 if not. + */ +static int +compare_line_list (list1, lengths1, list2, lengths2, nl) + char * const list1[], * const list2[]; + size_t const lengths1[], lengths2[]; + int nl; +{ + char + * const *l1 = list1, + * const *l2 = list2; + size_t const + *lgths1 = lengths1, + *lgths2 = lengths2; + + while (nl--) + if (!*l1 || !*l2 || *lgths1 != *lgths2++ + || memcmp (*l1++, *l2++, *lgths1++)) + return 0; + return 1; +} + +/* + * Routines to input and parse two way diffs. + */ + +extern char **environ; + +static struct diff_block * +process_diff (filea, fileb, last_block, diff_contents) + char const *filea, *fileb; + struct diff_block **last_block; + char **diff_contents; +{ + char *diff_limit; + char *scan_diff; + enum diff_type dt; + int i; + struct diff_block *block_list, **block_list_end, *bptr; + + diff_limit = read_diff (filea, fileb, diff_contents); + scan_diff = *diff_contents; + block_list_end = &block_list; + bptr = 0; /* Pacify `gcc -W'. */ + + while (scan_diff < diff_limit) + { + bptr = ALLOCATE (1, struct diff_block); + bptr->lines[0] = bptr->lines[1] = 0; + bptr->lengths[0] = bptr->lengths[1] = 0; + + dt = process_diff_control (&scan_diff, bptr); + if (dt == ERROR || *scan_diff != '\n') + { + fprintf (stderr, "%s: diff error: ", diff_program_name); + do + { + putc (*scan_diff, stderr); + } + while (*scan_diff++ != '\n'); + DIFF3_ABORT (2); + } + scan_diff++; + + /* Force appropriate ranges to be null, if necessary */ + switch (dt) + { + case ADD: + bptr->ranges[0][0]++; + break; + case DELETE: + bptr->ranges[1][0]++; + break; + case CHANGE: + break; + default: + diff3_fatal ("internal error: invalid diff type in process_diff"); + break; + } + + /* Allocate space for the pointers for the lines from filea, and + parcel them out among these pointers */ + if (dt != ADD) + { + int numlines = D_NUMLINES (bptr, 0); + bptr->lines[0] = ALLOCATE (numlines, char *); + bptr->lengths[0] = ALLOCATE (numlines, size_t); + for (i = 0; i < numlines; i++) + scan_diff = scan_diff_line (scan_diff, + &(bptr->lines[0][i]), + &(bptr->lengths[0][i]), + diff_limit, + '<'); + } + + /* Get past the separator for changes */ + if (dt == CHANGE) + { + if (strncmp (scan_diff, "---\n", 4)) + diff3_fatal ("invalid diff format; invalid change separator"); + scan_diff += 4; + } + + /* Allocate space for the pointers for the lines from fileb, and + parcel them out among these pointers */ + if (dt != DELETE) + { + int numlines = D_NUMLINES (bptr, 1); + bptr->lines[1] = ALLOCATE (numlines, char *); + bptr->lengths[1] = ALLOCATE (numlines, size_t); + for (i = 0; i < numlines; i++) + scan_diff = scan_diff_line (scan_diff, + &(bptr->lines[1][i]), + &(bptr->lengths[1][i]), + diff_limit, + '>'); + } + + /* Place this block on the blocklist. */ + *block_list_end = bptr; + block_list_end = &bptr->next; + } + + *block_list_end = 0; + *last_block = bptr; + return block_list; +} + +/* + * This routine will parse a normal format diff control string. It + * returns the type of the diff (ERROR if the format is bad). All of + * the other important information is filled into to the structure + * pointed to by db, and the string pointer (whose location is passed + * to this routine) is updated to point beyond the end of the string + * parsed. Note that only the ranges in the diff_block will be set by + * this routine. + * + * If some specific pair of numbers has been reduced to a single + * number, then both corresponding numbers in the diff block are set + * to that number. In general these numbers are interpetted as ranges + * inclusive, unless being used by the ADD or DELETE commands. It is + * assumed that these will be special cased in a superior routine. + */ + +static enum diff_type +process_diff_control (string, db) + char **string; + struct diff_block *db; +{ + char *s = *string; + int holdnum; + enum diff_type type; + +/* These macros are defined here because they can use variables + defined in this function. Don't try this at home kids, we're + trained professionals! + + Also note that SKIPWHITE only recognizes tabs and spaces, and + that READNUM can only read positive, integral numbers */ + +#define SKIPWHITE(s) { while (*s == ' ' || *s == '\t') s++; } +#define READNUM(s, num) \ + { unsigned char c = *s; if (!ISDIGIT (c)) return ERROR; holdnum = 0; \ + do { holdnum = (c - '0' + holdnum * 10); } \ + while (ISDIGIT (c = *++s)); (num) = holdnum; } + + /* Read first set of digits */ + SKIPWHITE (s); + READNUM (s, db->ranges[0][START]); + + /* Was that the only digit? */ + SKIPWHITE (s); + if (*s == ',') + { + /* Get the next digit */ + s++; + READNUM (s, db->ranges[0][END]); + } + else + db->ranges[0][END] = db->ranges[0][START]; + + /* Get the letter */ + SKIPWHITE (s); + switch (*s) + { + case 'a': + type = ADD; + break; + case 'c': + type = CHANGE; + break; + case 'd': + type = DELETE; + break; + default: + return ERROR; /* Bad format */ + } + s++; /* Past letter */ + + /* Read second set of digits */ + SKIPWHITE (s); + READNUM (s, db->ranges[1][START]); + + /* Was that the only digit? */ + SKIPWHITE (s); + if (*s == ',') + { + /* Get the next digit */ + s++; + READNUM (s, db->ranges[1][END]); + SKIPWHITE (s); /* To move to end */ + } + else + db->ranges[1][END] = db->ranges[1][START]; + + *string = s; + return type; +} + +static char * +read_diff (filea, fileb, output_placement) + char const *filea, *fileb; + char **output_placement; +{ + char *diff_result; + size_t bytes, current_chunk_size, total; + int fd, wstatus; + struct stat pipestat; + + /* 302 / 1000 is log10(2.0) rounded up. Subtract 1 for the sign bit; + add 1 for integer division truncation; add 1 more for a minus sign. */ +#define INT_STRLEN_BOUND(type) ((sizeof(type)*CHAR_BIT - 1) * 302 / 1000 + 2) + + char const *argv[7]; + char horizon_arg[17 + INT_STRLEN_BOUND (int)]; + char const **ap; + char *diffout; + + ap = argv; + *ap++ = "diff"; + if (always_text) + *ap++ = "-a"; + sprintf (horizon_arg, "--horizon-lines=%d", horizon_lines); + *ap++ = horizon_arg; + *ap++ = "--"; + *ap++ = filea; + *ap++ = fileb; + *ap = 0; + + diffout = tmpnam(NULL); + wstatus = diff_run (ap - argv, (char **) argv, diffout); + if (wstatus == 2) + diff3_fatal ("subsidiary diff failed"); + + if (-1 == (fd = open (diffout, O_RDONLY))) + diff3_fatal ("could not open temporary diff file"); + + current_chunk_size = 8 * 1024; + if (fstat (fd, &pipestat) == 0) + current_chunk_size = max (current_chunk_size, STAT_BLOCKSIZE (pipestat)); + + diff_result = xmalloc (current_chunk_size); + total = 0; + do { + bytes = myread (fd, + diff_result + total, + current_chunk_size - total); + total += bytes; + if (total == current_chunk_size) + { + if (current_chunk_size < 2 * current_chunk_size) + current_chunk_size = 2 * current_chunk_size; + else if (current_chunk_size < (size_t) -1) + current_chunk_size = (size_t) -1; + else + diff3_fatal ("files are too large to fit into memory"); + diff_result = xrealloc (diff_result, (current_chunk_size *= 2)); + } + } while (bytes); + + if (total != 0 && diff_result[total-1] != '\n') + diff3_fatal ("invalid diff format; incomplete last line"); + + *output_placement = diff_result; + + if (close (fd) != 0) + diff3_perror_with_exit ("pipe close"); + unlink (diffout); + + return diff_result + total; +} + + +/* + * Scan a regular diff line (consisting of > or <, followed by a + * space, followed by text (including nulls) up to a newline. + * + * This next routine began life as a macro and many parameters in it + * are used as call-by-reference values. + */ +static char * +scan_diff_line (scan_ptr, set_start, set_length, limit, leadingchar) + char *scan_ptr, **set_start; + size_t *set_length; + char *limit; + int leadingchar; +{ + char *line_ptr; + + if (!(scan_ptr[0] == leadingchar + && scan_ptr[1] == ' ')) + diff3_fatal ("invalid diff format; incorrect leading line chars"); + + *set_start = line_ptr = scan_ptr + 2; + while (*line_ptr++ != '\n') + ; + + /* Include newline if the original line ended in a newline, + or if an edit script is being generated. + Copy any missing newline message to stderr if an edit script is being + generated, because edit scripts cannot handle missing newlines. + Return the beginning of the next line. */ + *set_length = line_ptr - *set_start; + if (line_ptr < limit && *line_ptr == '\\') + { + if (edscript) + fprintf (stderr, "%s:", diff_program_name); + else + --*set_length; + line_ptr++; + do + { + if (edscript) + putc (*line_ptr, stderr); + } + while (*line_ptr++ != '\n'); + } + + return line_ptr; +} + +/* + * This routine outputs a three way diff passed as a list of + * diff3_block's. + * The argument MAPPING is indexed by external file number (in the + * argument list) and contains the internal file number (from the + * diff passed). This is important because the user expects his + * outputs in terms of the argument list number, and the diff passed + * may have been done slightly differently (if the last argument + * was "-", for example). + * REV_MAPPING is the inverse of MAPPING. + */ +static void +output_diff3 (outputfile, diff, mapping, rev_mapping) + FILE *outputfile; + struct diff3_block *diff; + int const mapping[3], rev_mapping[3]; +{ + int i; + int oddoneout; + char *cp; + struct diff3_block *ptr; + int line; + size_t length; + int dontprint; + static int skew_increment[3] = { 2, 3, 1 }; /* 0==>2==>1==>3 */ + char const *line_prefix = tab_align_flag ? "\t" : " "; + + for (ptr = diff; ptr; ptr = D_NEXT (ptr)) + { + char x[2]; + + switch (ptr->correspond) + { + case DIFF_ALL: + x[0] = '\0'; + dontprint = 3; /* Print them all */ + oddoneout = 3; /* Nobody's odder than anyone else */ + break; + case DIFF_1ST: + case DIFF_2ND: + case DIFF_3RD: + oddoneout = rev_mapping[(int) ptr->correspond - (int) DIFF_1ST]; + + x[0] = oddoneout + '1'; + x[1] = '\0'; + dontprint = oddoneout==0; + break; + default: + diff3_fatal ("internal error: invalid diff type passed to output"); + } + fprintf (outputfile, "====%s\n", x); + + /* Go 0, 2, 1 if the first and third outputs are equivalent. */ + for (i = 0; i < 3; + i = (oddoneout == 1 ? skew_increment[i] : i + 1)) + { + int realfile = mapping[i]; + int + lowt = D_LOWLINE (ptr, realfile), + hight = D_HIGHLINE (ptr, realfile); + + fprintf (outputfile, "%d:", i + 1); + switch (lowt - hight) + { + case 1: + fprintf (outputfile, "%da\n", lowt - 1); + break; + case 0: + fprintf (outputfile, "%dc\n", lowt); + break; + default: + fprintf (outputfile, "%d,%dc\n", lowt, hight); + break; + } + + if (i == dontprint) continue; + + if (lowt <= hight) + { + line = 0; + do + { + fprintf (outputfile, line_prefix); + cp = D_RELNUM (ptr, realfile, line); + length = D_RELLEN (ptr, realfile, line); + fwrite (cp, sizeof (char), length, outputfile); + } + while (++line < hight - lowt + 1); + if (cp[length - 1] != '\n') + fprintf (outputfile, "\n\\ No newline at end of file\n"); + } + } + } +} + + +/* + * Output to OUTPUTFILE the lines of B taken from FILENUM. + * Double any initial '.'s; yield nonzero if any initial '.'s were doubled. + */ +static int +dotlines (outputfile, b, filenum) + FILE *outputfile; + struct diff3_block *b; + int filenum; +{ + int i; + int leading_dot = 0; + + for (i = 0; + i < D_NUMLINES (b, filenum); + i++) + { + char *line = D_RELNUM (b, filenum, i); + if (line[0] == '.') + { + leading_dot = 1; + fprintf (outputfile, "."); + } + fwrite (line, sizeof (char), + D_RELLEN (b, filenum, i), outputfile); + } + + return leading_dot; +} + +/* + * Output to OUTPUTFILE a '.' line. If LEADING_DOT is nonzero, + * also output a command that removes initial '.'s + * starting with line START and continuing for NUM lines. + */ +static void +undotlines (outputfile, leading_dot, start, num) + FILE *outputfile; + int leading_dot, start, num; +{ + fprintf (outputfile, ".\n"); + if (leading_dot) + if (num == 1) + fprintf (outputfile, "%ds/^\\.//\n", start); + else + fprintf (outputfile, "%d,%ds/^\\.//\n", start, start + num - 1); +} + +/* + * This routine outputs a diff3 set of blocks as an ed script. This + * script applies the changes between file's 2 & 3 to file 1. It + * takes the precise format of the ed script to be output from global + * variables set during options processing. Note that it does + * destructive things to the set of diff3 blocks it is passed; it + * reverses their order (this gets around the problems involved with + * changing line numbers in an ed script). + * + * Note that this routine has the same problem of mapping as the last + * one did; the variable MAPPING maps from file number according to + * the argument list to file number according to the diff passed. All + * files listed below are in terms of the argument list. + * REV_MAPPING is the inverse of MAPPING. + * + * The arguments FILE0, FILE1 and FILE2 are the strings to print + * as the names of the three files. These may be the actual names, + * or may be the arguments specified with -L. + * + * Returns 1 if conflicts were found. + */ + +static int +output_diff3_edscript (outputfile, diff, mapping, rev_mapping, + file0, file1, file2) + FILE *outputfile; + struct diff3_block *diff; + int const mapping[3], rev_mapping[3]; + char const *file0, *file1, *file2; +{ + int leading_dot; + int conflicts_found = 0, conflict; + struct diff3_block *b; + + for (b = reverse_diff3_blocklist (diff); b; b = b->next) + { + /* Must do mapping correctly. */ + enum diff_type type + = ((b->correspond == DIFF_ALL) ? + DIFF_ALL : + ((enum diff_type) + (((int) DIFF_1ST) + + rev_mapping[(int) b->correspond - (int) DIFF_1ST]))); + + /* If we aren't supposed to do this output block, skip it. */ + switch (type) + { + default: continue; + case DIFF_2ND: if (!show_2nd) continue; conflict = 1; break; + case DIFF_3RD: if (overlap_only) continue; conflict = 0; break; + case DIFF_ALL: if (simple_only) continue; conflict = flagging; break; + } + + if (conflict) + { + conflicts_found = 1; + + + /* Mark end of conflict. */ + + fprintf (outputfile, "%da\n", D_HIGHLINE (b, mapping[FILE0])); + leading_dot = 0; + if (type == DIFF_ALL) + { + if (show_2nd) + { + /* Append lines from FILE1. */ + fprintf (outputfile, "||||||| %s\n", file1); + leading_dot = dotlines (outputfile, b, mapping[FILE1]); + } + /* Append lines from FILE2. */ + fprintf (outputfile, "=======\n"); + leading_dot |= dotlines (outputfile, b, mapping[FILE2]); + } + fprintf (outputfile, ">>>>>>> %s\n", file2); + undotlines (outputfile, leading_dot, + D_HIGHLINE (b, mapping[FILE0]) + 2, + (D_NUMLINES (b, mapping[FILE1]) + + D_NUMLINES (b, mapping[FILE2]) + 1)); + + + /* Mark start of conflict. */ + + fprintf (outputfile, "%da\n<<<<<<< %s\n", + D_LOWLINE (b, mapping[FILE0]) - 1, + type == DIFF_ALL ? file0 : file1); + leading_dot = 0; + if (type == DIFF_2ND) + { + /* Prepend lines from FILE1. */ + leading_dot = dotlines (outputfile, b, mapping[FILE1]); + fprintf (outputfile, "=======\n"); + } + undotlines (outputfile, leading_dot, + D_LOWLINE (b, mapping[FILE0]) + 1, + D_NUMLINES (b, mapping[FILE1])); + } + else if (D_NUMLINES (b, mapping[FILE2]) == 0) + /* Write out a delete */ + { + if (D_NUMLINES (b, mapping[FILE0]) == 1) + fprintf (outputfile, "%dd\n", + D_LOWLINE (b, mapping[FILE0])); + else + fprintf (outputfile, "%d,%dd\n", + D_LOWLINE (b, mapping[FILE0]), + D_HIGHLINE (b, mapping[FILE0])); + } + else + /* Write out an add or change */ + { + switch (D_NUMLINES (b, mapping[FILE0])) + { + case 0: + fprintf (outputfile, "%da\n", + D_HIGHLINE (b, mapping[FILE0])); + break; + case 1: + fprintf (outputfile, "%dc\n", + D_HIGHLINE (b, mapping[FILE0])); + break; + default: + fprintf (outputfile, "%d,%dc\n", + D_LOWLINE (b, mapping[FILE0]), + D_HIGHLINE (b, mapping[FILE0])); + break; + } + + undotlines (outputfile, dotlines (outputfile, b, mapping[FILE2]), + D_LOWLINE (b, mapping[FILE0]), + D_NUMLINES (b, mapping[FILE2])); + } + } + if (finalwrite) fprintf (outputfile, "w\nq\n"); + return conflicts_found; +} + +/* + * Read from INFILE and output to OUTPUTFILE a set of diff3_ blocks DIFF + * as a merged file. This acts like 'ed file0 <[output_diff3_edscript]', + * except that it works even for binary data or incomplete lines. + * + * As before, MAPPING maps from arg list file number to diff file number, + * REV_MAPPING is its inverse, + * and FILE0, FILE1, and FILE2 are the names of the files. + * + * Returns 1 if conflicts were found. + */ + +static int +output_diff3_merge (infile, outputfile, diff, mapping, rev_mapping, + file0, file1, file2) + FILE *infile, *outputfile; + struct diff3_block *diff; + int const mapping[3], rev_mapping[3]; + char const *file0, *file1, *file2; +{ + int c, i; + int conflicts_found = 0, conflict; + struct diff3_block *b; + int linesread = 0; + + for (b = diff; b; b = b->next) + { + /* Must do mapping correctly. */ + enum diff_type type + = ((b->correspond == DIFF_ALL) ? + DIFF_ALL : + ((enum diff_type) + (((int) DIFF_1ST) + + rev_mapping[(int) b->correspond - (int) DIFF_1ST]))); + char const *format_2nd = "<<<<<<< %s\n"; + + /* If we aren't supposed to do this output block, skip it. */ + switch (type) + { + default: continue; + case DIFF_2ND: if (!show_2nd) continue; conflict = 1; break; + case DIFF_3RD: if (overlap_only) continue; conflict = 0; break; + case DIFF_ALL: if (simple_only) continue; conflict = flagging; + format_2nd = "||||||| %s\n"; + break; + } + + /* Copy I lines from file 0. */ + i = D_LOWLINE (b, FILE0) - linesread - 1; + linesread += i; + while (0 <= --i) + do + { + c = getc (infile); + if (c == EOF) + if (ferror (infile)) + diff3_perror_with_exit ("input file"); + else if (feof (infile)) + diff3_fatal ("input file shrank"); + putc (c, outputfile); + } + while (c != '\n'); + + if (conflict) + { + conflicts_found = 1; + + if (type == DIFF_ALL) + { + /* Put in lines from FILE0 with bracket. */ + fprintf (outputfile, "<<<<<<< %s\n", file0); + for (i = 0; + i < D_NUMLINES (b, mapping[FILE0]); + i++) + fwrite (D_RELNUM (b, mapping[FILE0], i), sizeof (char), + D_RELLEN (b, mapping[FILE0], i), outputfile); + } + + if (show_2nd) + { + /* Put in lines from FILE1 with bracket. */ + fprintf (outputfile, format_2nd, file1); + for (i = 0; + i < D_NUMLINES (b, mapping[FILE1]); + i++) + fwrite (D_RELNUM (b, mapping[FILE1], i), sizeof (char), + D_RELLEN (b, mapping[FILE1], i), outputfile); + } + + fprintf (outputfile, "=======\n"); + } + + /* Put in lines from FILE2. */ + for (i = 0; + i < D_NUMLINES (b, mapping[FILE2]); + i++) + fwrite (D_RELNUM (b, mapping[FILE2], i), sizeof (char), + D_RELLEN (b, mapping[FILE2], i), outputfile); + + if (conflict) + fprintf (outputfile, ">>>>>>> %s\n", file2); + + /* Skip I lines in file 0. */ + i = D_NUMLINES (b, FILE0); + linesread += i; + while (0 <= --i) + while ((c = getc (infile)) != '\n') + if (c == EOF) + if (ferror (infile)) + diff3_perror_with_exit ("input file"); + else if (feof (infile)) + { + if (i || b->next) + diff3_fatal ("input file shrank"); + return conflicts_found; + } + } + /* Copy rest of common file. */ + while ((c = getc (infile)) != EOF || !(ferror (infile) | feof (infile))) + putc (c, outputfile); + return conflicts_found; +} + +/* + * Reverse the order of the list of diff3 blocks. + */ +static struct diff3_block * +reverse_diff3_blocklist (diff) + struct diff3_block *diff; +{ + register struct diff3_block *tmp, *next, *prev; + + for (tmp = diff, prev = 0; tmp; tmp = next) + { + next = tmp->next; + tmp->next = prev; + prev = tmp; + } + + return prev; +} + +static size_t +myread (fd, ptr, size) + int fd; + char *ptr; + size_t size; +{ + size_t result = read (fd, ptr, size); + if (result == -1) + diff3_perror_with_exit ("read failed"); + return result; +} + +static void +diff3_fatal (string) + char const *string; +{ + fprintf (stderr, "%s: %s\n", diff_program_name, string); + DIFF3_ABORT (2); +} + +static void +diff3_perror_with_exit (string) + char const *string; +{ + int e = errno; + fprintf (stderr, "%s: ", diff_program_name); + errno = e; + perror (string); + DIFF3_ABORT (2); +} + +static void +initialize_main (argcp, argvp) + int *argcp; + char ***argvp; +{ + always_text = 0; + edscript = 0; + flagging = 0; + horizon_lines = 10; + tab_align_flag = 0; + simple_only = 0; + overlap_only = 0; + show_2nd = 0; + finalwrite = 0; + merge = 0; + diff_program_name = (*argvp)[0]; +} + +static void +free_diff_blocks(p) + struct diff_block *p; +{ + register struct diff_block *next; + + while (p) + { + next = p->next; + if (p->lines[0]) free(p->lines[0]); + if (p->lines[1]) free(p->lines[1]); + if (p->lengths[0]) free(p->lengths[0]); + if (p->lengths[1]) free(p->lengths[1]); + free(p); + p = next; + } +} + +static void +free_diff3_blocks(p) + struct diff3_block *p; +{ + register struct diff3_block *next; + + while (p) + { + next = p->next; + if (p->lines[0]) free(p->lines[0]); + if (p->lines[1]) free(p->lines[1]); + if (p->lines[2]) free(p->lines[2]); + if (p->lengths[0]) free(p->lengths[0]); + if (p->lengths[1]) free(p->lengths[1]); + if (p->lengths[2]) free(p->lengths[2]); + free(p); + p = next; + } +} diff --git a/contrib/cvs/diff/dir.c b/contrib/cvs/diff/dir.c new file mode 100644 index 0000000..6eef9a6 --- /dev/null +++ b/contrib/cvs/diff/dir.c @@ -0,0 +1,220 @@ +/* Read, sort and compare two directories. Used for GNU DIFF. + Copyright (C) 1988, 1989, 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" + +/* Read the directory named by DIR and store into DIRDATA a sorted vector + of filenames for its contents. DIR->desc == -1 means this directory is + known to be nonexistent, so set DIRDATA to an empty vector. + Return -1 (setting errno) if error, 0 otherwise. */ + +struct dirdata +{ + char const **names; /* Sorted names of files in dir, 0-terminated. */ + char *data; /* Allocated storage for file names. */ +}; + +static int compare_names PARAMS((void const *, void const *)); +static int dir_sort PARAMS((struct file_data const *, struct dirdata *)); + +#ifdef _WIN32 +#define CLOSEDIR_VOID 1 +#endif + +static int +dir_sort (dir, dirdata) + struct file_data const *dir; + struct dirdata *dirdata; +{ + register struct dirent *next; + register int i; + + /* Address of block containing the files that are described. */ + char const **names; + + /* Number of files in directory. */ + size_t nnames; + + /* Allocated and used storage for file name data. */ + char *data; + size_t data_alloc, data_used; + + dirdata->names = 0; + dirdata->data = 0; + nnames = 0; + data = 0; + + if (dir->desc != -1) + { + /* Open the directory and check for errors. */ + register DIR *reading = opendir (dir->name); + if (!reading) + return -1; + + /* Initialize the table of filenames. */ + + data_alloc = max (1, (size_t) dir->stat.st_size); + data_used = 0; + dirdata->data = data = xmalloc (data_alloc); + + /* Read the directory entries, and insert the subfiles + into the `data' table. */ + + while ((errno = 0, (next = readdir (reading)) != 0)) + { + char *d_name = next->d_name; + size_t d_size = NAMLEN (next) + 1; + + /* Ignore the files `.' and `..' */ + if (d_name[0] == '.' + && (d_name[1] == 0 || (d_name[1] == '.' && d_name[2] == 0))) + continue; + + if (excluded_filename (d_name)) + continue; + + while (data_alloc < data_used + d_size) + dirdata->data = data = xrealloc (data, data_alloc *= 2); + memcpy (data + data_used, d_name, d_size); + data_used += d_size; + nnames++; + } + if (errno) + { + int e = errno; + closedir (reading); + errno = e; + return -1; + } +#if CLOSEDIR_VOID + closedir (reading); +#else + if (closedir (reading) != 0) + return -1; +#endif + } + + /* Create the `names' table from the `data' table. */ + dirdata->names = names = (char const **) xmalloc (sizeof (char *) + * (nnames + 1)); + for (i = 0; i < nnames; i++) + { + names[i] = data; + data += strlen (data) + 1; + } + names[nnames] = 0; + + /* Sort the table. */ + qsort (names, nnames, sizeof (char *), compare_names); + + return 0; +} + +/* Sort the files now in the table. */ + +static int +compare_names (file1, file2) + void const *file1, *file2; +{ + return filename_cmp (* (char const *const *) file1, + * (char const *const *) file2); +} + +/* Compare the contents of two directories named in FILEVEC[0] and FILEVEC[1]. + This is a top-level routine; it does everything necessary for diff + on two directories. + + FILEVEC[0].desc == -1 says directory FILEVEC[0] doesn't exist, + but pretend it is empty. Likewise for FILEVEC[1]. + + HANDLE_FILE is a caller-provided subroutine called to handle each file. + It gets five operands: dir and name (rel to original working dir) of file + in dir 0, dir and name pathname of file in dir 1, and the recursion depth. + + For a file that appears in only one of the dirs, one of the name-args + to HANDLE_FILE is zero. + + DEPTH is the current depth in recursion, used for skipping top-level + files by the -S option. + + Returns the maximum of all the values returned by HANDLE_FILE, + or 2 if trouble is encountered in opening files. */ + +int +diff_dirs (filevec, handle_file, depth) + struct file_data const filevec[]; + int (*handle_file) PARAMS((char const *, char const *, char const *, char const *, int)); + int depth; +{ + struct dirdata dirdata[2]; + int val = 0; /* Return value. */ + int i; + + /* Get sorted contents of both dirs. */ + for (i = 0; i < 2; i++) + if (dir_sort (&filevec[i], &dirdata[i]) != 0) + { + perror_with_name (filevec[i].name); + val = 2; + } + + if (val == 0) + { + register char const * const *names0 = dirdata[0].names; + register char const * const *names1 = dirdata[1].names; + char const *name0 = filevec[0].name; + char const *name1 = filevec[1].name; + + /* If `-S name' was given, and this is the topmost level of comparison, + ignore all file names less than the specified starting name. */ + + if (dir_start_file && depth == 0) + { + while (*names0 && filename_cmp (*names0, dir_start_file) < 0) + names0++; + while (*names1 && filename_cmp (*names1, dir_start_file) < 0) + names1++; + } + + /* Loop while files remain in one or both dirs. */ + while (*names0 || *names1) + { + /* Compare next name in dir 0 with next name in dir 1. + At the end of a dir, + pretend the "next name" in that dir is very large. */ + int nameorder = (!*names0 ? 1 : !*names1 ? -1 + : filename_cmp (*names0, *names1)); + int v1 = (*handle_file) (name0, 0 < nameorder ? 0 : *names0++, + name1, nameorder < 0 ? 0 : *names1++, + depth + 1); + if (v1 > val) + val = v1; + } + } + + for (i = 0; i < 2; i++) + { + if (dirdata[i].names) + free (dirdata[i].names); + if (dirdata[i].data) + free (dirdata[i].data); + } + + return val; +} diff --git a/contrib/cvs/diff/ed.c b/contrib/cvs/diff/ed.c new file mode 100644 index 0000000..717ef35 --- /dev/null +++ b/contrib/cvs/diff/ed.c @@ -0,0 +1,200 @@ +/* Output routines for ed-script format. + Copyright (C) 1988, 89, 91, 92, 93 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 void print_ed_hunk PARAMS((struct change *)); +static void print_rcs_hunk PARAMS((struct change *)); +static void pr_forward_ed_hunk PARAMS((struct change *)); + +/* Print our script as ed commands. */ + +void +print_ed_script (script) + struct change *script; +{ + print_script (script, find_reverse_change, print_ed_hunk); +} + +/* Print a hunk of an ed diff */ + +static void +print_ed_hunk (hunk) + struct change *hunk; +{ + int f0, l0, f1, l1; + int deletes, inserts; + +#if 0 + hunk = flip_script (hunk); +#endif +#ifdef DEBUG + debug_script (hunk); +#endif + + /* Determine range of line numbers involved in each file. */ + analyze_hunk (hunk, &f0, &l0, &f1, &l1, &deletes, &inserts); + if (!deletes && !inserts) + return; + + begin_output (); + + /* Print out the line number header for this hunk */ + print_number_range (',', &files[0], f0, l0); + fprintf (outfile, "%c\n", change_letter (inserts, deletes)); + + /* Print new/changed lines from second file, if needed */ + if (inserts) + { + int i; + int inserting = 1; + for (i = f1; i <= l1; i++) + { + /* Resume the insert, if we stopped. */ + if (! inserting) + fprintf (outfile, "%da\n", + i - f1 + translate_line_number (&files[0], f0) - 1); + inserting = 1; + + /* If the file's line is just a dot, it would confuse `ed'. + So output it with a double dot, and set the flag LEADING_DOT + so that we will output another ed-command later + to change the double dot into a single dot. */ + + if (files[1].linbuf[i][0] == '.' + && files[1].linbuf[i][1] == '\n') + { + fprintf (outfile, "..\n"); + fprintf (outfile, ".\n"); + /* Now change that double dot to the desired single dot. */ + fprintf (outfile, "%ds/^\\.\\././\n", + i - f1 + translate_line_number (&files[0], f0)); + inserting = 0; + } + else + /* Line is not `.', so output it unmodified. */ + print_1_line ("", &files[1].linbuf[i]); + } + + /* End insert mode, if we are still in it. */ + if (inserting) + fprintf (outfile, ".\n"); + } +} + +/* Print change script in the style of ed commands, + but print the changes in the order they appear in the input files, + which means that the commands are not truly useful with ed. */ + +void +pr_forward_ed_script (script) + struct change *script; +{ + print_script (script, find_change, pr_forward_ed_hunk); +} + +static void +pr_forward_ed_hunk (hunk) + struct change *hunk; +{ + int i; + int f0, l0, f1, l1; + int deletes, inserts; + + /* Determine range of line numbers involved in each file. */ + analyze_hunk (hunk, &f0, &l0, &f1, &l1, &deletes, &inserts); + if (!deletes && !inserts) + return; + + begin_output (); + + fprintf (outfile, "%c", change_letter (inserts, deletes)); + print_number_range (' ', files, f0, l0); + fprintf (outfile, "\n"); + + /* If deletion only, print just the number range. */ + + if (!inserts) + return; + + /* For insertion (with or without deletion), print the number range + and the lines from file 2. */ + + for (i = f1; i <= l1; i++) + print_1_line ("", &files[1].linbuf[i]); + + fprintf (outfile, ".\n"); +} + +/* Print in a format somewhat like ed commands + except that each insert command states the number of lines it inserts. + This format is used for RCS. */ + +void +print_rcs_script (script) + struct change *script; +{ + print_script (script, find_change, print_rcs_hunk); +} + +/* Print a hunk of an RCS diff */ + +static void +print_rcs_hunk (hunk) + struct change *hunk; +{ + int i; + int f0, l0, f1, l1; + int deletes, inserts; + int tf0, tl0, tf1, tl1; + + /* Determine range of line numbers involved in each file. */ + analyze_hunk (hunk, &f0, &l0, &f1, &l1, &deletes, &inserts); + if (!deletes && !inserts) + return; + + begin_output (); + + translate_range (&files[0], f0, l0, &tf0, &tl0); + + if (deletes) + { + fprintf (outfile, "d"); + /* For deletion, print just the starting line number from file 0 + and the number of lines deleted. */ + fprintf (outfile, "%d %d\n", + tf0, + (tl0 >= tf0 ? tl0 - tf0 + 1 : 1)); + } + + if (inserts) + { + fprintf (outfile, "a"); + + /* Take last-line-number from file 0 and # lines from file 1. */ + translate_range (&files[1], f1, l1, &tf1, &tl1); + fprintf (outfile, "%d %d\n", + tl0, + (tl1 >= tf1 ? tl1 - tf1 + 1 : 1)); + + /* Print the inserted lines. */ + for (i = f1; i <= l1; i++) + print_1_line ("", &files[1].linbuf[i]); + } +} diff --git a/contrib/cvs/diff/ifdef.c b/contrib/cvs/diff/ifdef.c new file mode 100644 index 0000000..2834cbd --- /dev/null +++ b/contrib/cvs/diff/ifdef.c @@ -0,0 +1,428 @@ +/* #ifdef-format output routines for GNU DIFF. + Copyright (C) 1989, 1991, 1992, 1993, 1994 Free Software Foundation, Inc. + +This file is part of GNU DIFF. + +GNU DIFF is distributed in the hope that it will be useful, +but WITHOUT ANY WARRANTY. No author or distributor +accepts responsibility to anyone for the consequences of using it +or for whether it serves any particular purpose or works at all, +unless he says so in writing. Refer to the GNU DIFF General Public +License for full details. + +Everyone is granted permission to copy, modify and redistribute +GNU DIFF, but only under the conditions described in the +GNU DIFF General Public License. A copy of this license is +supposed to have been given to you along with GNU DIFF so you +can know your rights and responsibilities. It should be in a +file named COPYING. Among other things, the copyright notice +and this notice must be preserved on all copies. */ + + +#include "diff.h" + +struct group +{ + struct file_data const *file; + int from, upto; /* start and limit lines for this group of lines */ +}; + +static char *format_group PARAMS((FILE *, char *, int, struct group const *)); +static char *scan_char_literal PARAMS((char *, int *)); +static char *scan_printf_spec PARAMS((char *)); +static int groups_letter_value PARAMS((struct group const *, int)); +static void format_ifdef PARAMS((char *, int, int, int, int)); +static void print_ifdef_hunk PARAMS((struct change *)); +static void print_ifdef_lines PARAMS((FILE *, char *, struct group const *)); + +static int next_line; + +/* Print the edit-script SCRIPT as a merged #ifdef file. */ + +void +print_ifdef_script (script) + struct change *script; +{ + next_line = - files[0].prefix_lines; + print_script (script, find_change, print_ifdef_hunk); + if (next_line < files[0].valid_lines) + { + begin_output (); + format_ifdef (group_format[UNCHANGED], next_line, files[0].valid_lines, + next_line - files[0].valid_lines + files[1].valid_lines, + files[1].valid_lines); + } +} + +/* Print a hunk of an ifdef diff. + This is a contiguous portion of a complete edit script, + describing changes in consecutive lines. */ + +static void +print_ifdef_hunk (hunk) + struct change *hunk; +{ + int first0, last0, first1, last1, deletes, inserts; + char *format; + + /* Determine range of line numbers involved in each file. */ + analyze_hunk (hunk, &first0, &last0, &first1, &last1, &deletes, &inserts); + if (inserts) + format = deletes ? group_format[CHANGED] : group_format[NEW]; + else if (deletes) + format = group_format[OLD]; + else + return; + + begin_output (); + + /* Print lines up to this change. */ + if (next_line < first0) + format_ifdef (group_format[UNCHANGED], next_line, first0, + next_line - first0 + first1, first1); + + /* Print this change. */ + next_line = last0 + 1; + format_ifdef (format, first0, next_line, first1, last1 + 1); +} + +/* Print a set of lines according to FORMAT. + Lines BEG0 up to END0 are from the first file; + lines BEG1 up to END1 are from the second file. */ + +static void +format_ifdef (format, beg0, end0, beg1, end1) + char *format; + int beg0, end0, beg1, end1; +{ + struct group groups[2]; + + groups[0].file = &files[0]; + groups[0].from = beg0; + groups[0].upto = end0; + groups[1].file = &files[1]; + groups[1].from = beg1; + groups[1].upto = end1; + format_group (outfile, format, '\0', groups); +} + +/* Print to file OUT a set of lines according to FORMAT. + The format ends at the first free instance of ENDCHAR. + Yield the address of the terminating character. + GROUPS specifies which lines to print. + If OUT is zero, do not actually print anything; just scan the format. */ + +static char * +format_group (out, format, endchar, groups) + register FILE *out; + char *format; + int endchar; + struct group const *groups; +{ + register char c; + register char *f = format; + + while ((c = *f) != endchar && c != 0) + { + f++; + if (c == '%') + { + char *spec = f; + switch ((c = *f++)) + { + case '%': + break; + + case '(': + /* Print if-then-else format e.g. `%(n=1?thenpart:elsepart)'. */ + { + int i, value[2]; + FILE *thenout, *elseout; + + for (i = 0; i < 2; i++) + { + unsigned char f0 = f[0]; + if (ISDIGIT (f0)) + { + value[i] = atoi (f); + while (ISDIGIT ((unsigned char) *++f)) + continue; + } + else + { + value[i] = groups_letter_value (groups, f0); + if (value[i] < 0) + goto bad_format; + f++; + } + if (*f++ != "=?"[i]) + goto bad_format; + } + if (value[0] == value[1]) + thenout = out, elseout = 0; + else + thenout = 0, elseout = out; + f = format_group (thenout, f, ':', groups); + if (*f) + { + f = format_group (elseout, f + 1, ')', groups); + if (*f) + f++; + } + } + continue; + + case '<': + /* Print lines deleted from first file. */ + print_ifdef_lines (out, line_format[OLD], &groups[0]); + continue; + + case '=': + /* Print common lines. */ + print_ifdef_lines (out, line_format[UNCHANGED], &groups[0]); + continue; + + case '>': + /* Print lines inserted from second file. */ + print_ifdef_lines (out, line_format[NEW], &groups[1]); + continue; + + default: + { + int value; + char *speclim; + + f = scan_printf_spec (spec); + if (!f) + goto bad_format; + speclim = f; + c = *f++; + switch (c) + { + case '\'': + f = scan_char_literal (f, &value); + if (!f) + goto bad_format; + break; + + default: + value = groups_letter_value (groups, c); + if (value < 0) + goto bad_format; + break; + } + if (out) + { + /* Temporarily replace e.g. "%3dnx" with "%3d\0x". */ + *speclim = 0; + fprintf (out, spec - 1, value); + /* Undo the temporary replacement. */ + *speclim = c; + } + } + continue; + + bad_format: + c = '%'; + f = spec; + break; + } + } + if (out) + putc (c, out); + } + return f; +} + +/* For the line group pair G, return the number corresponding to LETTER. + Return -1 if LETTER is not a group format letter. */ +static int +groups_letter_value (g, letter) + struct group const *g; + int letter; +{ + if (ISUPPER (letter)) + { + g++; + letter = tolower (letter); + } + switch (letter) + { + case 'e': return translate_line_number (g->file, g->from) - 1; + case 'f': return translate_line_number (g->file, g->from); + case 'l': return translate_line_number (g->file, g->upto) - 1; + case 'm': return translate_line_number (g->file, g->upto); + case 'n': return g->upto - g->from; + default: return -1; + } +} + +/* Print to file OUT, using FORMAT to print the line group GROUP. + But do nothing if OUT is zero. */ +static void +print_ifdef_lines (out, format, group) + register FILE *out; + char *format; + struct group const *group; +{ + struct file_data const *file = group->file; + char const * const *linbuf = file->linbuf; + int from = group->from, upto = group->upto; + + if (!out) + return; + + /* If possible, use a single fwrite; it's faster. */ + if (!tab_expand_flag && format[0] == '%') + { + if (format[1] == 'l' && format[2] == '\n' && !format[3]) + { + fwrite (linbuf[from], sizeof (char), + linbuf[upto] + (linbuf[upto][-1] != '\n') - linbuf[from], + out); + return; + } + if (format[1] == 'L' && !format[2]) + { + fwrite (linbuf[from], sizeof (char), + linbuf[upto] - linbuf[from], out); + return; + } + } + + for (; from < upto; from++) + { + register char c; + register char *f = format; + + while ((c = *f++) != 0) + { + if (c == '%') + { + char *spec = f; + switch ((c = *f++)) + { + case '%': + break; + + case 'l': + output_1_line (linbuf[from], + linbuf[from + 1] + - (linbuf[from + 1][-1] == '\n'), 0, 0); + continue; + + case 'L': + output_1_line (linbuf[from], linbuf[from + 1], 0, 0); + continue; + + default: + { + int value; + char *speclim; + + f = scan_printf_spec (spec); + if (!f) + goto bad_format; + speclim = f; + c = *f++; + switch (c) + { + case '\'': + f = scan_char_literal (f, &value); + if (!f) + goto bad_format; + break; + + case 'n': + value = translate_line_number (file, from); + break; + + default: + goto bad_format; + } + /* Temporarily replace e.g. "%3dnx" with "%3d\0x". */ + *speclim = 0; + fprintf (out, spec - 1, value); + /* Undo the temporary replacement. */ + *speclim = c; + } + continue; + + bad_format: + c = '%'; + f = spec; + break; + } + } + putc (c, out); + } + } +} + +/* Scan the character literal represented in the string LIT; LIT points just + after the initial apostrophe. Put the literal's value into *INTPTR. + Yield the address of the first character after the closing apostrophe, + or zero if the literal is ill-formed. */ +static char * +scan_char_literal (lit, intptr) + char *lit; + int *intptr; +{ + register char *p = lit; + int value, digits; + char c = *p++; + + switch (c) + { + case 0: + case '\'': + return 0; + + case '\\': + value = 0; + while ((c = *p++) != '\'') + { + unsigned digit = c - '0'; + if (8 <= digit) + return 0; + value = 8 * value + digit; + } + digits = p - lit - 2; + if (! (1 <= digits && digits <= 3)) + return 0; + break; + + default: + value = c; + if (*p++ != '\'') + return 0; + break; + } + *intptr = value; + return p; +} + +/* Scan optional printf-style SPEC of the form `-*[0-9]*(.[0-9]*)?[cdoxX]'. + Return the address of the character following SPEC, or zero if failure. */ +static char * +scan_printf_spec (spec) + register char *spec; +{ + register unsigned char c; + + while ((c = *spec++) == '-') + continue; + while (ISDIGIT (c)) + c = *spec++; + if (c == '.') + while (ISDIGIT (c = *spec++)) + continue; + switch (c) + { + case 'c': case 'd': case 'o': case 'x': case 'X': + return spec; + + default: + return 0; + } +} diff --git a/contrib/cvs/diff/io.c b/contrib/cvs/diff/io.c new file mode 100644 index 0000000..6605915 --- /dev/null +++ b/contrib/cvs/diff/io.c @@ -0,0 +1,714 @@ +/* File I/O for GNU DIFF. + Copyright (C) 1988, 1989, 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" + +/* Rotate a value n bits to the left. */ +#define UINT_BIT (sizeof (unsigned) * CHAR_BIT) +#define ROL(v, n) ((v) << (n) | (v) >> (UINT_BIT - (n))) + +/* Given a hash value and a new character, return a new hash value. */ +#define HASH(h, c) ((c) + ROL (h, 7)) + +/* Guess remaining number of lines from number N of lines so far, + size S so far, and total size T. */ +#define GUESS_LINES(n,s,t) (((t) - (s)) / ((n) < 10 ? 32 : (s) / ((n)-1)) + 5) + +/* Type used for fast prefix comparison in find_identical_ends. */ +#ifndef word +#define word int +#endif + +/* Lines are put into equivalence classes (of lines that match in line_cmp). + Each equivalence class is represented by one of these structures, + but only while the classes are being computed. + Afterward, each class is represented by a number. */ +struct equivclass +{ + int next; /* Next item in this bucket. */ + unsigned hash; /* Hash of lines in this class. */ + char const *line; /* A line that fits this class. */ + size_t length; /* That line's length, not counting its newline. */ +}; + +/* Hash-table: array of buckets, each being a chain of equivalence classes. + buckets[-1] is reserved for incomplete lines. */ +static int *buckets; + +/* Number of buckets in the hash table array, not counting buckets[-1]. */ +static int nbuckets; + +/* Array in which the equivalence classes are allocated. + The bucket-chains go through the elements in this array. + The number of an equivalence class is its index in this array. */ +static struct equivclass *equivs; + +/* Index of first free element in the array `equivs'. */ +static int equivs_index; + +/* Number of elements allocated in the array `equivs'. */ +static int equivs_alloc; + +static void find_and_hash_each_line PARAMS((struct file_data *)); +static void find_identical_ends PARAMS((struct file_data[])); +static void prepare_text_end PARAMS((struct file_data *)); + +/* Check for binary files and compare them for exact identity. */ + +/* Return 1 if BUF contains a non text character. + SIZE is the number of characters in BUF. */ + +#define binary_file_p(buf, size) (memchr (buf, '\0', size) != 0) + +/* Get ready to read the current file. + Return nonzero if SKIP_TEST is zero, + and if it appears to be a binary file. */ + +int +sip (current, skip_test) + struct file_data *current; + int skip_test; +{ + /* If we have a nonexistent file at this stage, treat it as empty. */ + if (current->desc < 0) + { + /* Leave room for a sentinel. */ + current->bufsize = sizeof (word); + current->buffer = xmalloc (current->bufsize); + } + else + { + current->bufsize = STAT_BLOCKSIZE (current->stat); + current->buffer = xmalloc (current->bufsize); + + if (! skip_test) + { + /* Check first part of file to see if it's a binary file. */ +#if HAVE_SETMODE + int oldmode = setmode (current->desc, O_BINARY); +#endif + size_t n = read (current->desc, current->buffer, current->bufsize); + if (n == -1) + pfatal_with_name (current->name); + current->buffered_chars = n; +#if HAVE_SETMODE + if (oldmode != O_BINARY) + { + if (lseek (current->desc, - (off_t) n, SEEK_CUR) == -1) + pfatal_with_name (current->name); + setmode (current->desc, oldmode); + current->buffered_chars = 0; + } +#endif + return binary_file_p (current->buffer, n); + } + } + + current->buffered_chars = 0; + return 0; +} + +/* Slurp the rest of the current file completely into memory. */ + +void +slurp (current) + struct file_data *current; +{ + size_t cc; + + if (current->desc < 0) + /* The file is nonexistent. */ + ; + else if (S_ISREG (current->stat.st_mode)) + { + /* It's a regular file; slurp in the rest all at once. */ + + /* Get the size out of the stat block. + Allocate enough room for appended newline and sentinel. */ + cc = current->stat.st_size + 1 + sizeof (word); + if (current->bufsize < cc) + { + current->bufsize = cc; + current->buffer = xrealloc (current->buffer, cc); + } + + if (current->buffered_chars < current->stat.st_size) + { + cc = read (current->desc, + current->buffer + current->buffered_chars, + current->stat.st_size - current->buffered_chars); + if (cc == -1) + pfatal_with_name (current->name); + current->buffered_chars += cc; + } + } + /* It's not a regular file; read it, growing the buffer as needed. */ + else if (always_text_flag || current->buffered_chars != 0) + { + for (;;) + { + if (current->buffered_chars == current->bufsize) + { + current->bufsize = current->bufsize * 2; + current->buffer = xrealloc (current->buffer, current->bufsize); + } + cc = read (current->desc, + current->buffer + current->buffered_chars, + current->bufsize - current->buffered_chars); + if (cc == 0) + break; + if (cc == -1) + pfatal_with_name (current->name); + current->buffered_chars += cc; + } + /* Allocate just enough room for appended newline and sentinel. */ + current->bufsize = current->buffered_chars + 1 + sizeof (word); + current->buffer = xrealloc (current->buffer, current->bufsize); + } +} + +/* Split the file into lines, simultaneously computing the equivalence class for + each line. */ + +static void +find_and_hash_each_line (current) + struct file_data *current; +{ + unsigned h; + unsigned char const *p = (unsigned char const *) current->prefix_end; + unsigned char c; + int i, *bucket; + size_t length; + + /* Cache often-used quantities in local variables to help the compiler. */ + char const **linbuf = current->linbuf; + int alloc_lines = current->alloc_lines; + int line = 0; + int linbuf_base = current->linbuf_base; + int *cureqs = (int *) xmalloc (alloc_lines * sizeof (int)); + struct equivclass *eqs = equivs; + int eqs_index = equivs_index; + int eqs_alloc = equivs_alloc; + char const *suffix_begin = current->suffix_begin; + char const *bufend = current->buffer + current->buffered_chars; + int use_line_cmp = ignore_some_line_changes; + + while ((char const *) p < suffix_begin) + { + char const *ip = (char const *) p; + + /* Compute the equivalence class for this line. */ + + h = 0; + + /* Hash this line until we find a newline. */ + if (ignore_case_flag) + { + if (ignore_all_space_flag) + while ((c = *p++) != '\n') + { + if (! ISSPACE (c)) + h = HASH (h, ISUPPER (c) ? tolower (c) : c); + } + else if (ignore_space_change_flag) + while ((c = *p++) != '\n') + { + if (ISSPACE (c)) + { + for (;;) + { + c = *p++; + if (!ISSPACE (c)) + break; + if (c == '\n') + goto hashing_done; + } + h = HASH (h, ' '); + } + /* C is now the first non-space. */ + h = HASH (h, ISUPPER (c) ? tolower (c) : c); + } + else + while ((c = *p++) != '\n') + h = HASH (h, ISUPPER (c) ? tolower (c) : c); + } + else + { + if (ignore_all_space_flag) + while ((c = *p++) != '\n') + { + if (! ISSPACE (c)) + h = HASH (h, c); + } + else if (ignore_space_change_flag) + while ((c = *p++) != '\n') + { + if (ISSPACE (c)) + { + for (;;) + { + c = *p++; + if (!ISSPACE (c)) + break; + if (c == '\n') + goto hashing_done; + } + h = HASH (h, ' '); + } + /* C is now the first non-space. */ + h = HASH (h, c); + } + else + while ((c = *p++) != '\n') + h = HASH (h, c); + } + hashing_done:; + + bucket = &buckets[h % nbuckets]; + length = (char const *) p - ip - 1; + + if ((char const *) p == bufend + && current->missing_newline + && ROBUST_OUTPUT_STYLE (output_style)) + { + /* This line is incomplete. If this is significant, + put the line into bucket[-1]. */ + if (! (ignore_space_change_flag | ignore_all_space_flag)) + bucket = &buckets[-1]; + + /* Omit the inserted newline when computing linbuf later. */ + p--; + bufend = suffix_begin = (char const *) p; + } + + for (i = *bucket; ; i = eqs[i].next) + if (!i) + { + /* Create a new equivalence class in this bucket. */ + i = eqs_index++; + if (i == eqs_alloc) + eqs = (struct equivclass *) + xrealloc (eqs, (eqs_alloc*=2) * sizeof(*eqs)); + eqs[i].next = *bucket; + eqs[i].hash = h; + eqs[i].line = ip; + eqs[i].length = length; + *bucket = i; + break; + } + else if (eqs[i].hash == h) + { + char const *eqline = eqs[i].line; + + /* Reuse existing equivalence class if the lines are identical. + This detects the common case of exact identity + faster than complete comparison would. */ + if (eqs[i].length == length && memcmp (eqline, ip, length) == 0) + break; + + /* Reuse existing class if line_cmp reports the lines equal. */ + if (use_line_cmp && line_cmp (eqline, ip) == 0) + break; + } + + /* Maybe increase the size of the line table. */ + if (line == alloc_lines) + { + /* Double (alloc_lines - linbuf_base) by adding to alloc_lines. */ + alloc_lines = 2 * alloc_lines - linbuf_base; + cureqs = (int *) xrealloc (cureqs, alloc_lines * sizeof (*cureqs)); + linbuf = (char const **) xrealloc (linbuf + linbuf_base, + (alloc_lines - linbuf_base) + * sizeof (*linbuf)) + - linbuf_base; + } + linbuf[line] = ip; + cureqs[line] = i; + ++line; + } + + current->buffered_lines = line; + + for (i = 0; ; i++) + { + /* Record the line start for lines in the suffix that we care about. + Record one more line start than lines, + so that we can compute the length of any buffered line. */ + if (line == alloc_lines) + { + /* Double (alloc_lines - linbuf_base) by adding to alloc_lines. */ + alloc_lines = 2 * alloc_lines - linbuf_base; + linbuf = (char const **) xrealloc (linbuf + linbuf_base, + (alloc_lines - linbuf_base) + * sizeof (*linbuf)) + - linbuf_base; + } + linbuf[line] = (char const *) p; + + if ((char const *) p == bufend) + break; + + if (context <= i && no_diff_means_no_output) + break; + + line++; + + while (*p++ != '\n') + ; + } + + /* Done with cache in local variables. */ + current->linbuf = linbuf; + current->valid_lines = line; + current->alloc_lines = alloc_lines; + current->equivs = cureqs; + equivs = eqs; + equivs_alloc = eqs_alloc; + equivs_index = eqs_index; +} + +/* Prepare the end of the text. Make sure it's initialized. + Make sure text ends in a newline, + but remember that we had to add one. */ + +static void +prepare_text_end (current) + struct file_data *current; +{ + size_t buffered_chars = current->buffered_chars; + char *p = current->buffer; + + if (buffered_chars == 0 || p[buffered_chars - 1] == '\n') + current->missing_newline = 0; + else + { + p[buffered_chars++] = '\n'; + current->buffered_chars = buffered_chars; + current->missing_newline = 1; + } + + /* Don't use uninitialized storage when planting or using sentinels. */ + if (p) + bzero (p + buffered_chars, sizeof (word)); +} + +/* Given a vector of two file_data objects, find the identical + prefixes and suffixes of each object. */ + +static void +find_identical_ends (filevec) + struct file_data filevec[]; +{ + word *w0, *w1; + char *p0, *p1, *buffer0, *buffer1; + char const *end0, *beg0; + char const **linbuf0, **linbuf1; + int i, lines; + size_t n0, n1, tem; + int alloc_lines0, alloc_lines1; + int buffered_prefix, prefix_count, prefix_mask; + + slurp (&filevec[0]); + if (filevec[0].desc != filevec[1].desc) + slurp (&filevec[1]); + else + { + filevec[1].buffer = filevec[0].buffer; + filevec[1].bufsize = filevec[0].bufsize; + filevec[1].buffered_chars = filevec[0].buffered_chars; + } + for (i = 0; i < 2; i++) + prepare_text_end (&filevec[i]); + + /* Find identical prefix. */ + + p0 = buffer0 = filevec[0].buffer; + p1 = buffer1 = filevec[1].buffer; + + n0 = filevec[0].buffered_chars; + n1 = filevec[1].buffered_chars; + + if (p0 == p1) + /* The buffers are the same; sentinels won't work. */ + p0 = p1 += n1; + else + { + /* Insert end sentinels, in this case characters that are guaranteed + to make the equality test false, and thus terminate the loop. */ + + if (n0 < n1) + p0[n0] = ~p1[n0]; + else + p1[n1] = ~p0[n1]; + + /* Loop until first mismatch, or to the sentinel characters. */ + + /* Compare a word at a time for speed. */ + w0 = (word *) p0; + w1 = (word *) p1; + while (*w0++ == *w1++) + ; + --w0, --w1; + + /* Do the last few bytes of comparison a byte at a time. */ + p0 = (char *) w0; + p1 = (char *) w1; + while (*p0++ == *p1++) + ; + --p0, --p1; + + /* Don't mistakenly count missing newline as part of prefix. */ + if (ROBUST_OUTPUT_STYLE (output_style) + && (buffer0 + n0 - filevec[0].missing_newline < p0) + != + (buffer1 + n1 - filevec[1].missing_newline < p1)) + --p0, --p1; + } + + /* Now P0 and P1 point at the first nonmatching characters. */ + + /* Skip back to last line-beginning in the prefix, + and then discard up to HORIZON_LINES lines from the prefix. */ + i = horizon_lines; + while (p0 != buffer0 && (p0[-1] != '\n' || i--)) + --p0, --p1; + + /* Record the prefix. */ + filevec[0].prefix_end = p0; + filevec[1].prefix_end = p1; + + /* Find identical suffix. */ + + /* P0 and P1 point beyond the last chars not yet compared. */ + p0 = buffer0 + n0; + p1 = buffer1 + n1; + + if (! ROBUST_OUTPUT_STYLE (output_style) + || filevec[0].missing_newline == filevec[1].missing_newline) + { + end0 = p0; /* Addr of last char in file 0. */ + + /* Get value of P0 at which we should stop scanning backward: + this is when either P0 or P1 points just past the last char + of the identical prefix. */ + beg0 = filevec[0].prefix_end + (n0 < n1 ? 0 : n0 - n1); + + /* Scan back until chars don't match or we reach that point. */ + while (p0 != beg0) + if (*--p0 != *--p1) + { + /* Point at the first char of the matching suffix. */ + ++p0, ++p1; + beg0 = p0; + break; + } + + /* Are we at a line-beginning in both files? If not, add the rest of + this line to the main body. Discard up to HORIZON_LINES lines from + the identical suffix. Also, discard one extra line, + because shift_boundaries may need it. */ + i = horizon_lines + !((buffer0 == p0 || p0[-1] == '\n') + && + (buffer1 == p1 || p1[-1] == '\n')); + while (i-- && p0 != end0) + while (*p0++ != '\n') + ; + + p1 += p0 - beg0; + } + + /* Record the suffix. */ + filevec[0].suffix_begin = p0; + filevec[1].suffix_begin = p1; + + /* Calculate number of lines of prefix to save. + + prefix_count == 0 means save the whole prefix; + we need this with for options like -D that output the whole file. + We also need it for options like -F that output some preceding line; + at least we will need to find the last few lines, + but since we don't know how many, it's easiest to find them all. + + Otherwise, prefix_count != 0. Save just prefix_count lines at start + of the line buffer; they'll be moved to the proper location later. + Handle 1 more line than the context says (because we count 1 too many), + rounded up to the next power of 2 to speed index computation. */ + + if (no_diff_means_no_output && ! function_regexp_list) + { + for (prefix_count = 1; prefix_count < context + 1; prefix_count *= 2) + ; + prefix_mask = prefix_count - 1; + alloc_lines0 + = prefix_count + + GUESS_LINES (0, 0, p0 - filevec[0].prefix_end) + + context; + } + else + { + prefix_count = 0; + prefix_mask = ~0; + alloc_lines0 = GUESS_LINES (0, 0, n0); + } + + lines = 0; + linbuf0 = (char const **) xmalloc (alloc_lines0 * sizeof (*linbuf0)); + + /* If the prefix is needed, find the prefix lines. */ + if (! (no_diff_means_no_output + && filevec[0].prefix_end == p0 + && filevec[1].prefix_end == p1)) + { + p0 = buffer0; + end0 = filevec[0].prefix_end; + while (p0 != end0) + { + int l = lines++ & prefix_mask; + if (l == alloc_lines0) + linbuf0 = (char const **) xrealloc (linbuf0, (alloc_lines0 *= 2) + * sizeof(*linbuf0)); + linbuf0[l] = p0; + while (*p0++ != '\n') + ; + } + } + buffered_prefix = prefix_count && context < lines ? context : lines; + + /* Allocate line buffer 1. */ + tem = prefix_count ? filevec[1].suffix_begin - buffer1 : n1; + + alloc_lines1 + = (buffered_prefix + + GUESS_LINES (lines, filevec[1].prefix_end - buffer1, tem) + + context); + linbuf1 = (char const **) xmalloc (alloc_lines1 * sizeof (*linbuf1)); + + if (buffered_prefix != lines) + { + /* Rotate prefix lines to proper location. */ + for (i = 0; i < buffered_prefix; i++) + linbuf1[i] = linbuf0[(lines - context + i) & prefix_mask]; + for (i = 0; i < buffered_prefix; i++) + linbuf0[i] = linbuf1[i]; + } + + /* Initialize line buffer 1 from line buffer 0. */ + for (i = 0; i < buffered_prefix; i++) + linbuf1[i] = linbuf0[i] - buffer0 + buffer1; + + /* Record the line buffer, adjusted so that + linbuf*[0] points at the first differing line. */ + filevec[0].linbuf = linbuf0 + buffered_prefix; + filevec[1].linbuf = linbuf1 + buffered_prefix; + filevec[0].linbuf_base = filevec[1].linbuf_base = - buffered_prefix; + filevec[0].alloc_lines = alloc_lines0 - buffered_prefix; + filevec[1].alloc_lines = alloc_lines1 - buffered_prefix; + filevec[0].prefix_lines = filevec[1].prefix_lines = lines; +} + +/* Largest primes less than some power of two, for nbuckets. Values range + from useful to preposterous. If one of these numbers isn't prime + after all, don't blame it on me, blame it on primes (6) . . . */ +static int const primes[] = +{ + 509, + 1021, + 2039, + 4093, + 8191, + 16381, + 32749, +#if 32767 < INT_MAX + 65521, + 131071, + 262139, + 524287, + 1048573, + 2097143, + 4194301, + 8388593, + 16777213, + 33554393, + 67108859, /* Preposterously large . . . */ + 134217689, + 268435399, + 536870909, + 1073741789, + 2147483647, +#endif + 0 +}; + +/* Given a vector of two file_data objects, read the file associated + with each one, and build the table of equivalence classes. + Return 1 if either file appears to be a binary file. + If PRETEND_BINARY is nonzero, pretend they are binary regardless. */ + +int +read_files (filevec, pretend_binary) + struct file_data filevec[]; + int pretend_binary; +{ + int i; + int skip_test = always_text_flag | pretend_binary; + int appears_binary = pretend_binary | sip (&filevec[0], skip_test); + + if (filevec[0].desc != filevec[1].desc) + appears_binary |= sip (&filevec[1], skip_test | appears_binary); + else + { + filevec[1].buffer = filevec[0].buffer; + filevec[1].bufsize = filevec[0].bufsize; + filevec[1].buffered_chars = filevec[0].buffered_chars; + } + if (appears_binary) + { +#if HAVE_SETMODE + setmode (filevec[0].desc, O_BINARY); + setmode (filevec[1].desc, O_BINARY); +#endif + return 1; + } + + find_identical_ends (filevec); + + equivs_alloc = filevec[0].alloc_lines + filevec[1].alloc_lines + 1; + equivs = (struct equivclass *) xmalloc (equivs_alloc * sizeof (struct equivclass)); + /* Equivalence class 0 is permanently safe for lines that were not + hashed. Real equivalence classes start at 1. */ + equivs_index = 1; + + for (i = 0; primes[i] < equivs_alloc / 3; i++) + if (! primes[i]) + abort (); + nbuckets = primes[i]; + + buckets = (int *) xmalloc ((nbuckets + 1) * sizeof (*buckets)); + bzero (buckets++, (nbuckets + 1) * sizeof (*buckets)); + + for (i = 0; i < 2; i++) + find_and_hash_each_line (&filevec[i]); + + filevec[0].equiv_max = filevec[1].equiv_max = equivs_index; + + free (equivs); + free (buckets - 1); + + return 0; +} diff --git a/contrib/cvs/diff/normal.c b/contrib/cvs/diff/normal.c new file mode 100644 index 0000000..4d9e23c --- /dev/null +++ b/contrib/cvs/diff/normal.c @@ -0,0 +1,71 @@ +/* Normal-format output routines for GNU DIFF. + Copyright (C) 1988, 1989, 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. */ + + +#include "diff.h" + +static void print_normal_hunk PARAMS((struct change *)); + +/* Print the edit-script SCRIPT as a normal diff. + INF points to an array of descriptions of the two files. */ + +void +print_normal_script (script) + struct change *script; +{ + print_script (script, find_change, print_normal_hunk); +} + +/* Print a hunk of a normal diff. + This is a contiguous portion of a complete edit script, + describing changes in consecutive lines. */ + +static void +print_normal_hunk (hunk) + struct change *hunk; +{ + int first0, last0, first1, last1, deletes, inserts; + register int i; + + /* Determine range of line numbers involved in each file. */ + analyze_hunk (hunk, &first0, &last0, &first1, &last1, &deletes, &inserts); + if (!deletes && !inserts) + return; + + begin_output (); + + /* Print out the line number header for this hunk */ + print_number_range (',', &files[0], first0, last0); + fprintf (outfile, "%c", change_letter (inserts, deletes)); + print_number_range (',', &files[1], first1, last1); + fprintf (outfile, "\n"); + + /* Print the lines that the first file has. */ + if (deletes) + for (i = first0; i <= last0; i++) + print_1_line ("<", &files[0].linbuf[i]); + + if (inserts && deletes) + fprintf (outfile, "---\n"); + + /* Print the lines that the second file has. */ + if (inserts) + for (i = first1; i <= last1; i++) + print_1_line (">", &files[1].linbuf[i]); +} diff --git a/contrib/cvs/diff/side.c b/contrib/cvs/diff/side.c new file mode 100644 index 0000000..a150b5e --- /dev/null +++ b/contrib/cvs/diff/side.c @@ -0,0 +1,284 @@ +/* sdiff-format output routines for GNU DIFF. + Copyright (C) 1991, 1992, 1993 Free Software Foundation, Inc. + +This file is part of GNU DIFF. + +GNU DIFF is distributed in the hope that it will be useful, +but WITHOUT ANY WARRANTY. No author or distributor +accepts responsibility to anyone for the consequences of using it +or for whether it serves any particular purpose or works at all, +unless he says so in writing. Refer to the GNU DIFF General Public +License for full details. + +Everyone is granted permission to copy, modify and redistribute +GNU DIFF, but only under the conditions described in the +GNU DIFF General Public License. A copy of this license is +supposed to have been given to you along with GNU DIFF so you +can know your rights and responsibilities. It should be in a +file named COPYING. Among other things, the copyright notice +and this notice must be preserved on all copies. */ + + +#include "diff.h" + +static unsigned print_half_line PARAMS((char const * const *, unsigned, unsigned)); +static unsigned tab_from_to PARAMS((unsigned, unsigned)); +static void print_1sdiff_line PARAMS((char const * const *, int, char const * const *)); +static void print_sdiff_common_lines PARAMS((int, int)); +static void print_sdiff_hunk PARAMS((struct change *)); + +/* Next line number to be printed in the two input files. */ +static int next0, next1; + +/* Print the edit-script SCRIPT as a sdiff style output. */ + +void +print_sdiff_script (script) + struct change *script; +{ + begin_output (); + + next0 = next1 = - files[0].prefix_lines; + print_script (script, find_change, print_sdiff_hunk); + + print_sdiff_common_lines (files[0].valid_lines, files[1].valid_lines); +} + +/* Tab from column FROM to column TO, where FROM <= TO. Yield TO. */ + +static unsigned +tab_from_to (from, to) + unsigned from, to; +{ + FILE *out = outfile; + unsigned tab; + + if (! tab_expand_flag) + for (tab = from + TAB_WIDTH - from % TAB_WIDTH; tab <= to; tab += TAB_WIDTH) + { + putc ('\t', out); + from = tab; + } + while (from++ < to) + putc (' ', out); + return to; +} + +/* + * Print the text for half an sdiff line. This means truncate to width + * observing tabs, and trim a trailing newline. Returns the last column + * written (not the number of chars). + */ +static unsigned +print_half_line (line, indent, out_bound) + char const * const *line; + unsigned indent, out_bound; +{ + FILE *out = outfile; + register unsigned in_position = 0, out_position = 0; + register char const + *text_pointer = line[0], + *text_limit = line[1]; + + while (text_pointer < text_limit) + { + register unsigned char c = *text_pointer++; + + switch (c) + { + case '\t': + { + unsigned spaces = TAB_WIDTH - in_position % TAB_WIDTH; + if (in_position == out_position) + { + unsigned tabstop = out_position + spaces; + if (tab_expand_flag) + { + if (out_bound < tabstop) + tabstop = out_bound; + for (; out_position < tabstop; out_position++) + putc (' ', out); + } + else + if (tabstop < out_bound) + { + out_position = tabstop; + putc (c, out); + } + } + in_position += spaces; + } + break; + + case '\r': + { + putc (c, out); + tab_from_to (0, indent); + in_position = out_position = 0; + } + break; + + case '\b': + if (in_position != 0 && --in_position < out_bound) + if (out_position <= in_position) + /* Add spaces to make up for suppressed tab past out_bound. */ + for (; out_position < in_position; out_position++) + putc (' ', out); + else + { + out_position = in_position; + putc (c, out); + } + break; + + case '\f': + case '\v': + control_char: + if (in_position < out_bound) + putc (c, out); + break; + + default: + if (! ISPRINT (c)) + goto control_char; + /* falls through */ + case ' ': + if (in_position++ < out_bound) + { + out_position = in_position; + putc (c, out); + } + break; + + case '\n': + return out_position; + } + } + + return out_position; +} + +/* + * Print side by side lines with a separator in the middle. + * 0 parameters are taken to indicate white space text. + * Blank lines that can easily be caught are reduced to a single newline. + */ + +static void +print_1sdiff_line (left, sep, right) + char const * const *left; + int sep; + char const * const *right; +{ + FILE *out = outfile; + unsigned hw = sdiff_half_width, c2o = sdiff_column2_offset; + unsigned col = 0; + int put_newline = 0; + + if (left) + { + if (left[1][-1] == '\n') + put_newline = 1; + col = print_half_line (left, 0, hw); + } + + if (sep != ' ') + { + col = tab_from_to (col, (hw + c2o - 1) / 2) + 1; + if (sep == '|' && put_newline != (right[1][-1] == '\n')) + sep = put_newline ? '/' : '\\'; + putc (sep, out); + } + + if (right) + { + if (right[1][-1] == '\n') + put_newline = 1; + if (**right != '\n') + { + col = tab_from_to (col, c2o); + print_half_line (right, col, hw); + } + } + + if (put_newline) + putc ('\n', out); +} + +/* Print lines common to both files in side-by-side format. */ +static void +print_sdiff_common_lines (limit0, limit1) + int limit0, limit1; +{ + int i0 = next0, i1 = next1; + + if (! sdiff_skip_common_lines && (i0 != limit0 || i1 != limit1)) + { + if (sdiff_help_sdiff) + fprintf (outfile, "i%d,%d\n", limit0 - i0, limit1 - i1); + + if (! sdiff_left_only) + { + while (i0 != limit0 && i1 != limit1) + print_1sdiff_line (&files[0].linbuf[i0++], ' ', &files[1].linbuf[i1++]); + while (i1 != limit1) + print_1sdiff_line (0, ')', &files[1].linbuf[i1++]); + } + while (i0 != limit0) + print_1sdiff_line (&files[0].linbuf[i0++], '(', 0); + } + + next0 = limit0; + next1 = limit1; +} + +/* Print a hunk of an sdiff diff. + This is a contiguous portion of a complete edit script, + describing changes in consecutive lines. */ + +static void +print_sdiff_hunk (hunk) + struct change *hunk; +{ + int first0, last0, first1, last1, deletes, inserts; + register int i, j; + + /* Determine range of line numbers involved in each file. */ + analyze_hunk (hunk, &first0, &last0, &first1, &last1, &deletes, &inserts); + if (!deletes && !inserts) + return; + + /* Print out lines up to this change. */ + print_sdiff_common_lines (first0, first1); + + if (sdiff_help_sdiff) + fprintf (outfile, "c%d,%d\n", last0 - first0 + 1, last1 - first1 + 1); + + /* Print ``xxx | xxx '' lines */ + if (inserts && deletes) + { + for (i = first0, j = first1; i <= last0 && j <= last1; ++i, ++j) + print_1sdiff_line (&files[0].linbuf[i], '|', &files[1].linbuf[j]); + deletes = i <= last0; + inserts = j <= last1; + next0 = first0 = i; + next1 = first1 = j; + } + + + /* Print `` > xxx '' lines */ + if (inserts) + { + for (j = first1; j <= last1; ++j) + print_1sdiff_line (0, '>', &files[1].linbuf[j]); + next1 = j; + } + + /* Print ``xxx < '' lines */ + if (deletes) + { + for (i = first0; i <= last0; ++i) + print_1sdiff_line (&files[0].linbuf[i], '<', 0); + next0 = i; + } +} diff --git a/contrib/cvs/diff/system.h b/contrib/cvs/diff/system.h new file mode 100644 index 0000000..7812b76 --- /dev/null +++ b/contrib/cvs/diff/system.h @@ -0,0 +1,270 @@ +/* System dependent declarations. + Copyright (C) 1988, 1989, 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. */ + +/* We must define `volatile' and `const' first (the latter inside config.h), + so that they're used consistently in all system includes. */ +#if !__STDC__ +#ifndef volatile +#define volatile +#endif +#endif +#include <config.h> + +#include <sys/types.h> +#include <sys/stat.h> + +#if __STDC__ +#define PARAMS(args) args +#define VOID void +#else +#define PARAMS(args) () +#define VOID char +#endif + +#if STAT_MACROS_BROKEN +#undef S_ISBLK +#undef S_ISCHR +#undef S_ISDIR +#undef S_ISFIFO +#undef S_ISREG +#undef S_ISSOCK +#endif +#ifndef S_ISDIR +#define S_ISDIR(mode) (((mode) & S_IFMT) == S_IFDIR) +#endif +#ifndef S_ISREG +#define S_ISREG(mode) (((mode) & S_IFMT) == S_IFREG) +#endif +#if !defined(S_ISBLK) && defined(S_IFBLK) +#define S_ISBLK(mode) (((mode) & S_IFMT) == S_IFBLK) +#endif +#if !defined(S_ISCHR) && defined(S_IFCHR) +#define S_ISCHR(mode) (((mode) & S_IFMT) == S_IFCHR) +#endif +#if !defined(S_ISFIFO) && defined(S_IFFIFO) +#define S_ISFIFO(mode) (((mode) & S_IFMT) == S_IFFIFO) +#endif +#if !defined(S_ISSOCK) && defined(S_IFSOCK) +#define S_ISSOCK(mode) (((mode) & S_IFMT) == S_IFSOCK) +#endif + +#if HAVE_UNISTD_H +#include <unistd.h> +#endif + +#ifndef SEEK_SET +#define SEEK_SET 0 +#endif +#ifndef SEEK_CUR +#define SEEK_CUR 1 +#endif + +#ifndef STDIN_FILENO +#define STDIN_FILENO 0 +#endif +#ifndef STDOUT_FILENO +#define STDOUT_FILENO 1 +#endif +#ifndef STDERR_FILENO +#define STDERR_FILENO 2 +#endif + +/* I believe that all relevant systems have + time.h. It is in ANSI, for example. The + code below looks quite bogus as I don't think + sys/time.h is ever a substitute for time.h; + it is something different. */ +#define HAVE_TIME_H 1 + +#if HAVE_TIME_H +#include <time.h> +#else +#include <sys/time.h> +#endif + +#if HAVE_FCNTL_H +#include <fcntl.h> +#else +#if HAVE_SYS_FILE_H +#include <sys/file.h> +#endif +#endif + +#ifndef O_RDONLY +#define O_RDONLY 0 +#endif + +#if HAVE_SYS_WAIT_H +#include <sys/wait.h> +#endif +#ifndef WEXITSTATUS +#define WEXITSTATUS(stat_val) ((unsigned) (stat_val) >> 8) +#endif +#ifndef WIFEXITED +#define WIFEXITED(stat_val) (((stat_val) & 255) == 0) +#endif + +#ifndef STAT_BLOCKSIZE +#if HAVE_ST_BLKSIZE +#define STAT_BLOCKSIZE(s) (s).st_blksize +#else +#define STAT_BLOCKSIZE(s) (8 * 1024) +#endif +#endif + +#if HAVE_DIRENT_H +# include <dirent.h> +# define NAMLEN(dirent) strlen((dirent)->d_name) +#else +# define dirent direct +# define NAMLEN(dirent) ((dirent)->d_namlen) +# if HAVE_SYS_NDIR_H +# include <sys/ndir.h> +# endif +# if HAVE_SYS_DIR_H +# include <sys/dir.h> +# endif +# if HAVE_NDIR_H +# include <ndir.h> +# endif +#endif + +#if HAVE_VFORK_H +#include <vfork.h> +#endif + +#if HAVE_STDLIB_H || defined(STDC_HEADERS) +#include <stdlib.h> +#else +VOID *malloc (); +VOID *realloc (); +#endif +#ifndef getenv +char *getenv (); +#endif + +#if HAVE_LIMITS_H +#include <limits.h> +#endif +#ifndef INT_MAX +#define INT_MAX 2147483647 +#endif +#ifndef CHAR_BIT +#define CHAR_BIT 8 +#endif + +#if STDC_HEADERS || HAVE_STRING_H +# include <string.h> +# ifndef bzero +# define bzero(s, n) memset (s, 0, n) +# endif +#else +# if !HAVE_STRCHR +# define strchr index +# define strrchr rindex +# endif +char *strchr (), *strrchr (); +# if !HAVE_MEMCHR +# define memcmp(s1, s2, n) bcmp (s1, s2, n) +# define memcpy(d, s, n) bcopy (s, d, n) +void *memchr (); +# endif +#endif + +#include <ctype.h> +/* CTYPE_DOMAIN (C) is nonzero if the unsigned char C can safely be given + as an argument to <ctype.h> macros like `isspace'. */ +#if STDC_HEADERS +#define CTYPE_DOMAIN(c) 1 +#else +#define CTYPE_DOMAIN(c) ((unsigned) (c) <= 0177) +#endif +#ifndef ISPRINT +#define ISPRINT(c) (CTYPE_DOMAIN (c) && isprint (c)) +#endif +#ifndef ISSPACE +#define ISSPACE(c) (CTYPE_DOMAIN (c) && isspace (c)) +#endif +#ifndef ISUPPER +#define ISUPPER(c) (CTYPE_DOMAIN (c) && isupper (c)) +#endif + +#ifndef ISDIGIT +#define ISDIGIT(c) ((unsigned) (c) - '0' <= 9) +#endif + +#include <errno.h> +#if !STDC_HEADERS +extern int errno; +#endif + +#ifdef min +#undef min +#endif +#ifdef max +#undef max +#endif +#define min(a,b) ((a) <= (b) ? (a) : (b)) +#define max(a,b) ((a) >= (b) ? (a) : (b)) + +/* This section contains Posix-compliant defaults for macros + that are meant to be overridden by hand in config.h as needed. */ + +#ifndef filename_cmp +#define filename_cmp(a, b) strcmp (a, b) +#endif + +#ifndef filename_lastdirchar +#define filename_lastdirchar(filename) strrchr (filename, '/') +#endif + +#ifndef HAVE_FORK +#define HAVE_FORK 1 +#endif + +#ifndef HAVE_SETMODE +#define HAVE_SETMODE 0 +#endif + +#ifndef initialize_main +#define initialize_main(argcp, argvp) +#endif + +/* Do struct stat *S, *T describe the same file? Answer -1 if unknown. */ +#ifndef same_file +#define same_file(s,t) ((s)->st_ino==(t)->st_ino && (s)->st_dev==(t)->st_dev) +#endif + +/* Place into Q a quoted version of A suitable for `popen' or `system', + incrementing Q and junking A. + Do not increment Q by more than 4 * strlen (A) + 2. */ +#ifndef SYSTEM_QUOTE_ARG +#define SYSTEM_QUOTE_ARG(q, a) \ + { \ + *(q)++ = '\''; \ + for (; *(a); *(q)++ = *(a)++) \ + if (*(a) == '\'') \ + { \ + *(q)++ = '\''; \ + *(q)++ = '\\'; \ + *(q)++ = '\''; \ + } \ + *(q)++ = '\''; \ + } +#endif diff --git a/contrib/cvs/diff/util.c b/contrib/cvs/diff/util.c new file mode 100644 index 0000000..89cc274 --- /dev/null +++ b/contrib/cvs/diff/util.c @@ -0,0 +1,722 @@ +/* Support routines for GNU DIFF. + 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. */ + +#include "diff.h" + +/* Queue up one-line messages to be printed at the end, + when -l is specified. Each message is recorded with a `struct msg'. */ + +struct msg +{ + struct msg *next; + char const *format; + char const *arg1; + char const *arg2; + char const *arg3; + char const *arg4; +}; + +/* Head of the chain of queues messages. */ + +static struct msg *msg_chain; + +/* Tail of the chain of queues messages. */ + +static struct msg **msg_chain_end = &msg_chain; + +/* Use when a system call returns non-zero status. + TEXT should normally be the file name. */ + +void +perror_with_name (text) + char const *text; +{ + int e = errno; + fprintf (stderr, "%s: ", diff_program_name); + errno = e; + perror (text); +} + +/* Use when a system call returns non-zero status and that is fatal. */ + +void +pfatal_with_name (text) + char const *text; +{ + int e = errno; + print_message_queue (); + fprintf (stderr, "%s: ", diff_program_name); + errno = e; + perror (text); + DIFF_ABORT (2); +} + +/* Print an error message from the format-string FORMAT + with args ARG1 and ARG2. */ + +void +diff_error (format, arg, arg1) + char const *format, *arg, *arg1; +{ + fprintf (stderr, "%s: ", diff_program_name); + fprintf (stderr, format, arg, arg1); + fprintf (stderr, "\n"); +} + +/* Print an error message containing the string TEXT, then exit. */ + +void +fatal (m) + char const *m; +{ + print_message_queue (); + diff_error ("%s", m, 0); + DIFF_ABORT (2); +} + +/* Like printf, except if -l in effect then save the message and print later. + This is used for things like "binary files differ" and "Only in ...". */ + +void +message (format, arg1, arg2) + char const *format, *arg1, *arg2; +{ + message5 (format, arg1, arg2, 0, 0); +} + +void +message5 (format, arg1, arg2, arg3, arg4) + char const *format, *arg1, *arg2, *arg3, *arg4; +{ + if (paginate_flag) + { + struct msg *new = (struct msg *) xmalloc (sizeof (struct msg)); + new->format = format; + new->arg1 = concat (arg1, "", ""); + new->arg2 = concat (arg2, "", ""); + new->arg3 = arg3 ? concat (arg3, "", "") : 0; + new->arg4 = arg4 ? concat (arg4, "", "") : 0; + new->next = 0; + *msg_chain_end = new; + msg_chain_end = &new->next; + } + else + { + if (sdiff_help_sdiff) + putc (' ', outfile); + fprintf (outfile, format, arg1, arg2, arg3, arg4); + } +} + +/* Output all the messages that were saved up by calls to `message'. */ + +void +print_message_queue () +{ + struct msg *m; + + for (m = msg_chain; m; m = m->next) + fprintf (outfile, m->format, m->arg1, m->arg2, m->arg3, m->arg4); +} + +/* Call before outputting the results of comparing files NAME0 and NAME1 + to set up OUTFILE, the stdio stream for the output to go to. + + Usually, OUTFILE is just stdout. But when -l was specified + we fork off a `pr' and make OUTFILE a pipe to it. + `pr' then outputs to our stdout. */ + +static char const *current_name0; +static char const *current_name1; +static int current_depth; + +static int output_in_progress = 0; + +void +setup_output (name0, name1, depth) + char const *name0, *name1; + int depth; +{ + current_name0 = name0; + current_name1 = name1; + current_depth = depth; +} + +#if HAVE_FORK && defined (PR_PROGRAM) +static pid_t pr_pid; +#endif + +void +begin_output () +{ + char *name; + + if (output_in_progress) + return; + output_in_progress = 1; + + /* Construct the header of this piece of diff. */ + name = xmalloc (strlen (current_name0) + strlen (current_name1) + + strlen (switch_string) + 7); + /* Posix.2 section 4.17.6.1.1 specifies this format. But there is a + bug in the first printing (IEEE Std 1003.2-1992 p 251 l 3304): + it says that we must print only the last component of the pathnames. + This requirement is silly and does not match historical practice. */ + sprintf (name, "diff%s %s %s", switch_string, current_name0, current_name1); + + if (paginate_flag) + { + /* Make OUTFILE a pipe to a subsidiary `pr'. */ + +#ifdef PR_PROGRAM + +# if HAVE_FORK + int pipes[2]; + + if (pipe (pipes) != 0) + pfatal_with_name ("pipe"); + + fflush (stdout); + + pr_pid = vfork (); + if (pr_pid < 0) + pfatal_with_name ("vfork"); + + if (pr_pid == 0) + { + close (pipes[1]); + if (pipes[0] != STDIN_FILENO) + { + if (dup2 (pipes[0], STDIN_FILENO) < 0) + pfatal_with_name ("dup2"); + close (pipes[0]); + } + + execl (PR_PROGRAM, PR_PROGRAM, "-f", "-h", name, 0); + pfatal_with_name (PR_PROGRAM); + } + else + { + close (pipes[0]); + outfile = fdopen (pipes[1], "w"); + if (!outfile) + pfatal_with_name ("fdopen"); + } +# else /* ! HAVE_FORK */ + char *command = xmalloc (4 * strlen (name) + strlen (PR_PROGRAM) + 10); + char *p; + char const *a = name; + sprintf (command, "%s -f -h ", PR_PROGRAM); + p = command + strlen (command); + SYSTEM_QUOTE_ARG (p, a); + *p = 0; + outfile = popen (command, "w"); + if (!outfile) + pfatal_with_name (command); + free (command); +# endif /* ! HAVE_FORK */ +#else + fatal ("This port does not support the --paginate option to diff."); +#endif + } + else + { + + /* If -l was not specified, output the diff straight to `stdout'. */ + + /* If handling multiple files (because scanning a directory), + print which files the following output is about. */ + if (current_depth > 0) + fprintf (outfile, "%s\n", name); + } + + free (name); + + /* A special header is needed at the beginning of context output. */ + switch (output_style) + { + case OUTPUT_CONTEXT: + print_context_header (files, 0); + break; + + case OUTPUT_UNIFIED: + print_context_header (files, 1); + break; + + default: + break; + } +} + +/* Call after the end of output of diffs for one file. + If -l was given, close OUTFILE and get rid of the `pr' subfork. */ + +void +finish_output () +{ + if (paginate_flag && outfile != 0 && outfile != stdout) + { +#ifdef PR_PROGRAM + int wstatus; + if (ferror (outfile)) + fatal ("write error"); +# if ! HAVE_FORK + wstatus = pclose (outfile); +# else /* HAVE_FORK */ + if (fclose (outfile) != 0) + pfatal_with_name ("write error"); + if (waitpid (pr_pid, &wstatus, 0) < 0) + pfatal_with_name ("waitpid"); +# endif /* HAVE_FORK */ + if (wstatus != 0) + fatal ("subsidiary pr failed"); +#else + fatal ("internal error in finish_output"); +#endif + } + + output_in_progress = 0; +} + +/* Compare two lines (typically one from each input file) + according to the command line options. + For efficiency, this is invoked only when the lines do not match exactly + but an option like -i might cause us to ignore the difference. + Return nonzero if the lines differ. */ + +int +line_cmp (s1, s2) + char const *s1, *s2; +{ + register unsigned char const *t1 = (unsigned char const *) s1; + register unsigned char const *t2 = (unsigned char const *) s2; + + while (1) + { + register unsigned char c1 = *t1++; + register unsigned char c2 = *t2++; + + /* Test for exact char equality first, since it's a common case. */ + if (c1 != c2) + { + /* Ignore horizontal white space if -b or -w is specified. */ + + if (ignore_all_space_flag) + { + /* For -w, just skip past any white space. */ + while (ISSPACE (c1) && c1 != '\n') c1 = *t1++; + while (ISSPACE (c2) && c2 != '\n') c2 = *t2++; + } + else if (ignore_space_change_flag) + { + /* For -b, advance past any sequence of white space in line 1 + and consider it just one Space, or nothing at all + if it is at the end of the line. */ + if (ISSPACE (c1)) + { + while (c1 != '\n') + { + c1 = *t1++; + if (! ISSPACE (c1)) + { + --t1; + c1 = ' '; + break; + } + } + } + + /* Likewise for line 2. */ + if (ISSPACE (c2)) + { + while (c2 != '\n') + { + c2 = *t2++; + if (! ISSPACE (c2)) + { + --t2; + c2 = ' '; + break; + } + } + } + + if (c1 != c2) + { + /* If we went too far when doing the simple test + for equality, go back to the first non-white-space + character in both sides and try again. */ + if (c2 == ' ' && c1 != '\n' + && (unsigned char const *) s1 + 1 < t1 + && ISSPACE(t1[-2])) + { + --t1; + continue; + } + if (c1 == ' ' && c2 != '\n' + && (unsigned char const *) s2 + 1 < t2 + && ISSPACE(t2[-2])) + { + --t2; + continue; + } + } + } + + /* Lowercase all letters if -i is specified. */ + + if (ignore_case_flag) + { + if (ISUPPER (c1)) + c1 = tolower (c1); + if (ISUPPER (c2)) + c2 = tolower (c2); + } + + if (c1 != c2) + break; + } + if (c1 == '\n') + return 0; + } + + return (1); +} + +/* Find the consecutive changes at the start of the script START. + Return the last link before the first gap. */ + +struct change * +find_change (start) + struct change *start; +{ + return start; +} + +struct change * +find_reverse_change (start) + struct change *start; +{ + return start; +} + +/* Divide SCRIPT into pieces by calling HUNKFUN and + print each piece with PRINTFUN. + Both functions take one arg, an edit script. + + HUNKFUN is called with the tail of the script + and returns the last link that belongs together with the start + of the tail. + + PRINTFUN takes a subscript which belongs together (with a null + link at the end) and prints it. */ + +void +print_script (script, hunkfun, printfun) + struct change *script; + struct change * (*hunkfun) PARAMS((struct change *)); + void (*printfun) PARAMS((struct change *)); +{ + struct change *next = script; + + while (next) + { + struct change *this, *end; + + /* Find a set of changes that belong together. */ + this = next; + end = (*hunkfun) (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; +#ifdef DEBUG + debug_script (this); +#endif + + /* Print this hunk. */ + (*printfun) (this); + + /* Reconnect the script so it will all be freed properly. */ + end->link = next; + } +} + +/* Print the text of a single line LINE, + flagging it with the characters in LINE_FLAG (which say whether + the line is inserted, deleted, changed, etc.). */ + +void +print_1_line (line_flag, line) + char const *line_flag; + char const * const *line; +{ + char const *text = line[0], *limit = line[1]; /* Help the compiler. */ + FILE *out = outfile; /* Help the compiler some more. */ + char const *flag_format = 0; + + /* If -T was specified, use a Tab between the line-flag and the text. + Otherwise use a Space (as Unix diff does). + Print neither space nor tab if line-flags are empty. */ + + if (line_flag && *line_flag) + { + flag_format = tab_align_flag ? "%s\t" : "%s "; + fprintf (out, flag_format, line_flag); + } + + output_1_line (text, limit, flag_format, line_flag); + + if ((!line_flag || line_flag[0]) && limit[-1] != '\n') + fprintf (out, "\n\\ No newline at end of file\n"); +} + +/* Output a line from TEXT up to LIMIT. Without -t, output verbatim. + With -t, expand white space characters to spaces, and if FLAG_FORMAT + is nonzero, output it with argument LINE_FLAG after every + internal carriage return, so that tab stops continue to line up. */ + +void +output_1_line (text, limit, flag_format, line_flag) + char const *text, *limit, *flag_format, *line_flag; +{ + if (!tab_expand_flag) + fwrite (text, sizeof (char), limit - text, outfile); + else + { + register FILE *out = outfile; + register unsigned char c; + register char const *t = text; + register unsigned column = 0; + + while (t < limit) + switch ((c = *t++)) + { + case '\t': + { + unsigned spaces = TAB_WIDTH - column % TAB_WIDTH; + column += spaces; + do + putc (' ', out); + while (--spaces); + } + break; + + case '\r': + putc (c, out); + if (flag_format && t < limit && *t != '\n') + fprintf (out, flag_format, line_flag); + column = 0; + break; + + case '\b': + if (column == 0) + continue; + column--; + putc (c, out); + break; + + default: + if (ISPRINT (c)) + column++; + putc (c, out); + break; + } + } +} + +int +change_letter (inserts, deletes) + int inserts, deletes; +{ + if (!inserts) + return 'd'; + else if (!deletes) + return 'a'; + else + return 'c'; +} + +/* Translate an internal line number (an index into diff's table of lines) + into an actual line number in the input file. + The internal line number is LNUM. FILE points to the data on the file. + + Internal line numbers count from 0 starting after the prefix. + Actual line numbers count from 1 within the entire file. */ + +int +translate_line_number (file, lnum) + struct file_data const *file; + int lnum; +{ + return lnum + file->prefix_lines + 1; +} + +void +translate_range (file, a, b, aptr, bptr) + struct file_data const *file; + int a, b; + int *aptr, *bptr; +{ + *aptr = translate_line_number (file, a - 1) + 1; + *bptr = translate_line_number (file, b + 1) - 1; +} + +/* Print a pair of line numbers with SEPCHAR, translated for file FILE. + If the two numbers are identical, print just one number. + + Args A and B are internal line numbers. + We print the translated (real) line numbers. */ + +void +print_number_range (sepchar, file, a, b) + int sepchar; + struct file_data *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%c%d", trans_a, sepchar, trans_b); + else + fprintf (outfile, "%d", trans_b); +} + +/* Look at a hunk of edit script and report the range of lines in each file + that it applies to. HUNK is the start of the hunk, which is a chain + of `struct change'. The first and last line numbers of file 0 are stored in + *FIRST0 and *LAST0, and likewise for file 1 in *FIRST1 and *LAST1. + Note that these are internal line numbers that count from 0. + + If no lines from file 0 are deleted, then FIRST0 is LAST0+1. + + Also set *DELETES nonzero if any lines of file 0 are deleted + and set *INSERTS nonzero if any lines of file 1 are inserted. + If only ignorable lines are inserted or deleted, both are + set to 0. */ + +void +analyze_hunk (hunk, first0, last0, first1, last1, deletes, inserts) + struct change *hunk; + int *first0, *last0, *first1, *last1; + int *deletes, *inserts; +{ + int l0, l1, show_from, show_to; + int i; + int trivial = ignore_blank_lines_flag || ignore_regexp_list; + struct change *next; + + show_from = show_to = 0; + + *first0 = hunk->line0; + *first1 = hunk->line1; + + next = hunk; + do + { + l0 = next->line0 + next->deleted - 1; + l1 = next->line1 + next->inserted - 1; + show_from += next->deleted; + show_to += next->inserted; + + for (i = next->line0; i <= l0 && trivial; i++) + if (!ignore_blank_lines_flag || files[0].linbuf[i][0] != '\n') + { + struct regexp_list *r; + char const *line = files[0].linbuf[i]; + int len = files[0].linbuf[i + 1] - line; + + for (r = ignore_regexp_list; r; r = r->next) + if (0 <= re_search (&r->buf, line, len, 0, len, 0)) + break; /* Found a match. Ignore this line. */ + /* If we got all the way through the regexp list without + finding a match, then it's nontrivial. */ + if (!r) + trivial = 0; + } + + for (i = next->line1; i <= l1 && trivial; i++) + if (!ignore_blank_lines_flag || files[1].linbuf[i][0] != '\n') + { + struct regexp_list *r; + char const *line = files[1].linbuf[i]; + int len = files[1].linbuf[i + 1] - line; + + for (r = ignore_regexp_list; r; r = r->next) + if (0 <= re_search (&r->buf, line, len, 0, len, 0)) + break; /* Found a match. Ignore this line. */ + /* If we got all the way through the regexp list without + finding a match, then it's nontrivial. */ + if (!r) + trivial = 0; + } + } + while ((next = next->link) != 0); + + *last0 = l0; + *last1 = l1; + + /* If all inserted or deleted lines are ignorable, + tell the caller to ignore this hunk. */ + + if (trivial) + show_from = show_to = 0; + + *deletes = show_from; + *inserts = show_to; +} + +/* Concatenate three strings, returning a newly malloc'd string. */ + +char * +concat (s1, s2, s3) + char const *s1, *s2, *s3; +{ + size_t len = strlen (s1) + strlen (s2) + strlen (s3); + char *new = xmalloc (len + 1); + sprintf (new, "%s%s%s", s1, s2, s3); + return new; +} + +/* Yield the newly malloc'd pathname + of the file in DIR whose filename is FILE. */ + +char * +dir_file_pathname (dir, file) + char const *dir, *file; +{ + char const *p = filename_lastdirchar (dir); + return concat (dir, "/" + (p && !p[1]), file); +} + +void +debug_script (sp) + struct change *sp; +{ + fflush (stdout); + for (; sp; sp = sp->link) + fprintf (stderr, "%3d %3d delete %d insert %d\n", + sp->line0, sp->line1, sp->deleted, sp->inserted); + fflush (stderr); +} diff --git a/contrib/cvs/diff/version.c b/contrib/cvs/diff/version.c new file mode 100644 index 0000000..343a098 --- /dev/null +++ b/contrib/cvs/diff/version.c @@ -0,0 +1,5 @@ +/* Version number of GNU diff. */ + +#include <config.h> + +char const diff_version_string[] = "2.7"; diff --git a/contrib/cvs/doc/ChangeLog b/contrib/cvs/doc/ChangeLog index c56c253..0571444 100644 --- a/contrib/cvs/doc/ChangeLog +++ b/contrib/cvs/doc/ChangeLog @@ -1,5 +1,704 @@ +Sun Jan 18 18:23:02 1998 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvsclient.texi (Requests): Add Kopt request. + +Thu Jan 1 17:36:42 1998 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvs.texinfo (BUGS, Credits): Change @unnumbered to @appendix now + that these are moved from the start to the end. + +Sat Dec 27 10:06:56 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvs.texinfo (Error messages): Add "Too many arguments!". + +Fri Dec 26 18:30:26 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvs.texinfo (What is CVS?): Just point to the two canonical web + sites (Pascal Molli and Cyclic) concerning CVS downloads. The GNU + URL was out of date and GNU only has source distributions anyway. + + * cvs.texinfo: Change bug-cvs address to gnu.org per email from + Martin Hamilton. + +Tue Dec 23 18:04:09 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvs.texinfo (Sticky tags): Further cleanups. Fix thinko + (s/subsequent cvs update/& commands/). Remove "vi driver.c" and + commit from example (totally vestigial). Reword start of + paragraph on non-branch sticky tags, so that it better alludes + to branch sticky tags. When introducing sticky tags, make it + clear that even people who aren't trying to use sticky tags + may need to know how to avoid them. Restore comment about + CVS/Tag files. + (Accessing branches): Don't xref to merging here; that is a much + more advanced topic and the "but see" wording didn't tell us what + to see the xref about. + +Tue Dec 23 14:39:08 1997 Karl Fogel <kfogel@floss.red-bean.com> + and Jim Kingdon + + * cvs.texinfo (Creating a branch): Rewritten. Introduce with + `tag', then discuss `rtag' and `-r'. + +Tue Dec 23 10:03:37 1997 Karl Fogel <kfogel@floss.red-bean.com> + and Jim Kingdon + + * cvs.texinfo: Changes to dehairify the "Sticky tags" situation: + (Revisions): "Sticky tags" moved here, description in menu changed + to be a little more informative. + (Sticky tags): Moved from "Branching and merging" to "Revisions". + (Accessing branches): New node in "Branching and merging", + explains how to use checkout vs update to retrieve a branch. + Text and example inherited from "Sticky tags", but text mostly + rewritten. + (Sticky tags): Moved under "Revisions", rewritten somewhat (more + rewrites to follow). + Don't use "-v" in "cvs status" example. + +Mon Dec 22 11:46:05 1997 Karl Fogel <kfogel@floss.red-bean.com> + and Jim Kingdon + + Cleanups related to recent separation of revisions from + branching/merging: + * cvs.texinfo (Revisions): Take paragraph introducing branches, + rewrite it and move it to "Branching and merging". + (Branching and merging): Also rewrite merging intro. + (Revision numbers): Don't go into detail about branch revision + numbers here, just mention that they happen and refer to new + node "Branches and revisions". + (Branches and revisions): New node under "Branching and merging", + inherits text from "Revision numbers". + (Creating a branch): Refer to "Branches and revisions" now, not + "Revision numbers". + (Binary why): Rewrite sentence which refers to merging, so that + it isn't specific to branch merging. + (Branches motivation): Fix typo (select -> elect). Add comment + about what this node is accomplishing, in general. + +Sun Dec 21 20:57:24 1997 Karl Fogel <kfogel@floss.red-bean.com> + and Jim Kingdon + + This is just moving text; related cleanups to follow. + * cvs.texinfo: Changes to put branching and merging together, and + keep it all separate from revisions: + (Revisions): Renamed from "Revisions and branches". + (Branching and merging): Renamed from "Merging". + (Branches motivation, Creating a branch, Sticky tags, Magic branch + numbers): these subnodes moved to "Branching and merging" from + "Revisions". + everywhere: Adjusted cross-references to cope with above. + +Sun Dec 21 20:36:39 1997 Karl Fogel <kfogel@floss.red-bean.com> + and Jim Kingdon + + Note that this is just moving text, not changing it: + * cvs.texinfo: divide top-level menu into sections. + (Multiple developers, Builds, Tracking sources, Keyword + substitution): moved to be in "CVS and the Real World" section. + (Compatibility): moved to be in "References" section. + +Mon Dec 22 08:54:31 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvsclient.texi (Example): In comment, in citing the BNF style + used in many RFCs, cite RFC2234 not RFC822 (now that the former is + out). + +Sun Dec 21 17:42:22 1997 Karl Fogel <kfogel@floss.red-bean.com> + + * cvs.texinfo (Overview): New node. + (What is CVS?, A sample session): Put under Overview. + (What is CVS not?): New node under Overview. + [text previously was part of "What is CVS?" -kingdon] + (Preface): Removed this node and its contents. + (Checklist): Removed this node and its contents. + (Credits): Now toward end of top-level menu (was under Preface). + (BUGS): Now toward end of top-level menu (was under Preface). + +Sun Dec 14 10:14:25 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvsclient.texi (Responses): Add MT response. + (Text tags): New node. + + * cvs.texinfo (loginfo): Add comment about which commands run + loginfo. + +Sat Dec 13 08:41:13 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvsclient.texi (Connection and Authentication): State that + GSSAPI is preferred to kserver. Try to be clearer about what + the term "pserver" means. Introduce GSSAPI and cite the relevant + RFCs. Discuss the limitations of the existing features in + preventing hijacking. + + * cvs.texinfo (GSSAPI authenticated, Kerberos authenticated): + Briefly introduce what GSSAPI and Kerberos are. Be slightly more + emphatic about protecting against downgrade attacks. + +Fri Dec 12 17:36:46 1997 Ian Lance Taylor <ian@cygnus.com> + + * cvs.texinfo (GSSAPI authenticated): New node. + (Global options): Document -a. Mention GSSAPI in -x + documentation. + * cvsclient.texi (Connection and Authentication): Document GSSAPI + authentication. + (Requests): Add Gssapi-encrypt and Gssapi-authenticate. + +Fri Dec 12 09:27:38 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvs.texinfo (cvsignore): Add note about comments and the + space-separated nature of the syntax. + +Sun Dec 7 09:33:11 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvs.texinfo (checkout): Clarify issues regarding updating + existing working directories. + +Sun Nov 30 20:38:17 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvs.texinfo (Wrappers): Add comment: we don't document %s. + +Mon Nov 24 23:00:09 1997 Karl Fogel <kfogel@floss.red-bean.com> + and Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvsclient.texi: Move Protocol Notes node to the end. + + * cvsclient.texi (Request intro): new node/section. + (Protocol): added some introductory material. + Rearranged menu into General Conventions, Protocol specification, + and Example etc sections. + (File Modes): replaces Modes, for consistency. + +Sat Nov 22 12:29:58 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvsclient.texi (Entries Lines): Clarify options in entries line. + +Tue Nov 18 09:23:15 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvsclient.texi (Requests): Be more explicit about "export" and + entries lines. + + * Makefile.in (DISTFILES): Remove DIFFUTILS-2.7-BUG. + +Mon Nov 17 18:20:47 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvs.texinfo (tag options): Expand comment with reference to FAQ. + +Fri Nov 14 11:02:37 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvs.texinfo (Error messages): Update discussion of "dying gasps". + + * cvs.texinfo (tag options): Add FIXME comment about renaming tags. + +Thu Nov 13 10:20:39 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvs.texinfo (Common options): Remove also has a -f option with a + different meaning than most. + +Wed Nov 12 21:57:40 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvs.texinfo (File permissions, Connecting via rsh, Environment + variables): When putting an environment variable in the index, say + it is an environment variable. Don't index the same name twice. + + * cvs.texinfo: Many edits to reflect the fact that CVS no longer + invokes external RCS programs. + +Tue Nov 11 15:15:49 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvs.texinfo (Locks, CVS in repository): New nodes, document the + locking scheme and briefly outline CVS and CVS/fileattr. + +Sun Nov 9 17:39:41 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * DIFFUTILS-2.7-BUG: Removed; the bug is fixed and the testcases + are incorporated into sanity.sh. + +Sat Nov 8 09:49:38 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvs.texinfo (Binary why): Try to be a little clearer about how + merges fit into CVS. Say it may be error prone to have developers + doing merges manually. + +Tue Nov 4 13:02:22 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvs.texinfo (admin options): Add discussion of what happens if + there are tags. + +Fri Oct 31 00:04:09 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvs.texinfo (admin options): Rewrite discussion of -o to + hopefully be clearer and to also document the new :: syntax. + (admin examples): Removed; incorporated into admin options. + (Invoking CVS): Wording fix for admin -o. + + * cvs.texinfo (Binary why): New node, talks about diff and merge. + (Binary howto): Renamed from Binary files. + (Binary files): Now just contains an introduction. + + * cvs.texinfo (Error messages): Add "could not merge" message. In + discussion of "Binary files . . . differ" message, mention that + this is only an issue with old verisons of CVS. + +Thu Oct 30 15:55:21 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvs.texinfo (Error messages): Add "authorization failed" message. + +Wed Oct 29 11:52:05 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvs.texinfo: Remove fake RCSid; we decided to remove rcsid's a + while ago. Cleanups suggested by Stephen Gildea (CVSROOT/passwd + has 2 or 3 fields; /user -> /usr; noone -> no one; in used -> in + use). Add comment about making compilers happy about rcsids. + +Sat Oct 25 00:58:24 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * RCSFILES: rcsfile.5 is correct about {num} after next being + optional. + +Wed Oct 22 10:08:27 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvs.texinfo (Error messages): Add message about unrecognized + response from cvs server. + +1997-10-11 Noel Cragg <noel@swish.red-bean.com> + + * cvs.texinfo (checkout options): describe how the `-d' and `-N' + flags really work. Give examples. + (export options): refer the reader to the descriptions for `-d' + and `-N' in checkout options, since the behavior is the same. + +Thu Oct 9 12:01:35 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvs.texinfo (log options): Add comment about "cvs log -r". + +Wed Oct 8 10:24:19 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvs.texinfo (rtag options): Add comment about how this is + confusing. + +Tue Sep 30 12:31:25 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvs.texinfo (Working directory storage): Add comment about + Entries.Static. + +Thu Sep 25 23:52:57 1997 Noel Cragg <noel@swish.red-bean.com> + + * cvsclient.texi (Responses): description of Module-expansion was + missing a carriage return after the @item clause. + +Wed Sep 24 12:04:42 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvs.texinfo (Remote repositories): Add comment about pserver + vs. having users create their own repositories. + +Sat Sep 20 00:59:53 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvs.texinfo (Keyword list): Change title from "RCS Keywords" to + "Keyword list" as it is CVS that expands them. + (Avoiding substitution): Change "rcs" to "cvs", in the context of + the program which expands keywords. + +Fri Sep 19 22:57:24 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * RCSFILES: Grammar fix in first paragraph. Re-word section on + dead newphrase. Add item about what it means if "expand" is omitted. + + * cvs.texinfo (Magic branch numbers): Change example branch number + from 1.2.3 to 1.2.4; CVS assigns even branch numbers and I don't + think vendor branches are very relevant to this example. + +Wed Sep 17 17:21:33 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvs.texinfo (admin options): Add comment about "cvs admin -b" + (with no argument to the -b). + + * RCSFILES: "next" is optional, not required. + +Tue Sep 16 15:13:22 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvs.texinfo (Binary files): Add comment about another possible + way to auto-detect binary files. + +Sun Sep 14 12:38:56 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvs.texinfo (Conflicts example): Adjust text and comments + regarding conflict markers to reflect change in CVS. + +Wed Sep 10 12:44:04 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvs.texinfo (Server requirements): Add comment about server + disk usage in /tmp. + + * cvs.texinfo (Common options): More comments about date formats: + "now", "yesterday", and the "3 weeks ago" family. + +Tue Sep 9 13:09:58 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * DIFFUTILS-2.7-BUG: Eggert patch is preferred to Rittle one. + +Sun Sep 7 18:38:23 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvs.texinfo (history options): Revise -e to say that it includes + future record types (and remove out of date list of what record + types it implies). + + * cvs.texinfo (Environment variables): Expand/correct discussion + of HOME, HOMEDRIVE, and HOMEPATH. + (Error messages): Add "could not find out home directory". + + * cvs.texinfo (update options): Reword -r doc to hopefully be + clearer that it takes either numeric or symbolic revision. + + * cvs.texinfo (syntax): Add comment about how regexp syntax may + be, er, creatively altered, by configure.in. + +Sat Sep 6 11:29:15 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvs.texinfo (Working directory storage): Document Baserev and + Baserev.tmp. + (Working directory storage): Adjust comment regarding CVS/* being + text files. + +Fri Sep 5 14:42:39 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvs.texinfo (BUGS): Remove mention of unsupported resources page + on http://www.cyclic.com, as it might go away in a future + reorganization. + + * DIFFUTILS-2.7-BUG: Further info from Eggert. + +1997-09-05 Paul Eggert <eggert@twinsun.com> + + * DIFFUTILS-2.7-BUG: Explain how this bug will probably be + fixed in the next diffutils release. + +Thu Sep 4 17:09:57 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvs.texinfo (Binary files): Reword the section on what you need + to do with cvs admin -kb to hopefully be a bit clearer. Still not + ideal (see comment). + + * cvs.texinfo (modules): Break node into separate nodes for alias + modules, regular modules, ampersand modules, and options. Expand + text with more examples and explanations. Add index entries. + +Wed Sep 3 14:49:43 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvs.texinfo (Multiple developers): Add idea about cvs editors + and reserved checkouts. + +Sun Aug 31 19:36:21 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvsclient.texi (Requests): Rewrite paragraph on cvs add on a + filename containing '/'. + +Thu Aug 28 14:13:50 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvs.texinfo (diff options): Add comment about "cvs diff" + vs. "cvs diff -r HEAD". + + * cvs.texinfo (Global options): Add comment about -w not + overriding cvs watch on. + +Wed Aug 27 08:09:31 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvs.texinfo (Password authentication server): Grammar fix ("under + as the username" -> "as the username"). + + * cvs.texinfo: Fix doubled 'the the' typos. Reported by + karlb@atg.com. + +Tue Aug 26 12:25:42 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvs.texinfo (Checklist): Reword xref to point to Binary files + rather than Keyword expansion. Credit goes to jeff@alum.mit.edu + (Jeff Breidenbach) for reporting the problem. + +Mon Aug 18 17:23:18 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvs.texinfo (modules): Suggest taginfo instead of -t. Add + comment with some of the reasons. Add comment about -u and -i + problems. + +Sat Aug 16 10:19:06 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvs.texinfo (Error messages): Add note about how "could not + check out foo.c" seems to also have been observed on Irix. + +Fri Aug 15 17:28:01 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvs.texinfo (Error messages): Add "could not check out foo.c". + +Thu Aug 14 23:57:53 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvs.texinfo (Wrappers): Document new -m 'COPY' behavior. + +Tue Aug 12 20:56:40 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvs.texinfo (Sticky tags): Add comment about how we should be + documenting sticky tags. + +Fri Aug 8 10:01:03 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvs.texinfo (File status): Add comment about "working revision" + in cvs status for a locally removed file. + +Thu Aug 7 22:53:45 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvs.texinfo (From other version control systems): Mention + pvcs_to_rcs alongside sccs2rcs. + +Tue Aug 5 17:22:50 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvs.texinfo (Compatibility): Add comment about how CVS probably + could be detecting the case of dead files killed by CVS 1.3. + + * cvs.texinfo (From other version control systems): Add paragraph + about converting from systems which don't export RCS files. + +Sun Aug 3 21:03:14 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvsclient.texi (Responses): Cite RFC1321 for MD5. + + * cvs.texinfo (A sample session): Nuke index entry for "A sample + session". The fact that this isn't "sample session" is totally + bogus, but in general the table of contents is probably better for + this entry. + + * cvs.texinfo (Error messages): Add comment about wording of error + concerning unknown -x option. + + * cvs.texinfo (Wrappers): Add comment about absolute filter pathname. + +Thu Jul 31 14:40:15 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvs.texinfo: Use @ref not @xref when reference is not at the + start of a sentence. Avoids capitalizing "See" when we shouldn't. + Fixes to other similar xref problems. + +Wed Jul 30 19:30:31 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvsclient.texi (Connection and Authentication): Don't use @samp + on BEGIN AUTH REQUEST and friends. Avoids overfull hbox. + +Fri Jul 25 10:40:22 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvsclient.texi (Requests): Remove obsolete sentence regarding + using Directory instead of Repository enabling alternate response + syntax. + + * cvsclient.texi (Response intro): Add discussing of file updating + responses and file update modifying responses. + (Responses): Refer to this description rather than trying to + describe it in each place. The descriptions in each place were + somewhat incomplete and didn't get updated when new file updating + responses were added. + + * cvsclient.texi: Split node Responses into Response intro, + Response pathnames, and Responses. + +Thu Jul 24 23:13:24 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvs.texinfo (config): Document SystemAuth. + (Password authentication server): Mention SystemAuth. + +Mon Jul 21 08:57:04 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * Makefile.in (DISTFILES): Add DIFFUTILS-2.7-BUG. + +Sun Jul 20 17:55:52 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvs.texinfo (admin options): For options with optional + arguments, specify that there can be no space between the option + and its argument. For -N, add xref to Magic branch numbers. For + -t, talk about reading from stdin. Comment changes. + +Sat Jul 19 22:28:47 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvs.texinfo (Preface): Make section titles more verbose. + Likewise for the menu. + +Fri Jul 18 08:41:11 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvs.texinfo (Error messages): No need for an external patch if + server and client are current. Add comment with more thoughts + about messages specific to old versions of CVS. + + * cvs.texinfo (Error messages): Add "cannot start server via rcmd". + + * cvs.texinfo (Error messages): Add "cannot open CVS/Root" for cvs + init. + + * cvs.texinfo (Error messages): Add "missing author". + +Tue Jul 15 16:47:08 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvs.texinfo (Keyword list): Fix documentation of $Log to reflect + the fact that we no longer use the comment leader. + (admin options): Fix documentation of $Log. + (admin examples): Remove example concerning comment leader, since + the example no longer does what it claims to. + (admin, admin options): Fix various parts of the documentation to + not refer to this being implemented via RCS. Say nastier things + about -I and -x. Add comments about options to "rcs" which we + don't document. + +Mon Jul 14 00:04:32 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvs.texinfo (Error messages): The "cannot change permissions on + temporary directory" error has been happening in various test cases. + +Sat Jul 12 11:12:18 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvs.texinfo (Repository files): Further comments about leading + "-" in filenames. + +Fri Jul 11 21:30:11 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvs.texinfo (Repository files): Add comment about legal + filenames. + +Wed Jul 9 18:05:26 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvsclient.texi (Responses): Add Mbinary response. + +Mon Jul 7 12:04:01 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvsclient.texi (Goals): Add previously unwritten goal about only + one way to do each operation. + + * cvs.texinfo (File permissions): Rewrite paragraph on setuid to + be more verbose and less unix-specific. + +Sat Jul 5 03:16:38 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvsclient.texi (Connection and Authentication): When we said to + "ignore" an unrecogized code we mean to treat it as nonspecific, + not to ignore the response. + + * cvsclient.texi (Example): Refer to RFC2119 when referring to + terminology of MUST, SHALL, &c. + + * cvs.texinfo (Windows permissions): New node. + +Fri Jul 4 15:27:43 1997 Ian Lance Taylor <ian@cygnus.com> + + * cvs.texinfo (Common options): Fix typo (avaliable for + available). + +Tue Jul 1 09:19:02 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvs.texinfo (Server requirements): Discuss memory used by diff. + + * cvs.texinfo (Substitution modes): Add comment about -A resetting + both sticky tags/dates and sticky options. + + * cvs.texinfo (File permissions): Add paragraph concerning + ownership of the RCS files. + + * cvs.texinfo (Working directory storage): Relative repositories + in CVS/Repository are legal. + +Mon Jun 30 10:48:21 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvsclient.texi (Top): Add menu item for Password scrambling. + + * cvs.texinfo (Committing your changes): Add comment concerning + documentation of message prompting. + +Fri Jun 27 11:20:34 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvsclient.texi (Password scrambling): New node. + (Connection and Authentication): Adjust accordingly. + (Protocol Notes): Add long discussion of character sets and + password scrambling. + + * cvs.texinfo (Repository files): Also mention doc/RCSFILES in + documenting RCS file format. + (CVSROOT, storage of files): New node. + +Thu Jun 26 09:18:15 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvs.texinfo (File permissions): xref to the pserver thing about + permissions in CVSROOT. + (Kerberos authenticated): Explicitly mention kerberos rsh. + Add various index entries for "security, <foo>". + +Wed Jun 25 13:39:16 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvs.texinfo (Common options): Rewrite comments concerning HEAD + and testcases and solution. Changing HEAD might be too big a + change; might be better to phase it out. + (Common options, Tags): Add index entries for HEAD and BASE. + +Tue Jun 24 09:37:26 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvs.texinfo (Error messages): Add assertion failed. + + * cvsclient.texi (Connection and Authentication): Add "E" and + "error" as responses in authentication protocol. The server + already was in the (formerly bad) habit of sending them, and we + might as well implement this in the client and document it. + + * cvs.texinfo (Password authentication security): Note about + permissions on $CVSROOT also applies to its parent and so on up to + /. + +Mon Jun 23 18:28:18 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvs.texinfo (Creating a repository): xref to Server requirements + for more details on memory, CPU. + (Server requirements): Add xref to Creating a repository regarding + disk space. + + * cvs.texinfo (Read-only access, Password authentication + security): The known holes which let a read-only user execute + arbitrary programs on the server are gone. + + * cvsclient.texi (Protocol Notes): Remove multisite item; it is + replaced by item 186 in TODO. Add a general reference to TODO. + Rewrite accordingly the sentence about multisite in the item + concerning sending modified files in "cvs update". + +Fri Jun 20 17:00:20 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvs.texinfo (Error messages): Add "binary files differ" when + trying to check in a binary file. + +Fri Jun 20 14:01:23 1997 David J MacKenzie <djm@va.pubnix.com> + and Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvs.texinfo: Fix various formatting, spelling, stylistic, and + factual errors. + +Thu Jun 19 07:11:33 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvs.texinfo (config): New node. + (Password authentication server): Talk about RCSBIN in config as + an alternative to -b global option. + * cvsclient.texi (Requests): Specify when Root can/must be used. + + * cvs.texinfo (Error messages): Add + "*PANIC* administration files missing". + + * cvs.texinfo (Password authentication server): Mention + permissions on $CVSROOT and $CVSROOT/CVSROOT as part of the + installation process. + (Password authentication security): Clarify that permissions issue + applies to $CVSROOT as well as $CVSROOT/CVSROOT. + Wed Jun 18 00:03:25 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + * cvs.texinfo (Password authentication security): Add paragraph + on write permissions of $CVSROOT/CVSROOT. + + * cvs.texinfo (Adding and removing): New node. Move Adding files, + Removing files, Removing directories, Moving files, and Moving + directories under it. + + * cvs.texinfo (Removing directories): Add sentence about how + one doesn't remove the directory itself. + * cvs.texinfo (Password authentication server): Document --allow-root. diff --git a/contrib/cvs/doc/RCSFILES b/contrib/cvs/doc/RCSFILES index 5d9c7f7..6d600b8 100644 --- a/contrib/cvs/doc/RCSFILES +++ b/contrib/cvs/doc/RCSFILES @@ -1,4 +1,4 @@ -It would be nice for the RCS file format (which is implemented by a +It would be nice if the RCS file format (which is implemented by a great many tools, both free and non-free, both by calling GNU RCS and by reimplementing access to RCS files) were documented in some standard separate from any one tool. But as far as I know no such @@ -31,6 +31,10 @@ rcsfile.5 also showed the order of the revisions (and the "next" and "branch" fields and anything else where it would be useful to have an example of how a revision tree is represented in an RCS file). +The rcsfile.5 grammar shows the {num} after "next" as optional; if it +is omitted then there is no next delta node (for example 1.1 or the +head of a branch will typically have no next). + There is one case where CVS uses CVS-specific, non-compatible changes to the RCS file format, and this is magic branches. See cvs.texinfo for more information on them. CVS also sets the RCS state to "dead" @@ -54,8 +58,9 @@ rules. namespace RCS library done at Silicon Graphics Inc. (SGI) in 1996 (a modified RCS 5.7--not sure it has any other name). dead A set of RCS patches developed by Rich Pixley at - Cygnus. These were for CVS, and predated the current - CVS death support, which does not require RCS changes. + Cygnus about 1992. These were for CVS, and predated + the current CVS death support, which uses a state "dead" + rather than a "dead" newphrase. The rules regarding keyword expansion are not documented along with the rest of the RCS file format; they are documented in the co(1) @@ -66,6 +71,9 @@ RCS 5.7 produces a warning whenever it behaves that way, and current versions of CVS do not handle this case in a special way (CVS 1.9 and earlier invoke RCS to perform keyword expansion). +Note that if the "expand" keyword is omitted from the RCS file, the +default is "kv". + Note that the "comment {string};" syntax from rcsfile.5 specifies a comment leader, which affects expansion of the $Log keyword for old versions of RCS. The comment leader is not used by RCS 5.7 or current diff --git a/contrib/cvs/doc/cvs.texinfo b/contrib/cvs/doc/cvs.texinfo index b087f3f..7c2a750 100644 --- a/contrib/cvs/doc/cvs.texinfo +++ b/contrib/cvs/doc/cvs.texinfo @@ -1,5 +1,4 @@ \input texinfo @c -*-texinfo-*- -@comment cvs.texinfo,v 1.6 1995/10/12 23:39:26 kfogel Exp @comment Documentation for CVS. @comment Copyright (C) 1992, 1993 Signum Support AB @comment Copyright (C) 1993 Free Software Foundation, Inc. @@ -46,13 +45,8 @@ @c -- TODO list: @c -- Fix all lines that match "^@c -- " -@c -- Document how CVS finds the binaries it executes. -@c Things to include in the index: -@c Finding RCS binaries -@c Path to RCS binaries -@c RCS, how CVS finds them -@c s/RCS/diff/ -@c -- More on binary files +@c -- Also places marked with FIXME should be manual +@c problems (as opposed to FIXCVS for CVS problems). @ifinfo Copyright @copyright{} 1992, 1993 Signum Support AB @@ -139,277 +133,62 @@ This info manual describes how to use and administer @end ifinfo @c This menu is pretty long. Not sure how easily that -@c can be fixed; seems like "Adding files", "Removing -@c files", "Removing directories", "Moving files", -@c and "Moving directories" all go together (into -@c "Adding, removing, and renaming"?). Other than that -@c no brilliant ideas for a fix... +@c can be fixed (no brilliant ideas right away)... @menu -* Preface:: About this manual -* What is CVS?:: What is CVS? -* A sample session:: A tour of basic CVS usage +* Overview:: An introduction to CVS * Repository:: Where all your sources are stored * Starting a new project:: Starting a project with CVS -* Multiple developers:: How CVS helps a group of developers -* Revisions and branches:: Numeric, symbolic, and branch revisions -* Merging:: How to move changes between branches +* Revisions:: Numeric and symbolic names for revisions +* Branching and merging:: Diverging/rejoining branches of development * Recursive behavior:: CVS descends directories -* Adding files:: Adding files -* Removing files:: Removing files -* Removing directories:: Removing directories -* Tracking sources:: Tracking third-party sources -* Moving files:: Moving and renaming files -* Moving directories:: Moving and renaming directories +* Adding and removing:: Adding/removing/renaming files/directories * History browsing:: Viewing the history of files in various ways -* Keyword substitution:: CVS can include the revision inside the file + +CVS and the Real World. +----------------------- * Binary files:: CVS can handle binary files -* Builds:: Issues related to CVS and builds -* Compatibility:: Upgrading CVS versions +* Multiple developers:: How CVS helps a group of developers * Revision management:: Policy questions for revision management +* Keyword substitution:: CVS can include the revision inside the file +* Tracking sources:: Tracking third-party sources +* Builds:: Issues related to CVS and builds + +References. +----------- * CVS commands:: CVS commands share some things * Invoking CVS:: Quick reference to CVS commands * Administrative files:: Reference manual for the Administrative files * Environment variables:: All environment variables which affect CVS +* Compatibility:: Upgrading CVS versions * Troubleshooting:: Some tips when nothing works +* Credits:: Some of the contributors to this manual +* BUGS:: Dealing with bugs in CVS or this manual * Copying:: GNU GENERAL PUBLIC LICENSE * Index:: Index @end menu @c --------------------------------------------------------------------- -@node Preface -@unnumbered About this manual -@cindex Preface -@cindex About this manual - -Up to this point, one of the weakest parts of @sc{cvs} -has been the documentation. @sc{cvs} is a complex -program. Previous versions of the manual were written -in the manual page format, which is not really well -suited for such a complex program. - -When writing this manual, I had several goals in mind: +@node Overview +@chapter Overview +@cindex Overview -@itemize @bullet -@item -No knowledge of @sc{rcs} should be necessary. +This chapter is for people who have never used +@sc{cvs}, and perhaps have never used version control +software before. -@item -No previous knowledge of revision control software -should be necessary. All terms, such as @dfn{revision -numbers}, @dfn{revision trees} and @dfn{merging} are -explained as they are introduced. +If you are already familiar with @sc{cvs} and are just +trying to learn a particular feature or remember a +certain command, you can probably skip everything here. -@item -The manual should concentrate on the things @sc{cvs} users -want to do, instead of what the @sc{cvs} commands can do. -The first part of this manual leads you through things -you might want to do while doing development, and -introduces the relevant @sc{cvs} commands as they are -needed. - -@item -Information should be easy to find. In the reference -manual in the appendices almost all information about -every @sc{cvs} command is gathered together. There is also -an extensive index, and a lot of cross references. -@end itemize - -@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - @menu -* Checklist:: -* Credits:: -* BUGS:: +* What is CVS?:: What you can do with @sc{cvs} +* What is CVS not?:: Problems @sc{cvs} doesn't try to solve +* A sample session:: A tour of basic @sc{cvs} usage @end menu -@node Checklist -@unnumberedsec Checklist for the impatient reader - -@sc{cvs} is a complex system. You will need to read -the manual to be able to use all of its capabilities. -There are dangers that can easily be avoided if you -know about them, and this manual tries to warn you -about them. This checklist is intended to help you -avoid the dangers without reading the entire manual. -If you intend to read the entire manual you can skip -this table. - -@table @asis -@item Binary files -@sc{cvs} can handle binary files, but -you must have @sc{rcs} release 5.5 or later and -a release of @sc{gnu} diff that supports the @samp{-a} -flag (release 1.15 and later are OK). You must also -configure both @sc{rcs} and @sc{cvs} to handle binary -files when you install them. - -Keyword substitution can be a source of trouble with -binary files. @xref{Keyword substitution}, for -solutions. - -@item The @code{admin} command -Careless use of the @code{admin} command can cause -@sc{cvs} to cease working. @xref{admin}, before trying -to use it. -@end table - @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -@node Credits -@unnumberedsec Credits - -@cindex Contributors (manual) -@cindex Credits (manual) -Roland Pesch, then of Cygnus Support <@t{roland@@wrs.com}> -wrote the manual pages which were distributed with -@sc{cvs} 1.3. Much of their text was copied into this -manual. He also read an early draft -of this manual and contributed many ideas and -corrections. - -The mailing-list @code{info-cvs} is sometimes -informative. I have included information from postings -made by the following persons: -David G. Grubbs <@t{dgg@@think.com}>. - -Some text has been extracted from the man pages for -@sc{rcs}. - -The @sc{cvs} @sc{faq} by David G. Grubbs has provided -useful material. The @sc{faq} is no longer maintained, -however, and this manual is about the closest thing there -is to a successor (with respect to documenting how to -use @sc{cvs}, at least). - -In addition, the following persons have helped by -telling me about mistakes I've made: - -@display -Roxanne Brunskill <@t{rbrunski@@datap.ca}>, -Kathy Dyer <@t{dyer@@phoenix.ocf.llnl.gov}>, -Karl Pingle <@t{pingle@@acuson.com}>, -Thomas A Peterson <@t{tap@@src.honeywell.com}>, -Inge Wallin <@t{ingwa@@signum.se}>, -Dirk Koschuetzki <@t{koschuet@@fmi.uni-passau.de}> -and Michael Brown <@t{brown@@wi.extrel.com}>. -@end display - -The list of contributors here is not comprehensive; for a more -complete list of who has contributed to this manual see -the file @file{doc/ChangeLog} in the @sc{cvs} source -distribution. - -@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -@node BUGS -@unnumberedsec BUGS - -@cindex Bugs in this manual or CVS -Neither @sc{cvs} nor this manual is perfect, and they -probably never will be. If you are having trouble -using @sc{cvs}, or think you have found a bug, there -are a number of things you can do about it. Note that -if the manual is unclear, that can be considered a bug -in the manual, so these problems are often worth doing -something about as well as problems with @sc{cvs} itself. - -@cindex Reporting bugs -@cindex Bugs, reporting -@cindex Errors, reporting -@itemize @bullet -@item -If you want someone to help you and fix bugs that you -report, there are companies which will do that for a -fee. Two such companies are: - -@cindex Signum Support -@cindex Cyclic Software -@cindex Support, getting CVS support -@example -Signum Support AB -Box 2044 -S-580 02 Linkoping -Sweden -Email: info@@signum.se -Phone: +46 (0)13 - 21 46 00 -Fax: +46 (0)13 - 21 47 00 -http://www.signum.se/ - -Cyclic Software -United States of America -http://www.cyclic.com/ -info@@cyclic.com -@end example - -@item -If you got @sc{cvs} through a distributor, such as an -operating system vendor or a vendor of freeware -@sc{cd-rom}s, you may wish to see whether the -distributor provides support. Often, they will provide -no support or minimal support, but this may vary from -distributor to distributor. - -@item -If you have the skills and time to do so, you may wish -to fix the bug yourself. If you wish to submit your -fix for inclusion in future releases of @sc{cvs}, see -the file @sc{hacking} in the @sc{cvs} source -distribution. It contains much more information on the -process of submitting fixes. - -@item -There may be resources on the net which can help. Two -good places to start are: - -@example -http://www.cyclic.com - @r{particularly the Unsupported Resources page} -http://www.loria.fr/~molli/cvs-index.html -@end example - -If you are so inspired, increasing the information -available on the net is likely to be appreciated. For -example, before the standard @sc{cvs} distribution -worked on Windows 95, there was a web page with some -explanation and patches for running @sc{cvs} on Windows -95, and various people helped out by mentioning this -page on mailing lists or newsgroups when the subject -came up. - -@item -It is also possible to report bugs to @code{bug-cvs}. -Note that someone may or may not want to do anything -with your bug report---if you need a solution consider -one of the options mentioned above. People probably do -want to hear about bugs which are particularly severe -in consequences and/or easy to fix, however. You can -also increase your odds by being as clear as possible -about the exact nature of the bug and any other -relevant information. The way to report bugs is to -send email to @code{bug-cvs@@prep.ai.mit.edu}. Note -that submissions to @code{bug-cvs} may be distributed -under the terms of the @sc{gnu} Public License, so if -you don't like this, don't submit them. There is -usually no justification for sending mail directly to -one of the @sc{cvs} maintainers rather than to -@code{bug-cvs}; those maintainers who want to hear -about such bug reports read @code{bug-cvs}. Also note -that sending a bug report to other mailing lists or -newsgroups is @emph{not} a substitute for sending it to -@code{bug-cvs}. It is fine to discuss @sc{cvs} bugs on -whatever forum you prefer, but there are not -necessarily any maintainers reading bug reports sent -anywhere except @code{bug-cvs}. -@end itemize - -@cindex Known bugs in this manual or CVS -People often ask if there is a list of known bugs or -whether a particular bug is a known one. The file -@sc{bugs} in the @sc{cvs} source distribution is one -list of known bugs, but it doesn't necessarily try to -be comprehensive. Perhaps there will never be a -comprehensive, detailed list of known bugs. - -@c --------------------------------------------------------------------- @node What is CVS? -@chapter What is CVS? +@section What is CVS? @cindex What is CVS? @cindex Introduction to CVS @cindex CVS, introduction to @@ -465,19 +244,14 @@ Jeff Polk later helped Brian with the design of the @sc{cvs} module and vendor branch support. @cindex Source, getting CVS source -You can get @sc{cvs} via anonymous @sc{ftp} from a -number of sites; for example see +You can get @sc{cvs} in a variety of ways, including +free download from the internet. For more information +on downloading @sc{cvs} and other @sc{cvs} topics, see: + @example -http://www.gnu.ai.mit.edu/order/ftp.html +http://www.cyclic.com/ +http://www.loria.fr/~molli/cvs-index.html @end example -for a list of the @sc{gnu} @sc{ftp} sites. -@c We could also be pointing to other resources like -@c the cyclic getting.html, Pascal Molli's page, etc., -@c and probably should, when someone gets around to -@c figuring out which pages are stable enough that we -@c should cite them, which ones are best to point -@c people to (supported? binary? source? zero-cost? -@c buying CD-ROMs? etc.), etc. @cindex Mailing list @cindex List, mailing list @@ -514,10 +288,12 @@ if there is sufficient @sc{cvs} traffic on You can also subscribe to the bug-cvs mailing list, described in more detail in @ref{BUGS}. To subscribe -send mail to bug-cvs-request@@prep.ai.mit.edu. +send mail to bug-cvs-request@@gnu.org. @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -@unnumberedsec CVS is not@dots{} +@node What is CVS not? +@section What is CVS not? +@cindex What is CVS not? @sc{cvs} can do a lot of things for you, but it does not try to be everything for everyone. @@ -663,8 +439,7 @@ only once they have been proven. @c --------------------------------------------------------------------- @node A sample session -@chapter A sample session -@cindex A sample session +@section A sample session @cindex Example of a work-session @cindex Getting started @cindex Work-session, example of @@ -720,7 +495,7 @@ called @samp{tc}. @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - @node Getting the source -@section Getting the source +@subsection Getting the source @cindex Getting the source @cindex Checking out source @cindex Fetching source @@ -755,7 +530,7 @@ you want to edit. @xref{Multiple developers}, for an explanation. @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - @node Committing your changes -@section Committing your changes +@subsection Committing your changes @cindex Committing changes @cindex Log message entry @cindex CVSEDITOR, environment variable @@ -806,6 +581,18 @@ will not show up in future editor sessions. @c FIXCVS: Might be nice if "commit" and other commands @c would reset that timestamp too, but currently commit @c doesn't. +@c FIXME: Need to talk more about the process of +@c prompting for the log message. Like show an example +@c of what it pops up in the editor, for example. Also +@c a discussion of how to get the "a)bort, c)ontinue, +@c e)dit" prompt and what to do with it. Might also +@c work in the suggestion that if you want a diff, you +@c should make it before running commit (someone +@c suggested that the diff pop up in the editor. I'm +@c not sure that is better than telling people to run +@c "cvs diff" first if that is what they want, but if +@c we want to tell people that, the manual possibly +@c should say it). If you want to avoid starting an editor you can specify the log message on @@ -818,7 +605,7 @@ $ cvs commit -m "Added an optimization pass" backend.c @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - @node Cleaning up -@section Cleaning up +@subsection Cleaning up @cindex Cleaning up @cindex Working copy, removing @cindex Removing your working copy @@ -875,7 +662,7 @@ when @code{release} asks for confirmation. @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - @node Viewing differences -@section Viewing differences +@subsection Viewing differences @cindex Viewing differences @cindex Diff @@ -954,7 +741,7 @@ access methods, see @ref{Remote repositories}. @c more of the buck to the Remote repositories node? If the access method is omitted, then if the repository does not contain @samp{:}, then @code{:local:} is -assumed. If it does contain @samp{:} than either +assumed. If it does contain @samp{:} then either @code{:ext:} or @code{:server:} is assumed. For example, if you have a local repository in @file{/usr/local/cvsroot}, you can use @@ -989,7 +776,7 @@ user-defined modules. @node Specifying a repository @section Telling CVS where your repository is -There are a couple of different ways to tell @sc{cvs} +There are several ways to tell @sc{cvs} where to find the repository. You can name the repository on the command line explicitly, with the @code{-d} (for "directory") option: @@ -1006,7 +793,7 @@ cvs -d /usr/local/cvsroot checkout yoyodyne/tc Or you can set the @code{$CVSROOT} environment variable to an absolute path to the root of the repository, @file{/usr/local/cvsroot} in this example. -To set @code{$CVSROOT}, all @code{csh} and @code{tcsh} +To set @code{$CVSROOT}, @code{csh} and @code{tcsh} users should have this line in their @file{.cshrc} or @file{.tcshrc} files: @@ -1049,7 +836,7 @@ For most purposes it isn't important @emph{how} @sc{cvs} stores information in the repository. In fact, the format has changed in the past, and is likely to change in the future. Since in almost all cases one -accesses the repository via @sc{cvs} commands; such +accesses the repository via @sc{cvs} commands, such changes need not be disruptive. However, in some cases it may be necessary to @@ -1061,12 +848,33 @@ the file permissions appropriate for the repository. @menu * Repository files:: What files are stored in the repository * File permissions:: File permissions +* Windows permissions:: Issues specific to Windows * Attic:: Some files are stored in the Attic +* CVS in repository:: Additional information in CVS directory +* Locks:: CVS locks control concurrent accesses +* CVSROOT storage:: A few things about CVSROOT are different @end menu @node Repository files @subsection Where files are stored within the repository +@c @cindex filenames, legal +@c @cindex legal filenames +@c Somewhere we need to say something about legitimate +@c characters in filenames in working directory and +@c repository. Not "/" (not even on non-unix). And +@c here is a specific set of issues: +@c Files starting with a - are handled inconsistently. They can not +@c be added to a repository with an add command, because it they are +@c interpreted as a switch. They can appear in a repository if they are +@c part of a tree that is imported. They can not be removed from the tree +@c once they are there. +@c Note that "--" *is* supported (as a +@c consequence of using GNU getopt). Should document +@c this somewhere ("Common options"?). The other usual technique, +@c "./-foo", isn't as effective, at least for "cvs add" +@c which doesn't support pathnames containing "/". + The overall structure of the repository is a directory tree corresponding to the directories in the working directory. For example, supposing the repository is in @@ -1154,7 +962,9 @@ known as @dfn{RCS files}, because the first program to store files in that format was a version control system known as @sc{rcs}. For a full description of the file format, see the @code{man} page -@cite{rcsfile(5)}, distributed with @sc{rcs}. This +@cite{rcsfile(5)}, distributed with @sc{rcs}, or the +file @file{doc/RCSFILES} in the @sc{cvs} source +distribution. This file format has become very common---many systems other than @sc{cvs} or @sc{rcs} can at least import history files in this format. @@ -1176,8 +986,12 @@ rules see @ref{Tags}. @node File permissions @subsection File permissions @c -- Move this to @node Creating a repository or similar -@cindex Security -@cindex File permissions +@cindex Security, file permissions in repository +@cindex File permissions, general +@cindex permissions, general +@c FIXME: we need to somehow reflect "permissions in +@c repository" versus "permissions in working +@c directory" in the index entries. @cindex Group @cindex read-only files, in repository All @samp{,v} files are created read-only, and you @@ -1207,9 +1021,13 @@ Also note that users must have write access to the @file{CVSROOT/val-tags} file. @sc{Cvs} uses it to keep track of what tags are valid tag names (it is sometimes updated when tags are used, as well as when they are -created, though). +created). -@cindex CVSUMASK +Each @sc{rcs} file will be owned by the user who last +checked it in. This has little significance; what +really matters is who owns the directories. + +@cindex CVSUMASK, environment variable @cindex umask, for repository files @sc{cvs} tries to set up reasonable file permissions for new directories that are added inside the tree, but @@ -1225,8 +1043,8 @@ typical for newly created files, except that sometimes @sc{cvs} creates them read-only (see the sections on watches, @ref{Setting a watch}; -r, @ref{Global options}; or CVSREAD, @ref{Environment variables}). -@c FIXME: Need more discussion of which users and -@c groups should own the file in the repository. +@c FIXME: Need more discussion of which +@c group should own the file in the repository. @c Include a somewhat detailed example of the usual @c case where CVSUMASK is 007, the developers are all @c in a group, and that group owns stuff in the @@ -1249,20 +1067,75 @@ of @sc{cvs}; do not rely on the setting of @code{CVSUMASK} on the client having no effect. @c FIXME: need to explain what a umask is or cite @c someplace which does. +@c +@c There is also a larger (largely separate) issue +@c about the meaning of CVSUMASK in a non-unix context. +@c For example, whether there is +@c an equivalent which fits better into other +@c protection schemes like POSIX.6, VMS, &c. +@c @c FIXME: Need one place which discusses this @c read-only files thing. Why would one use -r or -@c CVSREAD? Why would one use watches? How do they interact? +@c CVSREAD? Why would one use watches? How do they +@c interact? +@c @c FIXME: We need to state @c whether using CVSUMASK removes the need for manually @c fixing permissions (in fact, if we are going to mention @c manually fixing permission, we better document a lot @c better just what we mean by "fix"). +Using pserver, you will generally need stricter +permissions on the @sc{cvsroot} directory and +directories above it in the tree; see @ref{Password +authentication security}. + @cindex setuid @cindex setgid -Since @sc{cvs} was not written to be run setuid, it is -unsafe to try to run it setuid. You cannot use the -setuid features of @sc{rcs} together with @sc{cvs}. +@cindex security, setuid +@cindex installed images (VMS) +Some operating systems have features which allow a +particular program to run with the ability to perform +operations which the caller of the program could not. +For example, the set user ID (setuid) or set group ID +(setgid) features of unix or the installed image +feature of VMS. CVS was not written to use such +features and therefore attempting to install CVS in +this fashion will provide protection against only +accidental lapses; anyone who is trying to circumvent +the measure will be able to do so, and depending on how +you have set it up may gain access to more than just +CVS. You may wish to instead consider pserver. It +shares some of the same attributes, in terms of +possibly providing a false sense of security or opening +security holes wider than the ones you are trying to +fix, so read the documentation on pserver security +carefully if you are considering this option +(@ref{Password authentication security}). + +@node Windows permissions +@subsection File Permission issues specific to Windows +@cindex Windows, and permissions +@cindex File permissions, Windows-specific +@cindex permissions, Windows-specific + +Some file permission issues are specific to Windows +operating systems (Windows 95, Windows NT, and +presumably future operating systems in this family. +Some of the following might apply to OS/2 but I'm not +sure). + +If you are using local CVS and the repository is on a +networked file system which is served by the Samba SMB +server, some people have reported problems with +permissions. Enabling WRITE=YES in the samba +configuration is said to fix/workaround it. +Disclaimer: I haven't investigated enough to know the +implications of enabling that option, nor do I know +whether there is something which CVS could be doing +differently in order to avoid the problem. If you find +something out, please let us know as described in +@ref{BUGS}. @node Attic @subsection The attic @@ -1302,6 +1175,147 @@ non-@code{dead} state. @c arrange the discussion of the dead state, versus @c discussion of the attic). +@node CVS in repository +@subsection The CVS directory in the repository +@cindex CVS directory, in repository + +The @file{CVS} directory in each repository directory +contains information such as file attributes (in a file +called @file{CVS/fileattr}; see fileattr.h in the CVS +source distribution for more documentation). In the +future additional files may be added to this directory, +so implementations should silently ignore additional +files. + +This behavior is implemented only by @sc{cvs} 1.7 and +later; for details see @ref{Watches Compatibility}. + +@node Locks +@subsection CVS locks in the repository + +For an introduction to CVS locks focusing on +user-visible behavior, see @ref{Concurrency}. The +following section is aimed at people who are writing +tools which want to access a CVS repository without +interfering with other tools acessing the same +repository. If you find yourself confused by concepts +described here, like @dfn{read lock}, @dfn{write lock}, +and @dfn{deadlock}, you might consult the literature on +operating systems or databases. + +Any file in the repository with a name starting +with @file{#cvs.rfl} is a read lock. Any file in +the repository with a name starting with +@file{#cvs.wfl} is a write lock. Old versions of CVS +(before CVS 1.5) also created files with names starting +with @file{#cvs.tfl}, but they are not discussed here. +The directory @file{#cvs.lock} serves as a master +lock. That is, one must obtain this lock first before +creating any of the other locks. + +To obtain a readlock, first create the @file{#cvs.lock} +directory. This operation must be atomic (which should +be true for creating a directory under most operating +systems). If it fails because the directory already +existed, wait for a while and try again. After +obtaining the @file{#cvs.lock} lock, create a file +whose name is @file{#cvs.rfl} followed by information +of your choice (for example, hostname and process +identification number). Then remove the +@file{#cvs.lock} directory to release the master lock. +Then proceed with reading the repository. When you are +done, remove the @file{#cvs.rfl} file to release the +read lock. + +To obtain a writelock, first create the +@file{#cvs.lock} directory, as with a readlock. Then +check that there are no files whose names start with +@file{#cvs.rfl}. If there are, remove +@file{#cvs.lock}, wait for a while, and try again. If +there are no readers, then create a file whose name is +@file{#cvs.wfl} followed by information of your choice +(for example, hostname and process identification +number). Hang on to the @file{#cvs.lock} lock. Proceed +with writing the repository. When you are done, first +remove the @file{#cvs.wfl} file and then the +@file{#cvs.lock} directory. Note that unlike the +@file{#cvs.rfl} file, the @file{#cvs.wfl} file is just +informational; it has no effect on the locking operation +beyond what is provided by holding on to the +@file{#cvs.lock} lock itself. + +Note that each lock (writelock or readlock) only locks +a single directory in the repository, including +@file{Attic} and @file{CVS} but not including +subdirectories which represent other directories under +version control. To lock an entire tree, you need to +lock each directory (note that if you fail to obtain +any lock you need, you must release the whole tree +before waiting and trying again, to avoid deadlocks). + +Note also that @sc{cvs} expects writelocks to control +access to individual @file{foo,v} files. @sc{rcs} has +a scheme where the @file{,foo,} file serves as a lock, +but @sc{cvs} does not implement it and so taking out a +@sc{cvs} writelock is recommended. See the comments at +rcs_internal_lockfile in the @sc{cvs} source code for +further discussion/rationale. + +@node CVSROOT storage +@subsection How files are stored in the CVSROOT directory +@cindex CVSROOT, storage of files + +The @file{$CVSROOT/CVSROOT} directory contains the +various administrative files. In some ways this +directory is just like any other directory in the +repository; it contains @sc{rcs} files whose names end +in @samp{,v}, and many of the @sc{cvs} commands operate +on it the same way. However, there are a few +differences. + +For each administrative file, in addition to the +@sc{rcs} file, there is also a checked out copy of the +file. For example, there is an @sc{rcs} file +@file{loginfo,v} and a file @file{loginfo} which +contains the latest revision contained in +@file{loginfo,v}. When you check in an administrative +file, @sc{cvs} should print + +@example +cvs commit: Rebuilding administrative file database +@end example + +@noindent +@cindex checkoutlist +and update the checked out copy in +@file{$CVSROOT/CVSROOT}. If it does not, there is +something wrong (@pxref{BUGS}). To add your own files +to the files to be updated in this fashion, you can add +them to the @file{checkoutlist} administrative file. +@c FIXME: checkoutlist probably should be documented +@c somewhat more completely. + +@cindex modules.db +@cindex modules.pag +@cindex modules.dir +By default, the @file{modules} file behaves as +described above. If the modules file is very large, +storing it as a flat text file may make looking up +modules slow (I'm not sure whether this is as much of a +concern now as when @sc{cvs} first evolved this +feature; I haven't seen benchmarks). Therefore, by +making appropriate edits to the @sc{cvs} source code +one can store the modules file in a database which +implements the @code{ndbm} interface, such as Berkeley +db or GDBM. If this option is in use, then the modules +database will be stored in the files @file{modules.db}, +@file{modules.pag}, and/or @file{modules.dir}. +@c I think fileattr also will use the database stuff. +@c Anything else? + +For information on the meaning of the various +administrative files, see @ref{Administrative files}. + @node Working directory storage @section How data is stored in the working directory @@ -1312,6 +1326,7 @@ non-@code{dead} state. @c whether that is a good organization (is it based on @c what the user wants to do?). +@cindex CVS directory, in working directory While we are discussing @sc{cvs} internals which may become visible from time to time, we might as well talk about what @sc{cvs} puts in the @file{CVS} directories @@ -1342,10 +1357,14 @@ described in @ref{Specifying a repository}. @cindex CVS/Repository file @item Repository This file contains the directory within the repository -which the current directory corresponds with. For -historical reasons it is an absolute pathname, although -it would make more sense for it to be relative to the -root. For example, after the command +which the current directory corresponds with. It can +be either an absolute pathname or a relative pathname; +@sc{cvs} has had the ability to read either format +since at least version 1.3 or so. The relative +pathname is relative to the root, and is the more +sensible approach, but the absolute pathname is quite +common and implementations should accept either. For +example, after the command @example cvs -d :local:/usr/local/cvsroot checkout yoyodyne/tc @@ -1357,10 +1376,17 @@ cvs -d :local:/usr/local/cvsroot checkout yoyodyne/tc :local:/usr/local/cvsroot @end example -and @file{Repository} will contain +and @file{Repository} will contain either @example -/usr/local/cvsroot/yoydyne/tc +/usr/local/cvsroot/yoyodyne/tc +@end example + +@noindent +or + +@example +yoyodyne/tc @end example @cindex Entries file, in CVS directory @@ -1370,11 +1396,12 @@ This file lists the files and directories in the working directory. It is a text file according to the conventions appropriate for the operating system in question. -@c That seems like a lose, it makes it impossible (it +@c Using OS text file conventions makes it impossible (it @c would seem) to share a working directory via a @c networked file system between systems with diverse -@c text file conventions. But it seems to be how CVS -@c currently works. +@c text file conventions. But that might be correct, +@c because the text files under CVS control are subject +@c to the same problem. It is also the status quo. The first character of each line indicates what sort of line it is. If the character is unrecognized, programs reading the file should silently skip that line, to @@ -1481,6 +1508,18 @@ not create additional files in that directory. To clear it, use the @code{update} command with the @samp{-d} option, which will get the additional files and remove @file{Entries.Static}. +@c FIXME: This needs to be better documented, in places +@c other than Working Directory Storage. +@c FIXCVS: The fact that this setting exists needs to +@c be more visible to the user. For example "cvs +@c status foo", in the case where the file would be +@c gotten except for Entries.Static, might say +@c something to distinguish this from other cases. +@c One thing that periodically gets suggested is to +@c have "cvs update" print something when it skips +@c files due to Entries.Static, but IMHO that kind of +@c noise pretty much makes the Entries.Static feature +@c useless. @cindex Tag file, in CVS directory @cindex CVS/Tag file @@ -1541,6 +1580,28 @@ directory. This allows the @code{unedit} command to operate even if it is unable to communicate with the server. +@cindex Baserev file, in CVS directory +@cindex CVS/Baserev file +@item Baserev +The file lists the revision for each of the files in +the @file{Base} directory. The format is: + +@example +B@var{name}/@var{rev}/@var{expansion} +@end example + +where @var{expansion} should be ignored, to allow for +future expansion. + +@cindex Baserev.tmp file, in CVS directory +@cindex CVS/Baserev.tmp file +@item Baserev.tmp +This file is to @file{Baserev} as @file{Entries.Backup} +is to @file{Entries}. That is, to write @file{Baserev}, +first write the new contents to @file{Baserev.tmp} and +then (atomically where possible), rename it to +@file{Baserev}. + @cindex Template file, in CVS directory @cindex CVS/Template file @item Template @@ -1672,9 +1733,14 @@ repositories. To set up a @sc{cvs} repository, first choose the machine and disk on which you want to store the revision history of the source files. CPU and memory -requirements are modest---a server with 32M of memory -or even less can handle a fairly large source tree with -a fair amount of activity. To estimate disk space +requirements are modest, so most machines should be +adequate. For details see @ref{Server requirements}. +@c Possible that we should be providing a quick rule of +@c thumb, like the 32M memory for the server. That +@c might increase the number of people who are happy +@c with the answer, without following the xref. + +To estimate disk space requirements, if you are importing RCS files from another system, the size of those files is the approximate initial size of your repository, or if you @@ -1686,15 +1752,7 @@ for a while). On the machines on which the developers will be working, you'll want disk space for approximately one working directory for each developer (either the entire tree or a portion of it, depending -on what each developer uses). Don't worry about CPU -and memory requirements for the clients---any machine -with enough capacity to run the operating system in -question should have little trouble. -@c Stuff about memory duplicates Server requirements -@c to some extent. I'm not sure this is a bad thing, -@c though (one is aimed at people who are looking into -@c this carefully, the other is aimed at people who -@c want a rule of thumb). +on what each developer uses). The repository should be accessable (directly or via a networked file system) from all @@ -1856,10 +1914,14 @@ described in @ref{Connecting via rsh}. @c use SSH, for example. Plus it incorrectly implies @c that you need an @code{rsh} binary on the client to use @c :server:. +@c Also note that rsh not pserver is the right choice if you want +@c users to be able to create their own repositories +@c (because of the --allow-root related issues). @menu * Server requirements:: Memory and other resources for servers * Connecting via rsh:: Using the @code{rsh} program to connect * Password authenticated:: Direct connections using passwords +* GSSAPI authenticated:: Direct connections using GSSAPI * Kerberos authenticated:: Direct connections with kerberos @end menu @@ -1873,15 +1935,23 @@ large source tree with a fair amount of activity. @c Say something about CPU speed too? I'm even less sure @c what to say on that subject... -The real answer, of course, is more complicated. The -@sc{cvs} server consists of two processes for each -client that it is serving. Memory consumption on the -child process should remain fairly small. Memory -consumption on the parent process, particularly if the -network connection to the client is slow, can be -expected to grow to slightly more than the size of the -sources in a single directory, or two megabytes, -whichever is larger. +The real answer, of course, is more complicated. +Estimating the known areas of large memory consumption +should be sufficient to estimate memory requirements. +There are two such areas documented here; other memory +consumption should be small by comparison (if you find +that is not the case, let us know, as described in +@ref{BUGS}, so we can update this documentation). + +The first area of big memory consumption is large +checkouts, when using the @sc{cvs} server. The server +consists of two processes for each client that it is +serving. Memory consumption on the child process +should remain fairly small. Memory consumption on the +parent process, particularly if the network connection +to the client is slow, can be expected to grow to +slightly more than the size of the sources in a single +directory, or two megabytes, whichever is larger. @c "two megabytes" of course is SERVER_HI_WATER. But @c we don't mention that here because we are @c documenting the default configuration of CVS. If it @@ -1905,15 +1975,45 @@ than physical memory. @c in a first in, first out fashion, but I haven't @c looked very closely. -Resource consumption for the client or the -non-client/server @sc{cvs} is even more modest---any -machine with enough capacity to run the operating system -in question should have little trouble. -@c Probably we could be saying more about this. +@c What about disk usage in /tmp on the server? I think that +@c it can be substantial, but I haven't looked at this +@c again and tried to figure it out ("cvs import" is +@c probably the worst case...). + +The second area of large memory consumption is +@code{diff}, when checking in large files. This is +required even for binary files. The rule of thumb is +to allow about ten times the size of the largest file +you will want to check in, although five times may be +adequate. For example, if you want to check in a file +which is 10 megabytes, you should have 100 megabytes of +memory on the machine doing the checkin (the server +machine for client/server, or the machine running +@sc{cvs} for non-client/server). This can be swap +space rather than physical memory. Because the memory +is only required briefly, there is no particular need +to allow memory for more than one such checkin at a +time. +@c The 5-10 times rule of thumb is from Paul Eggert for +@c GNU diff. I don't think it is in the GNU diff +@c manual or anyplace like that. +@c +@c Probably we could be saying more about +@c non-client/server CVS. @c I would guess for non-client/server CVS in an NFS -@c environment the biggest issues is the network and +@c environment the biggest issues are the network and @c the NFS server. +Resource consumption for the client is even more +modest---any machine with enough capacity to run the +operating system in question should have little +trouble. +@c Is that true? I think the client still wants to +@c (bogusly) store entire files in memory at times. + +For information on disk space requirements, see +@ref{Creating a repository}. + @node Connecting via rsh @subsection Connecting with rsh @@ -1939,7 +2039,7 @@ Then test that @code{rsh} is working with rsh -l bach chainsaw.yard.com 'echo $PATH' @end example -@cindex CVS_SERVER +@cindex CVS_SERVER, environment variable Next you have to make sure that @code{rsh} will be able to find the server. Make sure that the path which @code{rsh} printed in the above example includes the @@ -2028,6 +2128,11 @@ some adjustments on both the server and client sides. @node Password authentication server @subsubsection Setting up the server for password authentication +First of all, you probably want to tighten the +permissions on the @file{$CVSROOT} and +@file{$CVSROOT/CVSROOT} directories. See @ref{Password +authentication security}, for more details. + @cindex Pserver (subcommand) @cindex password server, setting up @cindex authenticating server, setting up @@ -2048,11 +2153,10 @@ single line in @file{inetd.conf}) should be sufficient: @example 2401 stream tcp nowait root /usr/local/bin/cvs -cvs -b /usr/local/bin --allow-root=/usr/cvsroot pserver +cvs --allow-root=/usr/cvsroot pserver @end example -The @samp{-b} option specifies the directory which contains -the @sc{rcs} binaries on the server. You could also use the +You could also use the @samp{-T} option to specify a temporary directory. The @samp{--allow-root} option specifies the allowable @@ -2095,7 +2199,8 @@ regular passwords when they access the repository. This file is @file{$CVSROOT/CVSROOT/passwd} (@pxref{Intro administrative files}). Its format is similar to @file{/etc/passwd}, except that it only has -two fields, username and password. For example: +two or three fields, username, password, and optional +username for the server to use. For example: @example bach:ULtgRLXo7NRxs @@ -2113,9 +2218,11 @@ finds the user, it compares against that password. If it does not find the user, or if the @sc{cvs} @file{passwd} file does not exist, then the server tries to match the password using the system's -user-lookup routine. When using the @sc{cvs} -@file{passwd} file, the server runs under as the -username specified in the the third argument in the +user-lookup routine (using the system's user-lookup +routine can be disabled by setting @code{SystemAuth=no} +in the config file, @pxref{config}). When using the @sc{cvs} +@file{passwd} file, the server runs as the +username specified in the third argument in the entry, or as the first argument if there is no third argument (in this way @sc{cvs} allows imaginary usernames provided the @sc{cvs} @file{passwd} file @@ -2155,8 +2262,8 @@ multiple cvs usernames onto a single system username. This feature is designed to allow people repository access without full system access (in -particular, see @xref{Read-only access}); however, also -@xref{Password authentication security}. Any sort of +particular, see @ref{Read-only access}); however, also +see @ref{Password authentication security}. Any sort of repository access very likely implies a degree of general system access as well. @@ -2242,6 +2349,7 @@ password for transmission to the server. @node Password authentication security @subsubsection Security considerations with password authentication +@cindex security, of pserver The passwords are stored on the client side in a trivial encoding of the cleartext, and transmitted in the same encoding. The encoding is done only to @@ -2259,6 +2367,7 @@ The separate @sc{cvs} password file (@pxref{Password authentication server}) allows people to use a different password for repository access than for login access. On the other hand, once a user has +non-read-only access to the repository, she can execute programs on the server system through a variety of means. Thus, repository access implies fairly broad system access as well. It @@ -2273,7 +2382,28 @@ but no one has done so as of this writing. @c type). Furthermore, there may be other ways in which having access to @sc{cvs} allows people to gain more general -access to the system; noone has done a careful audit. +access to the system; no one has done a careful audit. + +Note that because the @file{$CVSROOT/CVSROOT} directory +contains @file{passwd} and other files which are used +to check security, you must control the permissions on +this directory as tightly as the permissions on +@file{/etc}. The same applies to the @file{$CVSROOT} +directory itself and any directory +above it in the tree. Anyone who has write access to +such a directory will have the ability to become any +user on the system. Note that these permissions are +typically tighter than you would use if you are not +using pserver. +@c TODO: Would be really nice to document/implement a +@c scheme where the CVS server can run as some non-root +@c user, e.g. "cvs". CVSROOT/passwd would contain a +@c bunch of entries of the form foo:xxx:cvs (or the "cvs" +@c would be implicit). This would greatly reduce +@c security risks such as those hinted at in the +@c previous paragraph. I think minor changes to CVS +@c might be required but mostly this would just need +@c someone who wants to play with it, document it, &c. In summary, anyone who gets the password gets repository access, and some measure of general system @@ -2282,17 +2412,78 @@ who can sniff network packets or read a protected (i.e., user read-only) file. If you want real security, get Kerberos. +@node GSSAPI authenticated +@subsection Direct connection with GSSAPI + +@cindex GSSAPI +@cindex security, GSSAPI +@cindex :gserver: +GSSAPI is a generic interface to network security +systems such as Kerberos 5. +If you have a working GSSAPI library, you can have +@sc{cvs} connect via a direct @sc{tcp} connection, +authenticating with GSSAPI. + +To do this, @sc{cvs} needs to be compiled with GSSAPI +support; when configuring @sc{cvs} it tries to detect +whether GSSAPI libraries using kerberos version 5 are +present. You can also use the @file{--with-gssapi} +flag to configure. + +The connection is authenticated using GSSAPI, but the +message stream is @emph{not} authenticated by default. +You must use the @code{-a} global option to request +stream authentication. + +The data transmitted is @emph{not} encrypted by +default. Encryption support must be compiled into both +the client and the server; use the +@file{--enable-encrypt} configure option to turn it on. +You must then use the @code{-x} global option to +request encryption. + +GSSAPI connections are handled on the server side by +the same server which handles the password +authentication server; see @ref{Password authentication +server}. If you are using a GSSAPI mechanism such as +Kerberos which provides for strong authentication, you +will probably want to disable the ability to +authenticate via cleartext passwords. To do so, create +an empty @file{CVSROOT/passwd} password file, and set +@code{SystemAuth=no} in the config file +(@pxref{config}). + +The GSSAPI server uses a principal name of +cvs/@var{hostname}, where @var{hostname} is the +canonical name of the server host. You will have to +set this up as required by your GSSAPI mechanism. + +To connect using GSSAPI, use @samp{:gserver:}. For +example, + +@example +cvs -d :gserver:chainsaw.yard.com:/usr/local/cvsroot checkout foo +@end example + @node Kerberos authenticated @subsection Direct connection with kerberos @cindex kerberos +@cindex security, kerberos @cindex :kserver: +The easiest way to use kerberos is to use the kerberos +@code{rsh}, as described in @ref{Connecting via rsh}. The main disadvantage of using rsh is that all the data needs to pass through additional programs, so it may be slower. So if you have kerberos installed you can connect via a direct @sc{tcp} connection, authenticating with kerberos. +This section concerns the kerberos network security +system, version 4. Kerberos version 5 is supported via +the GSSAPI generic network security interface, as +described in the previous section. + To do this, @sc{cvs} needs to be compiled with kerberos support; when configuring @sc{cvs} it tries to detect whether kerberos is present or you can use the @@ -2319,7 +2510,7 @@ which allows you to log into the server machine. Then you are ready to go: @example -cvs -d :kserver:chainsaw.yard.com:/user/local/cvsroot checkout foo +cvs -d :kserver:chainsaw.yard.com:/usr/local/cvsroot checkout foo @end example Previous versions of @sc{cvs} would fall back to a @@ -2347,9 +2538,16 @@ repository, except for certain ``administrative'' files (such as lock files and the history file). It may be desirable to use this feature in conjunction with user-aliasing (@pxref{Password authentication server}). -However, note that read-only access does not repeal the -existing security considerations in @xref{Password -authentication security}. + +Unlike with previous versions of @sc{cvs}, read-only +users should be able merely to read the repository, and +not to execute programs on the server or otherwise gain +unexpected levels of access. Or to be more accurate, +the @emph{known} holes have been plugged. Because this +feature is new and has not received a comprehensive +security audit, you should use whatever level of +caution seems warranted given your attitude concerning +security. There are two ways to specify read-only access for a user: by inclusion, and by exclusion. @@ -2605,6 +2803,13 @@ Many version control systems have the ability to export export the @sc{rcs} files and then follow the above instructions. +Failing that, probably your best bet is to write a +script that will check out the files one revision at a +time using the command line interface to the other +system, and then check the revisions into @sc{cvs}. +The @file{sccs2rcs} script mentioned below may be a +useful example to follow. + @cindex SCCS, importing files from @item From SCCS There is a script in the @file{contrib} directory of @@ -2614,6 +2819,16 @@ Note: you must run it on a machine which has both @sc{sccs} and @sc{rcs} installed, and like everything else in contrib it is unsupported (your mileage may vary). + +@cindex PVCS, importing files from +@item From PVCS +There is a script in the @file{contrib} directory of +the @sc{cvs} source distribution called @file{pvcs_to_rcs} +which converts @sc{pvcs} archives to @sc{rcs} files. +You must run it on a machine which has both +@sc{pvcs} and @sc{rcs} installed, and like everything +else in contrib it is unsupported (your mileage may +vary). See the comments in the script for details. @end table @c CMZ and/or PATCHY were systems that were used in the @c high energy physics community (especially for @@ -2717,1025 +2932,8 @@ $ cvs release -d CVSROOT @end enumerate @c --------------------------------------------------------------------- -@node Multiple developers -@chapter Multiple developers -@cindex Multiple developers -@cindex Team of developers -@cindex File locking -@cindex Locking files -@cindex Working copy -@cindex reserved checkouts -@cindex unreserved checkouts -@cindex RCS-style locking - -When more than one person works on a software project -things often get complicated. Often, two people try to -edit the same file simultaneously. One solution, known -as @dfn{file locking} or @dfn{reserved checkouts}, is -to allow only one person to edit each file at a time. -This is the only solution with some version control -systems, including @sc{rcs} and @sc{sccs}. Currently -the usual way to get reserved checkouts with @sc{cvs} -is the @code{cvs admin -l} command (@pxref{admin -options}). This is not as nicely integrated into -@sc{cvs} as the watch features, described below, but it -seems that most people with a need for reserved -checkouts find it adequate. -@c Or "find it better than worrying about implementing -@c nicely integrated reserved checkouts" or ...? -It also may be possible to use the watches -features described below, together with suitable -procedures (not enforced by software), to avoid having -two people edit at the same time. - -@c Our unreserved checkout model might not -@c be quite the same as others. For example, I -@c think that some systems will tend to create a branch -@c in the case where CVS prints "up-to-date check failed". -@c It isn't clear to me whether we should try to -@c explore these subtleties; it could easily just -@c confuse people. -The default model with @sc{cvs} is known as -@dfn{unreserved checkouts}. In this model, developers -can edit their own @dfn{working copy} of a file -simultaneously. The first person that commits his -changes has no automatic way of knowing that another -has started to edit it. Others will get an error -message when they try to commit the file. They must -then use @sc{cvs} commands to bring their working copy -up to date with the repository revision. This process -is almost automatic. - -@c FIXME? should probably use the word "watch" here, to -@c tie this into the text below and above. -@sc{Cvs} also supports mechanisms which facilitate -various kinds of communcation, without actually -enforcing rules like reserved checkouts do. - -The rest of this chapter describes how these various -models work, and some of the issues involved in -choosing between them. - -@ignore -Here is a draft reserved checkout design or discussion -of the issues. This seems like as good a place as any -for this. - -Might want a cvs lock/cvs unlock--in which the names -differ from edit/unedit because the network must be up -for these to work. unedit gives an error if there is a -reserved checkout in place (so that people don't -accidentally leave locks around); unlock gives an error -if one is not in place (this is more arguable; perhaps -it should act like unedit in that case). - -On the other hand, might want it so that emacs, -scripts, etc., can get ready to edit a file without -having to know which model is in use. In that case we -would have a "cvs watch lock" (or .cvsrc?) (that is, -three settings, "on", "off", and "lock"). Having cvs -watch lock set would cause a get to record in the CVS -directory which model is in use, and cause "cvs edit" -to change behaviors. We'd want a way to query which -setting is in effect (this would be handy even if it is -only "on" or "off" as presently). If lock is in -effect, then commit would require a lock before -allowing a checkin; chmod wouldn't suffice (might be -debatable--see chmod comment below, in watches--but it -is the way people expect RCS to work and I can't think -of any significant downside. On the other hand, maybe -it isn't worth bothering, because people who are used -to RCS wouldn't think to use chmod anyway). - -Implementation: use file attributes or use RCS -locking. The former avoids more dependence on RCS -behaviors we will need to reimplement as we librarify -RCS, and makes it easier to import/export RCS files (in -that context, want to ignore the locker field). But -note that RCS locks are per-branch, which is the -correct behavior (this is also an issue for the "watch -on" features; they should be per-branch too). - -Here are a few more random notes about implementation -details, assuming "cvs watch lock" and - -CVS/Watched file? Or try to fit this into CVS/Entries somehow? -Cases: (1) file is checked out (unreserved or with watch on) by old -version of CVS, now we do something with new one, (2) file is checked -out by new version, now we do something with old one. - -Remote protocol would have a "Watched" analogous to "Mode". Of course -it would apply to all Updated-like requests. How do we keep this -setting up to date? I guess that there wants to be a Watched request, -and the server would send a new one if it isn't up to date? (Ugh--hard -to implement and slows down "cvs -q update"--is there an easier way?) - -"cvs edit"--checks CVS/Watched, and if watch lock, then sends -"edit-lock" request. Which comes back with a Checked-in with -appropriate Watched (off, on, lock, locked, or some such?), or error -message if already locked. - -"cvs commit"--only will commit if off/on/locked. lock is not OK. - -Doc: -note that "cvs edit" must be connected to network if watch lock is in -effect. - -Talk about what to do if someone has locked a file and you want to -edit that file. (breaking locks, or lack thereof). - - -@end ignore - -@menu -* File status:: A file can be in several states -* Updating a file:: Bringing a file up-to-date -* Conflicts example:: An informative example -* Informing others:: To cooperate you must inform -* Concurrency:: Simultaneous repository access -* Watches:: Mechanisms to track who is editing files -* Choosing a model:: Reserved or unreserved checkouts? -@end menu - -@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -@node File status -@section File status -@cindex File status -@cindex Status of a file - -@c Shouldn't this start with an example or something, -@c introducing the unreserved checkout model? Before we -@c dive into listing states? -Based on what operations you have performed on a -checked out file, and what operations others have -performed to that file in the repository, one can -classify a file in a number of states. The states, as -reported by the @code{status} command, are: - -@c The order of items is chosen to group logically -@c similar outputs together. -@c People who want alphabetical can use the index... -@table @asis -@cindex Up-to-date -@item Up-to-date -The file is identical with the latest revision in the -repository for the branch in use. -@c FIXME: should we clarify "in use"? The answer is -@c sticky tags, and trying to distinguish branch sticky -@c tags from non-branch sticky tags seems rather awkward -@c here. -@c FIXME: What happens with non-branch sticky tags? Is -@c a stuck file "Up-to-date" or "Needs checkout" or what? - -@item Locally Modified -@cindex Locally Modified -You have edited the file, and not yet committed your changes. - -@item Locally Added -@cindex Locally Added -You have added the file with @code{add}, and not yet -committed your changes. -@c There are many cases involving the file being -@c added/removed/modified in the working directory, and -@c added/removed/modified in the repository, which we -@c don't try to describe here. I'm not sure that "cvs -@c status" produces a non-confusing output in most of -@c those cases. - -@item Locally Removed -@cindex Locally Removed -You have removed the file with @code{remove}, and not yet -committed your changes. - -@item Needs Checkout -@cindex Needs Checkout -Someone else has committed a newer revision to the -repository. The name is slightly misleading; you will -ordinarily use @code{update} rather than -@code{checkout} to get that newer revision. - -@item Needs Patch -@cindex Needs Patch -@c See also newb-123j0 in sanity.sh (although that case -@c should probably be changed rather than documented). -Like Needs Checkout, but the @sc{cvs} server will send -a patch rather than the entire file. Sending a patch or -sending an entire file accomplishes the same thing. - -@item Needs Merge -@cindex Needs Merge -Someone else has committed a newer revision to the repository, and you -have also made modifications to the file. - -@item File had conflicts on merge -@cindex File had conflicts on merge -@c is it worth saying that this message was "Unresolved -@c Conflict" in CVS 1.9 and earlier? I'm inclined to -@c think that is unnecessarily confusing to new users. -This is like Locally Modified, except that a previous -@code{update} command gave a conflict. If you have not -already done so, you need to -resolve the conflict as described in @ref{Conflicts example}. - -@item Unknown -@cindex Unknown -@sc{Cvs} doesn't know anything about this file. For -example, you have created a new file and have not run -@code{add}. -@c -@c "Entry Invalid" and "Classify Error" are also in the -@c status.c. The latter definitely indicates a CVS bug -@c (should it be worded more like "internal error" so -@c people submit bug reports if they see it?). The former -@c I'm not as sure; I haven't tracked down whether/when it -@c appears in "cvs status" output. - -@end table - -To help clarify the file status, @code{status} also -reports the @code{Working revision} which is the -revision that the file in the working directory derives -from, and the @code{Repository revision} which is the -latest revision in the repository for the branch in -use. -@c FIXME: should we clarify "in use"? The answer is -@c sticky tags, and trying to distinguish branch sticky -@c tags from non-branch sticky tags seems rather awkward -@c here. -@c FIXME: What happens with non-branch sticky tags? -@c What is the Repository Revision there? See the -@c comment at vn_rcs in cvs.h, which is kind of -@c confused--we really need to document better what this -@c field contains. -@c Q: Should we document "New file!" and other such -@c outputs or are they self-explanatory? -@c FIXME: what about the date to the right of "Working -@c revision"? It doesn't appear with client/server and -@c seems unnecessary (redundant with "ls -l") so -@c perhaps it should be removed for non-client/server too? -@c FIXME: Need some examples. - -@c Would be nice to have an @example showing output -@c from cvs status, with comments showing the xref -@c where each part of the output is described. This -@c might fit in nicely if it is desirable to split this -@c node in two; one to introduce "cvs status" and one -@c to list each of the states. -The options to @code{status} are listed in -@ref{Invoking CVS}. For information on its @code{Sticky tag} -and @code{Sticky date} output, see @ref{Sticky tags}. -For information on its @code{Sticky options} output, -see the @samp{-k} option in @ref{update options}. - -You can think of the @code{status} and @code{update} -commands as somewhat complementary. You use -@code{update} to bring your files up to date, and you -can use @code{status} to give you some idea of what an -@code{update} would do (of course, the state of the -repository might change before you actually run -@code{update}). In fact, if you want a command to -display file status in a more brief format than is -displayed by the @code{status} command, you can invoke - -@cindex update, to display file status -@example -$ cvs -n -q update -@end example - -The @samp{-n} option means to not actually do the -update, but merely to display statuses; the @samp{-q} -option avoids printing the name of each directory. For -more information on the @code{update} command, and -these options, see @ref{Invoking CVS}. - -@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -@node Updating a file -@section Bringing a file up to date -@cindex Bringing a file up to date -@cindex Updating a file -@cindex Merging a file -@cindex update, introduction - -When you want to update or merge a file, use the @code{update} -command. For files that are not up to date this is roughly equivalent -to a @code{checkout} command: the newest revision of the file is -extracted from the repository and put in your working copy of the -module. - -Your modifications to a file are never lost when you -use @code{update}. If no newer revision exists, -running @code{update} has no effect. If you have -edited the file, and a newer revision is available, -@sc{cvs} will merge all changes into your working copy. - -For instance, imagine that you checked out revision 1.4 and started -editing it. In the meantime someone else committed revision 1.5, and -shortly after that revision 1.6. If you run @code{update} on the file -now, @sc{cvs} will incorporate all changes between revision 1.4 and 1.6 into -your file. - -@cindex Overlap -If any of the changes between 1.4 and 1.6 were made too -close to any of the changes you have made, an -@dfn{overlap} occurs. In such cases a warning is -printed, and the resulting file includes both -versions of the lines that overlap, delimited by -special markers. -@xref{update}, for a complete description of the -@code{update} command. - -@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -@node Conflicts example -@section Conflicts example -@cindex Merge, an example -@cindex Example of merge -@cindex driver.c (merge example) - -Suppose revision 1.4 of @file{driver.c} contains this: - -@example -#include <stdio.h> - -void main() -@{ - parse(); - if (nerr == 0) - gencode(); - else - fprintf(stderr, "No code generated.\n"); - exit(nerr == 0 ? 0 : 1); -@} -@end example - -@noindent -Revision 1.6 of @file{driver.c} contains this: - -@example -#include <stdio.h> - -int main(int argc, - char **argv) -@{ - parse(); - if (argc != 1) - @{ - fprintf(stderr, "tc: No args expected.\n"); - exit(1); - @} - if (nerr == 0) - gencode(); - else - fprintf(stderr, "No code generated.\n"); - exit(!!nerr); -@} -@end example - -@noindent -Your working copy of @file{driver.c}, based on revision -1.4, contains this before you run @samp{cvs update}: -@c -- Really include "cvs"? - -@example -#include <stdlib.h> -#include <stdio.h> - -void main() -@{ - init_scanner(); - parse(); - if (nerr == 0) - gencode(); - else - fprintf(stderr, "No code generated.\n"); - exit(nerr == 0 ? EXIT_SUCCESS : EXIT_FAILURE); -@} -@end example - -@noindent -You run @samp{cvs update}: -@c -- Really include "cvs"? - -@example -$ cvs update driver.c -RCS file: /usr/local/cvsroot/yoyodyne/tc/driver.c,v -retrieving revision 1.4 -retrieving revision 1.6 -Merging differences between 1.4 and 1.6 into driver.c -rcsmerge warning: overlaps during merge -cvs update: conflicts found in driver.c -C driver.c -@end example - -@noindent -@cindex Conflicts (merge example) -@sc{cvs} tells you that there were some conflicts. -Your original working file is saved unmodified in -@file{.#driver.c.1.4}. The new version of -@file{driver.c} contains this: - -@example -#include <stdlib.h> -#include <stdio.h> - -int main(int argc, - char **argv) -@{ - init_scanner(); - parse(); - if (argc != 1) - @{ - fprintf(stderr, "tc: No args expected.\n"); - exit(1); - @} - if (nerr == 0) - gencode(); - else - fprintf(stderr, "No code generated.\n"); -@asis{}<<<<<<< driver.c - exit(nerr == 0 ? EXIT_SUCCESS : EXIT_FAILURE); -@asis{}======= - exit(!!nerr); -@asis{}>>>>>>> 1.6 -@} -@end example - -@noindent -@cindex Markers, conflict -@cindex Conflict markers -@cindex <<<<<<< -@cindex >>>>>>> -@cindex ======= - -Note how all non-overlapping modifications are incorporated in your working -copy, and that the overlapping section is clearly marked with -@samp{<<<<<<<}, @samp{=======} and @samp{>>>>>>>}. - -@cindex Resolving a conflict -@cindex Conflict resolution -You resolve the conflict by editing the file, removing the markers and -the erroneous line. Suppose you end up with this file: -@c -- Add xref to the pcl-cvs manual when it talks -@c -- about this. -@example -#include <stdlib.h> -#include <stdio.h> - -int main(int argc, - char **argv) -@{ - init_scanner(); - parse(); - if (argc != 1) - @{ - fprintf(stderr, "tc: No args expected.\n"); - exit(1); - @} - if (nerr == 0) - gencode(); - else - fprintf(stderr, "No code generated.\n"); - exit(nerr == 0 ? EXIT_SUCCESS : EXIT_FAILURE); -@} -@end example - -@noindent -You can now go ahead and commit this as revision 1.7. - -@example -$ cvs commit -m "Initialize scanner. Use symbolic exit values." driver.c -Checking in driver.c; -/usr/local/cvsroot/yoyodyne/tc/driver.c,v <-- driver.c -new revision: 1.7; previous revision: 1.6 -done -@end example - -For your protection, @sc{cvs} will refuse to check in a -file if a conflict occurred and you have not resolved -the conflict. Currently to resolve a conflict, you -must change the timestamp on the file, and must also -insure that the file contains no conflict markers. If -your file legitimately contains conflict markers (that -is, occurrences of @samp{>>>>>>> } at the start of a -line that don't mark a conflict), then @sc{cvs} has -trouble handling this and you need to start hacking on -the @code{CVS/Entries} file or other such workarounds. -@c FIXME: There should be a "cvs resolved" command -@c which clears the conflict indication. For a nice user -@c interface, this should be invoked by an interactive -@c merge tool like emerge rather than by the user -@c directly--such a tool can verify that the user has -@c really dealt with each conflict. - -@cindex emerge -If you use release 1.04 or later of pcl-cvs (a @sc{gnu} -Emacs front-end for @sc{cvs}) you can use an Emacs -package called emerge to help you resolve conflicts. -See the documentation for pcl-cvs. - -@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -@node Informing others -@section Informing others about commits -@cindex Informing others -@cindex Spreading information -@cindex Mail, automatic mail on commit - -It is often useful to inform others when you commit a -new revision of a file. The @samp{-i} option of the -@file{modules} file, or the @file{loginfo} file, can be -used to automate this process. @xref{modules}. -@xref{loginfo}. You can use these features of @sc{cvs} -to, for instance, instruct @sc{cvs} to mail a -message to all developers, or post a message to a local -newsgroup. -@c -- More text would be nice here. - -@node Concurrency -@section Several developers simultaneously attempting to run CVS - -@cindex locks, cvs -@c For a discussion of *why* CVS creates locks, see -@c the comment at the start of src/lock.c -If several developers try to run @sc{cvs} at the same -time, one may get the following message: - -@example -[11:43:23] waiting for bach's lock in /usr/local/cvsroot/foo -@end example - -@sc{cvs} will try again every 30 seconds, and either -continue with the operation or print the message again, -if it still needs to wait. If a lock seems to stick -around for an undue amount of time, find the person -holding the lock and ask them about the cvs command -they are running. If they aren't running a cvs -command, look in the repository directory mentioned in -the message and remove files which they own whose names -start with @file{#cvs.tfl}, @file{#cvs.rfl}, or -@file{#cvs.wfl}. - -Note that these locks are to protect @sc{cvs}'s -internal data structures and have no relationship to -the word @dfn{lock} in the sense used by -@sc{rcs}---which refers to reserved checkouts -(@pxref{Multiple developers}). - -Any number of people can be reading from a given -repository at a time; only when someone is writing do -the locks prevent other people from reading or writing. - -@cindex Atomic transactions, lack of -@cindex Transactions, atomic, lack of -@c the following talks about what one might call commit/update -@c atomicity. -@c Probably also should say something about -@c commit/commit atomicity, that is, "An update will -@c not get partial versions of more than one commit". -@c CVS currently has this property and I guess we can -@c make it a documented feature. -@c For example one person commits -@c a/one.c and b/four.c and another commits a/two.c and -@c b/three.c. Then an update cannot get the new a/one.c -@c and a/two.c and the old b/four.c and b/three.c. -One might hope for the following property - -@example -If someone commits some changes in one cvs command, -then an update by someone else will either get all the -changes, or none of them. -@end example - -but @sc{cvs} does @emph{not} have this property. For -example, given the files - -@example -a/one.c -a/two.c -b/three.c -b/four.c -@end example - -if someone runs - -@example -cvs ci a/two.c b/three.c -@end example - -and someone else runs @code{cvs update} at the same -time, the person running @code{update} might get only -the change to @file{b/three.c} and not the change to -@file{a/two.c}. - -@node Watches -@section Mechanisms to track who is editing files -@cindex Watches - -For many groups, use of @sc{cvs} in its default mode is -perfectly satisfactory. Users may sometimes go to -check in a modification only to find that another -modification has intervened, but they deal with it and -proceed with their check in. Other groups prefer to be -able to know who is editing what files, so that if two -people try to edit the same file they can choose to -talk about who is doing what when rather than be -surprised at check in time. The features in this -section allow such coordination, while retaining the -ability of two developers to edit the same file at the -same time. - -@c Some people might ask why CVS does not enforce the -@c rule on chmod, by requiring a cvs edit before a cvs -@c commit. The main reason is that it could always be -@c circumvented--one could edit the file, and -@c then when ready to check it in, do the cvs edit and put -@c in the new contents and do the cvs commit. One -@c implementation note: if we _do_ want to have cvs commit -@c require a cvs edit, we should store the state on -@c whether the cvs edit has occurred in the working -@c directory, rather than having the server try to keep -@c track of what working directories exist. -@c FIXME: should the above discussion be part of the -@c manual proper, somewhere, not just in a comment? -For maximum benefit developers should use @code{cvs -edit} (not @code{chmod}) to make files read-write to -edit them, and @code{cvs release} (not @code{rm}) to -discard a working directory which is no longer in use, -but @sc{cvs} is not able to enforce this behavior. - -@c I'm a little dissatisfied with this presentation, -@c because "watch on"/"edit"/"editors" are one set of -@c functionality, and "watch add"/"watchers" is another -@c which is somewhat orthogonal even though they interact in -@c various ways. But I think it might be -@c confusing to describe them separately (e.g. "watch -@c add" with loginfo). I don't know. - -@menu -* Setting a watch:: Telling CVS to watch certain files -* Getting Notified:: Telling CVS to notify you -* Editing files:: How to edit a file which is being watched -* Watch information:: Information about who is watching and editing -* Watches Compatibility:: Watches interact poorly with CVS 1.6 or earlier -@end menu - -@node Setting a watch -@subsection Telling CVS to watch certain files - -To enable the watch features, you first specify that -certain files are to be watched. - -@cindex watch on (subcommand) -@deffn Command {cvs watch on} [@code{-lR}] files @dots{} - -@cindex read-only files, and watches -Specify that developers should run @code{cvs edit} -before editing @var{files}. CVS will create working -copies of @var{files} read-only, to remind developers -to run the @code{cvs edit} command before working on -them. - -If @var{files} includes the name of a directory, CVS -arranges to watch all files added to the corresponding -repository directory, and sets a default for files -added in the future; this allows the user to set -notification policies on a per-directory basis. The -contents of the directory are processed recursively, -unless the @code{-l} option is given. -The @code{-R} option can be used to force recursion if the @code{-l} -option is set in @file{~/.cvsrc} (@pxref{~/.cvsrc}). - -If @var{files} is omitted, it defaults to the current directory. - -@cindex watch off (subcommand) -@end deffn - -@deffn Command {cvs watch off} [@code{-lR}] files @dots{} - -Do not provide notification about work on @var{files}. CVS will create -working copies of @var{files} read-write. - -The @var{files} and options are processed as for @code{cvs -watch on}. - -@end deffn - -@node Getting Notified -@subsection Telling CVS to notify you - -You can tell @sc{cvs} that you want to receive -notifications about various actions taken on a file. -You can do this without using @code{cvs watch on} for -the file, but generally you will want to use @code{cvs -watch on}, so that developers use the @code{cvs edit} -command. - -@cindex watch add (subcommand) -@deffn Command {cvs watch add} [@code{-a} action] [@code{-lR}] files @dots{} - -Add the current user to the list of people to receive notification of -work done on @var{files}. - -The @code{-a} option specifies what kinds of events CVS should notify -the user about. @var{action} is one of the following: - -@table @code - -@item edit -Another user has applied the @code{cvs edit} command (described -below) to a file. - -@item unedit -Another user has applied the @code{cvs unedit} command (described -below) or the @code{cvs release} command to a file, or has deleted -the file and allowed @code{cvs update} to recreate it. - -@item commit -Another user has committed changes to a file. - -@item all -All of the above. - -@item none -None of the above. (This is useful with @code{cvs edit}, -described below.) - -@end table - -The @code{-a} option may appear more than once, or not at all. If -omitted, the action defaults to @code{all}. - -The @var{files} and options are processed as for the -@code{cvs watch} commands. - -@end deffn - - -@cindex watch remove (subcommand) -@deffn Command {cvs watch remove} [@code{-a} action] [@code{-lR}] files @dots{} - -Remove a notification request established using @code{cvs watch add}; -the arguments are the same. If the @code{-a} option is present, only -watches for the specified actions are removed. - -@end deffn - -@cindex notify (admin file) -When the conditions exist for notification, @sc{cvs} -calls the @file{notify} administrative file. Edit -@file{notify} as one edits the other administrative -files (@pxref{Intro administrative files}). This -file follows the usual conventions for administrative -files (@pxref{syntax}), where each line is a regular -expression followed by a command to execute. The -command should contain a single ocurrence of @samp{%s} -which will be replaced by the user to notify; the rest -of the information regarding the notification will be -supplied to the command on standard input. The -standard thing to put in the @code{notify} file is the -single line: - -@example -ALL mail %s -s \"CVS notification\" -@end example - -This causes users to be notified by electronic mail. -@c FIXME: should it be this hard to set up this -@c behavior (and the result when one fails to do so, -@c silent failure to notify, so non-obvious)? Should -@c CVS give a warning if no line in notify matches (and -@c document the use of "DEFAULT :" for the case where -@c skipping the notification is indeed desired)? - -@cindex users (admin file) -Note that if you set this up in the straightforward -way, users receive notifications on the server machine. -One could of course write a @file{notify} script which -directed notifications elsewhere, but to make this -easy, @sc{cvs} allows you to associate a notification -address for each user. To do so create a file -@file{users} in @file{CVSROOT} with a line for each -user in the format @var{user}:@var{value}. Then -instead of passing the name of the user to be notified -to @file{notify}, @sc{cvs} will pass the @var{value} -(normally an email address on some other machine). - -@sc{Cvs} does not notify you for your own changes. -Currently this check is done based on whether the user -name of the person taking the action which triggers -notification matches the user name of the person -getting notification. In fact, in general, the watches -features only track one edit by each user. It probably -would be more useful if watches tracked each working -directory separately, so this behavior might be worth -changing. -@c "behavior might be worth changing" is an effort to -@c point to future directions while also not promising -@c that "they" (as in "why don't they fix CVS to....") -@c will do this. -@c one implementation issue is identifying whether a -@c working directory is same or different. Comparing -@c pathnames/hostnames is hopeless, but having the server -@c supply a serial number which the client stores in the -@c CVS directory as a magic cookie should work. - -@node Editing files -@subsection How to edit a file which is being watched - -@cindex checkout, as term for getting ready to edit -Since a file which is being watched is checked out -read-only, you cannot simply edit it. To make it -read-write, and inform others that you are planning to -edit it, use the @code{cvs edit} command. Some systems -call this a @dfn{checkout}, but @sc{cvs} uses that term -for obtaining a copy of the sources (@pxref{Getting the -source}), an operation which those systems call a -@dfn{get} or a @dfn{fetch}. -@c Issue to think about: should we transition CVS -@c towards the "get" terminology? "cvs get" is already a -@c synonym for "cvs checkout" and that section of the -@c manual refers to "Getting the source". If this is -@c done, needs to be done gingerly (for example, we should -@c still accept "checkout" in .cvsrc files indefinitely -@c even if the CVS's messages are changed from "cvs checkout: " -@c to "cvs get: "). -@c There is a concern about whether "get" is not as -@c good for novices because it is a more general term -@c than "checkout" (and thus arguably harder to assign -@c a technical meaning for). - -@cindex edit (subcommand) -@deffn Command {cvs edit} [options] files @dots{} - -Prepare to edit the working files @var{files}. CVS makes the -@var{files} read-write, and notifies users who have requested -@code{edit} notification for any of @var{files}. - -The @code{cvs edit} command accepts the same @var{options} as the -@code{cvs watch add} command, and establishes a temporary watch for the -user on @var{files}; CVS will remove the watch when @var{files} are -@code{unedit}ed or @code{commit}ted. If the user does not wish to -receive notifications, she should specify @code{-a none}. - -The @var{files} and options are processed as for the @code{cvs -watch} commands. - -@end deffn - -Normally when you are done with a set of changes, you -use the @code{cvs commit} command, which checks in your -changes and returns the watched files to their usual -read-only state. But if you instead decide to abandon -your changes, or not to make any changes, you can use -the @code{cvs unedit} command. - -@cindex unedit (subcommand) -@cindex abandoning work -@cindex reverting to repository version -@deffn Command {cvs unedit} [@code{-lR}] files @dots{} - -Abandon work on the working files @var{files}, and revert them to the -repository versions on which they are based. CVS makes those -@var{files} read-only for which users have requested notification using -@code{cvs watch on}. CVS notifies users who have requested @code{unedit} -notification for any of @var{files}. - -The @var{files} and options are processed as for the -@code{cvs watch} commands. - -If watches are not in use, the @code{unedit} command -probably does not work, and the way to revert to the -repository version is to remove the file and then use -@code{cvs update} to get a new copy. The meaning is -not precisely the same; removing and updating may also -bring in some changes which have been made in the -repository since the last time you updated. -@c It would be a useful enhancement to CVS to make -@c unedit work in the non-watch case as well. -@end deffn - -When using client/server @sc{cvs}, you can use the -@code{cvs edit} and @code{cvs unedit} commands even if -@sc{cvs} is unable to succesfully communicate with the -server; the notifications will be sent upon the next -successful @sc{cvs} command. - -@node Watch information -@subsection Information about who is watching and editing - -@cindex watchers (subcommand) -@deffn Command {cvs watchers} [@code{-lR}] files @dots{} - -List the users currently watching changes to @var{files}. The report -includes the files being watched, and the mail address of each watcher. - -The @var{files} and options are processed as for the -@code{cvs watch} commands. - -@end deffn - - -@cindex editors (subcommand) -@deffn Command {cvs editors} [@code{-lR}] files @dots{} - -List the users currently working on @var{files}. The report -includes the mail address of each user, the time when the user began -working with the file, and the host and path of the working directory -containing the file. - -The @var{files} and options are processed as for the -@code{cvs watch} commands. - -@end deffn - -@node Watches Compatibility -@subsection Using watches with old versions of CVS - -@cindex CVS 1.6, and watches -If you use the watch features on a repository, it -creates @file{CVS} directories in the repository and -stores the information about watches in that directory. -If you attempt to use @sc{cvs} 1.6 or earlier with the -repository, you get an error message such as the -following (all on one line): - -@example -cvs update: cannot open CVS/Entries for reading: -No such file or directory -@end example - -and your operation will likely be aborted. To use the -watch features, you must upgrade all copies of @sc{cvs} -which use that repository in local or server mode. If -you cannot upgrade, use the @code{watch off} and -@code{watch remove} commands to remove all watches, and -that will restore the repository to a state which -@sc{cvs} 1.6 can cope with. - -@node Choosing a model -@section Choosing between reserved or unreserved checkouts -@cindex choosing, reserved or unreserved checkouts - -Reserved and unreserved checkouts each have pros and -cons. Let it be said that a lot of this is a matter of -opinion or what works given different groups' working -styles, but here is a brief description of some of the -issues. There are many ways to organize a team of -developers. @sc{cvs} does not try to enforce a certain -organization. It is a tool that can be used in several -ways. - -Reserved checkouts can be very counter-productive. If -two persons want to edit different parts of a file, -there may be no reason to prevent either of them from -doing so. Also, it is common for someone to take out a -lock on a file, because they are planning to edit it, -but then forget to release the lock. - -@c "many groups"? specifics? cites to papers on this? -@c some way to weasel-word it a bit more so we don't -@c need facts :-)? -People, especially people who are familiar with -reserved checkouts, often wonder how often conflicts -occur if unreserved checkouts are used, and how -difficult they are to resolve. The experience with -many groups is that they occur rarely and usually are -relatively straightforward to resolve. - -The rarity of serious conflicts may be surprising, until one realizes -that they occur only when two developers disagree on the proper design -for a given section of code; such a disagreement suggests that the -team has not been communicating properly in the first place. In order -to collaborate under @emph{any} source management regimen, developers -must agree on the general design of the system; given this agreement, -overlapping changes are usually straightforward to merge. - -In some cases unreserved checkouts are clearly -inappropriate. If no merge tool exists for the kind of -file you are managing (for example word processor files -or files edited by Computer Aided Design programs), and -it is not desirable to change to a program which uses a -mergeable data format, then resolving conflicts is -going to be unpleasant enough that you generally will -be better off to simply avoid the conflicts instead, by -using reserved checkouts. - -The watches features described above in @ref{Watches} -can be considered to be an intermediate model between -reserved checkouts and unreserved checkouts. When you -go to edit a file, it is possible to find out who else -is editing it. And rather than having the system -simply forbid both people editing the file, it can tell -you what the situation is and let you figure out -whether it is a problem in that particular case or not. -Therefore, for some groups it can be considered the -best of both the reserved checkout and unreserved -checkout worlds. - -@c --------------------------------------------------------------------- -@node Revisions and branches -@chapter Revisions and branches -@cindex Branches -@cindex Main trunk and branches -@cindex Revision tree, making branches +@node Revisions +@chapter Revisions For many uses of @sc{cvs}, one doesn't need to worry too much about revision numbers; @sc{cvs} assigns @@ -3750,21 +2948,12 @@ went into a particular release, one uses a @dfn{tag}, which is a symbolic revision which can be assigned to a numeric revision in each file. -Another useful feature, especially when maintaining -several releases of a software product at once, is the -ability to make branches on the revision tree. -@c FIXME: probably want another sentence or two, very -@c briefly motivating branches. - @menu * Revision numbers:: The meaning of a revision number * Versions revisions releases:: Terminology used in this manual * Assigning revisions:: Assigning revisions * Tags:: Tags--Symbolic revisions -* Branches motivation:: What branches are good for -* Creating a branch:: Creating a branch -* Sticky tags:: Sticky tags -* Magic branch numbers:: Magic branch numbers +* Sticky tags:: Certain tags are persistent @end menu @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - @@ -3794,71 +2983,12 @@ a few revisions, with newer revisions to the right. +-----+ +-----+ +-----+ +-----+ +-----+ @end example -@c Probably should move the following down a few -@c sections, until after "branch motivation". -@sc{cvs} is not limited to linear development. The -@dfn{revision tree} can be split into @dfn{branches}, -where each branch is a self-maintained line of -development. Changes made on one branch can easily be -moved back to the main trunk. - -Each branch has a @dfn{branch number}, consisting of an -odd number of period-separated decimal integers. The -branch number is created by appending an integer to the -revision number where the corresponding branch forked -off. Having branch numbers allows more than one branch -to be forked off from a certain revision. - -@need 3500 -All revisions on a branch have revision numbers formed -by appending an ordinal number to the branch number. -The following figure illustrates branching with an -example. - -@example -@group - +-------------+ - Branch 1.2.2.3.2 -> ! 1.2.2.3.2.1 ! - / +-------------+ - / - / - +---------+ +---------+ +---------+ -Branch 1.2.2 -> _! 1.2.2.1 !----! 1.2.2.2 !----! 1.2.2.3 ! - / +---------+ +---------+ +---------+ - / - / -+-----+ +-----+ +-----+ +-----+ +-----+ -! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 ! <- The main trunk -+-----+ +-----+ +-----+ +-----+ +-----+ - ! - ! - ! +---------+ +---------+ +---------+ -Branch 1.2.4 -> +---! 1.2.4.1 !----! 1.2.4.2 !----! 1.2.4.3 ! - +---------+ +---------+ +---------+ - -@end group -@end example - -@c -- However, at least for me the figure is not enough. I suggest more -@c -- text to accompany it. "A picture is worth a thousand words", so you -@c -- have to make sure the reader notices the couple of hundred words -@c -- *you* had in mind more than the others! - -@c -- Why an even number of segments? This section implies that this is -@c -- how the main trunk is distinguished from branch roots, but you never -@c -- explicitly say that this is the purpose of the [by itself rather -@c -- surprising] restriction to an even number of segments. - -The exact details of how the branch number is -constructed is not something you normally need to be -concerned about, but here is how it works: When -@sc{cvs} creates a branch number it picks the first -unused even integer, starting with 2. So when you want -to create a branch from revision 6.4 it will be -numbered 6.4.2. All branch numbers ending in a zero -(such as 6.4.0) are used internally by @sc{cvs} -(@pxref{Magic branch numbers}). The branch 1.1.1 has a -special meaning. @xref{Tracking sources}. +It is also possible to end up with numbers containing +more than one period, for example @samp{1.3.2.2}. Such +revisions represent revisions on branches +(@pxref{Branching and merging}); such revision numbers +are explained in detail in @ref{Branches and +revisions}. @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - @node Versions revisions releases @@ -3925,7 +3055,7 @@ Note that the number you specify with @samp{-r} must be larger than any existing revision number. That is, if revision 3.0 exists, you cannot @samp{cvs commit -r 1.3}. If you want to maintain several releases in -parallel, you need to use a branch (@pxref{Revisions and branches}). +parallel, you need to use a branch (@pxref{Branching and merging}). @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - @node Tags @@ -3960,6 +3090,8 @@ rcsutil.c 5.10 @cindex Tag, symbolic name @cindex Symbolic name (tag) @cindex Name, symbolic (tag) +@cindex HEAD, as reserved tag name +@cindex BASE, as reserved tag name You can use the @code{tag} command to give a symbolic name to a certain revision of a file. You can use the @samp{-v} flag to the @code{status} command to see all tags that a file has, and @@ -4110,12 +3242,157 @@ like this: @end example @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +@node Sticky tags +@section Sticky tags +@cindex Sticky tags +@cindex Tags, sticky + +@c A somewhat related issue is per-directory sticky +@c tags (see comment at CVS/Tag in node Working +@c directory storage); we probably want to say +@c something like "you can set a sticky tag for only +@c some files, but you don't want to" or some such. + +Sometimes a working copy's revision has extra data +associated with it, for example it might be on a branch +(@pxref{Branching and merging}), or restricted to +versions prior to a certain date by @samp{checkout -D} +or @samp{update -D}. Because this data persists -- +that is, it applies to subsequent commands in the +working copy -- we refer to it as @dfn{sticky}. + +Most of the time, stickiness is an obscure aspect of +@sc{cvs} that you don't need to think about. However, +even if you don't want to use the feature, you may need +to know @emph{something} about sticky tags (for +example, how to avoid them!). + +You can use the @code{status} command to see if any +sticky tags or dates are set: + +@example +$ cvs status driver.c +=================================================================== +File: driver.c Status: Up-to-date + + Version: 1.7.2.1 Sat Dec 5 19:35:03 1992 + RCS Version: 1.7.2.1 /u/cvsroot/yoyodyne/tc/driver.c,v + Sticky Tag: release-1-0-patches (branch: 1.7.2) + Sticky Date: (none) + Sticky Options: (none) + +@end example + +@cindex Resetting sticky tags +@cindex Sticky tags, resetting +@cindex Deleting sticky tags +The sticky tags will remain on your working files until +you delete them with @samp{cvs update -A}. The +@samp{-A} option retrieves the version of the file from +the head of the trunk, and forgets any sticky tags, +dates, or options. + +@cindex sticky date +The most common use of sticky tags is to identify which +branch one is working on, as described in +@ref{Accessing branches}. However, non-branch +sticky tags have uses as well. For example, +suppose that you want to avoid updating your working +directory, to isolate yourself from possibly +destabilizing changes other people are making. You +can, of course, just refrain from running @code{cvs +update}. But if you want to avoid updating only a +portion of a larger tree, then sticky tags can help. +If you check out a certain revision (such as 1.4) it +will become sticky. Subsequent @code{cvs update} +commands will +not retrieve the latest revision until you reset the +tag with @code{cvs update -A}. Likewise, use of the +@samp{-D} option to @code{update} or @code{checkout} +sets a @dfn{sticky date}, which, similarly, causes that +date to be used for future retrievals. + +@cindex Restoring old version of removed file +@cindex Resurrecting old version of dead file +Many times you will want to retrieve an old version of +a file without setting a sticky tag. The way to do +that is with the @samp{-p} option to @code{checkout} or +@code{update}, which sends the contents of the file to +standard output. For example, suppose you have a file +named @file{file1} which existed as revision 1.1, and +you then removed it (thus adding a dead revision 1.2). +Now suppose you want to add it again, with the same +contents it had previously. Here is how to do it: + +@example +$ cvs update -p -r 1.1 file1 >file1 +=================================================================== +Checking out file1 +RCS: /tmp/cvs-sanity/cvsroot/first-dir/Attic/file1,v +VERS: 1.1 +*************** +$ cvs add file1 +cvs add: re-adding file file1 (in place of dead revision 1.2) +cvs add: use 'cvs commit' to add this file permanently +$ cvs commit -m test +Checking in file1; +/tmp/cvs-sanity/cvsroot/first-dir/file1,v <-- file1 +new revision: 1.3; previous revision: 1.2 +done +$ +@end example + +@c --------------------------------------------------------------------- +@node Branching and merging +@chapter Branching and merging +@cindex Branching +@cindex Merging +@cindex Copying changes +@cindex Main trunk and branches +@cindex Revision tree, making branches +@cindex Branches, copying changes between +@cindex Changes, copying between branches +@cindex Modifications, copying between branches + +CVS allows you to isolate changes onto a separate +line of development, known as a @dfn{branch}. When you +change files on a branch, those changes do not appear +on the main trunk or other branches. + +Later you can move changes from one branch to another +branch (or the main trunk) by @dfn{merging}. Merging +involves first running @code{cvs update -j}, to merge +the changes into the working directory. +You can then commit that revision, and thus effectively +copy the changes onto another branch. + +@menu +* Branches motivation:: What branches are good for +* Creating a branch:: Creating a branch +* Accessing branches:: Checking out and updating branches +* Branches and revisions:: Branches are reflected in revision numbers +* Magic branch numbers:: Magic branch numbers +* Merging a branch:: Merging an entire branch +* Merging more than once:: Merging from a branch several times +* Merging two revisions:: Merging differences between two revisions +* Merging adds and removals:: What if files are added or removed? +@end menu + +@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - @node Branches motivation @section What branches are good for @cindex Branches motivation @cindex What branches are good for @cindex Motivation for branches +@c FIXME: this node mentions one way to use branches, +@c but it is by no means the only way. For example, +@c the technique of committing a new feature on a branch, +@c until it is ready for the main trunk. The whole +@c thing is generally speaking more akin to the +@c "Revision management" node although it isn't clear to +@c me whether policy matters should be centralized or +@c distributed throughout the relevant sections. Suppose that release 1.0 of tc has been made. You are continuing to develop tc, planning to create release 1.1 in a couple of months. After a while your customers start to complain about a fatal bug. You check @@ -4129,7 +3406,7 @@ The thing to do in a situation like this is to create a @dfn{branch} on the revision trees for all the files that make up release 1.0 of tc. You can then make modifications to the branch without disturbing the main trunk. When the -modifications are finished you can select to either incorporate them on +modifications are finished you can elect to either incorporate them on the main trunk, or leave them on the branch. @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - @@ -4137,42 +3414,120 @@ the main trunk, or leave them on the branch. @section Creating a branch @cindex Creating a branch @cindex Branch, creating a +@cindex tag, creating a branch using @cindex rtag, creating a branch using -@c FIXME: should be more explicit about the value of -@c having a tag on the branchpoint. Also should talk -@c about creating a branch with tag not rtag. -The @code{rtag} command can be used to create a branch. -The @code{rtag} command is much like @code{tag}, but it -does not require that you have a working copy of the -module. @xref{rtag}. (You can also use the @code{tag} -command; @pxref{tag}). - -@c Why does this example use -r? That seems like a -@c confusing thing to do in an example where we are -@c introducing branches. One user thought it was -@c a mandatory part of creating a branch for example. -@c And we are not sufficiently -@c "step by step" in terms of explaining -@c what argument one should give to -r. +You can create a branch with @code{tag -b}; for +example, assuming you're in a working copy: + +@example +$ cvs tag -b release-1-0-patches +@end example + +@c FIXME: we should be more explicit about the value of +@c having a tag on the branchpoint. For example +@c "cvs tag release-1-0-patches-branchpoint" before +@c the "cvs tag -b". This points out that +@c release-1-0-patches is a pretty awkward name for +@c this example (more so than for the rtag example +@c below). + +This splits off a branch based on the current revisions +in the working copy, assigning that branch the name +@samp{release-1-0-patches}. + +It is important to understand that branches get created +in the repository, not in the working copy. Creating a +branch based on current revisions, as the above example +does, will @emph{not} automatically switch the working +copy to be on the new branch. For information on how +to do that, see @ref{Accessing branches}. + +You can also create a branch without reference to any +working copy, by using @code{rtag}: + @example $ cvs rtag -b -r release-1-0 release-1-0-patches tc @end example -The @samp{-b} flag makes @code{rtag} create a branch -(rather than just a symbolic revision name). @samp{-r -release-1-0} says that this branch should be rooted at the node (in -the revision tree) that corresponds to the tag -@samp{release-1-0}. Note that the numeric revision number that matches -@samp{release-1-0} will probably be different from file to file. The -name of the new branch is @samp{release-1-0-patches}, and the -module affected is @samp{tc}. +@samp{-r release-1-0} says that this branch should be +rooted at the revision that +corresponds to the tag @samp{release-1-0}. It need not +be the most recent revision -- it's often useful to +split a branch off an old revision (for example, when +fixing a bug in a past release otherwise known to be +stable). + +As with @samp{tag}, the @samp{-b} flag tells +@code{rtag} to create a branch (rather than just a +symbolic revision name). Note that the numeric +revision number that matches @samp{release-1-0} will +probably be different from file to file. -To fix the problem in release 1.0, you need a working -copy of the branch you just created. +So, the full effect of the command is to create a new +branch -- named @samp{release-1-0-patches} -- in module +@samp{tc}, rooted in the revision tree at the point tagged +by @samp{release-1-0}. + +@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +@node Accessing branches +@section Accessing branches +@cindex Check out a branch +@cindex Retrieve a branch +@cindex Access a branch +@cindex Identifying a branch +@cindex Branch, check out +@cindex Branch, retrieving +@cindex Branch, accessing +@cindex Branch, identifying + +You can retrieve a branch in one of two ways: by +checking it out fresh from the repository, or by +switching an existing working copy over to the branch. + +To check out a branch from the repository, invoke +@samp{checkout} with the @samp{-r} flag, followed by +the tag name of the branch (@pxref{Creating a branch}): @example $ cvs checkout -r release-1-0-patches tc +@end example + +Or, if you already have a working copy, you can switch +it to a given branch with @samp{update -r}: + +@example +$ cvs update -r release-1-0-patches tc +@end example + +or equivalently: + +@example +$ cd tc +$ cvs update -r release-1-0-patches +@end example + +It does not matter if the working copy was originally +on the main trunk or on some other branch -- the above +command will switch it to the named branch. And +similarly to a regular @samp{update} command, +@samp{update -r} merges any changes you have made, +notifying you of conflicts where they occur. + +Once you have a working copy tied to a particular +branch, it remains there until you tell it otherwise. +This means that changes checked in from the working +copy will add new revisions on that branch, while +leaving the main trunk and other branches unaffected. + +@cindex Branches, sticky +To find out what branch a working copy is on, you can +use the @samp{status} command. In its output, look for +the field named @samp{Sticky tag} (@pxref{Sticky tags}) +-- that's @sc{cvs}'s way of telling you the branch, if +any, of the current working files: + +@example $ cvs status -v driver.c backend.c =================================================================== File: driver.c Status: Up-to-date @@ -4203,119 +3558,104 @@ File: backend.c Status: Up-to-date @end example -@cindex Branch numbers -As the output from the @code{status} command shows the branch -number is created by adding a digit at the tail of the revision number -it is based on. (If @samp{release-1-0} corresponds to revision 1.4, the -branch's revision number will be 1.4.2. For obscure reasons @sc{cvs} always -gives branches even numbers, starting at 2. -@xref{Revision numbers}.). +Don't be confused by the fact that the branch numbers +for each file are different (@samp{1.7.2} and +@samp{1.4.2} respectively). The branch tag is the +same, @samp{release-1-0-patches}, and the files are +indeed on the same branch. The numbers simply reflect +the point in each file's revision history at which the +branch was made. In the above example, one can deduce +that @samp{driver.c} had been through more changes than +@samp{backend.c} before this branch was created. -@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -@node Sticky tags -@section Sticky tags -@cindex Sticky tags -@cindex Tags, sticky -@cindex Branches, sticky +See @ref{Branches and revisions} for details about how +branch numbers are constructed. -@c FIXME: make this stand alone better; many places -@c @xref to this node. -The @samp{-r release-1-0-patches} flag that was given -to @code{checkout} in the previous example -is @dfn{sticky}, that is, it will apply to subsequent commands -in this directory. If you commit any modifications, they are -committed on the branch. You can later merge the modifications into -the main trunk. @xref{Merging}. +@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +@node Branches and revisions +@section Branches and revisions +@cindex Branch number +@cindex Number, branch +@cindex Revision numbers (branches) -You can use the @code{status} command to see what -sticky tags or dates are set: +Ordinarily, a file's revision history is a linear +series of increments (@pxref{Revision numbers}): -@c FIXME: This example needs to stand alone better and it -@c would also better if it didn't use -v which only -@c clutters the output in this context. @example -$ vi driver.c # @r{Fix the bugs} -$ cvs commit -m "Fixed initialization bug" driver.c -Checking in driver.c; -/usr/local/cvsroot/yoyodyne/tc/driver.c,v <-- driver.c -new revision: 1.7.2.1; previous revision: 1.7 -done -$ cvs status -v driver.c -=================================================================== -File: driver.c Status: Up-to-date - - Version: 1.7.2.1 Sat Dec 5 19:35:03 1992 - RCS Version: 1.7.2.1 /u/cvsroot/yoyodyne/tc/driver.c,v - Sticky Tag: release-1-0-patches (branch: 1.7.2) - Sticky Date: (none) - Sticky Options: (none) - - Existing Tags: - release-1-0-patches (branch: 1.7.2) - release-1-0 (revision: 1.7) - + +-----+ +-----+ +-----+ +-----+ +-----+ + ! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 ! + +-----+ +-----+ +-----+ +-----+ +-----+ @end example -@cindex Resetting sticky tags -@cindex Sticky tags, resetting -@cindex Deleting sticky tags -The sticky tags will remain on your working files until -you delete them with @samp{cvs update -A}. The -@samp{-A} option retrieves the version of the file from -the head of the trunk, and forgets any sticky tags, -dates, or options. +However, @sc{cvs} is not limited to linear development. The +@dfn{revision tree} can be split into @dfn{branches}, +where each branch is a self-maintained line of +development. Changes made on one branch can easily be +moved back to the main trunk. -@cindex sticky date -Sticky tags are not just for branches. For example, -suppose that you want to avoid updating your working -directory, to isolate yourself from possibly -destabilizing changes other people are making. You -can, of course, just refrain from running @code{cvs -update}. But if you want to avoid updating only a -portion of a larger tree, then sticky tags can help. -If you check out a certain revision (such as 1.4) it -will become sticky. Subsequent @code{cvs update} will -not retrieve the latest revision until you reset the -tag with @code{cvs update -A}. Likewise, use of the -@samp{-D} option to @code{update} or @code{checkout} -sets a @dfn{sticky date}, which, similarly, causes that -date to be used for future retrievals. +Each branch has a @dfn{branch number}, consisting of an +odd number of period-separated decimal integers. The +branch number is created by appending an integer to the +revision number where the corresponding branch forked +off. Having branch numbers allows more than one branch +to be forked off from a certain revision. -@cindex Restoring old version of removed file -@cindex Resurrecting old version of dead file -Many times you will want to retrieve an old version of -a file without setting a sticky tag. The way to do -that is with the @samp{-p} option to @code{checkout} or -@code{update}, which sends the contents of the file to -standard output. For example, suppose you have a file -named @file{file1} which existed as revision 1.1, and -you then removed it (thus adding a dead revision 1.2). -Now suppose you want to add it again, with the same -contents it had previously. Here is how to do it: +@need 3500 +All revisions on a branch have revision numbers formed +by appending an ordinal number to the branch number. +The following figure illustrates branching with an +example. @example -$ cvs update -p -r 1.1 file1 >file1 -=================================================================== -Checking out file1 -RCS: /tmp/cvs-sanity/cvsroot/first-dir/Attic/file1,v -VERS: 1.1 -*************** -$ cvs add file1 -cvs add: re-adding file file1 (in place of dead revision 1.2) -cvs add: use 'cvs commit' to add this file permanently -$ cvs commit -m test -Checking in file1; -/tmp/cvs-sanity/cvsroot/first-dir/file1,v <-- file1 -new revision: 1.3; previous revision: 1.2 -done -$ +@group + +-------------+ + Branch 1.2.2.3.2 -> ! 1.2.2.3.2.1 ! + / +-------------+ + / + / + +---------+ +---------+ +---------+ +Branch 1.2.2 -> _! 1.2.2.1 !----! 1.2.2.2 !----! 1.2.2.3 ! + / +---------+ +---------+ +---------+ + / + / ++-----+ +-----+ +-----+ +-----+ +-----+ +! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 ! <- The main trunk ++-----+ +-----+ +-----+ +-----+ +-----+ + ! + ! + ! +---------+ +---------+ +---------+ +Branch 1.2.4 -> +---! 1.2.4.1 !----! 1.2.4.2 !----! 1.2.4.3 ! + +---------+ +---------+ +---------+ + +@end group @end example +@c -- However, at least for me the figure is not enough. I suggest more +@c -- text to accompany it. "A picture is worth a thousand words", so you +@c -- have to make sure the reader notices the couple of hundred words +@c -- *you* had in mind more than the others! + +@c -- Why an even number of segments? This section implies that this is +@c -- how the main trunk is distinguished from branch roots, but you never +@c -- explicitly say that this is the purpose of the [by itself rather +@c -- surprising] restriction to an even number of segments. + +The exact details of how the branch number is +constructed is not something you normally need to be +concerned about, but here is how it works: When +@sc{cvs} creates a branch number it picks the first +unused even integer, starting with 2. So when you want +to create a branch from revision 6.4 it will be +numbered 6.4.2. All branch numbers ending in a zero +(such as 6.4.0) are used internally by @sc{cvs} +(@pxref{Magic branch numbers}). The branch 1.1.1 has a +special meaning. @xref{Tracking sources}. + @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - @node Magic branch numbers @section Magic branch numbers -@c Want xref to here from "log" and "admin"? +@c Want xref to here from "log"? This section describes a @sc{cvs} feature called @dfn{magic branches}. For most purposes, you need not @@ -4328,8 +3668,8 @@ Externally, branch numbers consist of an odd number of dot-separated decimal integers. @xref{Revision numbers}. That is not the whole truth, however. For efficiency reasons @sc{cvs} sometimes inserts an extra 0 -in the second rightmost position (1.2.3 becomes -1.2.0.3, 8.9.10.11.12 becomes 8.9.10.11.0.12 and so +in the second rightmost position (1.2.4 becomes +1.2.0.4, 8.9.10.11.12 becomes 8.9.10.11.0.12 and so on). @sc{cvs} does a pretty good job at hiding these so @@ -4378,27 +3718,6 @@ committed on the branch. Be very careful so that you do not assign the tag to the wrong number. (There is no way to see how the tag was assigned yesterday). -@c --------------------------------------------------------------------- -@node Merging -@chapter Merging -@cindex Merging -@cindex Copying changes -@cindex Branches, copying changes between -@cindex Changes, copying between branches -@cindex Modifications, copying between branches - -You can include the changes made between any two -revisions into your working copy, by @dfn{merging}. -You can then commit that revision, and thus effectively -copy the changes onto another branch. - -@menu -* Merging a branch:: Merging an entire branch -* Merging more than once:: Merging from a branch several times -* Merging two revisions:: Merging differences between two revisions -* Merging adds and removals:: What if files are added or removed? -@end menu - @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - @node Merging a branch @section Merging an entire branch @@ -4579,6 +3898,10 @@ cvs update -A cvs update -jbranchtag @end example +After these commands are executed and a @samp{cvs commit} is done, +file @file{a} will be removed and file @file{d} added in the main branch. +@c (which was determined by trying it) + @c --------------------------------------------------------------------- @node Recursive behavior @chapter Recursive behavior @@ -4656,8 +3979,28 @@ $ cvs update -l # @r{Don't update files in subdirectories} @end example @c --------------------------------------------------------------------- +@node Adding and removing +@chapter Adding, removing, and renaming files and directories + +In the course of a project, one will often add new +files. Likewise with removing or renaming, or with +directories. The general concept to keep in mind in +all these cases is that instead of making an +irreversible change you want @sc{cvs} to record the +fact that a change has taken place, just as with +modifying an existing file. The exact mechanisms to do +this in @sc{cvs} vary depending on the situation. + +@menu +* Adding files:: Adding files +* Removing files:: Removing files +* Removing directories:: Removing directories +* Moving files:: Moving and renaming files +* Moving directories:: Moving and renaming directories +@end menu + @node Adding files -@chapter Adding files to a directory +@section Adding files to a directory @cindex Adding files To add a new file to a directory, follow these steps. @@ -4693,7 +4036,7 @@ Unlike most other commands, the @code{add} command is not recursive. You cannot even type @samp{cvs add foo/bar}! Instead, you have to @c FIXCVS: This is, of course, not a feature. It is -@c just that noone has gotten around to fixing "cvs add +@c just that no one has gotten around to fixing "cvs add @c foo/bar". @example @@ -4751,7 +4094,7 @@ $ cvs commit -m "Early version. Not yet compilable." backend.c @end example When you add a file it is added only on the branch -which you are working on (@pxref{Revisions and branches}). You can +which you are working on (@pxref{Branching and merging}). You can later merge the additions to another branch if you want (@pxref{Merging adds and removals}). @c Should we mention that earlier versions of CVS @@ -4768,14 +4111,13 @@ later merge the additions to another branch if you want @c --------------------------------------------------------------------- @node Removing files -@chapter Removing files +@section Removing files @cindex Removing files @cindex Deleting files @c FIXME: this node wants to be split into several -@c smaller nodes. Probably would fit well with merging -@c this chapter with "adding files" and the others, as -@c suggested at the top-level menu (death support could +@c smaller nodes. Could make these children of +@c "Adding and removing", probably (death support could @c be its own section, for example, as could the @c various bits about undoing mistakes in adding and @c removing). @@ -4915,12 +4257,12 @@ U oj.c @end example When you remove a file it is removed only on the branch -which you are working on (@pxref{Revisions and branches}). You can +which you are working on (@pxref{Branching and merging}). You can later merge the removals to another branch if you want (@pxref{Merging adds and removals}). @node Removing directories -@chapter Removing directories +@section Removing directories @cindex removing directories @cindex directories, removing @@ -4931,7 +4273,9 @@ be able to retrieve old releases in which the directory existed. The way that you remove a directory is to remove all -the files in it. Then specify the @samp{-P} option to +the files in it. You don't remove the directory +itself; there is no way to do that. +Instead you specify the @samp{-P} option to @code{cvs update}, @code{cvs checkout}, or @code{cvs export}, which will cause @sc{cvs} to remove empty directories from working directories. Probably the @@ -4953,257 +4297,8 @@ or not depending on whether the particular version you are checking out contains any files in that directory. @c --------------------------------------------------------------------- -@node Tracking sources -@chapter Tracking third-party sources -@cindex Third-party sources -@cindex Tracking sources - -@c FIXME: Need discussion of added and removed files. -@c FIXME: This doesn't really adequately introduce the -@c concepts of "vendor" and "you". They don't *have* -@c to be separate organizations or separate people. -@c We want a description which is somewhat more based on -@c the technical issues of which sources go where, but -@c also with enough examples of how this relates to -@c relationships like customer-supplier, developer-QA, -@c maintainer-contributor, or whatever, to make it -@c seem concrete. -If you modify a program to better fit your site, you -probably want to include your modifications when the next -release of the program arrives. @sc{cvs} can help you with -this task. - -@cindex Vendor -@cindex Vendor branch -@cindex Branch, vendor- -In the terminology used in @sc{cvs}, the supplier of the -program is called a @dfn{vendor}. The unmodified -distribution from the vendor is checked in on its own -branch, the @dfn{vendor branch}. @sc{cvs} reserves branch -1.1.1 for this use. - -When you modify the source and commit it, your revision -will end up on the main trunk. When a new release is -made by the vendor, you commit it on the vendor branch -and copy the modifications onto the main trunk. - -Use the @code{import} command to create and update -the vendor branch. After a successful @code{import} -the vendor branch is made the `head' revision, so -anyone that checks out a copy of the file gets that -revision. When a local modification is committed it is -placed on the main trunk, and made the `head' -revision. - -@menu -* First import:: Importing a module for the first time -* Update imports:: Updating a module with the import command -* Reverting local changes:: Reverting a module to the latest vendor release -* Binary files in imports:: Binary files require special handling -* Keywords in imports:: Keyword substitution might be undesirable -* Multiple vendor branches:: What if you get sources from several places? -@end menu - -@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -@node First import -@section Importing a module for the first time -@cindex Importing modules - -@c Should mention naming conventions for vendor tags, -@c release tags, and perhaps directory names. -Use the @code{import} command to check in the sources -for the first time. When you use the @code{import} -command to track third-party sources, the @dfn{vendor -tag} and @dfn{release tags} are useful. The -@dfn{vendor tag} is a symbolic name for the branch -(which is always 1.1.1, unless you use the @samp{-b -@var{branch}} flag---@xref{Multiple vendor branches}.). The -@dfn{release tags} are symbolic names for a particular -release, such as @samp{FSF_0_04}. - -@c I'm not completely sure this belongs here. But -@c we need to say it _somewhere_ reasonably obvious; it -@c is a common misconception among people first learning CVS -Note that @code{import} does @emph{not} change the -directory in which you invoke it. In particular, it -does not set up that directory as a @sc{cvs} working -directory; if you want to work with the sources import -them first and then check them out into a different -directory (@pxref{Getting the source}). - -@cindex Wdiff (import example) -Suppose you have the sources to a program called -@code{wdiff} in a directory @file{wdiff-0.04}, -and are going to make private modifications that you -want to be able to use even when new releases are made -in the future. You start by importing the source to -your repository: - -@example -$ cd wdiff-0.04 -$ cvs import -m "Import of FSF v. 0.04" fsf/wdiff FSF_DIST WDIFF_0_04 -@end example - -The vendor tag is named @samp{FSF_DIST} in the above -example, and the only release tag assigned is -@samp{WDIFF_0_04}. -@c FIXME: Need to say where fsf/wdiff comes from. - -@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -@node Update imports -@section Updating a module with the import command - -When a new release of the source arrives, you import it into the -repository with the same @code{import} command that you used to set up -the repository in the first place. The only difference is that you -specify a different release tag this time. - -@example -$ tar xfz wdiff-0.05.tar.gz -$ cd wdiff-0.05 -$ cvs import -m "Import of FSF v. 0.05" fsf/wdiff FSF_DIST WDIFF_0_05 -@end example - -For files that have not been modified locally, the newly created -revision becomes the head revision. If you have made local -changes, @code{import} will warn you that you must merge the changes -into the main trunk, and tell you to use @samp{checkout -j} to do so. - -@c FIXME: why "wdiff" here and "fsf/wdiff" in the -@c "import"? I think the assumption is that one has -@c "wdiff fsf/wdiff" or some such in modules, but it -@c would be better to not use modules in this example. -@example -$ cvs checkout -jFSF_DIST:yesterday -jFSF_DIST wdiff -@end example - -@noindent -The above command will check out the latest revision of -@samp{wdiff}, merging the changes made on the vendor branch @samp{FSF_DIST} -since yesterday into the working copy. If any conflicts arise during -the merge they should be resolved in the normal way (@pxref{Conflicts -example}). Then, the modified files may be committed. - -Using a date, as suggested above, assumes that you do -not import more than one release of a product per -day. If you do, you can always use something like this -instead: - -@example -$ cvs checkout -jWDIFF_0_04 -jWDIFF_0_05 wdiff -@end example - -@noindent -In this case, the two above commands are equivalent. - -@node Reverting local changes -@section Reverting to the latest vendor release - -You can also revert local changes completely and return -to the latest vendor release by changing the `head' -revision back to the vendor branch on all files. For -example, if you have a checked-out copy of the sources -in @file{~/work.d/wdiff}, and you want to revert to the -vendor's version for all the files in that directory, -you would type: - -@example -$ cd ~/work.d/wdiff -$ cvs admin -bWDIFF . -@end example - -@noindent -You must specify the @samp{-bWDIFF} without any space -after the @samp{-b}. @xref{admin options}. - -@node Binary files in imports -@section How to handle binary files with cvs import - -Use the @samp{-k} wrapper option to tell import which -files are binary. @xref{Wrappers}. - -@node Keywords in imports -@section How to handle keyword substitution with cvs import - -The sources which you are importing may contain -keywords (@pxref{Keyword substitution}). For example, -the vendor may use @sc{cvs} or some other system -which uses similar keyword expansion syntax. If you -just import the files in the default fashion, then -the keyword expansions supplied by the vendor will -be replaced by keyword expansions supplied by your -own copy of @sc{cvs}. It may be more convenient to -maintain the expansions supplied by the vendor, so -that this information can supply information about -the sources that you imported from the vendor. - -To maintain the keyword expansions supplied by the -vendor, supply the @samp{-ko} option to @code{cvs -import} the first time you import the file. -This will turn off keyword expansion -for that file entirely, so if you want to be more -selective you'll have to think about what you want -and use the @samp{-k} option to @code{cvs update} or -@code{cvs admin} as appropriate. -@c Supplying -ko to import if the file already existed -@c has no effect. Not clear to me whether it should -@c or not. - -@node Multiple vendor branches -@section Multiple vendor branches - -All the examples so far assume that there is only one -vendor from which you are getting sources. In some -situations you might get sources from a variety of -places. For example, suppose that you are dealing with -a project where many different people and teams are -modifying the software. There are a variety of ways to -handle this, but in some cases you have a bunch of -source trees lying around and what you want to do more -than anything else is just to all put them in CVS so -that you at least have them in one place. - -For handling situations in which there may be more than -one vendor, you may specify the @samp{-b} option to -@code{cvs import}. It takes as an argument the vendor -branch to import to. The default is @samp{-b 1.1.1}. - -For example, suppose that there are two teams, the red -team and the blue team, that are sending you sources. -You want to import the red team's efforts to branch -1.1.1 and use the vendor tag RED. You want to import -the blue team's efforts to branch 1.1.3 and use the -vendor tag BLUE. So the commands you might use are: - -@example -$ cvs import dir RED RED_1-0 -$ cvs import -b 1.1.3 dir BLUE BLUE_1-5 -@end example - -Note that if your vendor tag does not match your -@samp{-b} option, CVS will not detect this case! For -example, - -@example -$ cvs import -b 1.1.3 dir RED RED_1-0 -@end example - -@noindent -Be careful; this kind of mismatch is sure to sow -confusion or worse. I can't think of a useful purpose -for the ability to specify a mismatch here, but if you -discover such a use, don't. CVS is likely to make this -an error in some future release. - -@c Probably should say more about the semantics of -@c multiple branches. What about the default branch? -@c What about joining (perhaps not as useful with -@c multiple branches, or perhaps it is. Either way -@c should be mentioned). - -@c --------------------------------------------------------------------- @node Moving files -@chapter Moving and renaming files +@section Moving and renaming files @cindex Moving files @cindex Renaming files @cindex Files, moving @@ -5224,7 +4319,7 @@ The examples below assume that the file @var{old} is renamed to @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - @node Outside -@section The Normal way to Rename +@subsection The Normal way to Rename @c More rename issues. Not sure whether these are @c worth documenting; I'm putting them here because @@ -5270,7 +4365,7 @@ information see @ref{Assigning revisions}. @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - @node Inside -@section Moving the history file +@subsection Moving the history file This method is more dangerous, since it involves moving files inside the repository. Read this entire section @@ -5312,7 +4407,7 @@ commands while you move it. @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - @node Rename by copying -@section Copying the history file +@subsection Copying the history file This way also involves direct modifications to the repository. It is safe, but not without drawbacks. @@ -5378,7 +4473,7 @@ numbers will start at 1.0 again. @c --------------------------------------------------------------------- @node Moving directories -@chapter Moving and renaming directories +@section Moving and renaming directories @cindex Moving directories @cindex Renaming directories @cindex Directories, moving @@ -5676,6 +4771,1281 @@ in more detail in @ref{Common options}. @c changed this line *before* 1.4"...). @c --------------------------------------------------------------------- +@node Binary files +@chapter Handling binary files +@cindex Binary files + +The most common use for @sc{cvs} is to store text +files. With text files, @sc{cvs} can merge revisions, +display the differences between revisions in a +human-visible fashion, and other such operations. +However, if you are willing to give up a few of these +abilities, @sc{cvs} can store binary files. For +example, one might store a web site in @sc{cvs} +including both text files and binary images. + +@menu +* Binary why:: More details on issues with binary files +* Binary howto:: How to store them +@end menu + +@node Binary why +@section The issues with binary files + +While the need to manage binary files may seem obvious +if the files that you customarily work with are binary, +putting them into version control does present some +additional issues. + +One basic function of version control is to show the +differences between two revisions. For example, if +someone else checked in a new version of a file, you +may wish to look at what they changed and determine +whether their changes are good. For text files, +@sc{cvs} provides this functionality via the @code{cvs +diff} command. For binary files, it may be possible to +extract the two revisions and then compare them with a +tool external to @sc{cvs} (for example, word processing +software often has such a feature). If there is no +such tool, one must track changes via other mechanisms, +such as urging people to write good log messages, and +hoping that the changes they actually made were the +changes that they intended to make. + +Another ability of a version control system is the +ability to merge two revisions. For @sc{cvs} this +happens in two contexts. The first is when users make +changes in separate working directories +(@pxref{Multiple developers}). The second is when one +merges explicitly with the @samp{update -j} command +(@pxref{Branching and merging}). + +In the case of text +files, @sc{cvs} can merge changes made independently, +and signal a conflict if the changes conflict. With +binary files, the best that @sc{cvs} can do is present +the two different copies of the file, and leave it to +the user to resolve the conflict. The user may choose +one copy or the other, or may run an external merge +tool which knows about that particular file format, if +one exists. +Note that having the user merge relies primarily on the +user to not accidentally omit some changes, and thus is +potentially error prone. + +If this process is thought to be undesirable, the best +choice may be to avoid merging. To avoid the merges +that result from separate working directories, see the +discussion of reserved checkouts (file locking) in +@ref{Multiple developers}. To avoid the merges +resulting from branches, restrict use of branches. + +@node Binary howto +@section How to store binary files + +There are two issues with using @sc{cvs} to store +binary files. The first is that @sc{cvs} by default +converts line endings between the canonical form in +which they are stored in the repository (linefeed +only), and the form appropriate to the operating system +in use on the client (for example, carriage return +followed by line feed for Windows NT). + +The second is that a binary file might happen to +contain data which looks like a keyword (@pxref{Keyword +substitution}), so keyword expansion must be turned +off. + +@c FIXME: the third is that one can't do merges with +@c binary files. xref to Multiple Developers and the +@c reserved checkout issues. + +The @samp{-kb} option available with some @sc{cvs} +commands insures that neither line ending conversion +nor keyword expansion will be done. + +Here is an example of how you can create a new file +using the @samp{-kb} flag: + +@example +$ echo '$@asis{}Id$' > kotest +$ cvs add -kb -m"A test file" kotest +$ cvs ci -m"First checkin; contains a keyword" kotest +@end example + +If a file accidentally gets added without @samp{-kb}, +one can use the @code{cvs admin} command to recover. +For example: + +@example +$ echo '$@asis{}Id$' > kotest +$ cvs add -m"A test file" kotest +$ cvs ci -m"First checkin; contains a keyword" kotest +$ cvs admin -kb kotest +$ cvs update -A kotest +# @r{For non-unix systems:} +# @r{Copy in a good copy of the file from outside CVS} +$ cvs commit -m "make it binary" kotest +@end example + +@c Trying to describe this for both unix and non-unix +@c in the same description is very confusing. Might +@c want to split the two, or just ditch the unix "shortcut" +@c (unixheads don't do much with binary files, anyway). +@c This used to say "(Try the above example, and do a +@c @code{cat kotest} after every command)". But that +@c only really makes sense for the unix case. +When you check in the file @file{kotest} the file is +not preserved as a binary file, because you did not +check it in as a binary file. The @code{cvs +admin -kb} command sets the default keyword +substitution method for this file, but it does not +alter the working copy of the file that you have. If you need to +cope with line endings (that is, you are using +@sc{cvs} on a non-unix system), then you need to +check in a new copy of the file, as shown by the +@code{cvs commit} command above. +On unix, the @code{cvs update -A} command suffices. +@c FIXME: should also describe what the *other users* +@c need to do, if they have checked out copies which +@c have been corrupted by lack of -kb. I think maybe +@c "cvs update -kb" or "cvs +@c update -A" would suffice, although the user who +@c reported this suggested removing the file, manually +@c removing it from CVS/Entries, and then "cvs update" + +However, in using @code{cvs admin -k} to change the +keyword expansion, be aware that the keyword expansion +mode is not version controlled. This means that, for +example, that if you have a text file in old releases, +and a binary file with the same name in new releases, +@sc{cvs} provides no way to check out the file in text +or binary mode depending on what version you are +checking out. There is no good workaround for this +problem. + +You can also set a default for whether @code{cvs add} +and @code{cvs import} treat a file as binary based on +its name; for example you could say that files who +names end in @samp{.exe} are binary. @xref{Wrappers}. +There is currently no way to have @sc{cvs} detect +whether a file is binary based on its contents. The +main difficulty with designing such a feature is that +it is not clear how to distinguish between binary and +non-binary files, and the rules to apply would vary +considerably with the operating system. +@c For example, it would be good on MS-DOS-family OSes +@c for anything containing ^Z to be binary. Having +@c characters with the 8th bit set imply binary is almost +@c surely a bad idea in the context of ISO-8859-* and +@c other such character sets. On VMS or the Mac, we +@c could use the OS's file typing. This is a +@c commonly-desired feature, and something of this sort +@c may make sense. But there are a lot of pitfalls here. +@c +@c Another, probably better, way to tell is to read the +@c file in text mode, write it to a temp file in text +@c mode, and then do a binary mode compare of the two +@c files. If they differ, it is a binary file. This +@c might have problems on VMS (or some other system +@c with several different text modes), but in general +@c should be relatively portable. The only other +@c downside I can think of is that it would be fairly +@c slow, but that is perhaps a small price to pay for +@c not having your files corrupted. Another issue is +@c what happens if you import a text file with bare +@c linefeeds on Windows. Such files will show up on +@c Windows sometimes (I think some native windows +@c programs even write them, on occasion). Perhaps it +@c is reasonable to treat such files as binary; after +@c all it is something of a presumption to assume that +@c the user would want the linefeeds converted to CRLF. + +@c --------------------------------------------------------------------- +@node Multiple developers +@chapter Multiple developers +@cindex Multiple developers +@cindex Team of developers +@cindex File locking +@cindex Locking files +@cindex Working copy +@cindex reserved checkouts +@cindex unreserved checkouts +@cindex RCS-style locking + +When more than one person works on a software project +things often get complicated. Often, two people try to +edit the same file simultaneously. One solution, known +as @dfn{file locking} or @dfn{reserved checkouts}, is +to allow only one person to edit each file at a time. +This is the only solution with some version control +systems, including @sc{rcs} and @sc{sccs}. Currently +the usual way to get reserved checkouts with @sc{cvs} +is the @code{cvs admin -l} command (@pxref{admin +options}). This is not as nicely integrated into +@sc{cvs} as the watch features, described below, but it +seems that most people with a need for reserved +checkouts find it adequate. +@c Or "find it better than worrying about implementing +@c nicely integrated reserved checkouts" or ...? +It also may be possible to use the watches +features described below, together with suitable +procedures (not enforced by software), to avoid having +two people edit at the same time. + +@c Our unreserved checkout model might not +@c be quite the same as others. For example, I +@c think that some systems will tend to create a branch +@c in the case where CVS prints "up-to-date check failed". +@c It isn't clear to me whether we should try to +@c explore these subtleties; it could easily just +@c confuse people. +The default model with @sc{cvs} is known as +@dfn{unreserved checkouts}. In this model, developers +can edit their own @dfn{working copy} of a file +simultaneously. The first person that commits his +changes has no automatic way of knowing that another +has started to edit it. Others will get an error +message when they try to commit the file. They must +then use @sc{cvs} commands to bring their working copy +up to date with the repository revision. This process +is almost automatic. + +@c FIXME? should probably use the word "watch" here, to +@c tie this into the text below and above. +@sc{Cvs} also supports mechanisms which facilitate +various kinds of communcation, without actually +enforcing rules like reserved checkouts do. + +The rest of this chapter describes how these various +models work, and some of the issues involved in +choosing between them. + +@ignore +Here is a draft reserved checkout design or discussion +of the issues. This seems like as good a place as any +for this. + +Might want a cvs lock/cvs unlock--in which the names +differ from edit/unedit because the network must be up +for these to work. unedit gives an error if there is a +reserved checkout in place (so that people don't +accidentally leave locks around); unlock gives an error +if one is not in place (this is more arguable; perhaps +it should act like unedit in that case). + +On the other hand, might want it so that emacs, +scripts, etc., can get ready to edit a file without +having to know which model is in use. In that case we +would have a "cvs watch lock" (or .cvsrc?) (that is, +three settings, "on", "off", and "lock"). Having cvs +watch lock set would cause a get to record in the CVS +directory which model is in use, and cause "cvs edit" +to change behaviors. We'd want a way to query which +setting is in effect (this would be handy even if it is +only "on" or "off" as presently). If lock is in +effect, then commit would require a lock before +allowing a checkin; chmod wouldn't suffice (might be +debatable--see chmod comment below, in watches--but it +is the way people expect RCS to work and I can't think +of any significant downside. On the other hand, maybe +it isn't worth bothering, because people who are used +to RCS wouldn't think to use chmod anyway). + +Implementation: use file attributes or use RCS +locking. The former avoids more dependence on RCS +behaviors we will need to reimplement as we librarify +RCS, and makes it easier to import/export RCS files (in +that context, want to ignore the locker field). But +note that RCS locks are per-branch, which is the +correct behavior (this is also an issue for the "watch +on" features; they should be per-branch too). + +Here are a few more random notes about implementation +details, assuming "cvs watch lock" and + +CVS/Watched file? Or try to fit this into CVS/Entries somehow? +Cases: (1) file is checked out (unreserved or with watch on) by old +version of CVS, now we do something with new one, (2) file is checked +out by new version, now we do something with old one. + +Remote protocol would have a "Watched" analogous to "Mode". Of course +it would apply to all Updated-like requests. How do we keep this +setting up to date? I guess that there wants to be a Watched request, +and the server would send a new one if it isn't up to date? (Ugh--hard +to implement and slows down "cvs -q update"--is there an easier way?) + +"cvs edit"--checks CVS/Watched, and if watch lock, then sends +"edit-lock" request. Which comes back with a Checked-in with +appropriate Watched (off, on, lock, locked, or some such?), or error +message if already locked. + +"cvs commit"--only will commit if off/on/locked. lock is not OK. + +Doc: +note that "cvs edit" must be connected to network if watch lock is in +effect. + +Talk about what to do if someone has locked a file and you want to +edit that file. (breaking locks, or lack thereof). + + +One other idea (which could work along with the +existing "cvs admin -l" reserved checkouts, as well as +the above): + +"cvs editors" could show who has the file locked, if +someone does. + +@end ignore + +@menu +* File status:: A file can be in several states +* Updating a file:: Bringing a file up-to-date +* Conflicts example:: An informative example +* Informing others:: To cooperate you must inform +* Concurrency:: Simultaneous repository access +* Watches:: Mechanisms to track who is editing files +* Choosing a model:: Reserved or unreserved checkouts? +@end menu + +@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +@node File status +@section File status +@cindex File status +@cindex Status of a file + +@c Shouldn't this start with an example or something, +@c introducing the unreserved checkout model? Before we +@c dive into listing states? +Based on what operations you have performed on a +checked out file, and what operations others have +performed to that file in the repository, one can +classify a file in a number of states. The states, as +reported by the @code{status} command, are: + +@c The order of items is chosen to group logically +@c similar outputs together. +@c People who want alphabetical can use the index... +@table @asis +@cindex Up-to-date +@item Up-to-date +The file is identical with the latest revision in the +repository for the branch in use. +@c FIXME: should we clarify "in use"? The answer is +@c sticky tags, and trying to distinguish branch sticky +@c tags from non-branch sticky tags seems rather awkward +@c here. +@c FIXME: What happens with non-branch sticky tags? Is +@c a stuck file "Up-to-date" or "Needs checkout" or what? + +@item Locally Modified +@cindex Locally Modified +You have edited the file, and not yet committed your changes. + +@item Locally Added +@cindex Locally Added +You have added the file with @code{add}, and not yet +committed your changes. +@c There are many cases involving the file being +@c added/removed/modified in the working directory, and +@c added/removed/modified in the repository, which we +@c don't try to describe here. I'm not sure that "cvs +@c status" produces a non-confusing output in most of +@c those cases. + +@item Locally Removed +@cindex Locally Removed +You have removed the file with @code{remove}, and not yet +committed your changes. + +@item Needs Checkout +@cindex Needs Checkout +Someone else has committed a newer revision to the +repository. The name is slightly misleading; you will +ordinarily use @code{update} rather than +@code{checkout} to get that newer revision. + +@item Needs Patch +@cindex Needs Patch +@c See also newb-123j0 in sanity.sh (although that case +@c should probably be changed rather than documented). +Like Needs Checkout, but the @sc{cvs} server will send +a patch rather than the entire file. Sending a patch or +sending an entire file accomplishes the same thing. + +@item Needs Merge +@cindex Needs Merge +Someone else has committed a newer revision to the repository, and you +have also made modifications to the file. + +@item File had conflicts on merge +@cindex File had conflicts on merge +@c is it worth saying that this message was "Unresolved +@c Conflict" in CVS 1.9 and earlier? I'm inclined to +@c think that is unnecessarily confusing to new users. +This is like Locally Modified, except that a previous +@code{update} command gave a conflict. If you have not +already done so, you need to +resolve the conflict as described in @ref{Conflicts example}. + +@item Unknown +@cindex Unknown +@sc{Cvs} doesn't know anything about this file. For +example, you have created a new file and have not run +@code{add}. +@c +@c "Entry Invalid" and "Classify Error" are also in the +@c status.c. The latter definitely indicates a CVS bug +@c (should it be worded more like "internal error" so +@c people submit bug reports if they see it?). The former +@c I'm not as sure; I haven't tracked down whether/when it +@c appears in "cvs status" output. + +@end table + +To help clarify the file status, @code{status} also +reports the @code{Working revision} which is the +revision that the file in the working directory derives +from, and the @code{Repository revision} which is the +latest revision in the repository for the branch in +use. +@c FIXME: should we clarify "in use"? The answer is +@c sticky tags, and trying to distinguish branch sticky +@c tags from non-branch sticky tags seems rather awkward +@c here. +@c FIXME: What happens with non-branch sticky tags? +@c What is the Repository Revision there? See the +@c comment at vn_rcs in cvs.h, which is kind of +@c confused--we really need to document better what this +@c field contains. +@c Q: Should we document "New file!" and other such +@c outputs or are they self-explanatory? +@c FIXME: what about the date to the right of "Working +@c revision"? It doesn't appear with client/server and +@c seems unnecessary (redundant with "ls -l") so +@c perhaps it should be removed for non-client/server too? +@c FIXME: Need some examples. +@c FIXME: Working revision can also be something like +@c "-1.3" for a locally removed file. Not at all +@c self-explanatory (and it is possible that CVS should +@c be changed rather than documenting this). + +@c Would be nice to have an @example showing output +@c from cvs status, with comments showing the xref +@c where each part of the output is described. This +@c might fit in nicely if it is desirable to split this +@c node in two; one to introduce "cvs status" and one +@c to list each of the states. +The options to @code{status} are listed in +@ref{Invoking CVS}. For information on its @code{Sticky tag} +and @code{Sticky date} output, see @ref{Sticky tags}. +For information on its @code{Sticky options} output, +see the @samp{-k} option in @ref{update options}. + +You can think of the @code{status} and @code{update} +commands as somewhat complementary. You use +@code{update} to bring your files up to date, and you +can use @code{status} to give you some idea of what an +@code{update} would do (of course, the state of the +repository might change before you actually run +@code{update}). In fact, if you want a command to +display file status in a more brief format than is +displayed by the @code{status} command, you can invoke + +@cindex update, to display file status +@example +$ cvs -n -q update +@end example + +The @samp{-n} option means to not actually do the +update, but merely to display statuses; the @samp{-q} +option avoids printing the name of each directory. For +more information on the @code{update} command, and +these options, see @ref{Invoking CVS}. + +@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +@node Updating a file +@section Bringing a file up to date +@cindex Bringing a file up to date +@cindex Updating a file +@cindex Merging a file +@cindex update, introduction + +When you want to update or merge a file, use the @code{update} +command. For files that are not up to date this is roughly equivalent +to a @code{checkout} command: the newest revision of the file is +extracted from the repository and put in your working copy of the +module. + +Your modifications to a file are never lost when you +use @code{update}. If no newer revision exists, +running @code{update} has no effect. If you have +edited the file, and a newer revision is available, +@sc{cvs} will merge all changes into your working copy. + +For instance, imagine that you checked out revision 1.4 and started +editing it. In the meantime someone else committed revision 1.5, and +shortly after that revision 1.6. If you run @code{update} on the file +now, @sc{cvs} will incorporate all changes between revision 1.4 and 1.6 into +your file. + +@cindex Overlap +If any of the changes between 1.4 and 1.6 were made too +close to any of the changes you have made, an +@dfn{overlap} occurs. In such cases a warning is +printed, and the resulting file includes both +versions of the lines that overlap, delimited by +special markers. +@xref{update}, for a complete description of the +@code{update} command. + +@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +@node Conflicts example +@section Conflicts example +@cindex Merge, an example +@cindex Example of merge +@cindex driver.c (merge example) + +Suppose revision 1.4 of @file{driver.c} contains this: + +@example +#include <stdio.h> + +void main() +@{ + parse(); + if (nerr == 0) + gencode(); + else + fprintf(stderr, "No code generated.\n"); + exit(nerr == 0 ? 0 : 1); +@} +@end example + +@noindent +Revision 1.6 of @file{driver.c} contains this: + +@example +#include <stdio.h> + +int main(int argc, + char **argv) +@{ + parse(); + if (argc != 1) + @{ + fprintf(stderr, "tc: No args expected.\n"); + exit(1); + @} + if (nerr == 0) + gencode(); + else + fprintf(stderr, "No code generated.\n"); + exit(!!nerr); +@} +@end example + +@noindent +Your working copy of @file{driver.c}, based on revision +1.4, contains this before you run @samp{cvs update}: +@c -- Really include "cvs"? + +@example +#include <stdlib.h> +#include <stdio.h> + +void main() +@{ + init_scanner(); + parse(); + if (nerr == 0) + gencode(); + else + fprintf(stderr, "No code generated.\n"); + exit(nerr == 0 ? EXIT_SUCCESS : EXIT_FAILURE); +@} +@end example + +@noindent +You run @samp{cvs update}: +@c -- Really include "cvs"? + +@example +$ cvs update driver.c +RCS file: /usr/local/cvsroot/yoyodyne/tc/driver.c,v +retrieving revision 1.4 +retrieving revision 1.6 +Merging differences between 1.4 and 1.6 into driver.c +rcsmerge warning: overlaps during merge +cvs update: conflicts found in driver.c +C driver.c +@end example + +@noindent +@cindex Conflicts (merge example) +@sc{cvs} tells you that there were some conflicts. +Your original working file is saved unmodified in +@file{.#driver.c.1.4}. The new version of +@file{driver.c} contains this: + +@example +#include <stdlib.h> +#include <stdio.h> + +int main(int argc, + char **argv) +@{ + init_scanner(); + parse(); + if (argc != 1) + @{ + fprintf(stderr, "tc: No args expected.\n"); + exit(1); + @} + if (nerr == 0) + gencode(); + else + fprintf(stderr, "No code generated.\n"); +@asis{}<<<<<<< driver.c + exit(nerr == 0 ? EXIT_SUCCESS : EXIT_FAILURE); +@asis{}======= + exit(!!nerr); +@asis{}>>>>>>> 1.6 +@} +@end example + +@noindent +@cindex Markers, conflict +@cindex Conflict markers +@cindex <<<<<<< +@cindex >>>>>>> +@cindex ======= + +Note how all non-overlapping modifications are incorporated in your working +copy, and that the overlapping section is clearly marked with +@samp{<<<<<<<}, @samp{=======} and @samp{>>>>>>>}. + +@cindex Resolving a conflict +@cindex Conflict resolution +You resolve the conflict by editing the file, removing the markers and +the erroneous line. Suppose you end up with this file: +@c -- Add xref to the pcl-cvs manual when it talks +@c -- about this. +@example +#include <stdlib.h> +#include <stdio.h> + +int main(int argc, + char **argv) +@{ + init_scanner(); + parse(); + if (argc != 1) + @{ + fprintf(stderr, "tc: No args expected.\n"); + exit(1); + @} + if (nerr == 0) + gencode(); + else + fprintf(stderr, "No code generated.\n"); + exit(nerr == 0 ? EXIT_SUCCESS : EXIT_FAILURE); +@} +@end example + +@noindent +You can now go ahead and commit this as revision 1.7. + +@example +$ cvs commit -m "Initialize scanner. Use symbolic exit values." driver.c +Checking in driver.c; +/usr/local/cvsroot/yoyodyne/tc/driver.c,v <-- driver.c +new revision: 1.7; previous revision: 1.6 +done +@end example + +For your protection, @sc{cvs} will refuse to check in a +file if a conflict occurred and you have not resolved +the conflict. Currently to resolve a conflict, you +must change the timestamp on the file. In previous +versions of @sc{cvs}, you also needed to +insure that the file contains no conflict markers. +Because +your file may legitimately contain conflict markers (that +is, occurrences of @samp{>>>>>>> } at the start of a +line that don't mark a conflict), the current +version of @sc{cvs} will print a warning and proceed to +check in the file. +@c The old behavior was really icky; the only way out +@c was to start hacking on +@c the @code{CVS/Entries} file or other such workarounds. +@c +@c If the timestamp thing isn't considered nice enough, +@c maybe there should be a "cvs resolved" command +@c which clears the conflict indication. For a nice user +@c interface, this should be invoked by an interactive +@c merge tool like emerge rather than by the user +@c directly--such a tool can verify that the user has +@c really dealt with each conflict. + +@cindex emerge +If you use release 1.04 or later of pcl-cvs (a @sc{gnu} +Emacs front-end for @sc{cvs}) you can use an Emacs +package called emerge to help you resolve conflicts. +See the documentation for pcl-cvs. + +@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +@node Informing others +@section Informing others about commits +@cindex Informing others +@cindex Spreading information +@cindex Mail, automatic mail on commit + +It is often useful to inform others when you commit a +new revision of a file. The @samp{-i} option of the +@file{modules} file, or the @file{loginfo} file, can be +used to automate this process. @xref{modules}. +@xref{loginfo}. You can use these features of @sc{cvs} +to, for instance, instruct @sc{cvs} to mail a +message to all developers, or post a message to a local +newsgroup. +@c -- More text would be nice here. + +@node Concurrency +@section Several developers simultaneously attempting to run CVS + +@cindex locks, cvs +@c For a discussion of *why* CVS creates locks, see +@c the comment at the start of src/lock.c +If several developers try to run @sc{cvs} at the same +time, one may get the following message: + +@example +[11:43:23] waiting for bach's lock in /usr/local/cvsroot/foo +@end example + +@sc{cvs} will try again every 30 seconds, and either +continue with the operation or print the message again, +if it still needs to wait. If a lock seems to stick +around for an undue amount of time, find the person +holding the lock and ask them about the cvs command +they are running. If they aren't running a cvs +command, look in the repository directory mentioned in +the message and remove files which they own whose names +start with @file{#cvs.tfl}, @file{#cvs.rfl}, or +@file{#cvs.wfl}. + +Note that these locks are to protect @sc{cvs}'s +internal data structures and have no relationship to +the word @dfn{lock} in the sense used by +@sc{rcs}---which refers to reserved checkouts +(@pxref{Multiple developers}). + +Any number of people can be reading from a given +repository at a time; only when someone is writing do +the locks prevent other people from reading or writing. + +@cindex Atomic transactions, lack of +@cindex Transactions, atomic, lack of +@c the following talks about what one might call commit/update +@c atomicity. +@c Probably also should say something about +@c commit/commit atomicity, that is, "An update will +@c not get partial versions of more than one commit". +@c CVS currently has this property and I guess we can +@c make it a documented feature. +@c For example one person commits +@c a/one.c and b/four.c and another commits a/two.c and +@c b/three.c. Then an update cannot get the new a/one.c +@c and a/two.c and the old b/four.c and b/three.c. +One might hope for the following property + +@example +If someone commits some changes in one cvs command, +then an update by someone else will either get all the +changes, or none of them. +@end example + +but @sc{cvs} does @emph{not} have this property. For +example, given the files + +@example +a/one.c +a/two.c +b/three.c +b/four.c +@end example + +if someone runs + +@example +cvs ci a/two.c b/three.c +@end example + +and someone else runs @code{cvs update} at the same +time, the person running @code{update} might get only +the change to @file{b/three.c} and not the change to +@file{a/two.c}. + +@node Watches +@section Mechanisms to track who is editing files +@cindex Watches + +For many groups, use of @sc{cvs} in its default mode is +perfectly satisfactory. Users may sometimes go to +check in a modification only to find that another +modification has intervened, but they deal with it and +proceed with their check in. Other groups prefer to be +able to know who is editing what files, so that if two +people try to edit the same file they can choose to +talk about who is doing what when rather than be +surprised at check in time. The features in this +section allow such coordination, while retaining the +ability of two developers to edit the same file at the +same time. + +@c Some people might ask why CVS does not enforce the +@c rule on chmod, by requiring a cvs edit before a cvs +@c commit. The main reason is that it could always be +@c circumvented--one could edit the file, and +@c then when ready to check it in, do the cvs edit and put +@c in the new contents and do the cvs commit. One +@c implementation note: if we _do_ want to have cvs commit +@c require a cvs edit, we should store the state on +@c whether the cvs edit has occurred in the working +@c directory, rather than having the server try to keep +@c track of what working directories exist. +@c FIXME: should the above discussion be part of the +@c manual proper, somewhere, not just in a comment? +For maximum benefit developers should use @code{cvs +edit} (not @code{chmod}) to make files read-write to +edit them, and @code{cvs release} (not @code{rm}) to +discard a working directory which is no longer in use, +but @sc{cvs} is not able to enforce this behavior. + +@c I'm a little dissatisfied with this presentation, +@c because "watch on"/"edit"/"editors" are one set of +@c functionality, and "watch add"/"watchers" is another +@c which is somewhat orthogonal even though they interact in +@c various ways. But I think it might be +@c confusing to describe them separately (e.g. "watch +@c add" with loginfo). I don't know. + +@menu +* Setting a watch:: Telling CVS to watch certain files +* Getting Notified:: Telling CVS to notify you +* Editing files:: How to edit a file which is being watched +* Watch information:: Information about who is watching and editing +* Watches Compatibility:: Watches interact poorly with CVS 1.6 or earlier +@end menu + +@node Setting a watch +@subsection Telling CVS to watch certain files + +To enable the watch features, you first specify that +certain files are to be watched. + +@cindex watch on (subcommand) +@deffn Command {cvs watch on} [@code{-lR}] files @dots{} + +@cindex read-only files, and watches +Specify that developers should run @code{cvs edit} +before editing @var{files}. CVS will create working +copies of @var{files} read-only, to remind developers +to run the @code{cvs edit} command before working on +them. + +If @var{files} includes the name of a directory, CVS +arranges to watch all files added to the corresponding +repository directory, and sets a default for files +added in the future; this allows the user to set +notification policies on a per-directory basis. The +contents of the directory are processed recursively, +unless the @code{-l} option is given. +The @code{-R} option can be used to force recursion if the @code{-l} +option is set in @file{~/.cvsrc} (@pxref{~/.cvsrc}). + +If @var{files} is omitted, it defaults to the current directory. + +@cindex watch off (subcommand) +@end deffn + +@deffn Command {cvs watch off} [@code{-lR}] files @dots{} + +Do not provide notification about work on @var{files}. CVS will create +working copies of @var{files} read-write. + +The @var{files} and options are processed as for @code{cvs +watch on}. + +@end deffn + +@node Getting Notified +@subsection Telling CVS to notify you + +You can tell @sc{cvs} that you want to receive +notifications about various actions taken on a file. +You can do this without using @code{cvs watch on} for +the file, but generally you will want to use @code{cvs +watch on}, so that developers use the @code{cvs edit} +command. + +@cindex watch add (subcommand) +@deffn Command {cvs watch add} [@code{-a} action] [@code{-lR}] files @dots{} + +Add the current user to the list of people to receive notification of +work done on @var{files}. + +The @code{-a} option specifies what kinds of events CVS should notify +the user about. @var{action} is one of the following: + +@table @code + +@item edit +Another user has applied the @code{cvs edit} command (described +below) to a file. + +@item unedit +Another user has applied the @code{cvs unedit} command (described +below) or the @code{cvs release} command to a file, or has deleted +the file and allowed @code{cvs update} to recreate it. + +@item commit +Another user has committed changes to a file. + +@item all +All of the above. + +@item none +None of the above. (This is useful with @code{cvs edit}, +described below.) + +@end table + +The @code{-a} option may appear more than once, or not at all. If +omitted, the action defaults to @code{all}. + +The @var{files} and options are processed as for the +@code{cvs watch} commands. + +@end deffn + + +@cindex watch remove (subcommand) +@deffn Command {cvs watch remove} [@code{-a} action] [@code{-lR}] files @dots{} + +Remove a notification request established using @code{cvs watch add}; +the arguments are the same. If the @code{-a} option is present, only +watches for the specified actions are removed. + +@end deffn + +@cindex notify (admin file) +When the conditions exist for notification, @sc{cvs} +calls the @file{notify} administrative file. Edit +@file{notify} as one edits the other administrative +files (@pxref{Intro administrative files}). This +file follows the usual conventions for administrative +files (@pxref{syntax}), where each line is a regular +expression followed by a command to execute. The +command should contain a single ocurrence of @samp{%s} +which will be replaced by the user to notify; the rest +of the information regarding the notification will be +supplied to the command on standard input. The +standard thing to put in the @code{notify} file is the +single line: + +@example +ALL mail %s -s \"CVS notification\" +@end example + +This causes users to be notified by electronic mail. +@c FIXME: should it be this hard to set up this +@c behavior (and the result when one fails to do so, +@c silent failure to notify, so non-obvious)? Should +@c CVS give a warning if no line in notify matches (and +@c document the use of "DEFAULT :" for the case where +@c skipping the notification is indeed desired)? + +@cindex users (admin file) +Note that if you set this up in the straightforward +way, users receive notifications on the server machine. +One could of course write a @file{notify} script which +directed notifications elsewhere, but to make this +easy, @sc{cvs} allows you to associate a notification +address for each user. To do so create a file +@file{users} in @file{CVSROOT} with a line for each +user in the format @var{user}:@var{value}. Then +instead of passing the name of the user to be notified +to @file{notify}, @sc{cvs} will pass the @var{value} +(normally an email address on some other machine). + +@sc{Cvs} does not notify you for your own changes. +Currently this check is done based on whether the user +name of the person taking the action which triggers +notification matches the user name of the person +getting notification. In fact, in general, the watches +features only track one edit by each user. It probably +would be more useful if watches tracked each working +directory separately, so this behavior might be worth +changing. +@c "behavior might be worth changing" is an effort to +@c point to future directions while also not promising +@c that "they" (as in "why don't they fix CVS to....") +@c will do this. +@c one implementation issue is identifying whether a +@c working directory is same or different. Comparing +@c pathnames/hostnames is hopeless, but having the server +@c supply a serial number which the client stores in the +@c CVS directory as a magic cookie should work. + +@node Editing files +@subsection How to edit a file which is being watched + +@cindex checkout, as term for getting ready to edit +Since a file which is being watched is checked out +read-only, you cannot simply edit it. To make it +read-write, and inform others that you are planning to +edit it, use the @code{cvs edit} command. Some systems +call this a @dfn{checkout}, but @sc{cvs} uses that term +for obtaining a copy of the sources (@pxref{Getting the +source}), an operation which those systems call a +@dfn{get} or a @dfn{fetch}. +@c Issue to think about: should we transition CVS +@c towards the "get" terminology? "cvs get" is already a +@c synonym for "cvs checkout" and that section of the +@c manual refers to "Getting the source". If this is +@c done, needs to be done gingerly (for example, we should +@c still accept "checkout" in .cvsrc files indefinitely +@c even if the CVS's messages are changed from "cvs checkout: " +@c to "cvs get: "). +@c There is a concern about whether "get" is not as +@c good for novices because it is a more general term +@c than "checkout" (and thus arguably harder to assign +@c a technical meaning for). + +@cindex edit (subcommand) +@deffn Command {cvs edit} [options] files @dots{} + +Prepare to edit the working files @var{files}. CVS makes the +@var{files} read-write, and notifies users who have requested +@code{edit} notification for any of @var{files}. + +The @code{cvs edit} command accepts the same @var{options} as the +@code{cvs watch add} command, and establishes a temporary watch for the +user on @var{files}; CVS will remove the watch when @var{files} are +@code{unedit}ed or @code{commit}ted. If the user does not wish to +receive notifications, she should specify @code{-a none}. + +The @var{files} and options are processed as for the @code{cvs +watch} commands. + +@end deffn + +Normally when you are done with a set of changes, you +use the @code{cvs commit} command, which checks in your +changes and returns the watched files to their usual +read-only state. But if you instead decide to abandon +your changes, or not to make any changes, you can use +the @code{cvs unedit} command. + +@cindex unedit (subcommand) +@cindex abandoning work +@cindex reverting to repository version +@deffn Command {cvs unedit} [@code{-lR}] files @dots{} + +Abandon work on the working files @var{files}, and revert them to the +repository versions on which they are based. CVS makes those +@var{files} read-only for which users have requested notification using +@code{cvs watch on}. CVS notifies users who have requested @code{unedit} +notification for any of @var{files}. + +The @var{files} and options are processed as for the +@code{cvs watch} commands. + +If watches are not in use, the @code{unedit} command +probably does not work, and the way to revert to the +repository version is to remove the file and then use +@code{cvs update} to get a new copy. The meaning is +not precisely the same; removing and updating may also +bring in some changes which have been made in the +repository since the last time you updated. +@c It would be a useful enhancement to CVS to make +@c unedit work in the non-watch case as well. +@end deffn + +When using client/server @sc{cvs}, you can use the +@code{cvs edit} and @code{cvs unedit} commands even if +@sc{cvs} is unable to succesfully communicate with the +server; the notifications will be sent upon the next +successful @sc{cvs} command. + +@node Watch information +@subsection Information about who is watching and editing + +@cindex watchers (subcommand) +@deffn Command {cvs watchers} [@code{-lR}] files @dots{} + +List the users currently watching changes to @var{files}. The report +includes the files being watched, and the mail address of each watcher. + +The @var{files} and options are processed as for the +@code{cvs watch} commands. + +@end deffn + + +@cindex editors (subcommand) +@deffn Command {cvs editors} [@code{-lR}] files @dots{} + +List the users currently working on @var{files}. The report +includes the mail address of each user, the time when the user began +working with the file, and the host and path of the working directory +containing the file. + +The @var{files} and options are processed as for the +@code{cvs watch} commands. + +@end deffn + +@node Watches Compatibility +@subsection Using watches with old versions of CVS + +@cindex CVS 1.6, and watches +If you use the watch features on a repository, it +creates @file{CVS} directories in the repository and +stores the information about watches in that directory. +If you attempt to use @sc{cvs} 1.6 or earlier with the +repository, you get an error message such as the +following (all on one line): + +@example +cvs update: cannot open CVS/Entries for reading: +No such file or directory +@end example + +and your operation will likely be aborted. To use the +watch features, you must upgrade all copies of @sc{cvs} +which use that repository in local or server mode. If +you cannot upgrade, use the @code{watch off} and +@code{watch remove} commands to remove all watches, and +that will restore the repository to a state which +@sc{cvs} 1.6 can cope with. + +@node Choosing a model +@section Choosing between reserved or unreserved checkouts +@cindex choosing, reserved or unreserved checkouts + +Reserved and unreserved checkouts each have pros and +cons. Let it be said that a lot of this is a matter of +opinion or what works given different groups' working +styles, but here is a brief description of some of the +issues. There are many ways to organize a team of +developers. @sc{cvs} does not try to enforce a certain +organization. It is a tool that can be used in several +ways. + +Reserved checkouts can be very counter-productive. If +two persons want to edit different parts of a file, +there may be no reason to prevent either of them from +doing so. Also, it is common for someone to take out a +lock on a file, because they are planning to edit it, +but then forget to release the lock. + +@c "many groups"? specifics? cites to papers on this? +@c some way to weasel-word it a bit more so we don't +@c need facts :-)? +People, especially people who are familiar with +reserved checkouts, often wonder how often conflicts +occur if unreserved checkouts are used, and how +difficult they are to resolve. The experience with +many groups is that they occur rarely and usually are +relatively straightforward to resolve. + +The rarity of serious conflicts may be surprising, until one realizes +that they occur only when two developers disagree on the proper design +for a given section of code; such a disagreement suggests that the +team has not been communicating properly in the first place. In order +to collaborate under @emph{any} source management regimen, developers +must agree on the general design of the system; given this agreement, +overlapping changes are usually straightforward to merge. + +In some cases unreserved checkouts are clearly +inappropriate. If no merge tool exists for the kind of +file you are managing (for example word processor files +or files edited by Computer Aided Design programs), and +it is not desirable to change to a program which uses a +mergeable data format, then resolving conflicts is +going to be unpleasant enough that you generally will +be better off to simply avoid the conflicts instead, by +using reserved checkouts. + +The watches features described above in @ref{Watches} +can be considered to be an intermediate model between +reserved checkouts and unreserved checkouts. When you +go to edit a file, it is possible to find out who else +is editing it. And rather than having the system +simply forbid both people editing the file, it can tell +you what the situation is and let you figure out +whether it is a problem in that particular case or not. +Therefore, for some groups it can be considered the +best of both the reserved checkout and unreserved +checkout worlds. + +@c --------------------------------------------------------------------- +@node Revision management +@chapter Revision management +@cindex Revision management + +@c -- This chapter could be expanded a lot. +@c -- Experiences are very welcome! + +If you have read this far, you probably have a pretty +good grasp on what @sc{cvs} can do for you. This +chapter talks a little about things that you still have +to decide. + +If you are doing development on your own using @sc{cvs} +you could probably skip this chapter. The questions +this chapter takes up become more important when more +than one person is working in a repository. + +@menu +* When to commit:: Some discussion on the subject +@end menu + +@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +@node When to commit +@section When to commit? +@cindex When to commit +@cindex Commit, when to +@cindex Policy + +Your group should decide which policy to use regarding +commits. Several policies are possible, and as your +experience with @sc{cvs} grows you will probably find +out what works for you. + +If you commit files too quickly you might commit files +that do not even compile. If your partner updates his +working sources to include your buggy file, he will be +unable to compile the code. On the other hand, other +persons will not be able to benefit from the +improvements you make to the code if you commit very +seldom, and conflicts will probably be more common. + +It is common to only commit files after making sure +that they can be compiled. Some sites require that the +files pass a test suite. Policies like this can be +enforced using the commitinfo file +(@pxref{commitinfo}), but you should think twice before +you enforce such a convention. By making the +development environment too controlled it might become +too regimented and thus counter-productive to the real +goal, which is to get software written. + +@c --------------------------------------------------------------------- @node Keyword substitution @chapter Keyword substitution @cindex Keyword substitution @@ -5713,8 +6083,8 @@ a new revision of the file. @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - @node Keyword list -@section RCS Keywords -@cindex RCS keywords +@section Keyword List +@cindex Keyword List @c FIXME: need some kind of example here I think, @c perhaps in a @@ -5766,10 +6136,26 @@ header containing the @sc{rcs} filename, the revision number, the author, and the date (UTC). Existing log messages are @emph{not} replaced. Instead, the new log message is inserted after @code{$@asis{Log:@dots{}}$}. -Each new line is prefixed with a @dfn{comment leader} -which @sc{rcs} guesses from the file name extension. -It can be changed with @code{cvs admin -c}. -@xref{admin options}. This keyword is useful for +Each new line is prefixed with the same string which +precedes the @code{$Log} keyword. For example, if the +file contains + +@example + /* Here is what people have been up to: + * + * $@asis{}Log: frob.c,v $ + * Revision 1.1 1997/01/03 14:23:51 joe + * Add the superfrobnicate option + * + */ +@end example + +@noindent +then additional lines which are added when expanding +the @code{$Log} keyword will be preceded by @samp{ * }. +Unlike previous versions of @sc{cvs} and @sc{rcs}, the +@dfn{comment leader} from the @sc{rcs} file is not used. +The @code{$Log} keyword is useful for accumulating a complete change log in a source file, but for several reasons it can be problematic. @xref{Log keyword}. @@ -5789,7 +6175,7 @@ The full pathname of the RCS file. @cindex State keyword @item $@asis{State}$ The state assigned to the revision. States can be -assigned with @code{cvs admin -s}---@xref{admin options}. +assigned with @code{cvs admin -s}---see @ref{admin options}. @end table @@ -5808,6 +6194,15 @@ C source code. This example shows the first few lines of a typical file, after keyword substitution has been performed: +@c Hmm. Someone says that +@c "static const char rcsid[] = "foo" +@c is a simpler way to shut up GCC. But I really +@c suspect that we should be avoiding specifics in general +@c (what about Java, Ada, and who knows how many other +@c languages? What about #pragma ident and #ident and +@c other non-GCC C compilers? What about the VMS help +@c system and other systems which take text and convert +@c them to a generated file? @example static char *rcsid="$@asis{}Id: samp.c,v 1.5 1993/10/19 14:57:32 ceder Exp $"; /* @r{The following lines will prevent @code{gcc} version 2.@var{x}} @@ -5862,7 +6257,7 @@ static char *id="@@(#) $@asis{}Id: ab.c,v 1.5 1993/10/19 14:57:32 ceder Exp $"; Keyword substitution has its disadvantages. Sometimes you might want the literal text string @samp{$@asis{}Author$} to appear inside a file without -@sc{rcs} interpreting it as a keyword and expanding it +@sc{cvs} interpreting it as a keyword and expanding it into something like @samp{$@asis{}Author: ceder $}. There is unfortunately no way to selectively turn off @@ -5890,10 +6285,23 @@ Each file has a stored default substitution mode, and each working directory copy of a file also has a substitution mode. The former is set by the @samp{-k} option to @code{cvs add} and @code{cvs admin}; the -latter is set by the -k or -A options to @code{cvs +latter is set by the @samp{-k} or @samp{-A} options to @code{cvs checkout} or @code{cvs update}. @code{cvs diff} also has a @samp{-k} option. For some examples, -@xref{Binary files}. +see @ref{Binary files}. +@c The fact that -A is overloaded to mean both reset +@c sticky options and reset sticky tags/dates is +@c somewhat questionable. Perhaps there should be +@c separate options to reset sticky options (e.g. -k +@c A") and tags/dates (someone suggested -r HEAD could +@c do this instead of setting a sticky tag of "HEAD" +@c as in the status quo but I haven't thought much +@c about that idea. Of course -r .reset or something +@c could be coined if this needs to be a new option). +@c On the other hand, having -A mean "get things back +@c into the state after a fresh checkout" has a certain +@c appeal, and maybe there is no sufficient reason for +@c creeping featurism in this area. The modes available are: @@ -5968,10 +6376,9 @@ A more serious concern is that @sc{cvs} is not good at handling @code{$@asis{}Log$} entries when a branch is merged onto the main trunk. Conflicts often result from the merging operation. -@c We say "cvs" even though it is done via rcsmerge; -@c this is an implementation detail. If the merging is -@c done in CVS instead, should check if this problem -@c still persists. +@c Might want to check whether the CVS implementation +@c of RCS_merge has this problem the same way rcsmerge +@c does. I would assume so.... People also tend to "fix" the log entries in the file (correcting spelling mistakes and maybe even factual @@ -5987,107 +6394,253 @@ That way the long list of change messages will not interfere with everyday source file browsing. @c --------------------------------------------------------------------- -@node Binary files -@chapter Handling binary files -@cindex Binary files +@node Tracking sources +@chapter Tracking third-party sources +@cindex Third-party sources +@cindex Tracking sources -There are two issues with using @sc{cvs} to store -binary files. The first is that @sc{cvs} by default -convert line endings between the canonical form in -which they are stored in the repository (linefeed -only), and the form appropriate to the operating system -in use on the client (for example, carriage return -followed by line feed for Windows NT). +@c FIXME: Need discussion of added and removed files. +@c FIXME: This doesn't really adequately introduce the +@c concepts of "vendor" and "you". They don't *have* +@c to be separate organizations or separate people. +@c We want a description which is somewhat more based on +@c the technical issues of which sources go where, but +@c also with enough examples of how this relates to +@c relationships like customer-supplier, developer-QA, +@c maintainer-contributor, or whatever, to make it +@c seem concrete. +If you modify a program to better fit your site, you +probably want to include your modifications when the next +release of the program arrives. @sc{cvs} can help you with +this task. -The second is that a binary file might happen to -contain data which looks like a keyword (@pxref{Keyword -substitution}), so keyword expansion must be turned -off. +@cindex Vendor +@cindex Vendor branch +@cindex Branch, vendor- +In the terminology used in @sc{cvs}, the supplier of the +program is called a @dfn{vendor}. The unmodified +distribution from the vendor is checked in on its own +branch, the @dfn{vendor branch}. @sc{cvs} reserves branch +1.1.1 for this use. -@c FIXME: the third is that one can't do merges with -@c binary files. xref to Multiple Developers and the -@c reserved checkout issues. +When you modify the source and commit it, your revision +will end up on the main trunk. When a new release is +made by the vendor, you commit it on the vendor branch +and copy the modifications onto the main trunk. -The @samp{-kb} option available with some @sc{cvs} -commands insures that neither line ending conversion -nor keyword expansion will be done. If you are using -an old version of @sc{rcs} without this option, and you -are using an operating system, such as unix, which -terminates lines with linefeeds only, you can use -@samp{-ko} instead; if you are on another operating -system, upgrade to a version of @sc{rcs}, such as 5.7 -or later, which supports @samp{-kb}. +Use the @code{import} command to create and update +the vendor branch. After a successful @code{import} +the vendor branch is made the `head' revision, so +anyone that checks out a copy of the file gets that +revision. When a local modification is committed it is +placed on the main trunk, and made the `head' +revision. -Here is an example of how you can create a new file -using the @samp{-kb} flag: +@menu +* First import:: Importing a module for the first time +* Update imports:: Updating a module with the import command +* Reverting local changes:: Reverting a module to the latest vendor release +* Binary files in imports:: Binary files require special handling +* Keywords in imports:: Keyword substitution might be undesirable +* Multiple vendor branches:: What if you get sources from several places? +@end menu + +@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +@node First import +@section Importing a module for the first time +@cindex Importing modules + +@c Should mention naming conventions for vendor tags, +@c release tags, and perhaps directory names. +Use the @code{import} command to check in the sources +for the first time. When you use the @code{import} +command to track third-party sources, the @dfn{vendor +tag} and @dfn{release tags} are useful. The +@dfn{vendor tag} is a symbolic name for the branch +(which is always 1.1.1, unless you use the @samp{-b +@var{branch}} flag---@xref{Multiple vendor branches}.). The +@dfn{release tags} are symbolic names for a particular +release, such as @samp{FSF_0_04}. + +@c I'm not completely sure this belongs here. But +@c we need to say it _somewhere_ reasonably obvious; it +@c is a common misconception among people first learning CVS +Note that @code{import} does @emph{not} change the +directory in which you invoke it. In particular, it +does not set up that directory as a @sc{cvs} working +directory; if you want to work with the sources import +them first and then check them out into a different +directory (@pxref{Getting the source}). + +@cindex Wdiff (import example) +Suppose you have the sources to a program called +@code{wdiff} in a directory @file{wdiff-0.04}, +and are going to make private modifications that you +want to be able to use even when new releases are made +in the future. You start by importing the source to +your repository: @example -$ echo '$@asis{}Id$' > kotest -$ cvs add -kb -m"A test file" kotest -$ cvs ci -m"First checkin; contains a keyword" kotest +$ cd wdiff-0.04 +$ cvs import -m "Import of FSF v. 0.04" fsf/wdiff FSF_DIST WDIFF_0_04 @end example -If a file accidentally gets added without @samp{-kb}, -one can use the @code{cvs admin} command to recover. -For example: +The vendor tag is named @samp{FSF_DIST} in the above +example, and the only release tag assigned is +@samp{WDIFF_0_04}. +@c FIXME: Need to say where fsf/wdiff comes from. + +@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +@node Update imports +@section Updating a module with the import command + +When a new release of the source arrives, you import it into the +repository with the same @code{import} command that you used to set up +the repository in the first place. The only difference is that you +specify a different release tag this time. @example -$ echo '$@asis{}Id$' > kotest -$ cvs add -m"A test file" kotest -$ cvs ci -m"First checkin; contains a keyword" kotest -$ cvs admin -kb kotest -$ cvs update -A kotest -$ cvs commit -m "make it binary" kotest # @r{For non-unix systems} +$ tar xfz wdiff-0.05.tar.gz +$ cd wdiff-0.05 +$ cvs import -m "Import of FSF v. 0.05" fsf/wdiff FSF_DIST WDIFF_0_05 @end example -When you check in the file @file{kotest} the keywords -are expanded. (Try the above example, and do a -@code{cat kotest} after every command). The @code{cvs -admin -kb} command sets the default keyword -substitution method for this file, but it does not -alter the working copy of the file that you have. The -easiest way to get the unexpanded version of -@file{kotest} is @code{cvs update -A}. If you need to -cope with line endings (that is, you are using a -@sc{cvs} client on a non-unix system), then you need to -check in a new copy of the file, as shown by the -@code{cvs commit} command above. -@c FIXME: should also describe what the *other users* -@c need to do, if they have checked out copies which -@c have been corrupted by lack of -kb. I think maybe -@c "cvs update -kb" or "cvs -@c update -A" would suffice, although the user who -@c reported this suggested removing the file, manually -@c removing it from CVS/Entries, and then "cvs update" +For files that have not been modified locally, the newly created +revision becomes the head revision. If you have made local +changes, @code{import} will warn you that you must merge the changes +into the main trunk, and tell you to use @samp{checkout -j} to do so. -However, in using @code{cvs admin -k} to change the -keyword expansion, be aware that the keyword expansion -mode is not version controlled. This means that, for -example, that if you have a text file in old releases, -and a binary file with the same name in new releases, -@sc{cvs} provides no way to check out the file in text -or binary mode depending on what version you are -checking out. There is no good workaround for this -problem. +@c FIXME: why "wdiff" here and "fsf/wdiff" in the +@c "import"? I think the assumption is that one has +@c "wdiff fsf/wdiff" or some such in modules, but it +@c would be better to not use modules in this example. +@example +$ cvs checkout -jFSF_DIST:yesterday -jFSF_DIST wdiff +@end example -You can also set a default for whether @code{cvs add} -and @code{cvs import} treat a file as binary based on -its name; for example you could say that files who -names end in @samp{.exe} are binary. @xref{Wrappers}. -There is currently no way to have @sc{cvs} detect -whether a file is binary based on its contents. The -main difficulty with designing such a feature is that -it is not clear how to distinguish between binary and -non-binary files, and the rules to apply would vary -considerably with the operating system. -@c For example, it would be good on MS-DOS-family OSes -@c for anything containing ^Z to be binary. Having -@c characters with the 8th bit set imply binary is almost -@c surely a bad idea in the context of ISO-8859-* and -@c other such character sets. On VMS or the Mac, we -@c could use the OS's file typing. This is a -@c commonly-desired feature, and something of this sort -@c may make sense. But there are a lot of pitfalls here. +@noindent +The above command will check out the latest revision of +@samp{wdiff}, merging the changes made on the vendor branch @samp{FSF_DIST} +since yesterday into the working copy. If any conflicts arise during +the merge they should be resolved in the normal way (@pxref{Conflicts +example}). Then, the modified files may be committed. + +Using a date, as suggested above, assumes that you do +not import more than one release of a product per +day. If you do, you can always use something like this +instead: + +@example +$ cvs checkout -jWDIFF_0_04 -jWDIFF_0_05 wdiff +@end example + +@noindent +In this case, the two above commands are equivalent. + +@node Reverting local changes +@section Reverting to the latest vendor release + +You can also revert local changes completely and return +to the latest vendor release by changing the `head' +revision back to the vendor branch on all files. For +example, if you have a checked-out copy of the sources +in @file{~/work.d/wdiff}, and you want to revert to the +vendor's version for all the files in that directory, +you would type: + +@example +$ cd ~/work.d/wdiff +$ cvs admin -bWDIFF . +@end example + +@noindent +You must specify the @samp{-bWDIFF} without any space +after the @samp{-b}. @xref{admin options}. + +@node Binary files in imports +@section How to handle binary files with cvs import + +Use the @samp{-k} wrapper option to tell import which +files are binary. @xref{Wrappers}. + +@node Keywords in imports +@section How to handle keyword substitution with cvs import + +The sources which you are importing may contain +keywords (@pxref{Keyword substitution}). For example, +the vendor may use @sc{cvs} or some other system +which uses similar keyword expansion syntax. If you +just import the files in the default fashion, then +the keyword expansions supplied by the vendor will +be replaced by keyword expansions supplied by your +own copy of @sc{cvs}. It may be more convenient to +maintain the expansions supplied by the vendor, so +that this information can supply information about +the sources that you imported from the vendor. + +To maintain the keyword expansions supplied by the +vendor, supply the @samp{-ko} option to @code{cvs +import} the first time you import the file. +This will turn off keyword expansion +for that file entirely, so if you want to be more +selective you'll have to think about what you want +and use the @samp{-k} option to @code{cvs update} or +@code{cvs admin} as appropriate. +@c Supplying -ko to import if the file already existed +@c has no effect. Not clear to me whether it should +@c or not. + +@node Multiple vendor branches +@section Multiple vendor branches + +All the examples so far assume that there is only one +vendor from which you are getting sources. In some +situations you might get sources from a variety of +places. For example, suppose that you are dealing with +a project where many different people and teams are +modifying the software. There are a variety of ways to +handle this, but in some cases you have a bunch of +source trees lying around and what you want to do more +than anything else is just to all put them in CVS so +that you at least have them in one place. + +For handling situations in which there may be more than +one vendor, you may specify the @samp{-b} option to +@code{cvs import}. It takes as an argument the vendor +branch to import to. The default is @samp{-b 1.1.1}. + +For example, suppose that there are two teams, the red +team and the blue team, that are sending you sources. +You want to import the red team's efforts to branch +1.1.1 and use the vendor tag RED. You want to import +the blue team's efforts to branch 1.1.3 and use the +vendor tag BLUE. So the commands you might use are: + +@example +$ cvs import dir RED RED_1-0 +$ cvs import -b 1.1.3 dir BLUE BLUE_1-5 +@end example + +Note that if your vendor tag does not match your +@samp{-b} option, CVS will not detect this case! For +example, + +@example +$ cvs import -b 1.1.3 dir RED RED_1-0 +@end example + +@noindent +Be careful; this kind of mismatch is sure to sow +confusion or worse. I can't think of a useful purpose +for the ability to specify a mismatch here, but if you +discover such a use, don't. CVS is likely to make this +an error in some future release. + +@c Probably should say more about the semantics of +@c multiple branches. What about the default branch? +@c What about joining (perhaps not as useful with +@c multiple branches, or perhaps it is. Either way +@c should be mentioned). @c I'm not sure about the best location for this. In @c one sense, it might belong right after we've introduced @@ -6161,7 +6714,7 @@ location. Many people have come up with some such a @c a previous employer) @c and gtornblo@senet.abb.se (spicm and related tools), @c but as far as I know -@c noone has nicely packaged or released such a system (or +@c no one has nicely packaged or released such a system (or @c instructions for constructing one). system using features such as the symbolic link feature found in many operating systems, or the @code{VPATH} @@ -6186,130 +6739,6 @@ is Odin (see @c there is any point in mentioning them here unless they @c can work with CVS. -@node Compatibility -@chapter Compatibility between CVS Versions - -@cindex CVS, versions of -@cindex versions, of CVS -@cindex compatibility, between CVS versions -@c We don't mention versions older than CVS 1.3 -@c on the theory that it would clutter it up for the vast -@c majority of people, who don't have anything that old. -@c -The repository format is compatible going back to -@sc{cvs} 1.3. But see @ref{Watches Compatibility}, if -you have copies of @sc{cvs} 1.6 or older and you want -to use the optional developer communication features. -@c If you "cvs rm" and commit using 1.3, then you'll -@c want to run "rcs -sdead <file,v>" on each of the -@c files in the Attic if you then want 1.5 and -@c later to recognize those files as dead (I think the -@c symptom if this is not done is that files reappear -@c in joins). (Wait: the above will work but really to -@c be strictly correct we should suggest checking -@c in a new revision rather than just changing the -@c state of the head revision, shouldn't we?). -@c The old convert.sh script was for this, but it never -@c did get updated to reflect use of the RCS "dead" -@c state. -@c Note: this is tricky to document without confusing -@c people--need to carefully say what CVS version we -@c are talking about and keep in mind the distinction -@c between a -@c repository created with 1.3 and on which one now -@c uses 1.5+, and a repository on which one wants to -@c use both versions side by side (e.g. during a -@c transition period). -@c We might want to separate out the 1.3 compatibility -@c section (for repository & working directory) from the -@c rest--that might help avoid confusing people who -@c are upgrading (for example) from 1.6 to 1.8. -@c -@c A minor incompatibility is if a current version of CVS -@c puts "Nfoo" into CVS/Tag, then CVS 1.9 or older will -@c see this as if there is no tag. Seems to me this is -@c too obscure to mention. - -The working directory format is compatible going back -to @sc{cvs} 1.5. It did change between @sc{cvs} 1.3 -and @sc{cvs} 1.5. If you run @sc{cvs} 1.5 or newer on -a working directory checked out with @sc{cvs} 1.3, -@sc{cvs} will convert it, but to go back to @sc{cvs} -1.3 you need to check out a new working directory with -@sc{cvs} 1.3. - -The remote protocol is interoperable going back to @sc{cvs} 1.5, but no -further (1.5 was the first official release with the remote protocol, -but some older versions might still be floating around). In many -cases you need to upgrade both the client and the server to take -advantage of new features and bugfixes, however. - -@c Perhaps should be saying something here about the -@c "D" lines in Entries (written by CVS 1.9; 1.8 and -@c older don't use them). These are supposed to be -@c compatible in both directions, but I'm not sure -@c they quite are 100%. One common gripe is if you -@c "rm -r" a directory and 1.9 gets confused, as it -@c still sees it in Entries. That one is fixed in -@c (say) 1.9.6. Someone else reported problems with -@c starting with a directory which was checked out with -@c an old version, and then using a new version, and -@c some "D" lines appeared, but not for every -@c directory, causing some directories to be skipped. -@c They weren't sure how to reproduce this, though. - -@c --------------------------------------------------------------------- -@node Revision management -@chapter Revision management -@cindex Revision management - -@c -- This chapter could be expanded a lot. -@c -- Experiences are very welcome! - -If you have read this far, you probably have a pretty -good grasp on what @sc{cvs} can do for you. This -chapter talks a little about things that you still have -to decide. - -If you are doing development on your own using @sc{cvs} -you could probably skip this chapter. The questions -this chapter takes up become more important when more -than one person is working in a repository. - -@menu -* When to commit:: Some discussion on the subject -@end menu - -@c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -@node When to commit -@section When to commit? -@cindex When to commit -@cindex Commit, when to -@cindex Policy - -Your group should decide which policy to use regarding -commits. Several policies are possible, and as your -experience with @sc{cvs} grows you will probably find -out what works for you. - -If you commit files too quickly you might commit files -that do not even compile. If your partner updates his -working sources to include your buggy file, he will be -unable to compile the code. On the other hand, other -persons will not be able to benefit from the -improvements you make to the code if you commit very -seldom, and conflicts will probably be more common. - -It is common to only commit files after making sure -that they can be compiled. Some sites require that the -files pass a test suite. Policies like this can be -enforced using the commitinfo file -(@pxref{commitinfo}), but you should think twice before -you enforce such a convention. By making the -development environment too controlled it might become -too regimented and thus counter-productive to the real -goal, which is to get software written. - @c --------------------------------------------------------------------- @node CVS commands @appendix Guide to CVS commands @@ -6330,7 +6759,7 @@ reference to @sc{cvs} commands, @pxref{Invoking CVS}). * ~/.cvsrc:: Default options with the ~/.csvrc file * Global options:: Options you give to the left of cvs_command * Common options:: Options you give to the right of cvs_command -* admin:: Administration front end for rcs +* admin:: Administration * checkout:: Checkout sources for editing * commit:: Check files into the repository * diff:: Show differences between revisions @@ -6435,7 +6864,7 @@ There are some @code{command_options} that are used so often that you might have set up an alias or some other means to make sure you always specify that option. One example (the one that drove the implementation of the -.cvsrc support, actually) is that many people find the +@file{.cvsrc} support, actually) is that many people find the default output of the @samp{diff} command to be very hard to read, and that either context diffs or unidiffs are much easier to understand. @@ -6486,7 +6915,7 @@ example the following line in @file{.cvsrc} cvs -z6 @end example -causes @sc{cvs} to use compression level 6 +causes @sc{cvs} to use compression level 6. @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - @node Global options @@ -6503,13 +6932,25 @@ left of @samp{cvs_command}) are: Specify legal @sc{cvsroot} directory. See @ref{Password authentication server}. +@cindex authentication, stream +@cindex stream authentication +@item -a +Authenticate all communication between the client and +the server. Only has an effect on the @sc{cvs} client. +As of this writing, this is only implemented when using +a GSSAPI connection (@pxref{GSSAPI authenticated}). +Authentication prevents certain sorts of attacks +involving hijacking the active @sc{tcp} connection. +Enabling authentication does not enable encryption. + @cindex RCSBIN, overriding @cindex Overriding RCSBIN @item -b @var{bindir} -Use @var{bindir} as the directory where @sc{rcs} programs are -located. Overrides the setting of the @code{$RCSBIN} environment -variable and any precompiled directory. This parameter should be -specified as an absolute pathname. +In @sc{cvs} 1.9.18 and older, this specified that +@sc{rcs} programs are in the @var{bindir} directory. +Current versions of @sc{cvs} do not run @sc{rcs} +programs; for compatibility this option is accepted, +but it does nothing. @cindex TMPDIR, overriding @cindex Overriding TMPDIR @@ -6556,7 +6997,7 @@ a command name, @samp{cvs -H} displays overall help for @c perhaps that is confusing... @item -l -Do not log the cvs_command in the command history (but execute it +Do not log the @samp{cvs_command} in the command history (but execute it anyway). @xref{history}, for information on command history. @cindex Read-only mode @@ -6608,15 +7049,25 @@ Make new working files read-write. Overrides the setting of the @code{$CVSREAD} environment variable. Files are created read-write by default, unless @code{$CVSREAD} is set or @samp{-r} is given. - +@c Note that -w only overrides -r and CVSREAD; it has +@c no effect on files which are readonly because of +@c "cvs watch on". My guess is that is the way it +@c should be (or should "cvs -w get" on a watched file +@c be the same as a get and a cvs edit?), but I'm not +@c completely sure whether to document it this way. + +@cindex encryption @item -x Encrypt all communication between the client and the server. Only has an effect on the @sc{cvs} client. As of this writing, this is only implemented when using a +GSSAPI connection (@pxref{GSSAPI authenticated}) or a Kerberos connection (@pxref{Kerberos authenticated}). -Encryption support is not available by default; it must -be enabled using a special configure option, -@file{--enable-encryption}, when you build @sc{cvs}. +Enabling encryption implies that message traffic is +also authenticated. Encryption support is not +available by default; it must be enabled using a +special configure option, @file{--enable-encryption}, +when you build @sc{cvs}. @item -z @var{gzip-level} Set the compression level. Only has an effect on the @@ -6795,6 +7246,13 @@ These two date formats are preferred. However, formats. They are intentionally not documented here in any detail, and future versions of @sc{cvs} might not accept all of them. +@c We should document and testsuite "now" and +@c "yesterday". "now" is mentioned in the FAQ and +@c "yesterday" is mentioned in this document (and the +@c message from "cvs import" suggesting a merge +@c command). What else? Probably some/all of the "3 +@c weeks ago" family. +@c @c Maybe at @c some point have CVS start give warnings on "unofficial" @c formats (many of which might be typos or user @@ -6830,12 +7288,14 @@ will be used). @code{annotate}, @code{checkout}, @code{export}, @code{rdiff}, @code{rtag}, and @code{update}. -@strong{Warning:} The @code{commit} command also has a +@strong{Warning:} The @code{commit} and @code{remove} +commands also have a @samp{-f} option, but it has a different behavior for -that command. @xref{commit options}. +those commands. See @ref{commit options}, and +@ref{Removing files}. @item -k @var{kflag} -Alter the default @sc{rcs} processing of keywords. +Alter the default processing of keywords. @xref{Keyword substitution}, for the meaning of @var{kflag}. Your @var{kflag} specification is @dfn{sticky} when you use it to create a private copy @@ -6884,7 +7344,7 @@ Available with the @code{checkout}, @code{commit}, @code{export}, and @code{rtag} commands. @item -P -Prune empty directories. See @xref{Removing directories}. +Prune empty directories. See @ref{Removing directories}. @item -p Pipe the files retrieved from the repository to standard output, @@ -6901,6 +7361,8 @@ Available with the following commands: @code{annotate}, @code{checkout}, and @code{watchers}. @item -r @var{tag} +@cindex HEAD, special tag +@cindex BASE, special tag Use the revision specified by the @var{tag} argument instead of the default @dfn{head} revision. As well as arbitrary tags defined with the @code{tag} or @code{rtag} command, two special tags are @@ -6919,14 +7381,20 @@ revision you last checked out into the current working directory. @c presumably be @c little problem changing it. (b) is ugly as it differs @c from what HEAD means for other commands, but people -@c might be used to it (note a change in NEWS? Or provide -@c advance warning of it changing?) and possible useful -@c (could be fixed by a new tag ".bhead" which would mean -@c the head of the appropriate branch). This -@c should be investigated, test cases written, and -@c documented (but HEAD should mean the same thing for all -@c CVS commands, so I don't know if we should be -@c documenting the current "cvs diff" behavior). +@c and/or scripts are quite possibly used to it. +@c See "head" tests in sanity.sh. +@c Probably the best fix is to introduce two new +@c special tags, ".thead" for the head of the trunk, +@c and ".bhead" for the head of the current branch. +@c Then deprecate HEAD. This has the advantage of +@c not suprising people with a change to HEAD, and a +@c side benefit of also phasing out the poorly-named +@c HEAD (see discussion of reserved tag names in node +@c "Tags"). Of course, .thead and .bhead should be +@c carefully implemented (with the implementation the +@c same for "diff" as for everyone else), test cases +@c written (similar to the ones in "head"), new tests +@c cases written for things like default branches, &c. The tag specification is sticky when you use this @c option @@ -6939,11 +7407,11 @@ tag can be either a symbolic or numeric tag. Specifying the @samp{-q} global option along with the @samp{-r} command option is often useful, to suppress -the warning messages when the @sc{rcs} history file +the warning messages when the @sc{rcs} file does not contain the specified tag. -@strong{Warning:} this is not the same as the overall `cvs -r' option, -which you can specify to the left of a cvs command! +@strong{Warning:} this is not the same as the overall @samp{cvs -r} option, +which you can specify to the left of a @sc{cvs} command! @samp{-r} is available with the @code{checkout}, @code{commit}, @code{diff}, @code{history}, @code{export}, @code{rdiff}, @@ -6954,14 +7422,14 @@ Specify file names that should be filtered. You can use this option repeatedly. The spec can be a file name pattern of the same type that you can specify in the @file{.cvswrappers} file. -Avaliable with the following commands: @code{import}, +Available with the following commands: @code{import}, and @code{update}. @end table @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - @node admin -@appendixsec admin---Administration front end for rcs +@appendixsec admin---Administration @cindex Admin (subcommand) @itemize @bullet @@ -6973,38 +7441,34 @@ Changes: repository. Synonym: rcs @end itemize -This is the @sc{cvs} interface to assorted administrative @sc{rcs} -facilities, documented in rcs(1). @code{admin} simply passes -all its options and arguments to the @code{rcs} command; it does -no filtering or other processing. This command @emph{does} work -recursively, however, so extreme care should be used. - -@c "group" should probably read "unix group" (but what -@c does NT local do?). "compiled in value" is -@c unclear--compiled in to what? -If there is a group whose name matches a compiled in -value which defaults to @code{cvsadmin}, only members -of that group can use @code{cvs admin}. To disallow +This is the @sc{cvs} interface to assorted +administrative facilities. Some of them have +questionable usefulness for @sc{cvs} but exist for +historical purposes. Some of the questionable options +are likely to disappear in the future. This command +@emph{does} work recursively, so extreme care should be +used. + +On unix, if there is a group named @code{cvsadmin}, +only members of that group can run @code{cvs admin}. +This group should exist on the server, or any system +running the non-client/server @sc{cvs}. To disallow @code{cvs admin} for all users, create a group with no -users in it. +users in it. On NT, the @code{cvsadmin} feature does +not exist and all users can run @code{cvs admin}. @menu * admin options:: admin options -* admin examples:: admin examples @end menu @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . @node admin options @appendixsubsec admin options -Not all valid @code{rcs} options are useful together -with @sc{cvs}. Some even makes it impossible to use -@sc{cvs} until you undo the effect! - -This description of the available options is based on -the @samp{rcs(1)} man page, but modified to suit -readers that are more interested in @sc{cvs} than -@sc{rcs}. +Some of these options have questionable usefulness for +@sc{cvs} but exist for historical purposes. Some even +make it impossible to use @sc{cvs} until you undo the +effect! @table @code @item -A@var{oldfile} @@ -7018,23 +7482,27 @@ login names appearing in the comma-separated list @var{logins} to the access list of the @sc{rcs} file. @item -b[@var{rev}] -When used with bare @sc{rcs}, this -option sets the default branch to @var{rev}; in -@sc{cvs} sticky tags (@pxref{Sticky tags}) are a better -way to decide which branch you want to work on. There -is one use with @sc{cvs}: to revert to the vendor's +Set the default branch to @var{rev}. In @sc{cvs}, you +normally do not manipulate default branches; sticky +tags (@pxref{Sticky tags}) are a better way to decide +which branch you want to work on. There is one reason +to run @code{cvs admin -b}: to revert to the vendor's version when using vendor branches (@pxref{Reverting local changes}). - +There can be no space between @samp{-b} and its argument. +@c Hmm, we don't document the usage where rev is +@c omitted. Maybe that usage can/should be deprecated +@c (and replaced with -bHEAD or something?) (so we can toss +@c the optional argument). Note that -bHEAD does not +@c work, as of 17 Sep 1997, but probably will once "cvs +@c admin" is internal to CVS. + +@cindex comment leader @item -c@var{string} -Useful with @sc{cvs}. Sets the comment leader to -@var{string}. The comment leader is printed before -every log message line generated by the keyword -@code{$@asis{}Log$} (@pxref{Keyword substitution}). -This is useful for programming languages without -multi-line comments. @sc{Rcs} initially guesses the -value of the comment leader from the file name -extension when the file is first committed. +Sets the comment leader to @var{string}. The comment +leader is not used by current versions of @sc{cvs} or +@sc{rcs} 5.7. Therefore, you can almost surely not +worry about it. @xref{Keyword substitution}. @item -e[@var{logins}] Might not work together with @sc{cvs}. Erase the login @@ -7042,19 +7510,20 @@ names appearing in the comma-separated list @var{logins} from the access list of the RCS file. If @var{logins} is omitted, erase the entire access list. -@c FIXME: Doesn't work with client/server CVS; we -@c should probably just not accept the option. @item -I Run interactively, even if the standard input is not a -terminal. +terminal. This option does not work with the +client/server @sc{cvs} and is likely to disappear in +a future release of @sc{cvs}. @item -i -Useless with @sc{cvs}. When using bare @sc{rcs}, this -is used to create and initialize a new @sc{rcs} file, -without depositing a revision. +Useless with @sc{cvs}. This creates and initializes a +new @sc{rcs} file, without depositing a revision. With +@sc{cvs}, add files with the @code{cvs add} command +(@pxref{Adding files}). @item -k@var{subst} -Useful with @sc{cvs}. Set the default keyword +Set the default keyword substitution to @var{subst}. @xref{Keyword substitution}. Giving an explicit @samp{-k} option to @code{cvs update}, @code{cvs export}, or @code{cvs @@ -7064,7 +7533,8 @@ checkout} overrides this default. Lock the revision with number @var{rev}. If a branch is given, lock the latest revision on that branch. If @var{rev} is omitted, lock the latest revision on the -default branch. +default branch. There can be no space between +@samp{-l} and its argument. This can be used in conjunction with the @file{rcslock.pl} script in the @file{contrib} @@ -7091,9 +7561,13 @@ set; see the discussion under the @samp{-l} option above. Replace the log message of revision @var{rev} with @var{msg}. +@c The rcs -M option, to suppress sending mail, has never been +@c documented as a cvs admin option. + @item -N@var{name}[:[@var{rev}]] Act like @samp{-n}, except override any previous -assignment of @var{name}. +assignment of @var{name}. For use with magic branches, +see @ref{Magic branch numbers}. @item -n@var{name}[:[@var{rev}]] Associate the symbolic name @var{name} with the branch @@ -7108,9 +7582,9 @@ followed by a @samp{.} stands for the current latest revision in the branch. A @samp{:} with an empty @var{rev} stands for the current latest revision on the default branch, normally the trunk. For example, -@samp{rcs -n@var{name}: RCS/*} associates @var{name} with the -current latest revision of all the named RCS files; -this contrasts with @samp{rcs -n@var{name}:$ RCS/*} which +@samp{cvs admin -n@var{name}:} associates @var{name} with the +current latest revision of all the RCS files; +this contrasts with @samp{cvs admin -n@var{name}:$} which associates @var{name} with the revision numbers extracted from keyword strings in the corresponding working files. @@ -7119,23 +7593,103 @@ working files. @cindex Outdating revisions @cindex Saving space @item -o@var{range} -Potentially useful, but dangerous, with @sc{cvs} (see below). Deletes (@dfn{outdates}) the revisions given by -@var{range}. A range consisting of a single revision -number means that revision. A range consisting of a -branch number means the latest revision on that branch. -A range of the form @samp{@var{rev1}:@var{rev2}} means -revisions @var{rev1} to @var{rev2} on the same branch, -@samp{:@var{rev}} means from the beginning of the +@var{range}. + +Note that this command can be quite dangerous unless +you know @emph{exactly} what you are doing (for example +see the warnings below about how the +@var{rev1}:@var{rev2} syntax is confusing). + +If you are short on disc this option might help you. +But think twice before using it---there is no way short +of restoring the latest backup to undo this command! +If you delete different revisions than you planned, +either due to carelessness or (heaven forbid) a CVS +bug, there is no opportunity to correct the error +before the revisions are deleted. It probably would be +a good idea to experiment on a copy of the repository +first. + +Specify @var{range} in one of the following ways: + +@table @code +@item @var{rev1}::@var{rev2} +Collapse all revisions between rev1 and rev2, so that +CVS only stores the differences associated with going +from rev1 to rev2, not intermediate steps. For +example, after @samp{-o 1.3::1.5} one can retrieve +revision 1.3, revision 1.5, or the differences to get +from 1.3 to 1.5, but not the revision 1.4, or the +differences between 1.3 and 1.4. Other examples: +@samp{-o 1.3::1.4} and @samp{-o 1.3::1.3} have no +effect, because there are no intermediate revisions to +remove. + +@item ::@var{rev} +Collapse revisions between the beginning of the branch +containing @var{rev} and @var{rev} itself. The +branchpoint and @var{rev} are left intact. For +example, @samp{-o ::1.3.2.6} deletes revision 1.3.2.1, +revision 1.3.2.5, and everything in between, but leaves +1.3 and 1.3.2.6 intact. + +@item @var{rev}:: +Collapse revisions between @var{rev} and the end of the +branch containing @var{rev}. Revision @var{rev} is +left intact but the head revision is deleted. + +@item @var{rev} +Delete the revision @var{rev}. For example, @samp{-o +1.3} is equivalent to @samp{-o 1.2::1.4}. + +@item @var{rev1}:@var{rev2} +Delete the revisions from @var{rev1} to @var{rev2}, +inclusive, on the same branch. One will not be able to +retrieve @var{rev1} or @var{rev2} or any of the +revisions in between. For example, the command +@samp{cvs admin -oR_1_01:R_1_02 .} is rarely useful. +It means to delete revisions up to, and including, the +tag R_1_02. But beware! If there are files that have not +changed between R_1_02 and R_1_03 the file will have +@emph{the same} numerical revision number assigned to +the tags R_1_02 and R_1_03. So not only will it be +impossible to retrieve R_1_02; R_1_03 will also have to +be restored from the tapes! In most cases you want to +specify @var{rev1}::@var{rev2} instead. + +@item :@var{rev} +Delete revisions from the beginning of the branch containing @var{rev} up to and including -@var{rev}, and @samp{@var{rev}:} means from revision -@var{rev} to the end of the branch containing -@var{rev}. None of the outdated revisions may have +@var{rev}. + +@item @var{rev}: +Delete revisions from revision @var{rev}, including +@var{rev} itself, to the end of the branch containing +@var{rev}. +@end table + +None of the revisions to be deleted may have branches or locks. +If any of the revisions to be deleted have symbolic +names, and one specifies one of the @samp{::} syntaxes, +then @sc{cvs} will give an error and not delete any +revisions. If you really want to delete both the +symbolic names and the revisions, first delete the +symbolic names with @code{cvs tag -d}, then run +@code{cvs admin -o}. If one specifies the +non-@samp{::} syntaxes, then @sc{cvs} will delete the +revisions but leave the symbolic names pointing to +nonexistent revisions. This behavior is preserved for +compatibility with previous versions of @sc{cvs}, but +because it isn't very useful, in the future it may +change to be like the @samp{::} case. + Due to the way @sc{cvs} handles branches @var{rev} cannot be specified symbolically if it is a branch. @xref{Magic branch numbers}, for an explanation. +@c FIXME: is this still true? I suspect not. Make sure that no-one has checked out a copy of the revision you outdate. Strange things will happen if he @@ -7170,17 +7724,31 @@ commands like @code{cvs remove} and @code{cvs add}, not Useful with @sc{cvs}. Write descriptive text from the contents of the named @var{file} into the RCS file, deleting the existing text. The @var{file} pathname -may not begin with @samp{-}. If @var{file} is omitted, +may not begin with @samp{-}. The descriptive text can be seen in the +output from @samp{cvs log} (@pxref{log}). +There can be no space between @samp{-t} and its argument. + +If @var{file} is omitted, obtain the text from standard input, terminated by end-of-file or by a line containing @samp{.} by itself. Prompt for the text if interaction is possible; see -@samp{-I}. The descriptive text can be seen in the -output from @samp{cvs log} (@pxref{log}). +@samp{-I}. Reading from standard input does not work +for client/server @sc{cvs} and may change in a future +release of @sc{cvs}. +@c Changing it to doeditor() is the most obvious thing +@c (but with a different syntax, as we would like to +@c phase out optional arguments). I don't know. I'm +@c tempted to say the whole concept is unnecessary. @item -t-@var{string} Similar to @samp{-t@var{file}}. Write descriptive text from the @var{string} into the @sc{rcs} file, deleting the existing text. +There can be no space between @samp{-t} and its argument. + +@c The rcs -T option, do not update last-mod time for +@c minor changes, has never been documented as a +@c cvs admin option. @item -U Set locking to non-strict. Non-strict locking means @@ -7201,72 +7769,31 @@ This causes a mail message to be sent to the original locker. The message contains a commentary solicited from the breaker. The commentary is terminated by end-of-file or by a line containing @code{.} by itself. +There can be no space between @samp{-u} and its argument. +@c In the future "send mail" probably will go via the +@c CVSROOT/notify mechanism. But for now it means +@c whatever it means to "rcs". @item -V@var{n} -Emulate @sc{rcs} version @var{n}. Use -V@var{n} to make -an @sc{rcs} file acceptable to @sc{rcs} version @var{n} -by discarding information that would confuse version -@var{n}. +In previous versions of @sc{cvs}, this option meant to +write an @sc{rcs} file which would be acceptable to +@sc{rcs} version @var{n}, but it is now obsolete and +specifying it will produce an error. +@c Note that -V without an argument has never been +@c documented as a cvs admin option. @item -x@var{suffixes} -Useless with @sc{cvs}. Use @var{suffixes} to -characterize RCS files. +In previous versions of @sc{cvs}, this was documented +as a way of specifying the names of the @sc{rcs} +files. However, @sc{cvs} has always required that the +@sc{rcs} files used by @sc{cvs} end in @samp{,v}, so +this option has never done anything useful. + +@c The rcs -z option, to specify the timezone, has +@c never been documented as a cvs admin option. @end table -@c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -@node admin examples -@appendixsubsec admin examples - -@appendixsubsubsec Outdating is dangerous - -First, an example of how @emph{not} to use the -@code{admin} command. It is included to stress the -fact that this command can be quite dangerous unless -you know @emph{exactly} what you are doing. - -The @samp{-o} option can be used to @dfn{outdate} old revisions -from the history file. If you are short on disc this option -might help you. But think twice before using it---there is no -way short of restoring the latest backup to undo this command! - -The next line is an example of a command that you would -@emph{not} like to execute. - -@example -$ cvs admin -o:R_1_02 . -@end example - -The above command will delete all revisions up to, and -including, the revision that corresponds to the tag -R_1_02. But beware! If there are files that have not -changed between R_1_02 and R_1_03 the file will have -@emph{the same} numerical revision number assigned to -the tags R_1_02 and R_1_03. So not only will it be -impossible to retrieve R_1_02; R_1_03 will also have to -be restored from the tapes! - -@appendixsubsubsec Comment leaders -@cindex Comment leader -@cindex Log keyword, selecting comment leader -@cindex Nroff (selecting comment leader) - -If you use the @code{$@asis{}Log$} keyword and you do -not agree with the guess for comment leader that -@sc{cvs} has done, you can enforce your will with -@code{cvs admin -c}. This might be suitable for -@code{nroff} source: - -@example -$ cvs admin -c'.\" ' *.man -$ rm *.man -$ cvs update -@end example - -The two last steps are to make sure that you get the -versions with correct comment leaders in your working -files. - @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - @node checkout @appendixsec checkout---Check out sources for editing @@ -7284,13 +7811,13 @@ Changes: working directory. Synonyms: co, get @end itemize -Make a working directory containing copies of the +Create or update a working directory containing copies of the source files specified by @var{modules}. You must execute @code{checkout} before using most of the other @sc{cvs} commands, since most of them operate on your working directory. -The @var{modules} part of the command are either +The @var{modules} are either symbolic names for some collection of source directories and files, or paths to directories or files in the repository. The symbolic @@ -7299,6 +7826,10 @@ names are defined in the @samp{modules} file. @c Needs an example, particularly of the non-"modules" @c case but probably of both. +@c FIXME: this seems like a very odd place to introduce +@c people to how CVS works. The bit about unreserved +@c checkouts is also misleading as it depends on how +@c things are set up. Depending on the modules you specify, @code{checkout} may recursively create directories and populate them with the appropriate source files. You can then edit these @@ -7326,15 +7857,20 @@ read-write, unless the @samp{-r} option to @sc{cvs} (@pxref{Environment variables}), or a watch is in effect for that file (@pxref{Watches}). -@c FIXME: misleading--checkout takes a module as -@c argument, and update does not--so -d behavior is not the only -@c difference. -Running @code{checkout} on a directory that was already -built by a prior @code{checkout} is also permitted, and -has the same effect as specifying the @samp{-d} option -to the @code{update} command, that is, any new +Note that running @code{checkout} on a directory that was already +built by a prior @code{checkout} is also permitted. +This is similar to specifying the @samp{-d} option +to the @code{update} command in the sense that new directories that have been created in the repository -will appear in your work area. @xref{update}. +will appear in your work area. +However, @code{checkout} takes a module name whereas +@code{update} takes a directory name. Also +to use @code{checkout} this way it must be run from the +top level directory (where you originally ran +@code{checkout} from), so before you run +@code{checkout} to update an existing directory, don't +forget to change your directory to the top level +directory. For the output produced by the @code{checkout} command see @ref{update output}. @@ -7365,8 +7901,9 @@ retrieve the most recent revision (instead of ignoring the file). @item -k @var{kflag} -Process @sc{rcs} keywords according to @var{kflag}. See -co(1). This option is sticky; future updates of +Process keywords according to @var{kflag}. See +@ref{Keyword substitution}. +This option is sticky; future updates of this file in this working directory will use the same @var{kflag}. The @code{status} command can be viewed to see the sticky options. See @ref{Invoking CVS}, for @@ -7407,18 +7944,35 @@ Copy the module file, sorted, to the standard output, instead of creating or modifying any files or directories in your working directory. -@c Should clarify whether dir can specify a -@c subdirectory (for example "foo/bar"). As of May, -@c 1996, it is said to work for local CVS if the parent -@c directories already exist, and not at all for remote -@c CVS. The remote CVS behavior at least seems like it -@c is clearly a bug. @item -d @var{dir} Create a directory called @var{dir} for the working -files, instead of using the module name. Unless you -also use @samp{-N}, the paths created under @var{dir} -will be as short as possible. -@c FIXME: What the #$@!#$# does "short as possible" mean? +files, instead of using the module name. In general, +using this flag is equivalent to using @samp{mkdir +@var{dir}; cd @var{dir}} followed by the checkout +command without the @samp{-d} flag. + +There is an important exception, however. It is very +convenient when checking out a single item to have the +output appear in a directory that doesn't contain empty +intermediate directories. In this case @emph{only}, +CVS tries to ``shorten'' pathnames to avoid those empty +directories. + +For example, given a module @samp{foo} that contains +the file @samp{bar.c}, the command @samp{cvs co -d dir +foo} will create directory @samp{dir} and place +@samp{bar.c} inside. Similarly, given a module +@samp{bar} which has subdirectory @samp{baz} wherein +there is a file @samp{quux.c}, the command @samp{cvs -d +dir co bar/baz} will create directory @samp{dir} and +place @samp{quux.c} inside. + +Using the @samp{-N} flag will defeat this behavior. +Given the same module definitions above, @samp{cvs co +-N -d dir foo} will create directories @samp{dir/foo} +and place @samp{bar.c} inside, while @samp{cvs co -N -d +dir bar/baz} will create directories @samp{dir/bar/baz} +and place @samp{quux.c} inside. @item -j @var{tag} With two @samp{-j} options, merge changes from the @@ -7440,14 +7994,14 @@ date. An optional date is specified by adding a colon (:) to the tag: @samp{-j@var{Symbolic_Tag}:@var{Date_Specifier}}. -@xref{Merging}. +@xref{Branching and merging}. @item -N -Only useful together with @samp{-d @var{dir}}. With this -option, @sc{cvs} will not shorten module paths in your -working directory. (Normally, @sc{cvs} shortens paths as -much as possible when you specify an explicit target -directory). +Only useful together with @samp{-d @var{dir}}. With +this option, @sc{cvs} will not ``shorten'' module paths +in your working directory when you check out a single +module. See the @samp{-d} flag for examples and a +discussion. @item -s Like @samp{-c}, but include the status of all modules, @@ -7516,9 +8070,9 @@ time is right. When all is well, an editor is invoked to allow you to enter a log message that will be written to one or more logging programs (@pxref{modules}, and @pxref{loginfo}) -and placed in the @sc{rcs} history file inside the +and placed in the @sc{rcs} file inside the repository. This log message can be retrieved with the -@code{log} command; @xref{log}. You can specify the +@code{log} command; see @ref{log}. You can specify the log message on the command line with the @samp{-m @var{message}} option, and thus avoid the editor invocation, or use the @samp{-F @var{file}} option to specify @@ -7565,7 +8119,7 @@ of invoking an editor. @item -f Note that this is not the standard behavior of -the @samp{-f} option as defined in @xref{Common options}. +the @samp{-f} option as defined in @ref{Common options}. Force @sc{cvs} to commit a new revision even if you haven't made any changes to the file. If the current revision @@ -7677,7 +8231,7 @@ $ cvs checkout -r EXPR1 whatever_module @itemize @bullet @item -Synopsis: diff [-lR] [rcsdiff_options] [[-r rev1 | -D date1] [-r rev2 | -D date2]] [files@dots{}] +Synopsis: diff [-lR] [format_options] [[-r rev1 | -D date1] [-r rev2 | -D date2]] [files@dots{}] @item Requires: working directory, repository. @item @@ -7715,8 +8269,8 @@ Use the most recent revision no later than @var{date}. See @samp{-r} for how this affects the comparison. @item -k @var{kflag} -Process @sc{rcs} keywords according to @var{kflag}. See -co(1). +Process keywords according to @var{kflag}. See +@ref{Keyword substitution}. @item -l Local; run only in current working directory. @@ -7734,43 +8288,32 @@ revision will be compared to your current working file. With two @samp{-r} options those two revisions will be compared (and your working file will not affect the outcome in any way). +@c We should be a lot more explicit, with examples, +@c about the difference between "cvs diff" and "cvs +@c diff -r HEAD". This often confuses new users. One or both @samp{-r} options can be replaced by a @samp{-D @var{date}} option, described above. - -@item --ifdef=@var{arg} -Output in ifdef format. Consult the documentation of -your underlying diff program concerning the @samp{-D} -option to diff, for more information on this format. @end table -@c FIXME? Probably should document -c here, and -@c perhaps arrange for CVS to support it via a diff library or -@c some such. Or perhaps figure that "all" diff -@c programs support -c? Ideas is to preserve the -@c ability to pass the buck to diff on all the hairy -@c stuff, while still providing at least one, and -@c perhaps several popular standard formats. But this -@c is all in the idea stage, and probably needs more -@c thought and refinement. -u might be similar, in -@c terms of being something that it might make sense to -@c document here. -@c FIXME: also should be a way to pass through +@c Conceptually, this is a disaster. There are 3 +@c zillion diff formats that we support via the diff +@c library. It is not obvious to me that we should +@c document them all. Maybe just the most common ones +@c like -c and -u, and think about phasing out the +@c obscure ones. +@c FIXCVS: also should be a way to specify an external +@c diff program (which can be different for different +@c file types) and pass through @c arbitrary options, so that the user can do @c "--pass=-Z --pass=foo" or something even if CVS -@c doesn't know about the -Z option to diff. -@c Note on -N: The current CVS implementation does require that the -@c underlying diff supports -N so we can document it as -@c a pass-through even if the implementation details -@c are more complicated. -@c -@c FIXME? Reference to discussion of which diff CVS -@c uses (one in path, or....). -The following options are passed through to -@code{rcsdiff}, which in turn passes them to -@code{diff}. The exact meaning of the options depends -on which @code{diff} you are using. See the -documentation for your @code{diff} for details. +@c doesn't know about the "-Z foo" option to diff. +@c This would fit nicely with deprecating/eliminating +@c the obscure options of the diff library, because it +@c would let people specify an external GNU diff if +@c they are into that sort of thing. +The following options specify the format of the +output. They have the same meaning as in GNU diff. @code{-a} @code{-b} @code{-B} @code{-c} @w{@code{-C} @var{nlines}} @code{-d} @code{-e} @code{-f} @code{-h} @@ -7786,6 +8329,7 @@ documentation for your @code{diff} for details. @code{--context[=@var{lines}]} @code{--ed} @code{--expand-tabs} @code{--forward-ed} @code{--horizon-lines=@var{arg}} +@code{--ifdef=@var{arg}} @code{--ignore-all-space} @code{--ignore-blank-lines} @code{--ignore-case} @code{--ignore-matching-lines=@var{regexp}} @@ -7864,14 +8408,14 @@ date or tag (with @samp{-D} or @samp{-r}), so that you can count on reproducing the source you ship to others. One often would like to use @samp{-kv} with @code{cvs -export}. This causes any @sc{rcs} keywords to be +export}. This causes any keywords to be expanded such that an import done at some other site will not lose the keyword revision information. But be aware that doesn't handle an export containing binary files correctly. Also be aware that after having used @samp{-kv}, one can no longer use the @code{ident} command (which is part of the @sc{rcs} suite---see -ident(1)) which looks for @sc{rcs} keyword strings. If +ident(1)) which looks for keyword strings. If you want to be able to use @code{ident} you must not use @samp{-kv}. @@ -7914,19 +8458,17 @@ In addition, these options (that are common to @table @code @item -d @var{dir} Create a directory called @var{dir} for the working -files, instead of using the module name. Unless you -also use @samp{-N}, the paths created under @var{dir} -will be as short as possible. +files, instead of using the module name. +@xref{checkout options}, for complete details on how +@sc{cvs} handles this flag. @item -k @var{subst} Set keyword expansion mode (@pxref{Substitution modes}). @item -N -Only useful together with @samp{-d @var{dir}}. With this -option, @sc{cvs} will not shorten module paths in your -working directory. (Normally, @sc{cvs} shortens paths as -much as possible when you specify an explicit target -directory.) +Only useful together with @samp{-d @var{dir}}. +@xref{checkout options}, for complete details on how +@sc{cvs} handles this flag. @end table @ignore @@ -7982,8 +8524,12 @@ Report on each time commit was used (i.e., each time the repository was modified). @item -e -Everything (all record types); equivalent to specifying -@samp{-xMACFROGWUT}. +Everything (all record types). Equivalent to +specifying @samp{-x} with all record types. Of course, +@samp{-e} will also include record types which are +added in a future version of @sc{cvs}; if you are +writing a script which can only handle certain record +types, you'll want to specify @samp{-x}. @item -m @var{module} Report on a particular module. (You can meaningfully @@ -8085,7 +8631,7 @@ files. Each @sc{rcs} file is searched for the revision or tag. @item -t @var{tag} -Show records since tag @var{tag} was last added to the the +Show records since tag @var{tag} was last added to the history file. This differs from the @samp{-r} flag above in that it reads only the history file, not the @sc{rcs} files, and is much faster. @@ -8148,9 +8694,9 @@ If the file @file{$CVSROOT/CVSROOT/cvswrappers} exists, any file whose names match the specifications in that file will be treated as packages and the appropriate filtering will be performed on the file/directory -before being imported, @xref{Wrappers}. +before being imported. @xref{Wrappers}. -The outside source is saved in a first-level @sc{rcs} +The outside source is saved in a first-level branch, by default 1.1.1. Updates are leaves of this branch; for example, files from the first imported collection of source will be revision 1.1.1.1, then @@ -8193,14 +8739,14 @@ Use @var{message} as log information, instead of invoking an editor. @end table -There are three additional special options. +There are the following additional special options. @table @code @item -b @var{branch} See @ref{Multiple vendor branches}. @item -k @var{subst} -Indicate the RCS keyword expansion mode desired. This +Indicate the keyword expansion mode desired. This setting will apply to all files created during the import, but not to any files that previously existed in the repository. See @ref{Substitution modes}, for a @@ -8270,7 +8816,7 @@ to recreate symbolic links on checkout, update, etc.; @node import examples @appendixsubsec import examples -@xref{Tracking sources}, and @xref{From files}. +See @ref{Tracking sources}, and @ref{From files}. @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - @node log @@ -8373,7 +8919,8 @@ exclusive one. Note that the separator is a semicolon (;). @item -h -Print only the @sc{rcs} pathname, working pathname, head, +Print only the name of the @sc{rcs} file, name +of the file in the working directory, head, default branch, access list, locks, symbolic names, and suffix. @@ -8389,8 +8936,26 @@ information, the log information is presented without tags at all. @item -R -Print only the name of the @sc{rcs} history file. - +Print only the name of the @sc{rcs} file. + +@c Note that using a bare revision (in addition to not +@c being explicitly documented here) is potentially +@c confusing; it shows the log message to get from the +@c previous revision to that revision. "-r1.3 -r1.6" +@c (equivalent to "-r1.3,1.6") is even worse; it +@c prints the messages to get from 1.2 to 1.3 and 1.5 +@c to 1.6. By analogy with "cvs diff", users might +@c expect that it is more like specifying a range. +@c It is not 100% clear to me how much of this should +@c be documented (for example, multiple -r options +@c perhaps could/should be deprecated given the false +@c analogy with "cvs diff"). +@c In general, this section should be rewritten to talk +@c about messages to get from revision rev1 to rev2, +@c rather than messages for revision rev2 (that is, the +@c messages are associated with a change not a static +@c revision and failing to make this distinction causes +@c much confusion). @item -r@var{revisions} Print information about revisions given in the comma-separated list @var{revisions} of revisions and @@ -8471,7 +9036,7 @@ Synonym: patch @end itemize Builds a Larry Wall format patch(1) file between two -releases, that can be fed directly into the patch +releases, that can be fed directly into the @code{patch} program to bring an old release up-to-date with the new release. (This is one of the few @sc{cvs} commands that operates directly from the repository, and doesn't @@ -8487,8 +9052,8 @@ the @sc{rcs} file. Note that if the software release affected is contained in more than one directory, then it may be necessary to -specify the @samp{-p} option to the patch command when -patching the old sources, so that patch is able to find +specify the @samp{-p} option to the @code{patch} command when +patching the old sources, so that @code{patch} is able to find the files that are located in other directories. @menu @@ -8543,14 +9108,14 @@ last change to a file was. @item -u Use the unidiff format for the context diffs. -This option is not available if your diff does not +This option is not available if your @code{diff} does not support the unidiff format. Remember that old versions of the @code{patch} program can't handle the unidiff format, so if you plan to post this patch to the net you should probably not use @samp{-u}. @item -V @var{vn} -Expand @sc{rcs} keywords according to the rules current in +Expand keywords according to the rules current in @sc{rcs} version @var{vn} (the expansion format changed with @sc{rcs} version 5). @end table @@ -8780,6 +9345,10 @@ Do not run any tag program that was specified with the @item -R Tag directories recursively. This is on by default. +@c FIXME: this discussion is confusing. What part of +@c the rename operation being discussed relates to +@c "rtag -r" (that whole discussion needs an example, +@c and probably to be moved somewhere else)? @item -r @var{tag} Only tag those files that contain @var{tag}. This can be used to rename a tag: tag only the files identified @@ -8802,7 +9371,7 @@ symbolic tag as development continues (and files get removed from the up-coming distribution). @item -b -Make the tag a branch tag. @xref{Revisions and branches}. +Make the tag a branch tag. @xref{Branching and merging}. @item -d Delete the tag instead of creating it. @@ -8887,6 +9456,13 @@ them): @cindex renaming tags @cindex tags, renaming @cindex moving tags +@c FIXME: Where does this talk about renaming tags? +@c And what about rtag? This needs to be moved to +@c the body of the manual. +@c Also see: +@c "How do I move or rename a magic branch tag?" +@c in the FAQ (I think the issues it talks about still +@c apply, but this could use some sanity.sh work). @item -F Overwrite an existing tag of the same name on a different revision. @@ -8903,13 +9479,13 @@ Two special options are available: @table @code @item -b -The -b option makes the tag a branch tag -(@pxref{Revisions and branches}), allowing concurrent, isolated +Make the tag a branch tag +(@pxref{Branching and merging}), allowing concurrent, isolated development. This is most useful for creating a patch to a previously released software distribution. @item -c -The -c option checks that all files which are to be tagged are +Check that all files which are to be tagged are unmodified. This can be used to make sure that you can reconstruct the current file contents. @@ -8981,8 +9557,9 @@ retrieve the most recent revision (instead of ignoring the file). @item -k @var{kflag} -Process @sc{rcs} keywords according to @var{kflag}. See -co(1). This option is sticky; future updates of +Process keywords according to @var{kflag}. See +@ref{Keyword substitution}. +This option is sticky; future updates of this file in this working directory will use the same @var{kflag}. The @code{status} command can be viewed to see the sticky options. See @ref{Invoking CVS}, for @@ -9001,8 +9578,8 @@ Pipe files to the standard output. Update directories recursively (default). @xref{Recursive behavior}. -@item -r tag -Retrieve revision @var{tag}. This option is sticky, +@item -r rev +Retrieve revision/tag @var{rev}. This option is sticky, and implies @samp{-P}. See @ref{Sticky tags}, for more information on sticky tags/dates. @end table @@ -9061,14 +9638,14 @@ ancestor revision is the common ancestor of the revision which the working directory is based on, and the revision specified in the @samp{-j} option. -In addition, each -j option can contain an optional +In addition, each @samp{-j} option can contain an optional date specification which, when used with branches, can limit the chosen revision to one within a specific date. An optional date is specified by adding a colon (:) to the tag: @samp{-j@var{Symbolic_Tag}:@var{Date_Specifier}}. -@xref{Merging}. +@xref{Branching and merging}. @end table @@ -9077,7 +9654,7 @@ date. An optional date is specified by adding a colon @appendixsubsec update output @code{update} and @code{checkout} keep you informed of -its progress by printing a line for each file, preceded +their progress by printing a line for each file, preceded by one character indicating the status of the file: @table @code @@ -9127,13 +9704,13 @@ name of that file is printed while @code{update} runs. A conflict was detected while trying to merge your changes to @var{file} with changes from the source repository. @var{file} (the copy in your working -directory) is now the output of the rcsmerge(1) command -on the two revisions; an unmodified copy of your file +directory) is now the result of attempting to merge +the two revisions; an unmodified copy of your file is also in your working directory, with the name @file{.#@var{file}.@var{revision}} where @var{revision} -is the @sc{rcs} revision that your modified file started +is the revision that your modified file started from. Resolve the conflict as described in -@ref{Conflicts example} +@ref{Conflicts example}. @c "some systems" as in out-of-the-box OSes? Not as @c far as I know. We need to advise sysadmins as well @c as users how to set up this kind of purge, if that is @@ -9215,7 +9792,8 @@ Replace the log message of revision @var{rev} with @var{msg}. @item -o@var{range} -Delete revisions from the history files +Delete revisions from the repository. See +@ref{admin options}. @item -q Run quietly; do not print diagnostics. @@ -9296,7 +9874,8 @@ Use @var{kflag} keyword expansion. See Local; run only in current working directory. @xref{Recursive behavior}. @item -N -Don't shorten module paths if -d specified. See @ref{checkout options}. +Don't ``shorten'' module paths if -d specified. See +@ref{checkout options}. @item -n Do not run module program (if any). See @ref{checkout options}. @@ -9439,7 +10018,8 @@ Use @var{kflag} keyword expansion. See Local; run only in current working directory. @xref{Recursive behavior}. @item -N -Don't shorten module paths if -d specified. See @ref{export options}. +Don't ``shorten'' module paths if -d specified. See +@ref{export options}. @item -n Do not run module program (if any). See @ref{export options}. @@ -9530,7 +10110,7 @@ Use the file's modification time as the time of import. See @ref{import options}. @item -k @var{kflag} -Set default RCS keyword substitution mode. See +Set default keyword substitution mode. See @ref{import options}. @item -m @var{msg} @@ -9877,7 +10457,7 @@ Inside the repository, in the directory supportive files for @sc{cvs}. You can use @sc{cvs} in a limited fashion without any of them, but if they are set up properly they can help make life easier. For a -discussion of how to edit them, @xref{Intro +discussion of how to edit them, see @ref{Intro administrative files}. The most important of these files is the @file{modules} @@ -9896,6 +10476,7 @@ file, which defines the modules inside the repository. * cvsignore:: Ignoring files via cvsignore * history file:: History information * Variables:: Various variables are expanded +* config:: Miscellaneous CVS configuration @end menu @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - @@ -9916,10 +10497,31 @@ module definitions. Long lines can be continued on the next line by specifying a backslash (@samp{\}) as the last character on the line. -A module definition is a single line of the -@file{modules} file, in either of two formats. In both -cases, @var{mname} represents the symbolic module name, -and the remainder of the line is its definition. +There are three basic types of modules: alias modules, +regular modules, and ampersand modules. The difference +between them is the way that they map files in the +repository to files in the working directory. In all +of the following examples, the top-level repository +contains a directory called @file{first-dir}, which +contains two files, @file{file1} and @file{file2}, and a +directory @file{sdir}. @file{first-dir/sdir} contains +a file @file{sfile}. + +@c FIXME: should test all the examples in this section. + +@menu +* Alias modules:: The simplest kind of module +* Regular modules:: +* Ampersand modules:: +* Module options:: Regular and ampersand modules can take options +@end menu + +@node Alias modules +@appendixsubsec Alias modules +@cindex Alias modules +@cindex -a, in modules file + +Alias modules are the simplest kind of module: @table @code @item @var{mname} -a @var{aliases}@dots{} @@ -9933,8 +10535,39 @@ paths. When you use paths in aliases, @code{checkout} creates all intermediate directories in the working directory, just as if the path had been specified explicitly in the @sc{cvs} arguments. +@end table + +For example, if the modules file contains: -@item @var{mname} [ options ] @var{dir} [ @var{files}@dots{} ] [ &@var{module}@dots{} ] +@example +amodule -a first-dir +@end example + +@noindent +then the following two commands are equivalent: + +@example +$ cvs co amodule +$ cvs co first-dir +@end example + +@noindent +and they each would provide output such as: + +@example +cvs checkout: Updating first-dir +U first-dir/file1 +U first-dir/file2 +cvs checkout: Updating first-dir/sdir +U first-dir/sdir/sfile +@end example + +@node Regular modules +@appendixsubsec Regular modules +@cindex Regular modules + +@table @code +@item @var{mname} [ options ] @var{dir} [ @var{files}@dots{} ] In the simplest case, this form of module definition reduces to @samp{@var{mname} @var{dir}}. This defines all the files in directory @var{dir} as module mname. @@ -9945,47 +10578,104 @@ case, on checkout, a single directory called intermediate directory levels are used by default, even if @var{dir} was a path involving several directory levels. +@end table + +For example, if a module is defined by: + +@example +regmodule first-dir +@end example + +@noindent +then regmodule will contain the files from first-dir: + +@example +$ cvs co regmodule +cvs checkout: Updating regmodule +U regmodule/file1 +U regmodule/file2 +cvs checkout: Updating regmodule/sdir +U regmodule/sdir/sfile +$ +@end example By explicitly specifying files in the module definition after @var{dir}, you can select particular files from -directory @var{dir}. The sample definition for -@samp{modules} is an example of a module defined with a -single file from a particular directory. Here is -another example: +directory @var{dir}. Here is +an example: @example -m4test unsupported/gnu/m4 foreach.m4 forloop.m4 +regfiles first-dir/sdir sfile @end example @noindent -With this definition, executing @samp{cvs checkout -m4test} will create a single working directory -@file{m4test} containing the two files listed, which -both come from a common directory several levels deep -in the @sc{cvs} source repository. +With this definition, getting the regfiles module +will create a single working directory +@file{regfiles} containing the file listed, which +comes from a directory deeper +in the @sc{cvs} source repository: + +@example +$ cvs co regfiles +U regfiles/sfile +$ +@end example + +@node Ampersand modules +@appendixsubsec Ampersand modules +@cindex Ampersand modules +@cindex &, in modules file A module definition can refer to other modules by including @samp{&@var{module}} in its definition. -@code{checkout} creates a subdirectory for each such +@example +@var{mname} [ options ] @var{&module}@dots{} +@end example + +Then getting the module creates a subdirectory for each such module, in the directory containing the module. For example, if modules contains @example -m4test &unsupported +ampermod &first-dir @end example -then a checkout will create an @code{m4test} directory -which contains a directory called @code{unsupported}, +then a checkout will create an @code{ampermod} directory +which contains a directory called @code{first-dir}, which in turns contains all the directories and files -which live there. -@c FIXME: this is hard to describe since we don't tell -@c the user what the repository contains. Best way to -@c fix this whole mess is an extended example where we -@c first say what is in the repository, then show a -@c regular module, an alias module, and an & module. -@c We should mention the concept of options only -@c *after* we've taken care of those basics. -@c +which live there. For example, the command + +@example +$ cvs co ampermod +@end example + +@noindent +will create the following files: + +@example +ampermod/first-dir/file1 +ampermod/first-dir/file2 +ampermod/first-dir/sdir/sfile +@end example + +There is one quirk/bug: the messages that @sc{cvs} +prints omit the @file{ampermod}, and thus do not +correctly display the location to which it is checking +out the files: + +@example +$ cvs co ampermod +cvs checkout: Updating first-dir +U first-dir/file1 +U first-dir/file2 +cvs checkout: Updating first-dir/sdir +U first-dir/sdir/sfile +$ +@end example + +Do not rely on this buggy behavior; it may get fixed in +a future release of @sc{cvs}. + @c FIXCVS: What happens if regular and & modules are @c combined, as in "ampermodule first-dir &second-dir"? @c When I tried it, it seemed to just ignore the @@ -9995,12 +10685,25 @@ which live there. @c should put in a few words about why you would use one or @c the other in various situations. +@node Module options +@appendixsubsec Module options +@cindex options, in modules file + +Either regular modules or ampersand modules can contain +options, which supply additional information concerning +the module. + @table @code +@cindex -d, in modules file @item -d @var{name} Name the working directory something other than the module name. +@c FIXME: Needs a bunch of examples, analogous to the +@c examples for alias, regular, and ampersand modules +@c which show where the files go without -d. @cindex Export program +@cindex -e, in modules file @item -e @var{prog} Specify a program @var{prog} to run whenever files in a module are exported. @var{prog} runs with a single @@ -10008,6 +10711,7 @@ argument, the module name. @c FIXME: Is it run on server? client? @cindex Checkin program +@cindex -i, in modules file @item -i @var{prog} Specify a program @var{prog} to run whenever files in a module are committed. @var{prog} runs with a single @@ -10018,6 +10722,7 @@ ways to call a program on commit. @c FIXME: Is it run on server? client? @cindex Checkout program +@cindex -o, in modules file @item -o @var{prog} Specify a program @var{prog} to run whenever files in a module are checked out. @var{prog} runs with a single @@ -10026,6 +10731,7 @@ argument, the module name. @cindex Status of a module @cindex Module status +@cindex -s, in modules file @item -s @var{status} Assign a status to the module. When the module file is printed with @samp{cvs checkout -s} the modules are @@ -10036,15 +10742,23 @@ several things besides status: for instance, list the person that is responsible for this module. @cindex Tag program +@cindex -t, in modules file @item -t @var{prog} Specify a program @var{prog} to run whenever files in a module are tagged with @code{rtag}. @var{prog} runs with two arguments: the module name and the symbolic -tag specified to @code{rtag}. There is no way to -specify a program to run when @code{tag} is executed. +tag specified to @code{rtag}. It is not run +when @code{tag} is executed. Generally you will find +that taginfo is a better solution (@pxref{user-defined logging}). @c FIXME: Is it run on server? client? +@c Problems with -t include: +@c * It is run after the tag not before +@c * It doesn't get passed all the information that +@c taginfo does ("mov", &c). +@c * It only is run for rtag, not tag. @cindex Update program +@cindex -u, in modules file @item -u @var{prog} Specify a program @var{prog} to run whenever @samp{cvs update} is executed from the top-level directory of the @@ -10052,7 +10766,11 @@ checked-out module. @var{prog} runs with a single argument, the full path to the source repository for this module. @c FIXME: Is it run on server? client? -@end table +@c One drawback of -u and -i are that CVS/Update.prog +@c and CVS/Checkin.prog only get updated on initial +@c checkout, and don't get updated if the modules file +@c changes. Also, the user can edit them, which means +@c they are no good for security-type stuff. @end table @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - @@ -10088,16 +10806,23 @@ not work with client/server @sc{cvs}. The @file{cvswrappers} also has a @samp{-m} option to specify the merge methodology that should be used when the file is updated. @code{MERGE} means the usual -@sc{cvs} behavior: try to merge the files (this -generally will not work for binary files). @code{COPY} -means that @code{cvs update} will merely copy one -version over the other, and require the user using +@sc{cvs} behavior: try to merge the files. @code{COPY} +means that @code{cvs update} will refuse to merge +files, as it also does for files specified as binary +with @samp{-kb}. CVS will provide the user with the +two versions of the files, and require the user using mechanisms outside @sc{cvs}, to insert any necessary -changes. -@c FIXME: which version is copied over which version? +changes. @strong{WARNING}: do not use @code{COPY} with +@sc{cvs} 1.9 or earlier--such versions of @sc{cvs} will +copy one version of your file over the other, wiping +out the previous contents. +@c Ordinarily we don't document the behavior of old +@c versions. But this one is so dangerous, I think we +@c must. I almost renamed it to -m 'NOMERGE' so we +@c could say "never use -m 'COPY'". The @samp{-m} wrapper option only affects behavior when merging is done on update; it does not affect how files -are stored. See @xref{Binary files}, for more on +are stored. See @ref{Binary files}, for more on binary files. The basic format of the file @file{cvswrappers} is: @@ -10120,6 +10845,13 @@ and value is a single-quote delimited value. *.nib -f 'unwrap %s' -t 'wrap %s %s' -m 'COPY' *.c -t 'indent %s %s' @end example +@c When does the filter need to be an absolute pathname +@c and when will something like the above work? I +@c suspect it relates to the PATH of the server (which +@c in turn depends on all kinds of stuff, e.g. inetd +@c for pserver). I'm not sure whether/where to discuss +@c this. +@c FIXME: What do the %s's stand for? @noindent The above example of a @file{cvswrappers} file @@ -10130,7 +10862,7 @@ be filtered though the @file{unwrap} program when the file is checked out of the repository. The @file{cvswrappers} file also states that a @code{COPY} methodology should be used when updating the files in -the repository (that is no merging should be performed). +the repository (that is, no merging should be performed). @c What pitfalls arise when using indent this way? Is @c it a winning thing to do? Would be nice to at least @@ -10138,9 +10870,9 @@ the repository (that is no merging should be performed). @c how to solve problems, not just to say that cvs can @c do certain things. The last example line says that all files that end with -a @code{*.c} should be filtered with @file{indent} +@code{.c} should be filtered with @file{indent} before being checked into the repository. Unlike the previous -example no filtering of the @code{*.c} file is done when +example, no filtering of the @code{.c} file is done when it is checked out of the repository. @noindent The @code{-t} filter is called with two arguments, @@ -10290,6 +11022,8 @@ expression in the syntax used by GNU emacs. @c support all the obscure emacs extensions like \<. @c Also need to better cite (or include) full @c documentation for the syntax. +@c Also see comment in configure.in about what happens to the +@c syntax if we pick up a system-supplied regexp matcher. @item A whitespace separator---one or more spaces and/or tabs. @@ -10595,6 +11329,9 @@ The @file{rcsinfo} file contains this line: @cindex Distributing log messages @cindex Log messages +@c "cvs commit" is not quite right. What we +@c mean is "when the repository gets changed" which +@c also includes "cvs import" and "cvs add" on a directory. The @file{loginfo} file is used to control where @samp{cvs commit} log information is sent. The first entry on a line is a regular expression which is tested @@ -10640,7 +11377,7 @@ For example, some valid format strings are @samp{%}, @samp{%s}, @samp{%@{s@}}, and @samp{%@{sVv@}}. The output will be a string of tokens separated by -spaces. For backwards compatibility, the the first +spaces. For backwards compatibility, the first token will be the repository name. The rest of the tokens will be comma-delimited lists of the information requested in the format string. For example, if @@ -10783,8 +11520,8 @@ matching regular expression or @samp{DEFAULT}. @c it or anything. In particular we should say @c how to version control the template file. A @c probably better answer than the /usr/cvsssupport -@c stuff is to use checkoutlist. FIXME: it doesn't -@c seem like checkoutlist is documented at all! +@c stuff is to use checkoutlist (with xref to the +@c checkoutlist doc). @c Also I am starting to see a connection between @c this and the Keeping a checked out copy node. @c Probably want to say something about that. @@ -10899,6 +11636,18 @@ import. Because this is awkward, in the future @samp{-I !} might be modified to override @file{.cvsignore} files in each directory. +Note that the syntax of the ignore files consists of a +series of lines, each of which contains a space +separated list of filenames. This offers no clean way +to specify filenames which contain spaces, but you can +use a workaround like @file{foo?bar} to match a file +named @file{foo bar} (it also matches @file{fooxbar} +and the like). Also note that there is currently no +way to specify comments. +@c FIXCVS? I don't _like_ this syntax at all, but +@c changing it raises all the usual compatibility +@c issues and I'm also not sure what to change it to. + @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - @node history file @appendixsec The history file @@ -10931,9 +11680,9 @@ To find the home directory of the user running @sc{cvs} @samp{~} followed by @samp{/} or the end of the line. Likewise for the home directory of @var{user}, use @samp{~@var{user}}. These variables are expanded on -the server machine, and don't get any resonable +the server machine, and don't get any reasonable expansion if pserver (@pxref{Password authenticated}) -is in used; therefore user variables (see below) may be +is in use; therefore user variables (see below) may be a better choice to customize behavior based on the user running @sc{cvs}. @c Based on these limitations, should we deprecate ~? @@ -10956,9 +11705,11 @@ This is the value of the @sc{cvs} root in use. ways to specify this. @item RCSBIN -This is the value @sc{cvs} is using for where to find -@sc{rcs} binaries. @xref{Global options}, for a -description of how to specify this. +In @sc{cvs} 1.9.18 and older, this specified the +directory where @sc{cvs} was looking for @sc{rcs} +programs. Because @sc{cvs} no longer runs @sc{rcs} +programs, specifying this internal variable is now an +error. @item CVSEDITOR @itemx VISUAL @@ -10973,7 +11724,7 @@ server machine). @end table If you want to pass a value to the administrative files -which the user that is running @sc{cvs} can specify, +which the user who is running @sc{cvs} can specify, use a user variable. To expand a user variable, the administrative file contains @code{$@{=@var{variable}@}}. To set a user variable, @@ -11001,6 +11752,47 @@ All other strings containing @samp{$} are reserved; there is no way to quote a @samp{$} character so that @samp{$} represents itself. +@node config +@appendixsec The CVSROOT/config configuration file + +@cindex config, in CVSROOT +@cindex CVSROOT/config + +The administrative file @file{config} contains various +miscellaneous settings which affect the behavior of +@sc{cvs}. The syntax is slightly different from the +other administrative files. Variables are not +expanded. Lines which start with @samp{#} are +considered comments. +@c FIXME: where do we define comments for the other +@c administrative files. +Other lines consist of a keyword, @samp{=}, and a +value. Note that this syntax is very strict. +Extraneous spaces or tabs are not permitted. +@c See comments in parseinfo.c:parse_config for more +@c discussion of this strictness. + +Currently defined keywords are: + +@table @code +@cindex RCSBIN, in CVSROOT/config +@item RCSBIN=@var{bindir} +For @sc{cvs} 1.9.12 through 1.9.18, this setting told +@sc{cvs} to look for @sc{rcs} programs in the +@var{bindir} directory. Current versions of @sc{cvs} +do not run @sc{rcs} programs; for compatibility this +setting is accepted, but it does nothing. + +@cindex SystemAuth, in CVSROOT/config +@item SystemAuth=@var{value} +If @var{value} is @samp{yes}, then pserver should check +for users in the system's user database if not found in +@file{CVSROOT/passwd}. If it is @samp{no}, then all +pserver users must exist in @file{CVSROOT/passwd}. +The default is @samp{yes}. For more on pserver, see +@ref{Password authenticated}. +@end table + @c --------------------------------------------------------------------- @node Environment variables @appendix All environment variables which affect CVS @@ -11011,17 +11803,17 @@ This is a complete list of all environment variables that affect @sc{cvs}. @table @code -@cindex CVSIGNORE +@cindex CVSIGNORE, environment variable @item $CVSIGNORE A whitespace-separated list of file name patterns that @sc{cvs} should ignore. @xref{cvsignore}. -@cindex CVSWRAPPERS +@cindex CVSWRAPPERS, environment variable @item $CVSWRAPPERS A whitespace-separated list of file name patterns that @sc{cvs} should treat as wrappers. @xref{Wrappers}. -@cindex CVSREAD +@cindex CVSREAD, environment variable @cindex read-only files, and CVSREAD @item $CVSREAD If this is set, @code{checkout} and @code{update} will @@ -11033,10 +11825,9 @@ is to permit modification of your working files. Controls permissions of files in the repository. See @ref{File permissions}. -@cindex CVSROOT @item $CVSROOT Should contain the full pathname to the root of the @sc{cvs} -source repository (where the @sc{rcs} history files are +source repository (where the @sc{rcs} files are kept). This information must be available to @sc{cvs} for most commands to execute; if @code{$CVSROOT} is not set, or if you wish to override it for one invocation, you @@ -11047,36 +11838,34 @@ the file @file{CVS/Root}), so normally you only need to worry about this when initially checking out a working directory. -@cindex EDITOR -@cindex CVSEDITOR @item $EDITOR @itemx $CVSEDITOR Specifies the program to use for recording log messages during commit. @code{$CVSEDITOR} overrides @code{$EDITOR}. See @ref{Committing your changes}. -@cindex PATH +@cindex PATH, environment variable @item $PATH If @code{$RCSBIN} is not set, and no path is compiled into @sc{cvs}, it will use @code{$PATH} to try to find all programs it uses. -@cindex RCSBIN -@item $RCSBIN -This is the value @sc{cvs} is using for where to find -@sc{rcs} binaries. @xref{Global options}, for a -description of how to specify this. If not set, a -compiled-in value is used, or your @code{$PATH} is searched. - -@cindex HOME +@cindex HOME, environment variable @item $HOME -@cindex HOMEPATH +@cindex HOMEPATH, environment variable @item $HOMEPATH +@cindex HOMEDRIVE, environment variable +@item $HOMEDRIVE Used to locate the directory where the @file{.cvsrc} -file is searched (@code{$HOMEPATH} is used for Windows-NT). -@pxref{~/.cvsrc} - -@cindex CVS_RSH +file, and other such files, are searched. On Unix, CVS +just checks for HOME. On Windows NT, the system will +set HOMEDRIVE, for example to @samp{d:} and HOMEPATH, +for example to @file{\joe}. On Windows 95, you'll +probably need to set HOMEDRIVE and HOMEPATH yourself. +@c We are being vague about whether HOME works on +@c Windows; see long comment in windows-NT/filesubr.c. + +@cindex CVS_RSH, environment variable @item $CVS_RSH Specifies the external program which CVS connects with, when @code{:ext:} access method is specified. @@ -11099,13 +11888,13 @@ Used in client-server mode when accessing the server via Kerberos. @pxref{Kerberos authenticated} -@cindex CVS_RCMD_PORT +@cindex CVS_RCMD_PORT, environment variable @item $CVS_RCMD_PORT Used in client-server mode. If set, specifies the port number to be used when accessing the @sc{rcmd} demon on the server side. (Currently not used for Unix clients). -@cindex CVS_CLIENT_LOG +@cindex CVS_CLIENT_LOG, environment variable @item $CVS_CLIENT_LOG Used for debugging only in client-server mode. If set, everything send to the server is logged @@ -11113,38 +11902,37 @@ into @file{@code{$CVS_CLIENT_LOG}.in} and everything send from the server is logged into @file{@code{$CVS_CLIENT_LOG}.out}. -@cindex CVS_SERVER_SLEEP +@cindex CVS_SERVER_SLEEP, environment variable @item $CVS_SERVER_SLEEP Used only for debugging the server side in client-server mode. If set, delays the start of the -server child process the the specified amount of +server child process the specified amount of seconds so that you can attach to it with a debugger. -@cindex CVS_IGNORE_REMOTE_ROOT +@cindex CVS_IGNORE_REMOTE_ROOT, environment variable @item $CVS_IGNORE_REMOTE_ROOT (What is the purpose of this variable?) -@cindex COMSPEC +@cindex COMSPEC, environment variable @item $COMSPEC Used under OS/2 only. It specifies the name of the command interpreter and defaults to @sc{cmd.exe}. -@cindex TMPDIR +@cindex TMPDIR, environment variable @item $TMPDIR -@cindex TMP +@cindex TMP, environment variable @itemx $TMP -@cindex TEMP +@cindex TEMP, environment variable @itemx $TEMP @cindex temporary files, location of -@c I'm not even sure I've documented all the -@c conventions here. Furthermore, those conventions are +@c This is quite nuts. We don't talk about tempnam +@c or mkstemp which we sometimes use. The discussion +@c of "Global options" is semi-incoherent. +@c I'm not even sure those are the only inaccuracies. +@c Furthermore, the conventions are @c pretty crazy and they should be simplified. -Directory in which temporary files are located. Those -parts of @sc{cvs} which are implemented using @sc{rcs} -inspect the above variables in the order they appear -above and the first value found is taken; if none of -them are set, a host-dependent default is used, -typically @file{/tmp}. The @sc{cvs} server uses +Directory in which temporary files are located. +The @sc{cvs} server uses @code{TMPDIR}. @xref{Global options}, for a description of how to specify this. Some parts of @sc{cvs} will always use @file{/tmp} (via @@ -11155,34 +11943,89 @@ function provided by the system). The @code{patch} program which is used by the @sc{cvs} client uses @code{TMPDIR}, and if it is not set, uses -@file{/tmp} (at least with GNU patch 2.1). +@file{/tmp} (at least with GNU patch 2.1). Note that +if your server and client are both running @sc{cvs} +1.9.10 or later, @sc{cvs} will not invoke an external +@code{patch} program. @end table -@sc{cvs} invokes @sc{rcs} to perform certain -operations. The following environment -variables affect @sc{rcs}. Note that if you are using -the client/server @sc{cvs}, these variables need to be -set on the server side (which may or not may be -possible depending on how you are connecting). There -is probably not any need to set any of them, however. +@node Compatibility +@appendix Compatibility between CVS Versions -@table @code -@cindex LOGNAME -@item $LOGNAME -@cindex USER -@itemx $USER -If set, they affect who @sc{rcs} thinks you are. If you -have trouble checking in files it might be because your -login name differs from the setting of e.g. -@code{$LOGNAME}. - -@cindex RCSINIT -@item $RCSINIT -Options prepended to the argument list, separated by -spaces. A backslash escapes spaces within an option. -The @code{$RCSINIT} options are prepended to the -argument lists of most @sc{rcs} commands. -@end table +@cindex CVS, versions of +@cindex versions, of CVS +@cindex compatibility, between CVS versions +@c We don't mention versions older than CVS 1.3 +@c on the theory that it would clutter it up for the vast +@c majority of people, who don't have anything that old. +@c +The repository format is compatible going back to +@sc{cvs} 1.3. But see @ref{Watches Compatibility}, if +you have copies of @sc{cvs} 1.6 or older and you want +to use the optional developer communication features. +@c If you "cvs rm" and commit using 1.3, then you'll +@c want to run "rcs -sdead <file,v>" on each of the +@c files in the Attic if you then want 1.5 and +@c later to recognize those files as dead (I think the +@c symptom if this is not done is that files reappear +@c in joins). (Wait: the above will work but really to +@c be strictly correct we should suggest checking +@c in a new revision rather than just changing the +@c state of the head revision, shouldn't we?). +@c The old convert.sh script was for this, but it never +@c did get updated to reflect use of the RCS "dead" +@c state. +@c Note: this is tricky to document without confusing +@c people--need to carefully say what CVS version we +@c are talking about and keep in mind the distinction +@c between a +@c repository created with 1.3 and on which one now +@c uses 1.5+, and a repository on which one wants to +@c use both versions side by side (e.g. during a +@c transition period). +@c Wait, can't CVS just detect the case in which a file +@c is in the Attic but the head revision is not dead? +@c Not sure whether this should produce a warning or +@c something, and probably needs further thought, but +@c it would appear that the situation can be detected. +@c +@c We might want to separate out the 1.3 compatibility +@c section (for repository & working directory) from the +@c rest--that might help avoid confusing people who +@c are upgrading (for example) from 1.6 to 1.8. +@c +@c A minor incompatibility is if a current version of CVS +@c puts "Nfoo" into CVS/Tag, then CVS 1.9 or older will +@c see this as if there is no tag. Seems to me this is +@c too obscure to mention. + +The working directory format is compatible going back +to @sc{cvs} 1.5. It did change between @sc{cvs} 1.3 +and @sc{cvs} 1.5. If you run @sc{cvs} 1.5 or newer on +a working directory checked out with @sc{cvs} 1.3, +@sc{cvs} will convert it, but to go back to @sc{cvs} +1.3 you need to check out a new working directory with +@sc{cvs} 1.3. + +The remote protocol is interoperable going back to @sc{cvs} 1.5, but no +further (1.5 was the first official release with the remote protocol, +but some older versions might still be floating around). In many +cases you need to upgrade both the client and the server to take +advantage of new features and bugfixes, however. + +@c Perhaps should be saying something here about the +@c "D" lines in Entries (written by CVS 1.9; 1.8 and +@c older don't use them). These are supposed to be +@c compatible in both directions, but I'm not sure +@c they quite are 100%. One common gripe is if you +@c "rm -r" a directory and 1.9 gets confused, as it +@c still sees it in Entries. That one is fixed in +@c (say) 1.9.6. Someone else reported problems with +@c starting with a directory which was checked out with +@c an old version, and then using a new version, and +@c some "D" lines appeared, but not for every +@c directory, causing some directories to be skipped. +@c They weren't sure how to reproduce this, though. @c --------------------------------------------------------------------- @node Troubleshooting @@ -11226,11 +12069,29 @@ In some cases the list includes messages printed by old versions of @sc{cvs} (partly because users may not be sure which version of @sc{cvs} they are using at any particular moment). +@c If we want to start retiring messages, perhaps we +@c should pick a cutoff version (for example, no more +@c messages which are specific to versions before 1.9) +@c and then move the old messages to an "old messages" +@c node rather than deleting them completely. @table @code @c FIXME: What is the correct way to format a multiline @c error message here? Maybe @table is the wrong @c choice? Texinfo gurus? +@item cvs @var{command}: authorization failed: server @var{host} rejected access +This is a generic response when trying to connect to a +pserver server which chooses not to provide a +specific reason for denying authorization. Check that +the username and password specified are correct and +that the CVSROOT specified is allowed by --allow-root +in inetd.conf. See @ref{Password authenticated}. + +@item @var{file}:@var{line}: Assertion '@var{text}' failed +The exact format of this message may vary depending on +your system. It indicates a bug in @sc{cvs}, which can +be handled as described in @ref{BUGS}. + @item cannot change permissions on temporary directory @example Operation not permitted @@ -11248,8 +12109,10 @@ you have any information to add, please let us know as described in @ref{BUGS}. If you experience this error while using @sc{cvs}, retrying the operation which produced it should work fine. -@c Most recently this was in the multibranch-5 test. -@c But I'm not sure it is specific to that test. +@c This has been seen in a variety of tests, including +@c multibranch-2, multibranch-5, and basic1-24-rm-rm, +@c so it doesn't seem particularly specific to any one +@c test. @c For one example see basica-1a10 in the testsuite @c For another example, "cvs co ." on NT; see comment @@ -11262,23 +12125,80 @@ can be handled as with other @sc{cvs} bugs exact nature of which would depend on the situation but which hopefully could be figured out. +@c This is more obscure than it might sound; it only +@c happens if you run "cvs init" from a directory which +@c contains a CVS/Root file at the start. +@item cvs [init aborted]: cannot open CVS/Root: No such file or directory +This message is harmless. Provided it is not +accompanied by other errors, the operation has +completed successfully. This message should not occur +with current versions of @sc{cvs}, but it is documented +here for the benefit of @sc{cvs} 1.9 and older. + @item cvs [checkout aborted]: cannot rename file @var{file} to CVS/,,@var{file}: Invalid argument This message has been reported as intermittently happening with CVS 1.9 on Solaris 2.5. The cause is unknown; if you know more about what causes it, let us know as described in @ref{BUGS}. +@item cvs [@var{command} aborted]: cannot start server via rcmd +This, unfortunately, is a rather nonspecific error +message which @sc{cvs} 1.9 will print if you are +running the @sc{cvs} client and it is having trouble +connecting to the server. Current versions of @sc{cvs} +should print a much more specific error message. If +you get this message when you didn't mean to run the +client at all, you probably forgot to specify +@code{:local:}, as described in @ref{Repository}. + +@item ci: @var{file},v: bad diff output line: Binary files - and /tmp/T2a22651 differ +CVS 1.9 and older will print this message +when trying to check in a binary file if +@sc{rcs} is not correctly installed. Re-read the +instructions that came with your @sc{rcs} distribution +and the @sc{install} file in the @sc{cvs} +distribution. Alternately, upgrade to a current +version of @sc{cvs}, which checks in files itself +rather than via @sc{rcs}. + +@item cvs checkout: could not check out @var{file} +With CVS 1.9, this can mean that the @code{co} program +(part of @sc{rcs}) returned a failure. It should be +preceded by another error message, however it has been +observed without another error message and the cause is +not well-understood. With the current version of CVS, +which does not run @code{co}, if this message occurs +without another error message, it is definitely a CVS +bug (@pxref{BUGS}). +@c My current suspicion is that the RCS in the rcs (not +@c cvs/winnt/rcs57nt.zip) directory on the _Practical_ +@c CD is bad (remains to be confirmed). +@c There is also a report of something which looks +@c very similar on SGI, Irix 5.2, so I dunno. + +@item cvs [login aborted]: could not find out home directory +This means that you need to set the environment +variables that CVS uses to locate your home directory. +See the discussion of HOME, HOMEDRIVE, and HOMEPATH in +@ref{Environment variables}. + +@item cvs update: could not merge revision @var{rev} of @var{file}: No such file or directory +CVS 1.9 and older will print this message if there was +a problem finding the @code{rcsmerge} program. Make +sure that it is in your @code{PATH}, or upgrade to a +current version of CVS, which does not require +an external @code{rcsmerge} program. + @item cvs [update aborted]: could not patch @var{file}: No such file or directory This means that there was a problem finding the @code{patch} program. Make sure that it is in your @code{PATH}. Note that despite appearances the message is @emph{not} referring to whether it can find @var{file}. -@c Future versions of @sc{cvs} are -@c expected to dispense with the need for an external -@c patch program, but might as well not advertise -@c vaporware. -@c Even after that change is made, probably want to -@c preserve this message, see above about old messages. +If both the client and the server are running a current +version of @sc{cvs}, then there is no need for an +external patch program and you should not see this +message. But if either client or server is running +@sc{cvs} 1.9, then you need @code{patch}. @item cvs update: could not patch @var{file}; will refetch This means that for whatever reason the client was @@ -11291,9 +12211,12 @@ has no effect on what @sc{cvs} does. @c explains this whole "patch"/P/Needs Patch thing? @item dying gasps from @var{server} unexpected -This message seems to be caused by a hard-to-track-down -bug in @sc{cvs} or the systems it runs on (we don't -know---we haven't tracked it down yet!). If you see it, +There is a known bug in the server for @sc{cvs} 1.9.18 +and older which can cause this. For me, this was +reproducible if I used the @samp{-t} global option. It +was fixed by Andy Piper's 14 Nov 1997 change to +src/filesubr.c, if anyone is curious. +If you see the message, you probably can just retry the operation which failed, or if you have discovered information concerning its cause, please let us know as described in @ref{BUGS}. @@ -11324,6 +12247,33 @@ every place it appears in your @code{modules} file. For more information on the @code{modules} file, see @ref{modules}. +@c This messsage comes from "co", and I believe is +@c possible only with older versions of CVS which call +@c co. The problem with being able to create the bogus +@c RCS file still exists, though (and I think maybe +@c there is a different symptom(s) now). +@c FIXME: Would be nice to have a more exact wording +@c for this message. +@item missing author +Typically this can happen if you created an RCS file +with your username set to empty. CVS will, bogusly, +create an illegal RCS file with no value for the author +field. The solution is to make sure your username is +set to a non-empty value and re-create the RCS file. +@c "make sure your username is set" is complicated in +@c and of itself, as there are the environment +@c variables the system login name, &c, and it depends +@c on the version of CVS. + +@item *PANIC* administration files missing +This typically means that there is a directory named +CVS but it does not contain the administrative files +which CVS puts in a CVS directory. If the problem is +that you created a CVS directory via some mechanism +other than CVS, then the answer is simple, use a name +other than CVS. If not, it indicates a CVS bug +(@pxref{BUGS}). + @item rcs error: Unknown option: -x,v/ This message will be followed by a usage message for @sc{rcs}. It means that you have an old version of @@ -11333,6 +12283,8 @@ later. @c For more information on installing @sc{cvs}, see @c (FIXME: where? it depends on whether you are @c getting binaries or sources or what). +@c The message can also say "ci error" or something +@c instead of "rcs error", I suspect. @item cvs [server aborted]: received broken pipe signal This message seems to be caused by a hard-to-track-down @@ -11343,6 +12295,22 @@ you should be able to just ignore the message. However, if you have discovered information concerning its cause, please let us know as described in @ref{BUGS}. +@item Too many arguments! +This message is typically printed by the @file{log.pl} +script which is in the @file{contrib} directory in the +@sc{cvs} source distribution. In some versions of +@sc{cvs}, @file{log.pl} has been part of the default +@sc{cvs} installation. The @file{log.pl} script gets +called from the @file{loginfo} administrative file. +Check that the arguments passed in @file{loginfo} match +what your version of @file{log.pl} expects. In +particular, the @file{log.pl} from @sc{cvs} 1.3 and +older expects the logfile as an argument whereas the +@file{log.pl} from @sc{cvs} 1.5 and newer expects the +logfile to be specified with a @samp{-f} option. Of +course, if you don't need @file{log.pl} you can just +comment it out of @file{loginfo}. + @item cvs commit: Up-to-date check failed for `@var{file}' This means that someone else has committed a change to that file since the last time that you did a @code{cvs @@ -11366,13 +12334,26 @@ This indicates a problem with the installation of @code{rcsmerge} was compiled to look for GNU diff3, but it is finding unix diff3 instead. The exact text of the message will vary depending on the system. The -solution is to make sure @code{rcsmerge} finds GNU -diff3. Depending on how @code{rcsmerge} was compiled, -it might be sufficient to place GNU diff3 in your -@code{PATH}, or it might be necessary to recompile -@code{rcsmerge} or find a binary distribution of -@code{rcsmerge} which looks in the @code{PATH}. -@c Should we mention the cvsaux binaries here? +simplest solution is to upgrade to a current version of +@sc{cvs}, which does not rely on external +@code{rcsmerge} or @code{diff3} programs. + +@item warning: unrecognized response `@var{text}' from cvs server +If @var{text} contains a valid response (such as +@samp{ok}) followed by an extra carriage return +character (on many systems this will cause the second +part of the message to overwrite the first part), then +it probably means that you are using the @samp{:ext:} +access method with a version of rsh, such as most +non-unix rsh versions, which does not by default +provide a transparent data stream. In such cases you +probably want to try @samp{:server:} instead of +@samp{:ext:}. If @var{text} is something else, this +may signify a problem with your CVS server. +Double-check your installation against the instructions +for setting up the CVS server. +@c FIXCVS: should be printing CR as \r or \015 or some +@c such, probably. @item cvs commit: warning: editor session failed @cindex exit status, of editor @@ -11402,15 +12383,171 @@ particular order. @itemize @bullet @item -If @code{cvs update} finds a conflict and tries to +If you are running @sc{cvs} 1.9.18 or older, and +@code{cvs update} finds a conflict and tries to merge, as described in @ref{Conflicts example}, but doesn't tell you there were conflicts, then you may -have an old version of @sc{rcs}. For more information -on how to set this up, see the @file{INSTALL} file in -the @sc{cvs} source distribution. +have an old version of @sc{rcs}. The easiest solution +probably is to upgrade to a current version of +@sc{cvs}, which does not rely on external @sc{rcs} +programs. @end itemize @c --------------------------------------------------------------------- +@node Credits +@appendix Credits + +@cindex Contributors (manual) +@cindex Credits (manual) +Roland Pesch, then of Cygnus Support <@t{roland@@wrs.com}> +wrote the manual pages which were distributed with +@sc{cvs} 1.3. Much of their text was copied into this +manual. He also read an early draft +of this manual and contributed many ideas and +corrections. + +The mailing-list @code{info-cvs} is sometimes +informative. I have included information from postings +made by the following persons: +David G. Grubbs <@t{dgg@@think.com}>. + +Some text has been extracted from the man pages for +@sc{rcs}. + +The @sc{cvs} @sc{faq} by David G. Grubbs has provided +useful material. The @sc{faq} is no longer maintained, +however, and this manual is about the closest thing there +is to a successor (with respect to documenting how to +use @sc{cvs}, at least). + +In addition, the following persons have helped by +telling me about mistakes I've made: + +@display +Roxanne Brunskill <@t{rbrunski@@datap.ca}>, +Kathy Dyer <@t{dyer@@phoenix.ocf.llnl.gov}>, +Karl Pingle <@t{pingle@@acuson.com}>, +Thomas A Peterson <@t{tap@@src.honeywell.com}>, +Inge Wallin <@t{ingwa@@signum.se}>, +Dirk Koschuetzki <@t{koschuet@@fmi.uni-passau.de}> +and Michael Brown <@t{brown@@wi.extrel.com}>. +@end display + +The list of contributors here is not comprehensive; for a more +complete list of who has contributed to this manual see +the file @file{doc/ChangeLog} in the @sc{cvs} source +distribution. + +@c --------------------------------------------------------------------- +@node BUGS +@appendix Dealing with bugs in CVS or this manual + +@cindex Bugs in this manual or CVS +Neither @sc{cvs} nor this manual is perfect, and they +probably never will be. If you are having trouble +using @sc{cvs}, or think you have found a bug, there +are a number of things you can do about it. Note that +if the manual is unclear, that can be considered a bug +in the manual, so these problems are often worth doing +something about as well as problems with @sc{cvs} itself. + +@cindex Reporting bugs +@cindex Bugs, reporting +@cindex Errors, reporting +@itemize @bullet +@item +If you want someone to help you and fix bugs that you +report, there are companies which will do that for a +fee. Two such companies are: + +@cindex Signum Support +@cindex Cyclic Software +@cindex Support, getting CVS support +@example +Signum Support AB +Box 2044 +S-580 02 Linkoping +Sweden +Email: info@@signum.se +Phone: +46 (0)13 - 21 46 00 +Fax: +46 (0)13 - 21 47 00 +http://www.signum.se/ + +Cyclic Software +United States of America +http://www.cyclic.com/ +info@@cyclic.com +@end example + +@item +If you got @sc{cvs} through a distributor, such as an +operating system vendor or a vendor of freeware +@sc{cd-rom}s, you may wish to see whether the +distributor provides support. Often, they will provide +no support or minimal support, but this may vary from +distributor to distributor. + +@item +If you have the skills and time to do so, you may wish +to fix the bug yourself. If you wish to submit your +fix for inclusion in future releases of @sc{cvs}, see +the file @sc{hacking} in the @sc{cvs} source +distribution. It contains much more information on the +process of submitting fixes. + +@item +There may be resources on the net which can help. Two +good places to start are: + +@example +http://www.cyclic.com +http://www.loria.fr/~molli/cvs-index.html +@end example + +If you are so inspired, increasing the information +available on the net is likely to be appreciated. For +example, before the standard @sc{cvs} distribution +worked on Windows 95, there was a web page with some +explanation and patches for running @sc{cvs} on Windows +95, and various people helped out by mentioning this +page on mailing lists or newsgroups when the subject +came up. + +@item +It is also possible to report bugs to @code{bug-cvs}. +Note that someone may or may not want to do anything +with your bug report---if you need a solution consider +one of the options mentioned above. People probably do +want to hear about bugs which are particularly severe +in consequences and/or easy to fix, however. You can +also increase your odds by being as clear as possible +about the exact nature of the bug and any other +relevant information. The way to report bugs is to +send email to @code{bug-cvs@@gnu.org}. Note +that submissions to @code{bug-cvs} may be distributed +under the terms of the @sc{gnu} Public License, so if +you don't like this, don't submit them. There is +usually no justification for sending mail directly to +one of the @sc{cvs} maintainers rather than to +@code{bug-cvs}; those maintainers who want to hear +about such bug reports read @code{bug-cvs}. Also note +that sending a bug report to other mailing lists or +newsgroups is @emph{not} a substitute for sending it to +@code{bug-cvs}. It is fine to discuss @sc{cvs} bugs on +whatever forum you prefer, but there are not +necessarily any maintainers reading bug reports sent +anywhere except @code{bug-cvs}. +@end itemize + +@cindex Known bugs in this manual or CVS +People often ask if there is a list of known bugs or +whether a particular bug is a known one. The file +@sc{bugs} in the @sc{cvs} source distribution is one +list of known bugs, but it doesn't necessarily try to +be comprehensive. Perhaps there will never be a +comprehensive, detailed list of known bugs. + +@c --------------------------------------------------------------------- @node Copying @appendix GNU GENERAL PUBLIC LICENSE @center Version 2, June 1991 diff --git a/contrib/cvs/doc/cvsclient.texi b/contrib/cvs/doc/cvsclient.texi index d0aac35..f81ff92 100644 --- a/contrib/cvs/doc/cvsclient.texi +++ b/contrib/cvs/doc/cvsclient.texi @@ -15,9 +15,10 @@ means. @menu * Introduction:: What is CVS and what is the client/server protocol for? * Goals:: Basic design decisions, requirements, scope, etc. -* Protocol Notes:: Possible enhancements, limitations, etc. of the protocol * Connection and Authentication:: Various ways to connect to the server +* Password scrambling:: Scrambling used by pserver * Protocol:: Complete description of the protocol +* Protocol Notes:: Possible enhancements, limitations, etc. of the protocol @end menu @node Introduction @@ -111,80 +112,19 @@ current @sc{cvs} server) will make sure that it does not have any such locks in place whenever it is waiting for communication with the client; this prevents one client on a slow or flaky network from interfering with the work of others. -@end itemize - -@node Protocol Notes -@chapter Notes on the Protocol -A number of enhancements are possible: - -@itemize @bullet @item -The @code{Modified} request could be speeded up by sending diffs rather -than entire files. The client would need some way to keep the version -of the file which was originally checked out; probably requiring the use -of "cvs edit" in this case is the most sensible course (the "cvs edit" -could be handled by a package like VC for emacs). This would also allow -local operation of @code{cvs diff} without arguments. - -@item -Have the client keep a copy of some part of the repository. This allows -all of @code{cvs diff} and large parts of @code{cvs update} and -@code{cvs ci} to be local. The local copy could be made consistent with -the master copy at night (but if the master copy has been updated since -the latest nightly re-sync, then it would read what it needs to from the -master). - -It isn't clear exactly how this should relate to a more general -multisite feature (in which one can modify the local copy even if the -network is down between the local and the master, and then they get -reconciled by a potentially manual process). Another variant of a -multisite feature would be where version history is cached to speed up -operations such as @code{cvs diff}, but in which checkins still must be -checked in to all sites, or to a master site. - -@item -The current procedure for @code{cvs update} is highly sub-optimal if -there are many modified files. One possible alternative would be to -have the client send a first request without the contents of every -modified file, then have the server tell it what files it needs. Note -the server needs to do the what-needs-to-be-updated check twice (or -more, if changes in the repository mean it has to ask the client for -more files), because it can't keep locks open while waiting for the -network. Perhaps this whole thing is irrelevant if client-side -repositories are implemented, and the rcsmerge is done by the client. - -@item -The fact that @code{pserver} requires an extra network turnaround in -order to perform authentication would be nice to avoid. This relates to -the issue of reporting errors; probably the clean solution is to defer -the error until the client has issued a request which expects a -response. To some extent this might relate to the next item (in terms -of how easy it is to skip a whole bunch of requests until we get to one -that expects a response). I know that the kerberos code doesn't wait in -this fashion, but that probably can cause network deadlocks and perhaps -future problems running over a transport which is more transaction -oriented than TCP. On the other hand I'm not sure it is wise to make -the client conduct a lengthy upload only to find there is an -authentication failure. - -@item -The protocol uses an extra network turnaround for protocol negotiation -(@code{valid-requests}). It might be nice to avoid this by having the -client be able to send requests and tell the server to ignore them if -they are unrecognized (different requests could produce a fatal error if -unrecognized). To do this there should be a standard syntax for -requests. For example, perhaps all future requests should be a single -line, with mechanisms analogous to @code{Argumentx}, or several requests -working together, to provide greater amounts of information. Or there -might be a standard mechanism for counted data (analogous to that used -by @code{Modified}) or continuation lines (like a generalized -@code{Argumentx}). It would be useful to compare what HTTP is planning -in this area; last I looked they were contemplating something called -Protocol Extension Protocol but I haven't looked at the relevant IETF -documents in any detail. Obviously, we want something as simple as -possible (but no simpler). - +It is a general design goal to provide only one way to do a given +operation (where possible). For example, implementations have no choice +about whether to terminate lines with linefeeds or some other +character(s), and request and response names are case-sensitive. This +is to enhance interoperability. If a protocol allows more than one way +to do something, it is all too easy for some implementations to support +only some of them (perhaps accidentally). +@c I vaguely remember reading, probably in an RFC, about the problems +@c that were caused when some people decided that SMTP should accept +@c other line termination (in the message ("DATA")?) than CRLF. However, I +@c can't seem to track down the reference. @end itemize @node Connection and Authentication @@ -209,60 +149,191 @@ by having inetd call "cvs kserver") which defaults to 1999. The client connects, sends the usual kerberos authentication information, and then starts the cvs protocol. Note: port 1999 is officially registered for another use, and in any event one cannot register more than one port for -CVS, so the kerberized client and server should be changed to use port -2401 (see below), and send a different string in place of @samp{BEGIN -AUTH REQUEST} to identify the authentication method in use. However, -noone has yet gotten around to implementing this. +CVS, so GSS-API (see below) is recommended instead of kserver as a way +to support kerberos. @item pserver -The password authenticated server listens on a port (in the current +The name @dfn{pserver} is somewhat confusing. It refers to both a +generic framework which allows the CVS protocol to support several +authentication mechanisms, and a name for a specific mechanism which +transfers a username and a cleartext password. Servers need not support +all mechanisms, and in fact servers will typically want to support only +those mechanisms which meet the relevant security needs. + +The pserver server listens on a port (in the current implementation, by having inetd call "cvs pserver") which defaults to 2401 (this port is officially registered). The client -connects, sends the string @samp{BEGIN AUTH REQUEST}, a linefeed, the -cvs root, a linefeed, the username, a linefeed, the password trivially -encoded (see scramble.c in the cvs sources), a linefeed, the string -@samp{END AUTH REQUEST}, and a linefeed. The client must send the +connects, and sends the following: + +@itemize @bullet +@item +the string @samp{BEGIN AUTH REQUEST}, a linefeed, +@item +the cvs root, a linefeed, +@item +the username, a linefeed, +@item +the password trivially encoded (see @ref{Password scrambling}), a +linefeed, +@item +the string @samp{END AUTH REQUEST}, and a linefeed. +@end itemize + +The client must send the identical string for cvs root both here and later in the @code{Root} request of the cvs protocol itself. Servers are encouraged to enforce this restriction. -The server responds with -@samp{I LOVE YOU} and a linefeed if the authentication is successful or -@samp{I HATE YOU} and a linefeed if the authentication fails. After -receiving @samp{I LOVE YOU}, the client proceeds with the cvs protocol. +The possible server responses (each of which is followed by a linefeed) +are the following. Note that although there is a small similarity +between this authentication protocol and the cvs protocol, they are +separate. + +@table @code +@item I LOVE YOU +The authentication is successful. The client proceeds with the cvs +protocol itself. + +@item I HATE YOU +The authentication fails. After sending this response, the server may +close the connection. It is up to the server to decide whether to give +this response, which is generic, or a more specific response using +@samp{E} and/or @samp{error}. + +@item E @var{text} +Provide a message for the user. After this reponse, the authentication +protocol continues with another response. Typically the server will +provide a series of @samp{E} responses followed by @samp{error}. +Compatibility note: @sc{cvs} 1.9.10 and older clients will print +@code{unrecognized auth response} and @var{text}, and then exit, upon +receiving this response. + +@item error @var{code} @var{text} +The authentication fails. After sending this response, the server may +close the connection. The @var{code} is a code describing why it +failed, intended for computer consumption. The only code currently +defined is @samp{0} which is nonspecific, but clients must silently +treat any unrecognized codes as nonspecific. +The @var{text} should be supplied to the +user. Compatibility note: @sc{cvs} 1.9.10 and older clients will print +@code{unrecognized auth response} and @var{text}, and then exit, upon +receiving this response. +@end table + +@c If you are thinking of putting samp or code around BEGIN AUTH REQUEST +@c and friends, watch for overfull hboxes. If the client wishes to merely authenticate without starting the cvs -protocol, the procedure is the same, except @samp{BEGIN AUTH REQUEST} is -replaced with @samp{BEGIN VERIFICATION REQUEST}, @samp{END AUTH REQUEST} -is replaced with @samp{END VERIFICATION REQUEST}, and upon receipt of -@samp{I LOVE YOU} the connection is closed rather than continuing. +protocol, the procedure is the same, except BEGIN AUTH REQUEST is +replaced with BEGIN VERIFICATION REQUEST, END AUTH REQUEST +is replaced with END VERIFICATION REQUEST, and upon receipt of +I LOVE YOU the connection is closed rather than continuing. + +Another mechanism is GSSAPI authentication. GSSAPI is a +generic interface to security services such as kerberos. GSSAPI is +specified in RFC2078 (GSSAPI version 2) and RFC1508 (GSSAPI version 1); +we are not aware of differences between the two which affect the +protocol in incompatible ways, so we make no attempt to specify one +version or the other. +The procedure here is to start with @samp{BEGIN +GSSAPI REQUEST}. GSSAPI authentication information is then exchanged +between the client and the server. Each packet of information consists +of a two byte big endian length, followed by that many bytes of data. +After the GSSAPI authentication is complete, the server continues with +the responses described above (@samp{I LOVE YOU}, etc.). @item future possibilities There are a nearly unlimited number of ways to connect and authenticate. One might want to allow access based on IP address (similar to the usual rsh protocol but with different/no restrictions on ports < 1024), to -adopt mechanisms such as the General Security Service (GSS) API or -Pluggable Authentication Modules (PAM), to allow users to run their own -servers under their own usernames without root access, or any number of -other possibilities. The way to add future mechanisms, for the most -part, should be to continue to use port 2401, but to use different -strings in place of @samp{BEGIN AUTH REQUEST}. +adopt mechanisms such as Pluggable Authentication Modules (PAM), to +allow users to run their own servers under their own usernames without +root access, or any number of other possibilities. The way to add +future mechanisms, for the most part, should be to continue to use port +2401, but to use different strings in place of @samp{BEGIN AUTH +REQUEST}. @end table +@node Password scrambling +@chapter Password scrambling algorithm + +The pserver authentication protocol, as described in @ref{Connection and +Authentication}, trivially encodes the passwords. This is only to +prevent inadvertent compromise; it provides no protection against even a +relatively unsophisticated attacker. For comparison, HTTP Basic +Authentication (as described in RFC2068) uses BASE64 for a similar +purpose. CVS uses its own algorithm, described here. + +The scrambled password starts with @samp{A}, which serves to identify +the scrambling algorithm in use. After that follows a single octet for +each character in the password, according to a fixed encoding. The +values are shown here, with the encoded values in decimal. Control +characters, space, and characters outside the invariant ISO 646 +character set are not shown; such characters are not recommended for use +in passwords. There is a long discussion of character set issues in +@ref{Protocol Notes}. + +@example + 0 111 P 125 p 58 +! 120 1 52 A 57 Q 55 a 121 q 113 +" 53 2 75 B 83 R 54 b 117 r 32 + 3 119 C 43 S 66 c 104 s 90 + 4 49 D 46 T 124 d 101 t 44 +% 109 5 34 E 102 U 126 e 100 u 98 +& 72 6 82 F 40 V 59 f 69 v 60 +' 108 7 81 G 89 W 47 g 73 w 51 +( 70 8 95 H 38 X 92 h 99 x 33 +) 64 9 65 I 103 Y 71 i 63 y 97 +* 76 : 112 J 45 Z 115 j 94 z 62 ++ 67 ; 86 K 50 k 93 +, 116 < 118 L 42 l 39 +- 74 = 110 M 123 m 37 +. 68 > 122 N 91 n 61 +/ 87 ? 105 O 35 _ 56 o 48 +@end example + @node Protocol @chapter The CVS client/server protocol -In the following, @samp{\n} refers to a linefeed and @samp{\t} refers -to a horizontal tab. - +In the following, @samp{\n} refers to a linefeed and @samp{\t} refers to +a horizontal tab; @dfn{requests} are what the client sends and +@dfn{responses} are what the server sends. In general, the connection is +governed by the client---the server does not send responses without +first receiving requests to do so; see @ref{Response intro} for more +details of this convention. + +It is typical, early in the connection, for the client to transmit a +@code{Valid-responses} request, containing all the responses it +supports, followed by a @code{valid-requests} request, which elicits +from the server a @code{Valid-requests} response containing all the +requests it understands. In this way, the client and server each find +out what the other supports before exchanging large amounts of data +(such as file contents). + +@c Hmm, having 3 sections in this menu makes a certain amount of sense +@c but that structure gets lots in the printed manual (not sure about +@c HTML). Perhaps there is a better way. @menu -* Entries Lines:: -* Modes:: + +General protocol conventions: + +* Entries Lines:: Transmitting RCS data +* File Modes:: Read, write, execute, and possibly more... * Filenames:: Conventions regarding filenames * File transmissions:: How file contents are transmitted * Strings:: Strings in various requests and responses -* Requests:: -* Responses:: -* Example:: -* Requirements:: + +The protocol itself: + +* Request intro:: General conventions relating to requests +* Requests:: List of requests +* Response intro:: General conventions relating to responses +* Response pathnames:: The "pathname" in responses +* Responses:: List of responses +* Text tags:: More details about the MT response + +An example session, and some further observations: + +* Example:: A conversation between client and server +* Requirements:: Things not to omit from an implementation * Obsolete:: Former protocol features @end menu @@ -290,8 +361,16 @@ conflicts in it. The rest of @var{conflict} is @samp{=} if the timestamp matches the file, or anything else if it doesn't. If @var{conflict} does not start with a @samp{+}, it is silently ignored. -@node Modes -@section Modes +@var{options} signifies the keyword expansion options (for example +@samp{-ko}). In an @code{Entry} request, this indicates the options +that were specified with the file from the previous file updating +response (@pxref{Response intro}, for a list of file updating +responses); if the client is specifying the @samp{-k} or @samp{-A} +option to @code{update}, then it is the server which figures out what +overrides what. + +@node File Modes +@section File Modes A mode is any number of repetitions of @@ -389,8 +468,8 @@ existing practice is probably to just transmit whatever the user specifies, and hope that everyone involved agrees which character set is in use, or sticks to a common subset. -@node Requests -@section Requests +@node Request intro +@section Request intro By convention, requests which begin with a capital letter do not elicit a response from the server, while all others do -- save one. The @@ -398,6 +477,11 @@ exception is @samp{gzip-file-contents}. Unrecognized requests will always elicit a response from the server, even if that request begins with a capital letter. +@node Requests +@section Requests + +Here are the requests: + @table @code @item Root @var{pathname} \n Response expected: no. Tell the server which @code{CVSROOT} to use. @@ -408,6 +492,10 @@ already exist; if creating a new root, use the @code{init} request, not server, how to access the server, etc.; by the time the CVS protocol is in use, connection, authentication, etc., are already taken care of. +The @code{Root} request must be sent only once, and it must be sent +before any requests other than @code{Valid-responses}, +@code{valid-requests}, @code{UseUnchanged}, or @code{init}. + @item Valid-responses @var{request-list} \n Response expected: no. Tell the server what responses the client will accept. @@ -426,8 +514,7 @@ also for @code{ci} and the other commands; normal usage is to send @code{Directory} for each directory in which there will be an @code{Entry} or @code{Modified}, and then a final @code{Directory} for the original directory, then the command. -If the client uses this request, it affects the way the server returns -pathnames; see @ref{Responses}. @var{local-directory} is relative to +The @var{local-directory} is relative to the top level at which the command is occurring (i.e. the last @code{Directory} which is sent before the command); to indicate that top level, @samp{.} should be send for @@ -549,6 +636,15 @@ sent for the same file, @code{Entry} must be sent first. For a given file, one can send @code{Modified}, @code{Is-modified}, or @code{Unchanged}, but not more than one of these three. +@item Kopt @var{option} \n +This indicates to the server which keyword expansion options to use for +the file specified by the next @code{Modified} or @code{Is-modified} +request (for example @samp{-kb} for a binary file). This is similar to +@code{Entry}, but is used for a file for which there is no entries line. +Typically this will be a file being added via an @code{add} or +@code{import} request. The client may not send both @code{Kopt} and +@code{Entry} for the same file. + @item Modified @var{filename} \n Response expected: no. Additional data: mode, \n, file transmission. Send the server a copy of one locally modified file. @var{filename} is @@ -703,6 +799,38 @@ the client and server encrypt the compressed data, as opposed to compressing the encrypted data. Encrypted data is generally incompressible. +Note that this request does not fully prevent an attacker from hijacking +the connection, in the sense that it does not prevent hijacking the +connection between the initial authentication and the +@code{Kerberos-encrypt} request. + +@item Gssapi-encrypt \n +Response expected: no. +Use GSSAPI encryption to encrypt all further communication between the +client and the server. This will only work if the connection was made +over GSSAPI in the first place. See @code{Kerberos-encrypt}, above, for +the relation between @code{Gssapi-encrypt} and @code{Gzip-stream}. + +Note that this request does not fully prevent an attacker from hijacking +the connection, in the sense that it does not prevent hijacking the +connection between the initial authentication and the +@code{Gssapi-encrypt} request. + +@item Gssapi-authenticate \n +Response expected: no. +Use GSSAPI authentication to authenticate all further communication +between the client and the server. This will only work if the +connection was made over GSSAPI in the first place. Encrypted data is +automatically authenticated, so using both @code{Gssapi-authenticate} +and @code{Gssapi-encrypt} has no effect beyond that of +@code{Gssapi-encrypt}. Unlike encrypted data, it is reasonable to +compress authenticated data. + +Note that this request does not fully prevent an attacker from hijacking +the connection, in the sense that it does not prevent hijacking the +connection between the initial authentication and the +@code{Gssapi-authenticate} request. + @item Set @var{variable}=@var{value} \n Response expected: no. Set a user variable @var{variable} to @var{value}. @@ -766,7 +894,6 @@ directory. @itemx log \n @itemx remove \n @itemx admin \n -@itemx export \n @itemx history \n @itemx watchers \n @itemx editors \n @@ -788,6 +915,19 @@ correspond to except by (1) just sending the @code{co} request, and then seeing what directory names the server sends back in its responses, and (2) the @code{expand-modules} request. +@item export \n +Response expected: yes. Get files from the repository. This uses any +previous @code{Argument}, @code{Directory}, @code{Entry}, or +@code{Modified} requests, if they have been sent. Arguments to this +command are module names, as described for the @code{co} request. The +intention behind this command is that a client can get sources from a +server without storing CVS information about those sources. That is, a +client probably should not count on being able to take the entries line +returned in the @code{Created} response from an @code{export} request +and send it in a future @code{Entry} request. Note that the entries +line in the @code{Created} response must indicate whether the file is +binary or text, so the client can create it correctly. + @item rdiff \n @itemx rtag \n Response expected: yes. Actually do a cvs command. This uses any @@ -882,17 +1022,17 @@ to perform a few more checks. The client sends a subsequent @code{ci} to actually add the file to the repository. -Another quirk of the @code{add} request is that a pathname specified in +Another quirk of the @code{add} request is that with CVS 1.9 and older, +a pathname specified in an @code{Argument} request cannot contain @samp{/}. There is no good -reason for this restriction, and it could be eliminated if someone took -the effort to rewrite the @code{add} code in the CVS server to not have -it. But in the meantime, the way to comply with it is to ensure that +reason for this restriction, and in fact more recent CVS servers don't +have it. +But the way to interoperate with the older servers is to ensure that all @code{Directory} requests for @code{add} (except those used to add directories, as described above), use @samp{.} for @var{local-directory}. Specifying another string for @var{local-directory} may not get an error, but it will get you strange -@code{Checked-in} responses, until servers are fixed to send the correct -responses. +@code{Checked-in} responses from the buggy servers. @item watch-on \n @itemx watch-off \n @@ -951,8 +1091,8 @@ a previous command which doesn't expect a response produced an error. When the client is done, it drops the connection. -@node Responses -@section Responses +@node Response intro +@section Introduction to Responses After a command which expects a response, the server sends however many of the following responses are appropriate. The server should not send @@ -960,9 +1100,31 @@ data at other times (the current implementation may violate this principle in a few minor places, where the server is printing an error message and exiting---this should be investigated further). +Any set of responses always ends with @samp{error} or @samp{ok}. This +indicates that the response is over. + +@c "file updating response" and "file update modifying response" are +@c lame terms (mostly because they are so awkward). Any better ideas? +The responses @code{Checked-in}, @code{New-entry}, @code{Updated}, +@code{Created}, @code{Update-existing}, @code{Merged}, and +@code{Patched} are refered to as @dfn{file updating} responses, because +they change the status of a file in the working directory in some way. +The responses @code{Mode}, @code{Mod-time}, and @code{Checksum} are +referred to as @dfn{file update modifying} responses because they modify +the next file updating response. In no case shall a file update +modifying response apply to a file updating response other than the next +one. Nor can the same file update modifying response occur twice for +a given file updating response (if servers diagnose this problem, it may +aid in detecting the case where clients send an update modifying +response without following it by a file updating response). + +@node Response pathnames +@section The "pathname" in responses + +Many of the responses contain something called @var{pathname}. @c FIXME: should better document when the specified repository needs to @c end in "/.". -In the following, @var{pathname} actually indicates a pair of +The name is somewhat misleading; it actually indicates a pair of pathnames. First, a local directory name relative to the directory in which the command was given (i.e. the last @code{Directory} before the command). Then a linefeed and a repository @@ -1001,8 +1163,10 @@ greatly by only telling the client to create directories if the directory in question should exist, but until servers do this, clients will need to offer the @samp{-P} behavior described above. -Any response always ends with @samp{error} or @samp{ok}. This indicates -that the response is over. +@node Responses +@section Responses + +Here are the responses: @table @code @item Valid-requests @var{request-list} \n @@ -1096,13 +1260,14 @@ only support @code{Patched}. @item Mode @var{mode} \n This @var{mode} applies to the next file mentioned in -@code{Checked-in}. It does not apply to any request which follows a -@code{Checked-in}, @code{New-entry}, @code{Updated}, @code{Merged}, or -@code{Patched} response. +@code{Checked-in}. @code{Mode} is a file update modifying response +as described in @ref{Response intro}. @item Mod-time @var{time} \n -Set the modification time of the next file sent to @var{time}. Next -file sent means sent by @code{Checked-in}, @code{Created}, etc. The +Set the modification time of the next file sent to @var{time}. +@code{Mod-time} is a file update modifying response +as described in @ref{Response intro}. +The @var{time} is in the format specified by RFC822 as modified by RFC1123. The server may specify any timezone it chooses; clients will want to convert that to their own timezone as appropriate. An example of this @@ -1118,13 +1283,16 @@ synchronized. The server just sends its recommendation for a timestamp it (this means that the time might be in the future, for example). @item Checksum @var{checksum}\n -The @var{checksum} applies to the next file sent over via -@code{Updated}, @code{Merged}, or @code{Patched}. In the case of +The @var{checksum} applies to the next file sent (that is, +@code{Checksum} is a file update modifying response +as described in @ref{Response intro}). +In the case of @code{Patched}, the checksum applies to the file after being patched, not to the patch itself. The client should compute the checksum itself, after receiving the file or patch, and signal an error if the checksums do not match. The checksum is the 128 bit MD5 checksum represented as -32 hex digits. This response is optional, and is only used if the +32 hex digits (MD5 is described in RFC1321). +This response is optional, and is only used if the client supports it (as judged by the @code{Valid-responses} request). @item Copy-file @var{pathname} \n @@ -1194,7 +1362,8 @@ request; if there are several @code{Notify} requests for a single file, the requests should be processed in order; the first @code{Notified} response pertains to the first @code{Notify} request, etc. -@item Module-expansion @var{pathname} \n Return a file or directory +@item Module-expansion @var{pathname} \n +Return a file or directory which is included in a particular module. @var{pathname} is relative to cvsroot, unlike most pathnames in responses. @var{pathname} should be used to look and see whether some or all of the module exists on @@ -1206,6 +1375,13 @@ contains the @samp{-d} option, it will be the directory specified with @item M @var{text} \n A one-line message for the user. +@item Mbinary \n +Additional data: file transmission (note: compressed file transmissions +are not supported). This is like @samp{M}, except the contents of the +file transmission are binary and should be copied to standard output +without translation to local text file conventions. To transmit a text +file to standard output, servers should use a series of @samp{M} requests. + @item E @var{text} \n Same as @code{M} but send to stderr not stdout. @@ -1217,6 +1393,77 @@ Flush stderr. That is, make it possible for the user to see what has been written to stderr (it is up to the implementation to decide exactly how far it should go to ensure this). +@item MT @var{tagname} @var{data} \n + +This response provides for tagged text. It is similar to +SGML/HTML/XML in that the data is structured and a naive application +can also make some sense of it without understanding the structure. +The syntax is not SGML-like, however, in order to fit into the CVS +protocol better and (more importantly) to make it easier to parse, +especially in a language like perl or awk. + +The @var{tagname} can have several forms. If it starts with @samp{a} +to @samp{z} or @samp{A} to @samp{Z}, then it represents tagged text. +If the implementation recognizes @var{tagname}, then it may interpret +@var{data} in some particular fashion. If the implementation does not +recognize @var{tagname}, then it should simply treat @var{data} as +text to be sent to the user (similar to an @samp{M} response). There +are two tags which are general purpose. The @samp{text} tag is +similar to an unrecognized tag in that it provides text which will +ordinarily be sent to the user. The @samp{newline} tag is used +without @var{data} and indicates that a newline will ordinarily be +sent to the user (there is no provision for embedding newlines in the +@var{data} of other tagged text responses). + +If @var{tagname} starts with @samp{+} it indicates a start tag and if +it starts with @samp{-} it indicates an end tag. The remainder of +@var{tagname} should be the same for matching start and end tags, and +tags should be nested (for example one could have tags in the +following order @code{+bold} @code{+italic} @code{text} @code{-italic} +@code{-bold} but not @code{+bold} @code{+italic} @code{text} +@code{-bold} @code{-italic}). A particular start and end tag may be +documented to constrain the tagged text responses which are valid +between them. + +Note that if @var{data} is present there will always be exactly one +space between @var{tagname} and @var{data}; if there is more than one +space, then the spaces beyond the first are part of @var{data}. + +Here is an example of some tagged text responses. Note that there is +a trailing space after @samp{Checking in} and @samp{initial revision:} +and there are two trailing spaces after @samp{<--}. Such trailing +spaces are, of course, part of @var{data}. + +@example +MT +checking-in +MT text Checking in +MT fname gz.tst +MT text ; +MT newline +MT rcsfile /home/kingdon/zwork/cvsroot/foo/gz.tst,v +MT text <-- +MT fname gz.tst +MT newline +MT text initial revision: +MT init-rev 1.1 +MT newline +MT text done +MT newline +MT -checking-in +@end example + +If the client does not support the @samp{MT} response, the same +responses might be sent as: + +@example +M Checking in gz.tst; +M /home/kingdon/zwork/cvsroot/foo/gz.tst,v <-- gz.tst +M initial revision: 1.1 +M done +@end example + +For a list of specific tags, see @ref{Text tags}. + @item error @var{errno-code} @samp{ } @var{text} \n The command completed with an error. @var{errno-code} is a symbolic error code (e.g. @code{ENOENT}); if the server doesn't support this @@ -1229,6 +1476,35 @@ strerror(), or any other message the server wants to use. The command completed successfully. @end table +@node Text tags +@section Tags for the MT tagged text response + +The @code{MT} response, as described in @ref{Responses}, offers a +way for the server to send tagged text to the client. This section +describes specific tags. The intention is to update this section as +servers add new tags. + +In the following descriptions, @code{text} and @code{newline} tags are +omitted. Such tags contain information which is intended for users (or +to be discarded), and are subject to change at the whim of the server. +To avoid being vulnerable to such whim, clients should look for the tags +listed here, not @code{text}, @code{newline}, or other tags. + +The following tag means to indicate to the user that a file has been +updated. It is more or less redundant with the @code{Created} and +@code{Update-existing} responses, but we don't try to specify here +whether it occurs in exactly the same circumstances as @code{Created} +and @code{Update-existing}. The @var{name} is the pathname of the file +being updated relative to the directory in which the command is +occurring (that is, the last @code{Directory} request which is sent +before the command). + +@example +MT +updated +MT fname @var{name} +MT -updated +@end example + @node Example @section Example @@ -1236,9 +1512,9 @@ The command completed successfully. @c other RFC's). In other formatting concerns, we might want to think @c about whether there is an easy way to provide RFC1543 formatting @c (without negating the advantages of texinfo), and whether we should -@c use RFC822-style BNF (I fear that would be less clear than -@c what we do now, however). Plus what about IETF terminology (SHOULD, -@c MUST, etc.) or ISO terminology (shall, should, or whatever they are)? +@c use RFC2234 BNF (I fear that would be less clear than +@c what we do now, however). Plus what about RFC2119 terminology (MUST, +@c SHOULD, &c) or ISO terminology (shall, should, or whatever they are)? Here is an example; lines are prefixed by @samp{C: } to indicate the client sends them or @samp{S: } to indicate the server sends them. @@ -1410,4 +1686,102 @@ working directory, and the meaning of sending @code{Entries} without @code{Lost} or @code{Modified} was different. All current clients (CVS 1.5 and later) will send @code{UseUnchanged} if it is supported. +@node Protocol Notes +@chapter Notes on the Protocol + +A number of enhancements are possible. Also see the file @sc{todo} in +the @sc{cvs} source distribution, which has further ideas concerning +various aspects of @sc{cvs}, some of which impact the protocol. + +@itemize @bullet +@item +The @code{Modified} request could be speeded up by sending diffs rather +than entire files. The client would need some way to keep the version +of the file which was originally checked out; probably requiring the use +of "cvs edit" in this case is the most sensible course (the "cvs edit" +could be handled by a package like VC for emacs). This would also allow +local operation of @code{cvs diff} without arguments. + +@item +The current procedure for @code{cvs update} is highly sub-optimal if +there are many modified files. One possible alternative would be to +have the client send a first request without the contents of every +modified file, then have the server tell it what files it needs. Note +the server needs to do the what-needs-to-be-updated check twice (or +more, if changes in the repository mean it has to ask the client for +more files), because it can't keep locks open while waiting for the +network. Perhaps this whole thing is irrelevant if there is a multisite +capability (as noted in @sc{todo}), and therefore the rcsmerge can be +done with a repository which is connected via a fast connection. + +@item +The fact that @code{pserver} requires an extra network turnaround in +order to perform authentication would be nice to avoid. This relates to +the issue of reporting errors; probably the clean solution is to defer +the error until the client has issued a request which expects a +response. To some extent this might relate to the next item (in terms +of how easy it is to skip a whole bunch of requests until we get to one +that expects a response). I know that the kerberos code doesn't wait in +this fashion, but that probably can cause network deadlocks and perhaps +future problems running over a transport which is more transaction +oriented than TCP. On the other hand I'm not sure it is wise to make +the client conduct a lengthy upload only to find there is an +authentication failure. + +@item +The protocol uses an extra network turnaround for protocol negotiation +(@code{valid-requests}). It might be nice to avoid this by having the +client be able to send requests and tell the server to ignore them if +they are unrecognized (different requests could produce a fatal error if +unrecognized). To do this there should be a standard syntax for +requests. For example, perhaps all future requests should be a single +line, with mechanisms analogous to @code{Argumentx}, or several requests +working together, to provide greater amounts of information. Or there +might be a standard mechanism for counted data (analogous to that used +by @code{Modified}) or continuation lines (like a generalized +@code{Argumentx}). It would be useful to compare what HTTP is planning +in this area; last I looked they were contemplating something called +Protocol Extension Protocol but I haven't looked at the relevant IETF +documents in any detail. Obviously, we want something as simple as +possible (but no simpler). + +@item +The scrambling algorithm in the CVS client and server actually support +more characters than those documented in @ref{Password scrambling}. +Someday we are going to either have to document them all (but this is +not as easy as it may look, see below), or (gradually and with adequate +process) phase out the support for other characters in the CVS +implementation. This business of having the feature partly undocumented +isn't a desirable state long-term. + +The problem with documenting other characters is that unless we know +what character set is in use, there is no way to make a password +portable from one system to another. For example, a with a circle on +top might have different encodings in different character sets. + +It @emph{almost} works to say that the client picks an arbitrary, +unknown character set (indeed, having the CVS client know what character +set the user has in mind is a hard problem otherwise), and scrambles +according to a certain octet<->octet mapping. There are two problems +with this. One is that the protocol has no way to transmit character 10 +decimal (linefeed), and the current server and clients have no way to +handle 0 decimal (NUL). This may cause problems with certain multibyte +character sets, in which octets 10 and 0 will appear in the middle of +other characters. The other problem, which is more minor and possibly +not worth worrying about, is that someone can type a password on one +system and then go to another system which uses a different encoding for +the same characters, and have their password not work. + +The restriction to the ISO646 invariant subset is the best approach for +strings which are not particularly significant to users. Passwords are +visible enough that this is somewhat doubtful as applied here. ISO646 +does, however, have the virtue (!?) of offending everyone. It is easy +to say "But the $ is right on people's keyboards! Surely we can't +forbid that". From a human factors point of view, that makes quite a +bit of sense. The contrary argument, of course, is that a with a circle +on top, or some of the characters poorly handled by Unicode, are on +@emph{someone}'s keyboard. + +@end itemize + @bye diff --git a/contrib/cvs/lib/ChangeLog b/contrib/cvs/lib/ChangeLog index 02a0e1f..3d858ab 100644 --- a/contrib/cvs/lib/ChangeLog +++ b/contrib/cvs/lib/ChangeLog @@ -1,3 +1,77 @@ +13 Jan 1998 Jim Kingdon + + * fncase.c: Include config.h before system.h. + + * system.h: Just include string.h unconditionally. We already + include it unconditionally elsewhere. + +Tue Jan 13 16:51:59 1998 Ian Lance Taylor <ian@cygnus.com> + + * fncase.c: New file, taken from windows-NT/filesubr.c. + * system.h: If __CYGWIN32__ or WIN32 are defined, define + FOLD_FN_CHAR, FILENAMES_CASE_INSENSITIVE, and ISDIRSEP, and + declare fncmp and fnfold. Taken from windows-NT/config.h. + * Makefile.in (SOURCES): Add fncase.c. + +Sat Jan 10 10:51:26 1998 Jim Kingdon <kingdon@harvey.cyclic.com> + + * getline.c (getstr): Make sure to set errno when appropriate. I + didn't test the error case for the new code but inspection shows + the old code was rather broken. + +Sat Nov 29 22:03:39 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + getwd and getcwd were a big big mess. Although Jim's fix might + indeed be fixing a typo, the code is so tangled that I would guess + it probably breaks some system. So clean this up: + * xgetwd.c: Always assume we have getcwd (we had been anyway, + before Jim's change). + * getwd.c: Removed. + * Makefile.in: Remove getwd.c + * system.h: Remove declarations of getwd and getcwd. Move getcwd + declaration to the !HAVE_UNISTD_H section. + +1997-11-29 Jim Meyering <meyering@na-net.ornl.gov> + + * xgetwd.c: Fix typo s/ifndef/ifdef/ in test of HAVE_GETWD. + +Wed Nov 26 10:12:33 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * system.h: Always use "rb" and "wb". Check for O_BINARY with an + #ifdef, not the error-prone LINES_CRLF_TERMINATED. + +Thu Sep 25 10:57:39 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * getdate.y (get_date): If gmtime returns NULL, try to cope. + * getdate.c: Regenerated using byacc. + + * getdate.y: Remove comment about sending email concerning this file + to Rich Salz. + * getdate.c: Regenerated using byacc. + +Wed Sep 24 10:35:38 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * Makefile.in (OBJECTS): Add regex.o. + +Wed Sep 17 16:37:17 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * getdate.y (ToSeconds): For am or pm, a hour of "12" really means 0. + * getdate.c: Regenerated using byacc (not bison per comment). + +Tue Sep 9 20:51:45 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * build_lib.com: Add vasprintf.c and vasprintf.obj. + + * build_lib.com: Remove strippath.obj from library/create command. + +Sun Sep 7 17:35:27 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * system.h: Replace comment referring to ChangeLog with a + comment based on the ChangeLog entries. + + * strdup.c: Removed, per change to ../configure.in + * Makefile.in (SOURCES): Remove strdup.c. + Mon Jun 16 18:59:50 1997 Jim Kingdon <kingdon@harvey.cyclic.com> * system.h: Add CVS_FNMATCH. diff --git a/contrib/cvs/lib/Makefile.in b/contrib/cvs/lib/Makefile.in index 9645ae9..9c32d9f 100644 --- a/contrib/cvs/lib/Makefile.in +++ b/contrib/cvs/lib/Makefile.in @@ -25,6 +25,7 @@ exec_prefix = @exec_prefix@ SOURCES = \ argmatch.c \ dup2.c \ + fncase.c \ fnmatch.c \ ftruncate.c \ getdate.c \ @@ -32,7 +33,6 @@ SOURCES = \ getline.c \ getopt.c \ getopt1.c \ - getwd.c \ hostname.c \ md5.c \ mkdir.c \ @@ -40,7 +40,6 @@ SOURCES = \ rename.c \ savecwd.c \ sighandle.c \ - strdup.c \ strstr.c \ strerror.c \ stripslash.c \ @@ -53,6 +52,7 @@ SOURCES = \ HEADERS = getline.h getopt.h fnmatch.h regex.h system.h wait.h md5.h savecwd.h +# See long comment in ../configure.in concerning inclusion of regex.o. OBJECTS = \ @LIBOBJS@ \ argmatch.o \ @@ -60,6 +60,7 @@ OBJECTS = \ getopt.o \ getopt1.o \ md5.o \ + regex.o \ savecwd.o \ sighandle.o \ stripslash.o \ @@ -142,7 +143,6 @@ getdate.c: getdate.y fnmatch.o: fnmatch.h getopt1.o: getopt.h regex.o: regex.h -getwd.o: system.h md5.o: md5.h xlint: diff --git a/contrib/cvs/lib/fncase.c b/contrib/cvs/lib/fncase.c new file mode 100644 index 0000000..56e7f51 --- /dev/null +++ b/contrib/cvs/lib/fncase.c @@ -0,0 +1,115 @@ +/* fncase.c -- CVS support for case insensitive file systems. + Jim Blandy <jimb@cyclic.com> + + This file is part of GNU CVS. + + GNU CVS 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. */ + +#ifdef HAVE_CONFIG_H +#include "config.h" +#endif + +#include "system.h" + +/* The equivalence class mapping for filenames. + Windows NT filenames are case-insensitive, but case-preserving. + Both / and \ are path element separators. + Thus, this table maps both upper and lower case to lower case, and + both / and \ to /. */ + +#if 0 +main () +{ + int c; + + for (c = 0; c < 256; c++) + { + int t; + + if (c == '\\') + t = '/'; + else + t = tolower (c); + + if ((c & 0x7) == 0x0) + printf (" "); + printf ("0x%02x,", t); + if ((c & 0x7) == 0x7) + putchar ('\n'); + else if ((c & 0x7) == 0x3) + putchar (' '); + } +} +#endif + +unsigned char +WNT_filename_classes[] = +{ + 0x00,0x01,0x02,0x03, 0x04,0x05,0x06,0x07, + 0x08,0x09,0x0a,0x0b, 0x0c,0x0d,0x0e,0x0f, + 0x10,0x11,0x12,0x13, 0x14,0x15,0x16,0x17, + 0x18,0x19,0x1a,0x1b, 0x1c,0x1d,0x1e,0x1f, + 0x20,0x21,0x22,0x23, 0x24,0x25,0x26,0x27, + 0x28,0x29,0x2a,0x2b, 0x2c,0x2d,0x2e,0x2f, + 0x30,0x31,0x32,0x33, 0x34,0x35,0x36,0x37, + 0x38,0x39,0x3a,0x3b, 0x3c,0x3d,0x3e,0x3f, + 0x40,0x61,0x62,0x63, 0x64,0x65,0x66,0x67, + 0x68,0x69,0x6a,0x6b, 0x6c,0x6d,0x6e,0x6f, + 0x70,0x71,0x72,0x73, 0x74,0x75,0x76,0x77, + 0x78,0x79,0x7a,0x5b, 0x2f,0x5d,0x5e,0x5f, + 0x60,0x61,0x62,0x63, 0x64,0x65,0x66,0x67, + 0x68,0x69,0x6a,0x6b, 0x6c,0x6d,0x6e,0x6f, + 0x70,0x71,0x72,0x73, 0x74,0x75,0x76,0x77, + 0x78,0x79,0x7a,0x7b, 0x7c,0x7d,0x7e,0x7f, + 0x80,0x81,0x82,0x83, 0x84,0x85,0x86,0x87, + 0x88,0x89,0x8a,0x8b, 0x8c,0x8d,0x8e,0x8f, + 0x90,0x91,0x92,0x93, 0x94,0x95,0x96,0x97, + 0x98,0x99,0x9a,0x9b, 0x9c,0x9d,0x9e,0x9f, + 0xa0,0xa1,0xa2,0xa3, 0xa4,0xa5,0xa6,0xa7, + 0xa8,0xa9,0xaa,0xab, 0xac,0xad,0xae,0xaf, + 0xb0,0xb1,0xb2,0xb3, 0xb4,0xb5,0xb6,0xb7, + 0xb8,0xb9,0xba,0xbb, 0xbc,0xbd,0xbe,0xbf, + 0xc0,0xc1,0xc2,0xc3, 0xc4,0xc5,0xc6,0xc7, + 0xc8,0xc9,0xca,0xcb, 0xcc,0xcd,0xce,0xcf, + 0xd0,0xd1,0xd2,0xd3, 0xd4,0xd5,0xd6,0xd7, + 0xd8,0xd9,0xda,0xdb, 0xdc,0xdd,0xde,0xdf, + 0xe0,0xe1,0xe2,0xe3, 0xe4,0xe5,0xe6,0xe7, + 0xe8,0xe9,0xea,0xeb, 0xec,0xed,0xee,0xef, + 0xf0,0xf1,0xf2,0xf3, 0xf4,0xf5,0xf6,0xf7, + 0xf8,0xf9,0xfa,0xfb, 0xfc,0xfd,0xfe,0xff, +}; + +/* Like strcmp, but with the appropriate tweaks for file names. + Under Windows NT, filenames are case-insensitive but case-preserving, + and both \ and / are path element separators. */ +int +fncmp (const char *n1, const char *n2) +{ + while (*n1 && *n2 + && (WNT_filename_classes[(unsigned char) *n1] + == WNT_filename_classes[(unsigned char) *n2])) + n1++, n2++; + return (WNT_filename_classes[(unsigned char) *n1] + - WNT_filename_classes[(unsigned char) *n2]); +} + +/* Fold characters in FILENAME to their canonical forms. + If FOLD_FN_CHAR is not #defined, the system provides a default + definition for this. */ +void +fnfold (char *filename) +{ + while (*filename) + { + *filename = FOLD_FN_CHAR (*filename); + filename++; + } +} diff --git a/contrib/cvs/lib/getdate.y b/contrib/cvs/lib/getdate.y index 8ed565c..fdb177d 100644 --- a/contrib/cvs/lib/getdate.y +++ b/contrib/cvs/lib/getdate.y @@ -4,7 +4,6 @@ ** at the University of North Carolina at Chapel Hill. Later tweaked by ** a couple of people on Usenet. Completely overhauled by Rich $alz ** <rsalz@bbn.com> and Jim Berets <jberets@bbn.com> in August, 1990; -** send any email to Rich. ** ** This grammar has 10 shift/reduce conflicts. ** @@ -604,10 +603,14 @@ ToSeconds(Hours, Minutes, Seconds, Meridian) case MERam: if (Hours < 1 || Hours > 12) return -1; + if (Hours == 12) + Hours = 0; return (Hours * 60L + Minutes) * 60L + Seconds; case MERpm: if (Hours < 1 || Hours > 12) return -1; + if (Hours == 12) + Hours = 0; return ((Hours + 12) * 60L + Minutes) * 60L + Seconds; default: abort (); @@ -913,17 +916,34 @@ get_date(p, now) yyInput = p; if (now == NULL) { + struct tm *gmt_ptr; + now = &ftz; (void)time (&nowtime); - if (! (tm = gmtime (&nowtime))) - return -1; - gmt = *tm; /* Make a copy, in case localtime modifies *tm. */ + gmt_ptr = gmtime (&nowtime); + if (gmt_ptr != NULL) + { + /* Make a copy, in case localtime modifies *tm (I think + that comment now applies to *gmt_ptr, but I am too + lazy to dig into how gmtime and locatime allocate the + structures they return pointers to). */ + gmt = *gmt_ptr; + } if (! (tm = localtime (&nowtime))) return -1; - - ftz.timezone = difftm (&gmt, tm) / 60; + + if (gmt_ptr != NULL) + ftz.timezone = difftm (&gmt, tm) / 60; + else + /* We are on a system like VMS, where the system clock is + in local time and the system has no concept of timezones. + Hopefully we can fake this out (for the case in which the + user specifies no timezone) by just saying the timezone + is zero. */ + ftz.timezone = 0; + if(tm->tm_isdst) ftz.timezone += 60; } diff --git a/contrib/cvs/lib/getline.c b/contrib/cvs/lib/getline.c index 5f4fba6..5b63fc1 100644 --- a/contrib/cvs/lib/getline.c +++ b/contrib/cvs/lib/getline.c @@ -21,6 +21,7 @@ General Public License for more details. */ #include <sys/types.h> #include <stdio.h> #include <assert.h> +#include <errno.h> #if STDC_HEADERS #include <stdlib.h> @@ -35,7 +36,9 @@ char *malloc (), *realloc (); + OFFSET (and null-terminate it). *LINEPTR is a pointer returned from malloc (or NULL), pointing to *N characters of space. It is realloc'd as necessary. Return the number of characters read (not including the - null terminator), or -1 on error or EOF. */ + null terminator), or -1 on error or EOF. On a -1 return, the caller + should check feof(), if not then errno has been set to indicate + the error. */ int getstr (lineptr, n, stream, terminator, offset) @@ -50,14 +53,20 @@ getstr (lineptr, n, stream, terminator, offset) int ret; if (!lineptr || !n || !stream) - return -1; + { + errno = EINVAL; + return -1; + } if (!*lineptr) { *n = MIN_CHUNK; *lineptr = malloc (*n); if (!*lineptr) - return -1; + { + errno = ENOMEM; + return -1; + } } nchars_avail = *n - offset; @@ -65,8 +74,11 @@ getstr (lineptr, n, stream, terminator, offset) for (;;) { + int save_errno; register int c = getc (stream); + save_errno = errno; + /* We always want at least one char left in the buffer, since we always (unless we get an error while reading the first char) NUL-terminate the line buffer. */ @@ -82,12 +94,24 @@ getstr (lineptr, n, stream, terminator, offset) nchars_avail = *n + *lineptr - read_pos; *lineptr = realloc (*lineptr, *n); if (!*lineptr) - return -1; + { + errno = ENOMEM; + return -1; + } read_pos = *n - nchars_avail + *lineptr; assert((*lineptr + *n) == (read_pos + nchars_avail)); } - if (c == EOF || ferror (stream)) + if (ferror (stream)) + { + /* Might like to return partial line, but there is no + place for us to store errno. And we don't want to just + lose errno. */ + errno = save_errno; + return -1; + } + + if (c == EOF) { /* Return partial line, if any. */ if (read_pos == *lineptr) diff --git a/contrib/cvs/lib/system.h b/contrib/cvs/lib/system.h index 1a692ff..7648b76 100644 --- a/contrib/cvs/lib/system.h +++ b/contrib/cvs/lib/system.h @@ -27,8 +27,14 @@ #undef S_ISNWK #endif -/* Not all systems have S_IFMT, but we probably want to use it if we - do. See ChangeLog for a more detailed discussion. */ +/* Not all systems have S_IFMT, but we want to use it if we have it. + The S_IFMT code below looks right (it masks and compares). The + non-S_IFMT code looks bogus (are there really systems on which + S_IFBLK, S_IFLNK, &c, each have their own bit? I suspect it was + written for OS/2 using the IBM C/C++ Tools 2.01 compiler). + + Of course POSIX systems will have S_IS*, so maybe the issue is + semi-moot. */ #if !defined(S_ISBLK) && defined(S_IFBLK) # if defined(S_IFMT) @@ -147,6 +153,7 @@ #include <limits.h> #else off_t lseek (); +char *getcwd (); #endif #if TIME_WITH_SYS_TIME @@ -276,16 +283,7 @@ int utime (); # endif #endif -#if STDC_HEADERS || HAVE_STRING_H -# include <string.h> - /* An ANSI string.h and pre-ANSI memory.h might conflict. */ -# if !STDC_HEADERS && HAVE_MEMORY_H -# include <memory.h> -# endif /* not STDC_HEADERS and HAVE_MEMORY_H */ -#else /* not STDC_HEADERS and not HAVE_STRING_H */ -# include <strings.h> - /* memory.h and strings.h conflict on some systems. */ -#endif /* not STDC_HEADERS and not HAVE_STRING_H */ +#include <string.h> #ifndef ERRNO_H_MISSING #include <errno.h> @@ -329,12 +327,6 @@ extern int errno; #define EXIT_FAILURE 1 #endif -#if defined(USG) || defined(POSIX) -char *getcwd (); -#else -char *getwd (); -#endif - /* check for POSIX signals */ #if defined(HAVE_SIGACTION) && defined(HAVE_SIGPROCMASK) # define POSIX_SIGNALS @@ -470,6 +462,31 @@ char *getwd (); #define CVS_FNMATCH fnmatch #endif +#if defined (__CYGWIN32__) || defined (WIN32) + +/* Under Windows NT, filenames are case-insensitive, and both / and \ + are path component separators. */ + +#define FOLD_FN_CHAR(c) (WNT_filename_classes[(unsigned char) (c)]) +extern unsigned char WNT_filename_classes[]; +#define FILENAMES_CASE_INSENSITIVE 1 + +/* Is the character C a path name separator? Under + Windows NT, you can use either / or \. */ +#define ISDIRSEP(c) (FOLD_FN_CHAR(c) == '/') + +/* Like strcmp, but with the appropriate tweaks for file names. + Under Windows NT, filenames are case-insensitive but case-preserving, + and both \ and / are path element separators. */ +extern int fncmp (const char *n1, const char *n2); + +/* Fold characters in FILENAME to their canonical forms. + If FOLD_FN_CHAR is not #defined, the system provides a default + definition for this. */ +extern void fnfold (char *FILENAME); + +#endif /* defined (__CYGWIN32__) || defined (WIN32) */ + /* Some file systems are case-insensitive. If FOLD_FN_CHAR is #defined, it maps the character C onto its "canonical" form. In a case-insensitive system, it would map all alphanumeric characters @@ -488,21 +505,22 @@ char *getwd (); #endif -/* On some systems, lines in text files should be terminated with CRLF, - not just LF, and the read and write routines do this translation - for you. LINES_CRLF_TERMINATED is #defined on such systems. - - OPEN_BINARY is the flag to pass to the open function for - untranslated I/O. - - FOPEN_BINARY_READ is the string to pass to fopen to get - untranslated reading. - - FOPEN_BINARY_WRITE is the string to pass to fopen to get - untranslated writing. */ -#if LINES_CRLF_TERMINATED -#define OPEN_BINARY (O_BINARY) +/* On some systems, we have to be careful about writing/reading files + in text or binary mode (so in text mode the system can handle CRLF + vs. LF, VMS text file conventions, &c). We decide to just always + be careful. That way we don't have to worry about whether text and + binary differ on this system. We just have to worry about whether + the system has O_BINARY and "rb". The latter is easy; all ANSI C + libraries have it, SunOS4 has it, and CVS has used it unguarded + some places for a while now without complaints (e.g. "rb" in + server.c (server_updated), since CVS 1.8). The former is just an + #ifdef. */ + #define FOPEN_BINARY_READ ("rb") #define FOPEN_BINARY_WRITE ("wb") + +#ifdef O_BINARY +#define OPEN_BINARY (O_BINARY) #else #define OPEN_BINARY (0) -#define FOPEN_BINARY_READ ("r") -#define FOPEN_BINARY_WRITE ("w") #endif diff --git a/contrib/cvs/lib/xgetwd.c b/contrib/cvs/lib/xgetwd.c index e2a3baa..bbae81d 100644 --- a/contrib/cvs/lib/xgetwd.c +++ b/contrib/cvs/lib/xgetwd.c @@ -1,5 +1,5 @@ /* xgetwd.c -- return current directory with unlimited length - Copyright (C) 1992 Free Software Foundation, Inc. + Copyright (C) 1992, 1997 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 @@ -26,14 +26,6 @@ extern int errno; #endif #include <sys/types.h> -#ifndef HAVE_GETWD -char *getwd (); -#define GETWD(buf, max) getwd (buf) -#else -char *getcwd (); -#define GETWD(buf, max) getcwd (buf, max) -#endif - /* Amount by which to increase buffer size when allocating more space. */ #define PATH_INCR 32 @@ -57,7 +49,7 @@ xgetwd () cwd = xmalloc (path_max); errno = 0; - while ((ret = GETWD (cwd, path_max)) == NULL && errno == ERANGE) + while ((ret = getcwd (cwd, path_max)) == NULL && errno == ERANGE) { path_max += PATH_INCR; cwd = xrealloc (cwd, path_max); diff --git a/contrib/cvs/man/ChangeLog b/contrib/cvs/man/ChangeLog index 6023631..c873cb2 100644 --- a/contrib/cvs/man/ChangeLog +++ b/contrib/cvs/man/ChangeLog @@ -1,3 +1,18 @@ +Mon Jan 12 11:10:21 1998 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvs.1: Refer to Cederqvist as Cederqvist not as cvs.texinfo. + Describe it in a way which hopefully makes more sense for people + who aren't getting the CVS source distribution itself. In "SEE + ALSO" section, also mention web pages. Use a period not a comma + at the end of the references to other manpages. + + * cvs.1: Remove $Id; we decided to get rid of these some time ago. + +Sun Jan 11 13:46:54 1998 Peter Wemm <peter@netplex.com.au> + + * cvs.1: Fix "the the" typo. From Wolfram Schneider + <wosch@freebsd.org> via FreeBSD sources. + Wed Feb 12 14:20:43 1997 Jim Kingdon <kingdon@harvey.cyclic.com> * Makefile.in (install): Depend on installdirs. diff --git a/contrib/cvs/man/cvs.1 b/contrib/cvs/man/cvs.1 index 30f0ff9..a0efd4b 100644 --- a/contrib/cvs/man/cvs.1 +++ b/contrib/cvs/man/cvs.1 @@ -2,7 +2,6 @@ .ds Rv \\$3 .ds Dt \\$4 .. -.Id $Id: cvs.1,v 1.15 1996/11/30 19:49:56 kingdon Exp $ .TH CVS 1 "\*(Dt" .\" Full space in nroff; half space in troff .de SP @@ -27,7 +26,7 @@ cvs \- Concurrent Versions System .SH "NOTE" This manpage is a summary of some of the features of .B cvs -but for more in-depth documentation, consult cvs.texinfo (as +but for more in-depth documentation, consult the Cederqvist manual (as described in the SEE ALSO section of this manpage). .SH "DESCRIPTION" .IX "revision control system" "\fLcvs\fR" @@ -1284,7 +1283,7 @@ Each file is searched for the revision or tag. .TP 1i \fB\ \ \ \ \ \ \-t\fP \fItag\fP -Show records since tag \fItag\fP was last added to the the history file. +Show records since tag \fItag\fP was last added to the history file. This differs from the \fB-r\fP flag above in that it reads only the history file, not the .SM RCS @@ -1327,7 +1326,7 @@ names associated with administration, or with other common source control systems; common names for patch files, object files, archive files, and editor backup files; and other names that are usually artifacts of assorted utilities. -For an up to date list of ignored file names, see cvs.texinfo (as +For an up to date list of ignored file names, see the Cederqvist manual (as described in the SEE ALSO section of this manpage). .SP The outside source is saved in a first-level @@ -1888,7 +1887,7 @@ Use \fB\-I\fP \fIname\fP to ignore files whose names match \fIname\fP \fB\-I\fP more than once on the command line to specify several files to ignore. By default, \fBupdate\fP ignores files whose names match certain patterns; for -an up to date list of ignored file names, see cvs.texinfo (as +an up to date list of ignored file names, see the Cederqvist manual (as described in the SEE ALSO section of this manpage). .SP Use @@ -2152,12 +2151,20 @@ module and vendor branch support and author of the shell script (the ancestor of .` "cvs import"). .SH "SEE ALSO" -The most comprehensive manual for CVS is cvs.texinfo, also known as -Version Management with CVS by Per Cederqvist et al. For more -information about the formats which this manual is in or can be -converted to (info, postscript, etc.), see the README file in the CVS -distribution. - +The most comprehensive manual for CVS is +Version Management with CVS by Per Cederqvist et al. Depending on +your system, you may be able to get it with the +.B info cvs +command or it may be available as cvs.ps (postscript), cvs.texinfo +(texinfo source), or cvs.html. +.SP +For CVS updates, more information on documentation, software related +to CVS, development of CVS, and more, see: +.in +1i +.B http://www.cyclic.com +.B http://www.loria.fr/~molli/cvs-index.html +.in -1i +.SP .BR ci ( 1 ), .BR co ( 1 ), .BR cvs ( 5 ), @@ -2168,4 +2175,4 @@ distribution. .BR rcs ( 1 ), .BR rcsdiff ( 1 ), .BR rcsmerge ( 1 ), -.BR rlog ( 1 ), +.BR rlog ( 1 ). diff --git a/contrib/cvs/src/ChangeLog b/contrib/cvs/src/ChangeLog index 0c8b0f6..96540fb 100644 --- a/contrib/cvs/src/ChangeLog +++ b/contrib/cvs/src/ChangeLog @@ -1,1376 +1,199 @@ -Tue Jun 17 22:48:00 1997 Jim Kingdon <kingdon@harvey.cyclic.com> +Thu Jan 22 10:05:55 1998 Jim Kingdon <kingdon@harvey.cyclic.com> - * main.c (main): Add --allow-root=ROOT argument; call - root_allow_add for each time it is specified. Call - root_allow_free before exiting. - * root.c, cvs.h (root_allow_add, root_allow_free, root_allow_ok): - New function. - * server.c (pserver_authenticate_connection): If root_allow_ok - doesn't like the CVSROOT directory, don't allow access. + * server.c (serve_kopt): Check for length of arg. Based on + inspection of the code, plugs a buffer overrun security hole which + was introduced Monday. -Tue Jun 17 14:30:14 1997 Jim Kingdon (unknown@beezley) + * server.c (serve_is_modified): Don't call xmalloc; we aren't + allowed to call error() here. Remove duplicate (and potentially + confusing) variable 'p'. - * client.c: Add "copyright" notice. If NO_EXT_METHOD, omit - start_rsh_method. - * client.c (update_entries): Cast argument to MD5Update from - char * to unsigned char *. + * log.c (log_fileproc): Look for first character of version + '0' AND second character '\0', rather than OR. I didn't try to + come up with a test case but this looks like a simple thinko + (albeit one which would show up in obscure cases if at all). -Mon Jun 16 16:46:28 1997 Jim Kingdon <kingdon@harvey.cyclic.com> +Tue Jan 20 19:37:53 1998 Jim Kingdon <kingdon@harvey.cyclic.com> - * run.c (piped_child, filter_stream_through_program): - If USE_SETMODE_BINARY, then put the pipes into binary mode. - * find_names.c, ignore.c, lock.c, wrapper.c: Change fnmatch to - CVS_FNMATCH. - * client.c (start_server): If NO_EXT_METHOD, then give a fatal - error on any use of :ext:. + * client.c (send_dirent_proc): Don't send nonexistent directories + unless noexec. + * sanity.sh (modules2): New tests modules2-13 through modules2-18 + test for this fix. -Sun Jun 15 22:30:27 1997 Jim Kingdon <kingdon@harvey.cyclic.com> +Mon Jan 19 11:17:51 1998 Jim Kingdon <kingdon@harvey.cyclic.com> - * sanity.sh (toplevel): Match U CVSROOT/* lines with DOTSTAR in - test toplevel-9. + * server.c (serve_kopt): New function. + (requests): Add "Kopt" request. + (kopt): New variable. + (serve_is_modified): Write kopts from there into entries. + (serve_modified): Call serve_is_modified so we do the same. + Declare serve_modified and serve_is_modified. + * vers_ts.c (Version_TS): Set ->options even for a dummy ("D" + timestamp) entry. + * import.c (process_import_file): Check for -k options. + * client.c (client_process_import_file): Send Kopt request. + (send_fileproc): Likewise, for "cvs add". + * sanity.sh: Enable test binwrap3-sub2-add1 for remote. + Add -I .cvswrappers to binwrap3-2a; adjust binwrap3-2d + accordingly. Tests for this fix. -Thu Jun 12 10:27:51 1997 Jim Kingdon <kingdon@harvey.cyclic.com> +Mon Jan 19 08:48:59 1998 Larry Jones <larry.jones@sdrc.com> - * sanity.sh (toplevel): Remove Emptydir before starting. + * sanity.sh (errmsg1): Append test 168 output to log file. - * sanity.sh: Change "rm -rf" to "rm -r" when deleting working - directories (except a few watches cases). Helps detect cases - where the testsuite has cd'd to somewhere other than where we - think it has. - (basic2): Remove "rm -r first-dir" between tests 49 and 50. The - directory was already deleted in test 45.5. - (rcs): Add "cd .." at end of tests. - (stamps): No longer cd to TESTDIR; shouldn't be necessary with - fix to "rcs" test. +Sat Jan 17 08:01:51 1998 Jim Kingdon <kingdon@harvey.cyclic.com> -Wed Jun 11 22:28:38 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + * sanity.sh (ann-10, ann-11): Don't make assumptions about the + number of characters in the username. - * sanity.sh (basicb): Also remove CVSROOT/Emptydir at end of - test. Otherwise it affects the toplevel-9 test for remote. +Fri Jan 16 15:34:02 1998 Larry Jones <larry.jones@sdrc.com> -Tue Jun 10 14:03:32 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + * diff.c (diff_fileproc): Free label1 and label2 when finished. - * sanity.sh (toplevel): Change "update" and "checkout" to "[a-z]*" - as these read "server" instead for "make remotecheck". Change - expect strings for toplevel-9 to accept the behavior of remote CVS - (see comments for more discussion). + * edit.c (editor_set): Don't free edlist until after we're + done using it. - * sanity.sh: New tests stamps-9 through stamps-11 test timestamp - behavior on cvs update. + * rcscmds.c (RCS_merge): Free xrev1 and xrev2 when finished. -Mon Jun 9 22:42:50 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + * subr.c (make_message_rcslegal): Don't access uninitialized or + unallocated memory; only strip trailing blank lines. + * sanity.sh (log-3): Enhance to test this fix. - * sanity.sh: Remove "#! /bin/zsh" line at end. I assume it was - added accidentally. +Fri Jan 16 12:41:03 1998 Jim Kingdon <kingdon@harvey.cyclic.com> -Tue Jun 10 03:08:46 1997 Norbert Kiesel <nk@psycho.de> + * sanity.sh: Add keywordlog to list of tests run by default. - * sanity.sh: new tests "toplevel" for the new toplevel CVS - directory creation (including one test which shows an error in - this area). + * rcs.c (RCS_deltas): Don't call cvs_output if length is zero; + passing zero length to cvs_output does not mean output zero + bytes. The 27 Dec 1997 change to no longer '\0'-terminate the + ->text field turned this from a time bomb to a user-visible bug. + * sanity.sh (ann): New tests, test for this fix and other annotate + behaviors. -Sun Jun 8 20:52:00 1997 Jim Kingdon <kingdon@harvey.cyclic.com> +Thu Jan 15 23:52:00 1998 Jim Kingdon <kingdon@harvey.cyclic.com> - * rcs.c (getrcsrev): Before printing error, check whether it was - feof or ferror. + * root.c (root_allow_ok): If inetd.conf didn't specify an + --allow-root options at all, we know we are in trouble. Give a + specific error message. - * rcs.h, import.c (add_rcs_file): No longer static. New arguments - add_vbranch, add_vhead, and add_logfp replace access to static - variables vbranch, vhead, and logfp. - * mkmodules.c: Call it instead of RCS_CI. - * import.c (process_import_file): Adjust call to add_rcs_file. +Thu Jan 15 21:24:59 1998 Ian Lance Taylor <ian@cygnus.com> -Tue Jun 3 10:18:33 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + * sanity.sh (dotest_sort): New variant of dotest which sorts the + output, for use when the output depends upon details of the file + system, typically when doing an import. + (rdiff): Use dotest_sort for rdiff-1. + (ignore): Use dotest_sort for 188a, 188b, 189d, 190, and 191. - * sanity.sh (basicb): Match "." with "\." not ".". + * sanity.sh: (TESTSHELL): New variable. + (editor, info, reserved): Use TESTSHELL in temporary script. -Tue Jun 3 13:02:37 1997 Norbert Kiesel <nk@cosa.de> + * sanity.sh (ignore): Do all tests in subdirectory, to avoid + conflict between cvsroot and CVSROOT on Windows. + (binwrap3, mwrap, info, config): Likewise. - * checkout.c (checkout): Removed restriction of not sending -k in - remote export (I think this was introduced while the -k handling - was still broken in remote mode). Give better error texts - regarding -c and -s options. Use error() instead of usage() for - reporting errors in all places. Reindented some lines. Free - xmalloc'd space of options. + * sanity.sh (binfiles2): Correct test name binfile2-7-brmod to + binfiles2-7-brmod. -Thu May 29 16:32:47 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + * release.c (release_delete): If __CYGWIN32__ is defined, don't + worry about mismatched inodes. This is a hack, but then I think + the test is rather peculiar anyhow. - * rcscmds.c (RCS_checkin), mkmodules.c (init): Pass -w option to - "ci", specifying getcaller (). - * server.h, server.c (CVS_Username): Now extern. - * subr.c (getcaller): Return CVS_Username if it is set. +Thu Jan 15 16:07:36 1998 Larry Jones <larry.jones@sdrc.com> -Wed May 28 22:31:38 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + * sanity.sh (reserved-9): Use ${PROG} instead of "cvs". - * update.c (update_fileproc): If wrap_merge_is_copy and we would - like to do a merge, give a fatal error. See comment for why. - * sanity.sh (mwrap): New tests, tests for above fix. +Wed Jan 14 15:43:13 1998 Jim Kingdon <kingdon@harvey.cyclic.com> -Tue May 27 21:59:32 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + * Split ChangeLog into ChangeLog-97 and ChangeLog. + * Makefile.in (DISTFILES): Add ChangeLog-97. - * sanity.sh (stamps): cd to ${TESTDIR} before starting. +13 Jan 1998 Jim Kingdon -Mon May 26 15:31:30 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + * client.c: Declare handle_mt. - * client.c (handle_mod_time): New function. - (responses): Add "Mod-time". - (stored_modtime_valid, stored_modtime): New variables. - (update_entries): If it is set, change the file's modtime. - * server.c, server.h (server_modtime): New function. - * vers_ts.c (Version_TS): Call it. - * patch.c (patch_fileproc): Add comment about why we don't. - * sanity.sh (stamps): Added, tests for above fix. +Tue Jan 13 22:21:30 1998 Jim Kingdon <kingdon@harvey.cyclic.com> -Fri May 16 13:14:30 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + * sanity.sh: Add comment about how pwd and /bin/pwd often differ + in behavior (but are not guaranteed to). - * subr.c (free_names): Update documentation to reflect fact that - free_names is now called to free vectors allocated by expand_wild - as well as by line2argv. +Tue Jan 13 13:49:53 1998 Ian Lance Taylor <ian@cygnus.com> - * main.c (main): Use "xstrdup (foo)" not "xstrdup(foo)" as - specified in HACKING. + * sanity.sh: When setting TMPPWD use just pwd, not /bin/pwd. -Fri May 16 15:10:37 1997 Norbert Kiesel <nk@cosa.de> + * update.c (checkout_file): Don't pass set_time as true to + Version_TS if the file is dead. + * sanity.sh (modules): Add tests modules-155c6 through + modules-155c8 to test for above patch (without the above patch, + modules-155c8 will fail when remote). - * modules.c (do_module): initialize optind to 0. use local copies - of optarg's (because they might me freed within free_names). +Tue Jan 13 10:37:02 1998 Larry Jones <larry.jones@sdrc.com> -Thu May 15 11:50:15 1997 Norbert Kiesel <nk@cosa.de> + * client.c (send_modified): Change bufsize and newsize from int + to size_t to avoid type clashes in call to read_and_gzip. - * main.c (main): initialize optind to 0. use local copies of - optarg's (because they might me freed within read_cvsrc). +Tue Jan 13 10:33:02 1998 Larry Jones <larry.jones@sdrc.com> - * cvsrc.c (read_cvsrc): free old argv after constructing a new - one. This fixes a memory leak. + * zlib.c (read_and_gzip): Set finish to 0; it was uninitialized. - * recurse.c (start_recursion): use free_names() instead of - reimplementing it +Tue Jan 13 10:26:43 1998 Larry Jones <larry.jones@sdrc.com> - * rcs.c (RCS_deltas): free branchversion (memory leak). + * add.c, rcs.c: Plug memory leaks. - * parseinfo.c (Parse_Info): free some vars (3 memory leaks). +Mon Jan 12 10:45:27 1998 Larry Jones <larry.jones@sdrc.com> - * logmsg.c (logfile_write): free str_list_format (memory leak). + * server.c (mkdir_p): Don't try to create nameless directories + (i.e., given "/foo//bar", don't try to create "/foo/", + just "/foo" and "/foo//bar") since it isn't necessary and + it fails on some systems in unexpected ways. - * watch.c (watch_addremove), (watchers), update.c (update), tag.c - (cvstag), status.c (status), rtag.c (rtag), remove.c (cvsremove), - release.c (release), patch.c (patch), log.c (cvslog), import.c - (import), history.c (history), edit.c (watch_onoff), (edit), - (unedit), (editors), diff.c (diff), commit.c (commit), checkout.c - (checkout), add.c (add): initialize optind to 0 +1998-01-11 enami tsugutomo <enami@but-b.or.jp> - * diff.c (diff_fileproc): cosmetic change (whitespace added). + * rcs.c (linevector_copy): Delete lines before overwriting them. - * checkout.c (checkout): move local variable definition into the - block where the variable is used. +Sat Jan 10 11:05:40 1998 Jim Kingdon <kingdon@harvey.cyclic.com> - * client.c (update_entries): initialize some local variables to shut up - gcc -O -Wall. + * cvsrc.c, entries.c, login.c, logmsg.c, myndbm.c, patch.c, + release.c, server.c: Check for errors from getline, CVS_FOPEN, + fprintf, CVS_UNLINK and fclose. Note that the new errors are + nonfatal. This is because of conservatism more than because + it is always the best thing. + * login.c (get_cvs_password): Close the file when done with it. + * client.c (notified_a_file): If -1 return from getline, check + feof rather than assuming errno is set. - * buffer.c (buf_read_line): initialize a local variable to shut up - gcc -O -Wall. - +Fri Jan 9 14:38:54 1998 Jim Kingdon <kingdon@harvey.cyclic.com> -Wed May 14 16:29:50 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + * server.c (expand_proc): Also output server_dir in + "Module-expansion", not just in output_dir ("Created", &c). + * sanity.sh (modules2): New tests modules2-9 through modules2-12 + test for this. - * admin.c (admin): When sending options to server, don't try to - send av[ac]. It may contain one of the names that we'll send in - send_file_names (which caused tests like keyword-6 to work, - sort of accidentally), or it may contain NULL (which would tend to - cause a coredump). - * sanity.sh (basicb): New test basicb-21 tests for above fix. +Thu Jan 8 12:56:55 1998 Yasutoshi Hiroe <hiroe@rgk.ricoh.co.jp> -Mon May 12 16:22:00 1997 Larry Jones <larry.jones@sdrc.com> + * import.c (import): Don't strcat on uninitialized memory. Fixes + possible SIGSEGV with zero-length message. - * add.c (add): Free message and repository in client code. - * checkout.c (checkout): Don't free repository unless allocated. - * client.c (start_rsh_server): Free command. +Tue Jan 6 22:56:29 1998 Jim Kingdon <kingdon@harvey.cyclic.com> -Sun May 11 11:43:54 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + * sanity.sh (crerepos): Fix mistaken variable name which caused us + not to clean up at the end of the test. - * client.c: Remove all references to USE_DIRECT_TCP; see - ../ChangeLog for rationale. +Mon Dec 22 01:40:57 1997 Jim Kingdon <kingdon@harvey.cyclic.com> -Fri May 9 22:19:36 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + * add.c (add): Also look for .cvswrappers files. + * sanity.sh (binwrap3): New tests binwrap3-2*, binwrap3-sub2-add* + test for this. - * main.c (main): Add comment explaining why we call exit. Pass 0 - not EXIT_SUCCESS, because lib/system.h has portability cruft for - EXIT_FAILURE but not EXIT_SUCCESS. +Tue Jan 6 11:50:38 1998 Jim Kingdon <kingdon@harvey.cyclic.com> -Fri May 9 17:25:00 1997 Larry Jones <larry.jones@sdrc.com> + * sanity.sh (crerepos): New tests crerepos-8 through crerepos-18 + test behaviors when mixing repositories. - Fix miscellaneous memory allocation problems: - * add.c (add): Free repository. - * client.c (notified_a_file): Free getline buffer. - * edit.c (notify_check): Free getline buffer. - * hash.c (dellist): Free header node when not caching. - * login.c (login): Don't continually free & allocate getline - buffer, use xstrdup instead of xmalloc/strcpy, free getline - buffer before returning. - * main.c (main): Call exit instead of returning so tools like - Purify won't consider permanently allocated memory as leaks. - * mkmodules.c (mkmodules): Free getline buffer. - * modules.c (cat_module): Call close_module. - * rcs.c (rcsvers_delproc): Free state. - * recurse.c (start_recursion): Free files_by_dir. - (unroll_files_proc): NULL out p->data after using it to set - filelist to avoid multiple frees. - * server.c (check_command_legal_p): Don't continually free & - allocate getline buffer, free getline buffer before returning. - (check_repository_password): Ditto, use xstrdup instead of - xmalloc/strcpy. - * wrapper.c (wrap_add_file): Free getline buffer. +Sun Jan 4 17:40:22 1998 Jim Kingdon <kingdon@harvey.cyclic.com> -Thu May 8 14:21:00 1997 Larry Jones <larry.jones@sdrc.com> - and Jim Kingdon <kingdon@harvey.cyclic.com> + * version.c: Change version number to 1.9.23. - * checkout.c (checkout_proc): Free finfo.rcs (memory leak). + * Version 1.9.22. -8 May 1997 Larry Jones <larry.jones@sdrc.com> - and Jim Kingdon <kingdon@harvey.cyclic.com> - * hash.c: Add #ifdef's to disable caching. This makes it easier - to track down memory allocation problems. - -Thu May 8 11:40:39 1997 Larry Jones <larry.jones@sdrc.com> - - * sanity.sh: In setting "tests" use a number of statements rather - than one very long line. - -Thu May 8 11:40:39 1997 Jim Kingdon <kingdon@harvey.cyclic.com> - - * cvsbug.sh: Remove $Id; we decided to get rid of these some time - ago. - -Thu May 8 11:34:02 1997 Larry Jones <larry.jones@sdrc.com> - - * cvsbug.sh: Put separate statements on separate lines, so it - works if awk is AT&T nawk. - -Tue May 6 16:56:00 1997 Larry Jones <larry.jones@sdrc.com> - and Jim Kingdon <kingdon@harvey.cyclic.com> - - * cvsrc.c (read_cvsrc): Fix various memory allocation problems: - rearrange code to avoid leaks, use xrealloc instead of xmalloc/ - copy/free, make sure there's room for the remaining args before - appending them. - -Tue May 6 14:20:00 1997 Larry Jones <larry.jones@sdrc.com> - - * edit.c (watch_onoff, edit, unedit, editors): Add -R like - other things with -l. - * watch.c (watch_addremove, watchers): Ditto. - -Mon May 5 18:10:37 1997 larry.jones@sdrc.com - and Jim Kingdon <kingdon@harvey.cyclic.com> - - * sanity.sh: Change all /tmp/cvs-sanity to TESTDIR. If TESTDIR - environment variable is set, use it instead of /tmp/cvs-sanity. - * sanity.sh: Make TMPPWD the pwd equivalent of TESTDIR, not of /tmp. - -4 May 1997 Larry jones <larry.jones@sdrc.com> - and Jim Kingdon - - * checkout.c, diff.c, patch.c, rcs.c: Update usage messages. - * rcs.c (annotate): Add -R like other things with -l. - -Sat May 3 14:57:40 1997 Jim Kingdon <kingdon@harvey.cyclic.com> - - * sanity.sh (basic1): Rewrite test (use dotest, unroll the loops - which IMHO makes the test a zillion times more understandable, and - only do the variant which tests for 4 files at a time--we test one - file at a time lots of places). - -2 May 1997 Ziv Gigus <ziv@rest.home.net> - and Jim Kingdon - - * client.c, client.h (client_process_import_file): New argument - all_files_binary means treat all files as binary. - * import.c (import_descend): Pass it if -kb is specified. - * client.c (client_process_import_file): In the - non-all_files_binary case, call wrap_rcsoption to determine - whether the file is binary. - -Thu May 1 13:44:51 1997 Jim Kingdon <kingdon@harvey.cyclic.com> - - * sanity.sh (binfiles2): New tests, for update -j and binary files. - -Wed Apr 30 11:18:36 1997 Jim Kingdon <kingdon@harvey.cyclic.com> - - * recurse.c (start_recursion): Also free reposfile. - Don't look in repository if client_active (latter bug reported by Paul - Sanders <p.sanders@dial.pipex.com>). - -Mon Apr 28 22:36:39 1997 Jim Kingdon <kingdon@harvey.cyclic.com> - - * diff.c (diff_file_nodiff): Remove SERVER_SUPPORT ifdefs. They - were not based on server_active, which doesn't really make any - sense (it meant that compiling --disable-server could affect the - behavior of the non-client/server CVS). This affected the output - in tests death2-diff-11 and death2-diff-12 in the testsuite. - * sanity.sh (newb-123j0): Also accept "Needs Checkout", for a - --disable-server CVS. - - * main.c (cmd_usage): Change "run diffs" to "show differences"; - the former is jargon. - * edit.c (edit_usage): Fix typo ("." -> ","). - * edit.c (editors_usage), watch.c (watchers_usage): Mention -l. - * checkout.c (export_usage): Say what -P does. - * history.c (history_usg): Add comment about message wording. - -Mon Apr 28 14:47:45 1997 Norbert Kiesel <nk@cosa.de> - - * checkin.c (Checkin): use filename without path when calling - wrapper (bug found by Michal Schmitz <ms@cosa.de>). - -Fri Apr 25 13:28:55 1997 Ian Lance Taylor <ian@cygnus.com> - - * client.c (update_entries): In UPDATE_ENTRIES_RCS_DIFF case, - write to a temporary file and then rename it. - -Thu Apr 24 11:35:40 1997 Jim Kingdon <kingdon@harvey.cyclic.com> - - * subr.c, cvs.h (pathname_levels): New function, from a piece of - send_file_names. - * client.c (send_file_names): Call pathname_levels in place of the - code which was moved there. - * server.c, server.h (server_pathname_check): New function. - * recurse.c (start_recursion): Call it. - * sanity.sh (modules3): New test modules3-11b tests for above fix. - - * filesubr.c: Do not define L_tmpnam. It is in ANSI and SunOS4, - so I don't think there will be a problem with it being missing. - Defining it too small can cause memory corruption. - (cvs_temp_name): Do not use L_tmpnam in the mktemp code; this - could cause a buffer overflow if the -T global option was in use. - -Thu Apr 24 13:21:15 1997 Norbert Kiesel <nk@cosa.de> - - * filesubr.c (cvs_temp_name): Use tempnam if available, else - mktemp, else tmpnam. See the comment for rationale. - - * sanity.sh: use "tar cf - ." instead of "tar cf - *" for - directory copies. - -Wed Apr 23 23:41:47 1997 Jim Kingdon <kingdon@harvey.cyclic.com> - - * server.c (serve_update_prog): If in readonly mode, give an error. - -Wed Apr 23 19:07:41 1997 Norbert Kiesel <nk@cosa.de> - - * subr.c (line2argv): Allocate at least 4 slots for argv. - - * checkout.c (checkout_proc): Add a comment which says why the - above change was necessary to avoid writing to unallocated memory. - -Wed Apr 23 11:20:40 1997 Jim Kingdon <kingdon@harvey.cyclic.com> - - * entries.c (ParseTag): Always set *NONBRANCHP. - -21 Apr 1997 Jim Kingdon - - * client.c (update_entries), rcs.c (expand_keywords): Rewrite - test to avoid signed/unsigned warning. - -Mon Apr 21 09:02:22 1997 Jim Kingdon <kingdon@harvey.cyclic.com> - - * update.c (patch_file): Add comment about whether auto-detecting - features of the DIFF program is a good idea. - -Mon Apr 21 00:03:34 1997 Ian Lance Taylor <ian@cygnus.com> - - Don't require the patch program: - * client.c (struct update_entries_data): Add - UPDATE_ENTRIES_RCS_DIFF to contents enum. - (update_entries): Handle UPDATE_ENTRIES_RCS_DIFF. - (handle_rcs_diff): New static function. - (responses): Add "Rcs-diff". - * server.c (server_updated): Handle SERVER_RCS_DIFF. - (server_use_rcs_diff): New function. - * server.h (enum server_updated_arg4): Add SERVER_RCS_DIFF. - (server_use_rcs_diff): Declare. - * update.c (rcs_diff_patches): New static variable. - (update): Set rcs_diff_patches. - (update_fileproc): If rcs_diff_patches, pass SERVER_RCS_DIFF - rather than SERVER_PATCHED to server_updated. - (patch_file): Correct initial comment to say diff rather than - rcsdiff. If rcs_diff_options, pass -n to diff rather than -c. - * rcs.c (rcs_change_text): New function. - * rcs.h (rcs_change_text): Declare. - -Mon Apr 21 00:08:59 1997 Jim Kingdon <kingdon@harvey.cyclic.com> - - * diff.c (diff_fileproc): Add comment concerning updating the - client timestamp. - -Sun Apr 20 23:20:37 1997 Jim Kingdon <kingdon@harvey.cyclic.com> - - * commit.c (commit): Add comment regarding SEND_FORCE rationale. - -Sat Apr 19 17:10:36 1997 Jim Kingdon <kingdon@harvey.cyclic.com> - - * server.c (dirswitch): If directory ends in '/', complain. - -Fri Apr 18 18:09:57 1997 Ian Lance Taylor <ian@cygnus.com> - - * rcs.c (apply_rcs_changes): New static function, broken out of - RCS_deltas. - (RCS_deltas): Call it. - (linevector_add): Change return type to int. Return an indication - of an error for an invalid add, rather than calling error. - -Fri Apr 18 11:24:26 1997 Jim Kingdon <kingdon@harvey.cyclic.com> - - * version.c: Change version number to 1.9.9. - - * version.c: Version 1.9.8. - - * commit.c (struct find_data): Add field force. - (find_fileproc, commit): Use it instead of force_ci to decide - whether to send files to server. - (commit): Set it if either -f or -r is specified. - * sanity.sh (basica): Add tests basica-8a0, basica-8a1, and - basica-8a2; tests for above fix. - -Wed Apr 16 11:50:59 1997 Jim Kingdon <kingdon@harvey.cyclic.com> - - * zlib.c: Remove paragraph with Free Software Foundation address. - See 2 Jan 1997 entry in ../ChangeLog for rationale. - -Tue Apr 15 00:36:23 1997 Jim Kingdon <kingdon@harvey.cyclic.com> - - * update.c (patch_file_write): Always assign to final_nl, so that - it ends up reflecting whether the data from the last call had a - newline, not whether the data from any of the calls ended in a - newline. Doesn't matter with the current RCS_checkout - implementation, but it will if RCS_checkout is changed to pass - less than the entire file. - - * rcs.c (RCS_cmp_file): Change NULL to RUN_TTY in passing sout to - RCS_checkout, for clarity. - - * import.c (update_rcs_file): Remove unused variable ierrno. - - * add.c, checkout.c, commit.c, diff.c, edit.c, import.c, - history.c, log.c, main.c, patch.c, release.c, remove.c, rtag.c, - status.c, tag.c, update.c, watch.c: Pass "+" to all calls to - getopt. This ensures that we maintain existing behavior even with - glibc2. - - * filesubr.c (fopen_case): Don't set *PATHP if we return an - error. Since the 9 Apr 1997 change, the behavior has been to - sometimes set it and sometimes not. - * rcs.c (RCS_parse): Adjust callers to not free it. Without this - change, they could call free() on an uninitialized variable. - - * checkout.c (checkout): Add comment about export -k. - - * root.c (check_root_consistent): Add comment about wording of - message. - -Mon Apr 14 11:51:49 1997 Jim Kingdon <kingdon@harvey.cyclic.com> - - * client.c (call_in_directory): If rdirp reaches the end of - reposdirname, then just set it to NULL. If server does not create - directories one at a time, give a warning. - * sanity.sh (modules3): Enable tests modules3-8 through - modules3-11 for remote; tests for above fix. - - * client.c (call_in_directory): Don't set short_pathname to - pathname for a while; just use pathname itself (cleans up a relic - of the old "Repository" (not "Directory") code). Add comment - explaining short_pathname. - -Sun Apr 13 18:07:50 1997 Ian Lance Taylor <ian@cygnus.com> - - * rcs.c (RCS_checkout): Add pfn and callerdat parameters. Change - all callers. Move setting of expand after retrieval of file - data. - (struct cmp_file_data): Define. - (RCS_cmp_file): New function. - (cmp_file_buffer): New static function. - * rcs.h (RCSCHECKOUTPROC): Define type. - (RCS_checkout): Update declaration. - (RCS_cmp_file): Define. - * diff.c (diff_file_nodiff): Call RCS_cmp_file rather than - RCS_checkout and xcmp. - * import.c (update_rcs_file): Likewise. - * no_diff.c (No_Difference): Likewise. - * update.c (struct patch_file_data): Define. - (patch_file): Just return if noexec, or if binary file. Pass - patch_file_write to RCS_checkout. Don't check for newlines or - compute checksums here. Stat RCS file to set modes. - (patch_file_write): New static function. - - * update.c (patch_file): Checkout directly to file2, rather than - to finfo->file followed by rename. Remove check for whether - result of checkout is readable; that was for an old, obsolete, - form of death support. - -Sun Apr 13 13:16:40 1997 Jim Kingdon <kingdon@harvey.cyclic.com> - - * checkout.c (build_one_dir): New function. - (struct dir_to_build): New structure. - (build_dirs_and_chir): Rewritten to accept a linked list of struct - dir_to_build rather than the silly string processing we had been - doing before. - (checkout_proc): Rewrite code that calls build_dirs_and_chdir - accordingly. - * sanity.sh: Enable tests modules3-10 and modules3-11 for local CVS; - tests for above fix. - - * rcs.h (RCS_CO): Removed; no longer used. - -Sun Apr 13 00:04:34 1997 Ian Lance Taylor <ian@cygnus.com> - - Expand RCS keywords internally; never call co: - * rcs.h (struct rcsversnode): Add state field. - * rcs.c (kflags): Move out of RCS_check_kflag, and make file - static. - (enum kflag): Define. - (RCS_reparsercsfile): Always save lock information. Save state in - new state field, rather than other field. - (struct rcs_keyword): Define. - (keywords): New static variable. - (enum keyword): Define. - (printable_date, escape_keyword_value): New static functions. - (expand_keywords): New static function. - (RCS_checkout): Call expand_keywords. Don't call - RCS_exec_checkout. - (RCS_deltas): Add log and loglen parameters. Change all callers. - * log.c (log_version_requested): Use new state field. - (log_version): Likewise. - * cvs.h (RCS_exec_checkout): Don't declare. - * rcscmds.c (RCS_exec_checkout): Remove. - -Sat Apr 12 17:32:59 1997 Ian Lance Taylor <ian@cygnus.com> - - * sanity.sh (modules3): Remove second-dir at end of tests. - (sticky): Correct removal of directories at end of tests. - - * sanity.sh (keyword): New tests for RCS keyword expansion. - -Sat Apr 12 16:47:13 1997 Jim Kingdon <kingdon@harvey.cyclic.com> - - * sanity.sh (basicb): New tests basicb-1b, basicb-1c, basicb-9b, - basic-9c test current build_dirs_and_chdir behavior. - -Fri Apr 11 23:54:56 1997 Jim Kingdon <kingdon@harvey.cyclic.com> - - * sanity.sh (modules3): New tests modules3-7* test for ability to - supply a path in -d in modules. Similar to modules3-8 through - modules3-11 except because the nesting is different, these ones - work. - -Thu Apr 10 00:14:47 1997 Jim Kingdon <kingdon@harvey.cyclic.com> - - * sanity.sh (modules3): New tests modules3-12 through modules3-15 - test use of a module name which contains a slash. - - * sanity.sh (basicb): New tests basicb-14 to basicb-20 test use of - co -d with two or more arguments. - - * rcscmds.c: Refer to doc/RCSFILES in comment. - -Wed Apr 9 09:49:17 1997 Jim Kingdon <kingdon@harvey.cyclic.com> - - * sanity.sh (basicb): New tests basicb-11 through basicb-13 test - ability to specify several directory levels in co -d (commented - out). - - * filesubr.c (fopen_case): If CVS_OPENDIR gives an - existence_error, return it to the caller instead of giving a fatal - error. - - * client.c (update_entries): Fix typo in call to error (1 -> errno). - -Tue Apr 8 23:02:22 1997 Jim Kingdon <kingdon@harvey.cyclic.com> - - * error.h, error.c: Test for #ifdef __STDC__, not #if __STDC__. - This is consistent with other parts of CVS; it means that the - declaration for fperror will match the definition even if __STDC__ - is defined to 0 as the SunPro 4.0 compiler does. Reported by - Richard Smith <rjsmith@cisco.com>. - -2 Apr 1997 Jim Kingdon - - * entries.c (ParseTag): Add "break;" after "default:" to avoid - error from Visual C++. - -Wed Apr 2 12:06:44 1997 Vince Del Vecchio <vdelvecc@spd.analog.com> - and Jim Kingdon - - * client.c: In reporting errors from socket calls, use - SOCK_STRERROR and SOCK_ERRNO since strerror(errno) doesn't work - for Win32. - -Tue Apr 8 10:45:32 1997 Jim Kingdon <kingdon@harvey.cyclic.com> - - * sanity.sh (modules3): Add tests modules3-8 to modules3-11, to - test for ability to supply a path to -d in modules. Mostly - commented out as CVS is buggy in this area. - -Mon Apr 7 12:41:44 1997 Jim Kingdon <kingdon@harvey.cyclic.com> - - * add.c (add): Add comment about SEND_NO_CONTENTS. - -Sun Apr 6 21:46:32 1997 Jim Kingdon <kingdon@harvey.cyclic.com> - - * update.c (update): Add comment about noexec and SEND_NO_CONTENTS. - -Sun Apr 6 17:34:08 1997 Robert Bihlmeyer <robbe@orcus.priv.at> - - * Pass +f not f to getopt_long to prevent options from being - permuted with glibc 2.0.1. - -Sun Mar 30 00:07:05 1997 Jim Kingdon <kingdon@harvey.cyclic.com> - - * cvs.h (struct vers_ts): Adjust comment regarding ts_user. - * server.c (serve_is_modified): New function. Set entries to show - that the file is modified but we don't know the contents. - * server.c (requests): Add "Is-modified" request. - * vers_ts.c (time_stamp_server): If the timestamp in entdata is - "M" or "D", just copy that over into ts_user. - * vers_ts.c (Version_TS): If timestamp is "D", use the entries - line for the sole purpose of passing it to time_stamp_server. - * no_diff.c (No_Difference): If ts_user is "M", conclude the files - are different. - * client.h, client.c (send_files): Replace arguments build_dirs - and force with argument flags. Add flag SEND_NO_CONTENTS and add - to struct send_data. - (send_fileproc): If no_contents, then send Is-modified instead of - Modified. - * add.c, admin.c, client.c, commit.c, diff.c, edit.c, log.c, - rcs.c, remove.c, status.c, tag.c, update.c, watch.c: Change all - send_files callers. - -Fri Mar 28 22:32:25 1997 Jim Kingdon <kingdon@harvey.cyclic.com> - - * server.c (requests): Change "Repository" to rq_optional. I'm - not sure whether I overlooked this when I removed support for - Repository, or whether I was thinking that servers would need to - support it anyway, for CVS 1.5 to 1.9 clients, but making it - optional doesn't prevent the server from supporting it and it - seems silly for the client to complain about absence of a request - that it never will use. - -Fri Mar 28 10:06:59 1997 Steven Miller <Miller@wingra.com> - - * entries.c (Subdirs_Known): Don't create Entries.Log if noexec. - -Thu Mar 27 18:14:12 1997 Ian Lance Taylor <ian@cygnus.com> - - * sanity.sh (death2): Remove commented out test death2-21. It - would now pass, but it duplicates the new test sticky-11. - -Thu Mar 27 10:21:19 1997 Jim Kingdon <kingdon@harvey.cyclic.com> - - * sanity.sh (dotest_internal): Write test output to logfile even - if test succeeds. This was the behavior prior to 30 Sep 1996. - See the comment for rationale. - -Tue Mar 25 13:26:52 1997 Jim Kingdon <kingdon@harvey.cyclic.com> - - * cvs.h, entries.c (WriteTag): Add arguments nonbranch, - update_dir, and repository. Move the server_set_sticky call from - callers to here. - * cvs.h, create_adm.c (Create_Admin): New argument nonbranch. - * cvs.h, entries.c (ParseTag): Add argument nonbranchp. - * cvs.h (struct stickydirtag): Add field nonbranch. - * entries.c (Entries_Open): Set it. - * cvs.h (Vers_TS): Add field nonbranch. - * vers_ts.c (Version_TS): Copy it from struct stickydirtag. - * server.c, server.h (server_set_sticky): Add argument nonbranch. - * add.c, client.c, checkout.c, modules.c, update.c, create_adm.c, - commit.c: Update callers. - * add.c (add): If nonbranch, don't add the file on that "branch". - * commit.c (write_dirnonbranch): New variable. - (commit_fileproc, commit): Set it. - (commit_dirleaveproc): Pass it to WriteTag. - * update.c (rewrite_tag, nonbranch): New variables. - (update, update_dirent_proc, update_fileproc): Set them. - (update_filesdoneproc): If rewrite_tag, call WriteTag. - * sanity.sh (sticky): New tests, test for above fix. - - * version.c: Change version number to 1.9.7. - - * version.c: Version 1.9.6. - -Mon Mar 24 13:02:04 1997 Jim Kingdon <kingdon@harvey.cyclic.com> - - * entries.c (ParseTag): Add comment about unrecognized characters - in CVS/Tag file. - - * classify.c (Classify_File): Add comment about how specifying a - tag (bogusly?) suppresses certain messages. - -Fri Mar 21 13:37:46 1997 Jim Kingdon <kingdon@harvey.cyclic.com> - - * rcs.h (struct rcsnode): Add comment about case of PATH. - * rcs.c (RCS_parse): If ign_case, then try opening the file with - fopen_case. - * ignore.c (ign_case): Adjust comment. - * cvs.h, filesubr.c (cvs_casecmp, fopen_case): New functions. - -20 Mar 1997 Jim Kingdon - - * client.c (send_repository): When sending Directory request, - send any ISDIRSEP character as '/'. Fixes - "cvs log foo\bar\baz.c" on NT & friends. - - * client.c (send_file_names): Don't try to read Entries file if - CVSADM directory does not exist. Fixes fairly serious regression - (warning on all fresh checkouts) introduced by 1997-01-08 change. - -Tue Mar 18 13:03:33 1997 Jim Meyering <meyering@totoro.cyclic.com> - - * sanity.sh (RCSINIT): Define to be empty and export, to hide any - existing value that might cause spurious failures. - - * Makefile.in: (install): Depend on installdirs. - Remove `CYGNUS LOCAL' comment saying not to. - -Tue Mar 18 09:36:26 1997 Jim Kingdon <kingdon@harvey.cyclic.com> - - * recurse.c (struct recursion_frame): Reindent. - (do_dir_proc): Print message if we try to recurse into a CVSADM - directory. - * sanity.sh (basicb): New test basicb-4a tests for above fix. - -Sun Mar 16 10:18:28 1997 Jim Kingdon <kingdon@harvey.cyclic.com> - - * sanity.sh (death2): Replace regexp matching temporary file name - with new variable ${tempname}. For most of the tests this is a - cosmetic change, but death2-diff-6 had been missing _ which caused - it to fail on Solaris (at least sometimes). - - * sanity.sh (modes): Don't use export -n; it doesn't seem - to be sufficiently portable. - - * version.c: Change version number to 1.9.5. - - * version.c: Version 1.9.4. - - * rcscmds.c (RCS_checkin): Preserve the mode of the rcsfile. - RCS_CI usually, but not always, does this for us. - * commit.c (fix_rcs_modes): Replace algorithm with a more - CVSUMASK-friendly one. - * sanity.sh (modes): Update tests modes-5, modes-7, modes-10, and - modes-15 so they test that CVSUMASK is honored. - -Sun Mar 16 10:18:28 1997 Jim Kingdon <kingdon@harvey.cyclic.com> - - * sanity.sh (modes): New tests modes-7a and modes-7b test behavior - if one manually changes the modes in the repository. - - * server.c (server): Revise code which checks for errors creating - temporary directory. This won't solve the intermittent - can't create temporary directory - Unknown error -1 - but it will mean (a) the right message based on errno gets - printed, instead of "unknown error -1", and (b) the message says - that it happened in chmod instead of mkdir_p. - -Sat Mar 15 16:47:12 1997 Jim Kingdon <kingdon@harvey.cyclic.com> - - * sanity.sh (modes): New tests. Note that (for now) these are - just testing how CVS already behaves; I want to record that before - I move on to changing CVS's behavior with modes of RCS files. - -13 Mar 1997 Jim Kingdon - - * subr.c (line2argv): Change argv_allocated from size_t to int. - -Wed Mar 12 22:16:44 1997 Jim Kingdon <kingdon@harvey.cyclic.com> - - * add.c (add_directory): If repository has an extraneous "." - directory at the end, strip it off. This fixes a bug which was - introduced when strip_path was nuked (this fix is much more - limited in scope than strip_path was; I _think_ that is a good - thing). - (add): Likewise, for client. - (combine_dir): New function, helps with above. - * sanity.sh (modules3): Reenable tests for this behavior. - (basica-0b, basicb-0e): Adjust test to reflect "foo/bar" instead - of "foo/./bar" in message. As with the rest of this, I believe - this is just restoring the behavior prior to the strip_path nuking - (I tried it with CVS 1.9). - -Sun Mar 9 10:06:29 1997 Jim Kingdon <kingdon@harvey.cyclic.com> - - * root.c (parse_cvsroot), server.c (serve_root, serve_init): - If CVSroot_directory is not an absolute pathname, give a fatal error. - * sanity.sh (crerepos): New tests crerepos-6* test for above fixes. - -Sat Mar 8 22:06:17 1997 Jim Kingdon <kingdon@harvey.cyclic.com> - - This cleans up the last known code which can overflow its buffers - (except the Mac client). I've skimmed through much of CVS looking - for other such places; but I didn't read everything. If I missed - any please report it to bug-cvs. - * logmsg.c (logfile_write, title_proc): Realloc str_list as - needed; don't assume MAXLISTLEN is enough. - * cvs.h (MAXLISTLEN, MAXFILEPERDIR): Removed; no longer used. - * add.c, myndbm.c, parseinfo.c, update.c: Nuke MAXLINELEN limit. - * parseinfo.c, update.c, mkmodules.c: Check for errors reading file. - * cvs.h (MAXLINELEN): Removed; no longer used. - * logmsg (MAXHOSTNAMELEN): Removed; not used. - * main.c (cmd_synonyms): Allocate based on fullname, nick1, and - nick2, just in case someone makes those big enough so that 100 - bytes is not enough. - (Make_Date): Use MAXDATELEN rather than our own fixed size. - * mkmodules.c (mkmodules): Nuke arbitrary limit on line length. - * rcs.c (ALLOCINCR): Remove; not used. - (RCS_check_kflag): Add comment concerning karg size. - * run.c: Allocate run_prog to the needed size, rather than - allocating a fixed size buffer. - -Fri Mar 7 22:39:08 1997 Jim Kingdon <kingdon@harvey.cyclic.com> - - * logmsg.c (logfile_write): Allocate prog to needed length rather - than assuming MAXPROGLEN is enough. - * cvs.h (MAXPROGLEN): Removed; no longer used. - * subr.c (MIN_INCR): Update comment to reflect MAXPROGLEN's demise. - - * subr.c (free_names): Fix comment: this function is not used to - free memory allocated by Find_Names (at least it hasn't for a long - time). - * subr.c, cvs.h (line2argv): Change calling convention so that we - allocate argv array rather than the caller. The previous one had - no way of checking whether we overflowed the passed-in buffer. - * subr.c (free_names): Free the argv array too. - * modules.c (do_module, cat_module): Update callers. - -Thu Mar 6 12:44:42 1997 Jim Kingdon <kingdon@harvey.cyclic.com> - - * import.c: Allocate vhead and vbranch dynamically; removes - arbitrary limit. - * history.c: Likewise (since_rev, since_tag, backto, rec_types). - * ignore.c: Likewise (line). Also check for errors from getline - and add 'copyright' notice to top of file. - * wrapper.c (wrap_add_file): Likewise (line). Also check for - errors from various calls and add 'copyright' notice to top of file. - -Tue Mar 4 17:39:15 1997 Jim Kingdon <kingdon@harvey.cyclic.com> - - * client.c (update_entries): Add comment about "move away <file>" - message. - -Mon Mar 3 21:51:40 1997 Jim Kingdon <kingdon@harvey.cyclic.com> - - * sanity.sh (basicb): Clean up topfile,v at end of test. Fixes - failure in modules-155b. - -Sun Mar 2 18:11:09 1997 Dan Wilder <dan@gasboy.com> - and Jim Kingdon - - * admin.c (admin): Arrange to perform recursion if "cvs admin" - is passed only options. - -Sun Mar 2 18:11:09 1997 Jim Kingdon <kingdon@harvey.cyclic.com> - - * sanity.sh (basicb): New tests basicb-0* test for files at top - level. - - * error.c (error): Add newline to "out of memory" message. I think - that its omission probably could cause the message to be lost in - the bowels of server.c and never passed to the user. - - * client.c (start_rsh_server): Add comment about "remsh" vs. "rsh". - - * cvs.h: Move copyright notice to top of file. - -Sun Mar 2 13:44:36 1997 Ian Lance Taylor <ian@cygnus.com> - - * sanity.sh: Use -n when testing whether rsh works. - - * server.c (serve_root): Free path. - -Sun Mar 2 13:12:46 1997 Jim Kingdon <kingdon@harvey.cyclic.com> - - The following are things that I noticed in the process of trying - to track down: - can't create temporary directory - Unknown error -1 - FAIL: test 28 - from nightly testing. I'm not sure that either item explains that - message however. - * server.c (server): Allocate pending_error_text; - print_pending_error will try to free it so - pending_error_text = "foo" - won't work. - (mkdir_p): Don't assume that isdir will leave errno unmolested. - -Thu Feb 27 15:29:58 1997 Ian Lance Taylor <ian@cygnus.com> - - * remove.c (cvsremove): When forcing removal in client mode, use - start_recursion rather than calling CVS_UNLINK on each argument. - (remove_force_fileproc): New static function. - * sanity.sh (deep): Add tests deep-rm7 through deep-rm10 for above - patch. - - * sanity.sh (death): Enable death-76a0 and death-76a1 tests for - remote, since they now work. - -Wed Feb 26 16:13:26 1997 Ian Lance Taylor <ian@cygnus.com> - - * client.c (add_prune_candidate): Skip adding this directory if - it is the same as the first directory already on the list. - -Mon Feb 24 21:36:43 1997 Noel Cragg <noel@gargle.rain.org> - - * main.c (lookup_command_attribute): Add the "init" command to the - list of commands that don't use the current working directory. - -Sun Feb 23 09:54:49 1997 Jim Kingdon <kingdon@harvey.cyclic.com> - - * sanity.sh (devcom3): Clean up at end of test. - - * sanity.sh (basicb): Add commented out test basicb-8a0, for - whether CVS can print an error on bad numeric revision to diff. - Commented out until we get around to fixing CVS. - * diff.c (diff_file_nodiff): Add comment about this case. - - * fileattr.c (fileattr_read): If a filename is duplicated, - continue to ignore subsequent lines but free the node so that we - don't leak memory. - * sanity.sh (devcom3): New tests devcom3-8 and devcom3-9 test for - behavior on duplicated filenames. - - * fileattr.h: Add comment about unrecognized ENT-TYPE and order of - lines in fileattr file. - * fileattr.c (struct unrecog, unrecog_head): New variables, to - record unrecognized lines. - (fileattr_startdir): Assert that unrecog_head == NULL. - (fileattr_read): Record unrecognized lines in unrecog_head linked - list rather than ignoring them. - (fileattr_write): Also write out unrecognized lines, if any. - * sanity.sh (devcom3): New tests, test for above fix. - - * fileattr.h (fileattr_modify): Fix example in comment. - -Sat Feb 22 08:30:27 1997 Jim Kingdon <kingdon@harvey.cyclic.com> - - * sanity.sh: Add variable username. - (basica rdiff multibranch log log2): Use it instead of our own - (inconsistent) ways of matching an author name. - - * filesubr.c, root.c, rtag.c, server.c, subr.c, update.c, - wrapper.c: Nuke PATH_MAX. - * cvs.h, wrapper.c (wrap_fromcvs_process_file): Now returns void - (return value had been unused). - * cvs.h: Adjust comment to reflect the fact that PATH_MAX is - gone, at least from src/*.c (except safe_location, as noted). - -22 Feb 1997 patch by Tom Hageman <tom@basil.icce.rug.nl> (4 Jun 1996) - updated and commented by Jim Kingdon <kingdon@harvey.cyclic.com> - - * update.c (checkout_file): Call unlink_file_dir on backup, not - unlink_file. - -Fri Feb 21 16:40:03 1997 Jim Kingdon <kingdon@harvey.cyclic.com> - - * Makefile.in (DISTFILES): Remove NOTES. - - * NOTES: Removed. bcopy->memcpy is done. "static buffers" I - assume refers to what is covered by reentrancy text in HACKING. - Obstack idea moved to comment in hash.c (at nodecache). Checking - system calls for error returns largely done, and isn't a very - helpful suggestion unless you know where the bogus calls are - anyway. Sizing limits--we're in the progress of removing them - (assuming it meant things like PATH_MAX and earlier, already - nuked, limits). Removed various items about changes which were - done a long time ago (I realize that the ChangeLog's probably - aren't reliable that far back, but I'm not convinced anyone cares - anymore). CONFIRM_DIRECTORY_ADDS: I assume this is a - reference to the #if 0'd code in add_directory which asks for - confirmation--a better way of making it harder to accidentally add - directories would be to have to add and commit directories like - for files. I don't know what FORCE_MESSAGE_ON_ADD meant. - - * rcs.c (RCS_getrevtime): Fix documentation (in particular, the - size of the array that DATE must point to, but many other things - too). - * patch.c, recurse.c, release.c, remove.c, repos.c: Nuke PATH_MAX. - (patch_fileproc): Use MAXDATELEN not hardcoded 50. - -Sun Feb 16 12:00:44 1997 Jim Kingdon <kingdon@harvey.cyclic.com> - - * client.c (client_process_import_file): New variable fullname; - pass it to send_modified. This finishes the job of untangling the - old short_pathname variable into update_dir vs. fullname. - - * client.c (client_process_import_file): Nuke first_time. If - toplevel_repos were ever NULL here, the code would dump core in - strncmp a few lines down. And client_import_setup ensures - toplevel_repos is not NULL. - -Sun Feb 16 08:16:48 1997 Ian Lance Taylor <ian@cygnus.com> - - * client.c (client_process_import_file): Rename short_pathname to - update_dir (to reflect its function) and make sure that it doesn't - point to uninitialized memory if repository and toplevel_repos - contain the same string. - -Sun Feb 16 08:16:48 1997 Jim Kingdon <kingdon@harvey.cyclic.com> - - * client.c (start_rsh_server): Nuke comment about weirdnesses with - pre-1.5 versions of CVS and .bashrc/.cshrc. The remote protocol - is interoperable only back to 1.5, and people who need to know are - unlikely to see this comment anyway. - -Sun Dec 15 13:12:30 1996 Michael Douglass <mikedoug@texas.net> - and Jim Kingdon <kingdon@harvey.cyclic.com> - - * main.c (cmds): Added an entry for new logout command. - (cmd_usage): Added an entry for new logout command. - (lookup_command_attribute): Added 'logout' to list of commands - that set need_to_crate_root to 1. - * login.c, cvs.h (logout): New command for removing entries from - the .cvspass file. - (logout_usage): Usage information on the logout command. - -Wed Feb 12 11:19:42 1997 Jim Kingdon <kingdon@harvey.cyclic.com> - - * client.c (struct send_data): Fix indentation. - -Wed Feb 12 08:48:04 1997 Greg A. Woods <woods@most.weird.com> - - * mkmodules.c (loginfo_contents): add missing comma in - initializer statement (caused syntax error on SunOS-4). - -Tue Feb 11 21:14:28 1997 Ian Lance Taylor <ian@cygnus.com> - - * commit.c (find_fileproc): If force_ci is set, set the status to - T_MODIFIED even if the file hasn't changed. - (commit): Pass force_ci to send_files as new force argument. - * client.c (struct send_data): Define. - (send_fileproc): The callerdat parameter now points to a send_data - struct. If force is set, always call send_modified. - (send_dirent_proc): The callerdat parameter now points to a - send_data struct. - (send_files): Add force parameter. Change all callers. Set up a - send_data struct and pass it to start_recursion as callerdat. - * client.h (send_files): Update declaration. - * sanity.sh (basica): Add a simple test for the above patch. - -Sun Feb 9 12:58:59 1997 Jim Kingdon <kingdon@harvey.cyclic.com> - - * tag.c (cvstag), rtag.c (rtag): Pass -f to server if specified in - the client. I haven't tried to come up with a test case because - the fix seems obvious. - - * import.c (add_rcs_file): Change size of altdate1 and altdate2 to - MAXDATELEN. - * cvs.h (MAXDATELEN): Fix comments; describe what this is for. - - * diff.c (diff_usage): Document --ifdef and try to briefly say - what "rcsdiff-options" means. - - * update.c (update): If update had a nonzero status and we haven't - yet tried to fetch unpatchable files, go ahead and try it again. - The previous behavior was to quit, which meant that updates would - keep failing until you hacked around the problem. Patch and bug - report by Ian; comment, ChangeLog entry, and willingness to take - the flak if checking it is premature by Jim. - - * server.c (alloc_pending): New function. - * server.c: Call it. Fixes places where we had neglected to - check for NULL return from malloc. - - * sanity.sh (binwrap): Add test binwrap-0, tests for import.c fix - below. - -Sun, 9 Feb 1997 (submitted 19 Jul 1996) John Polstra <jdp@polstra.com> - - * import.c (import): Give error if the same tag is specified more - than once. The previous behavior was to write an RCS file which - had the same tag listed twice, once pointing to each revision, - which is not legal. - -Sun Feb 9 12:37:09 1997 Jim Kingdon <kingdon@harvey.cyclic.com> - - * checkin.c (Checkin): Use cvs_output to print message (should - make out of order bugs no worse, as it merely substitues a - protocol_pipe vs. stderr_pipe race instead of a stdout_pipe - vs. stderr_pipe race). Add comment about stdout vs. stderr. - -Fri Feb 7 08:29:52 1997 Josef Nelissen <josef.nelissen@munich.ixos.de> - - * server.c (check_command_legal_p): Don't use ANSI-style definition. - -Thu Feb 6 10:55:37 1997 Jim Kingdon <kingdon@harvey.cyclic.com> - - * patch.c (patch): Give a fatal error for -V option (see comment - for rationale). - - * diff.c (diff): Also send "options" to server. Pretty much the - patch submitted independently by josef.nelissen@munich.ixos.de and - Ronald Khoo <ronald@demon.net>. - -Wed Feb 5 18:57:14 1997 Jim Kingdon <kingdon@harvey.cyclic.com> - - * modules.c (do_module): Fix typo in 30 Jan 97 PATH_MAX nuking - (free -> free_cwd). Testsuite test 151 gets credit for catching - this one. - -Mon Feb 3 16:14:54 1997 Ian Lance Taylor <ian@cygnus.com> - - * main.c (lookup_command_attribute): Don't use an ANSI prototype - when defining the function. - -Fri Jan 31 12:49:02 1997 Ian Lance Taylor <ian@cygnus.com> - - * modules.c (do_module): Actually goto found if is_found is set - (fixes thinko in PATH_MAX nuking of 30 Jan 97). - -Fri Jan 31 12:49:02 1997 Jim Kingdon <kingdon@harvey.cyclic.com> - - * sanity.sh: Add modules3 and big to list of tests to run - by default; they were omitted by accident. - -Thu Jan 30 11:46:33 1997 Jim Kingdon <kingdon@harvey.cyclic.com> - - * logmsg.c, main.c, mkmodules.c, modules.c, parseinfo.c, patch.c: - Nuke more PATH_MAX. - - * server.c (server_updated): After we send Created or - Update-existing for a file, mark it as unchanged, in case we - process it again. - * sanity.sh (modules3): New tests, test for above fix. - - * logmsg.c (do_verify): Error return from fopen is NULL, not -1. - Pass errno to error(). - - * login.c [_CRAY]: Don't declare getpass. - -Mon Jan 27 17:25:27 1997 Jim Kingdon <kingdon@harvey.cyclic.com> - - * import.c (process_import_file): Fix freeing of rcs (Don't free - it before we are done using it, and don't free it twice). - - * modules.c (cat_module): Allocate line right before we use - it. The previous code was wrong because the length of the - s_h->rest changes between the time we allocate line and the time we - sprintf s_h->rest into it. - -Sun Jan 26 21:58:16 1997 Jim Kingdon <kingdon@harvey.cyclic.com> - - * expand_path.c (expand_path): Revise to call expand_string as - needed. Nuke PATH_MAX. - * find_names.c (find_dirs): Likewise. - * import.c, lock.c: Nuke more PATH_MAX. - - * server.c (mkdir_p): Set retval to 0 at start of function. - Previously it had been uninitialized for some cases. Thanks are - due to nightly testing for catching this one. - -Sat Jan 25 21:34:19 1997 Jim Kingdon <kingdon@harvey.cyclic.com> - - * subr.c, cvs.h (expand_string): New function. - * rcs.c (getrcskey, getrcsrev): Call it. This greatly reduces the - number of calls to realloc if there is a very large file in the - RCS file. Credit goes to Mike Heath <mike@pswtech.com> for - pointing out the problem and the basic solution (MIN_INCR, - MAX_INCR); I adapted it into the separate function expand_string. - * sanity.sh (big): New test helps insure this hasn't broken - anything obvious. - -Wed Jan 22 10:06:13 1997 Jim Kingdon <kingdon@harvey.cyclic.com> - - * status.c (status_fileproc): Change message which is printed for - T_MODIFIED and ts_conflict set, so that it doesn't say "unresolved - confict". This message occurs whether the conflict is resolved or - not. - * sanity.sh (conflicts): Add tests conflicts-status-* to test - output of "cvs status" in the context of conflicts. Tests for - above fix. - - * rtag.c (rtag): Send -n if run_module_prog is NOT true. - -Thu Jan 16 00:06:00 1997 Jim Kingdon <kingdon@harvey.cyclic.com> - - * version.c: Change version number to 1.9.3. - - * version.c: Version 1.9.2. - -Wed Jan 15 09:14:38 1997 Jim Kingdon <kingdon@harvey.cyclic.com> - - * client.c (call_in_directory): Take code that creates CVSADM at - top level, move it before the CVS_CHDIR (dir_name) call, and do it - regardless of whether dir_name is ".". Pass "." not dir_name to - Create_Admin (when the code was written they were always the - same). Don't add reposdirname to the repository we pass to - Create_Admin (when the code was written, I think reposdirname - probably would always be "."). Don't create CVSADM if - reposdirname_absolute. - * sanity.sh (basicb): Enable tests basicb-1a and basicb-9a for - remote; tests for above fix. - (basic1): Do entire test within a "1" directory to deal with - creation of CVS directories at top level. Support --keep. - (conflicts): In test conflicts-136, only update first-dir. - (basica): Uncomment the part that tests "cvs co -l .". That tests - the existing functionality which I might have (but hopefully did not) - perturbed with the call_in_directory changes. - -Mon Jan 13 11:04:32 1997 Jim Kingdon <kingdon@harvey.cyclic.com> - - * server.c (check_command_legal_p): Do not call error (1, ...) - here; that will always cause a protocol violation by shutting down - the connection prematurely. Remove croak_on_illegal arg. - (do_cvs_command): Move call to check_command_legal_p until after - the call to print_pending_error. Print the error message ourself. - - * mkmodules.c (filelist): Add readers and writers. Add comment - about why passwd is not included. Add comment about meaning of - NULL contents field. - -Fri Jan 10 13:23:09 1997 Norbert Kiesel <nk@col.sw-ley.de> - - * release.c (release): Initialize delete_flag before reading it - (found by running purify) - - * logmsg.c (do_verify): Fix reading unallocated memory (found by - running purify) - -Thu Jan 9 16:32:47 1997 Jim Kingdon <kingdon@harvey.cyclic.com> - - * checkout.c (build_dirs_and_chdir): Partially revert 3 Jan - change--move call to Subdir_Register back above the CVS_CHDIR call - (we need to register in the old, not the new, directory). Instead - of calling CVS_MKDIR and ignoring errors, call mkdir_if_needed; - this is an effort to catch errors there rather than catching them - in the CVS_CHDIR. This makes test 27-add-add in sanity.sh work - again. - - * find_names.c (Find_Directories): Remove code inside - #ifdef ATTIC_DIR_SUPPORT and replace it with a comment explaining - why we don't look in the attic. ATTIC_DIR_SUPPORT was never defined. - - * find_names.c (find_dirs): Add comment about tmp being unset. - - * commit.c (checkaddfile): Report errors with errno and specific - error messages. - - * rcs.c, commit.c, create_adm.c, entries.c, find_names.c, - ignore.c, history.c: Nuke PATH_MAX arbitrary limits. - -Wed Jan 8 23:07:41 1997 Jim Kingdon <kingdon@harvey.cyclic.com> - - * add.c (add): Reindent a portion which needed it. - -1997-01-08 Jim Kingdon - - * client.c (send_file_names): When looking name up in Entries, - call Entries_Open and Entries_Close. This has two effects: - (1) we look at Entries.Log, and (2) we don't skip 'D' entries, - both of which are needed to make us get the right (command - line) name for a directory we are adding. - -Wed Jan 8 14:50:47 1997 Jim Kingdon <kingdon@harvey.cyclic.com> - - * Makefile.in, cvs.h, hash.h, myndbm.h, rcs.h: Remove CVSid; we - decided to get rid of these some time ago. - -Tue Jan 7 12:56:10 1997 Karl Fogel <kfogel@ynu38.ynu.edu.cn> - - * root.c (check_root_consistent): new func, compares below new - global var with CVSroot_directory, assuming both set. - (set_local_cvsroot): use above new func for security check. - (parse_cvsroot): same. - But do all of above only #ifdef AUTH_SERVER_SUPPORT. - - * server.c: (Pserver_Repos): new global var, init to NULL. - (pserver_authenticate_connection): set above new global. - (check_repository_password): be a good scout and use - CVSROOTADM and CVSROOTADM_PASSWD, now that they are the standard. - Make sure all of above is in #ifdef AUTH_SERVER_SUPPORT. - (check_command_legal_p): wrap most of body in #ifdef - AUTH_SERVER_SUPPORT. - Everywhere: wrap all references to CVS_Username in #ifdef - AUTH_SERVER_SUPPORT. - - * cvs.h (Pserver_Repos): new var, used in consistency [security] - check. Defined only #ifdef AUTH_SERVER_SUPPORT. - (CVSROOTADM_PASSWD): new #define, trying to get with the program. - -Fri Jan 3 18:10:39 1997 Ian Lance Taylor <ian@cygnus.com> - - * checkout.c (build_dirs_and_chdir): Move call to Subdir_Register - until after we know that the directory exists. - -Thu Jan 2 13:30:56 1997 Jim Kingdon <kingdon@harvey.cyclic.com> - - * Makefile.in, cvsbug.sh, edit.c, edit.h, error.c, error.h, - fileattr.c, fileattr.h, filesubr.c, run.c, update.h, watch.c, - watch.h: Remove "675" paragraph; see ../ChangeLog for rationale. - -Thu Jan 2 12:27:46 1997 Jim Kingdon <kingdon@harvey.cyclic.com> - - * sanity.sh (info): New test info-cleanup-verifymsg gets rid of - verifymsg when we are done with it. - - * sanity.sh (basicb): Skip tests basicb-1a and basicb-9a for remote. - * sanity.sh (modules-155a4): It is OK if a CVS directory exists. - * sanity.sh (ignore): Do everything inside a "1" directory. The - change to create CVS directories at top-level causes messages such as - "? home" otherwise. In test 191, specify -I CVS so that new CVS - directory is ignored. - * sanity.sh (crerepos): Manually remove CVS directory which had not - existed before. - -Thu Jan 2 09:06:20 1997 Karl Fogel <kfogel@ynu38.ynu.edu.cn> - - * server.c: Changes for pserver read-only repository access: - (check_command_legal_p): new func. Right now, just checks if - repository modification is permitted, and that only if pserver is - active. - (do_cvs_command): take new parameter `cmd_name', a string. All - callers changed. Pass it on to new func check_command_legal_p() - before executing the command. - (CVS_Username): new global, init to NULL. Used by - check_command_legal_p(), set in check_password(). - (check_password): set above new global CVS_Username; reorganized a - bit to facilitate this. - (check_repository_password): give *host_user_ptr permanent - storage iff success. - - * main.c: Changes for pserver read-only repository access: - (lookup_command_attribute): new func. - (main): use new func lookup_command_attribute() to establish if - CVS_CMD_IGNORE_ADMROOT and CVS_CMD_USES_WORK_DIR. - - * cvs.h: Changes for pserver read-only repository access: - (CVSROOTADM_READERS, CVSROOTADM_WRITERS): new #defines. - Prototype lookup_command_attribute(). - (CVS_CMD_IGNORE_ADMROOT, CVS_CMD_USES_WORK_DIR, - CVS_CMD_MODIFIES_REPOSITORY): new #defines for - lookup_command_attribute() and its callers. - -Wed Jan 1 19:50:38 1997 Jim Kingdon <kingdon@harvey.cyclic.com> - - * options.h.in: Reword comment for TMPDIR_DFLT to make it clear - that this isn't specific to the pserver server. - - * modules.c (do_module): Give an error message if one tries to - specify -a together with another option. - * sanity.sh (modules2): New tests modules2-a* test for above fix. - - * sanity.sh (devcom): Add tests devcom-a-nonexist and - devcom-t-nonexist for "cvs watchers" on nonexistent argument. - -1997-01-01 Fred Fish <fnf@ninemoons.com> - - * run.c (piped_child, filter_stream_through_program): Actually - install these HAVE_VFORK patches that got missed. - (There was a log entry for these changes for 29 Nov 1996 but it - seems I accidentally forgot to actually check them in -kingdon). - -Wed Jan 1 18:32:44 1997 Jim Kingdon <kingdon@harvey.cyclic.com> - - * Makefile.in: Add ChangeLog-96. - * ChangeLog-96: New file, contains former contents of ChangeLog. - * ChangeLog: Now just contains 1997 changes. - - -For older changes see ChangeLog-96. +For older changes see ChangeLog-97. diff --git a/contrib/cvs/src/ChangeLog-97 b/contrib/cvs/src/ChangeLog-97 new file mode 100644 index 0000000..ce7180b --- /dev/null +++ b/contrib/cvs/src/ChangeLog-97 @@ -0,0 +1,3249 @@ +1997-12-30 enami tsugutomo <enami@but-b.or.jp> + + * rcs.c (RCS_checkin): Use gmtime() instead of localtime() + (restores behavior from RCS 5.x which was broken with RCS library + -kingdon). + +Mon Dec 29 12:53:00 1997 Ian Lance Taylor <ian@cygnus.com> + + * modules.c (do_module): Check for a request for a file within a + module which is not a directory. + * sanity.sh (modules): Add test 149b1 for above patch. + + * client.c (start_tcp_server): Remove useless assignment, left + behind by Dec 15 patch. + +Sat Dec 27 17:41:11 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * client.c, options.h.in, history.c, import.c, main.c, rcs.c, + update.c: Remove !HAVE_RCS5 code. It had bit-rotted a while ago, + and more to the point is obsolete with the RCS library. + +27 Dec 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * zlib.c, server.h (gunzip_and_write): New function. + * client.c (update_entries): Call it instead of a gunzip subprocess. + * zlib.c, server.h (read_and_gzip): New function. + * client.c (send_modified): Call it instead of a gzip subprocess. + +Sat Dec 27 13:07:38 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + Decrease RCS_deltas memory usage to what we need (approximately + the size of the file we are patching plus the size of the largest + patch). Previously memory usage had been approximately the size + of the RCS file because we never freed lines until the end. + * rcs.c (linevector_free, linevector_copy, linevector_add, + linevector_delete): + Instead of having all the lines and struct line's in the alloc_* + space, have each line and its struct line in its own malloc'd + space. Use a refcount to deal with curlines vs. headlines + vs. trunklines in RCS_deltas. + (struct allocblock, blocks, block_alloc, block_free): Remove; no + longer used. + (apply_rcs_changes, RCS_deltas): Don't copy lines into allocated + space; linevector_add now does that for us. + (rcs_change_text, RCS_deltas): Don't call block_free. + +Tue Dec 23 08:28:44 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvsbug.sh: Change bug-cvs address from prep.ai.mit.edu to gnu.org + per email from Martin Hamilton. + +Sun Dec 21 21:49:50 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * rcs.c (RCS_checkin): Disable keyword expansion when generating + the change text. + * sanity.sh: Move tests keyword-24 through keyword-27 into + new section keywordlog and expand greatly. Note that CVS 1.9.18 + passes the new tests both local and remote but the current + version failed them both local and remote before this fix. + +Sat Dec 20 19:56:00 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * rcs.c (RCS_delete_revs): Clean up temporary files even if noexec. + Without this fix, basica-o5a in sanity.sh would leave files around. + +Thu Dec 18 13:05:00 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * run.c: Fix typo in declaration (evecvp -> execvp) (credit to + Erik Walthinsen for reporting this). Only declare it if not + HAVE_UNISTD_H. Move declaration to before the first use. + +Tue Dec 16 12:59:00 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * update.c: Collapse two identical declarations for join_file. + +Mon Dec 15 16:01:49 1997 Ian Lance Taylor <ian@cygnus.com> + + * client.c (start_tcp_server): Remove calls to htons and add one + call to ntohs (init_sockaddr calls htons on the port argument). + +Mon Dec 15 00:07:02 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * client.c (failure_exit): New variable. + (get_server_responses): If it is set, then return + failure. + (updated_seen, updated_fname): New variables. + (update_entries): Use updated_fname if set. In the "move away + foo.c; it is in the way" case print "C" not "U", and set + failure_exit. + (handle_mt): If we get +updated tagged text, stash it away in + updated_fname rather than printing it immediately. + (handle_mt, get_server_responses): If we stashed a filename and + didn't get around to printing it, go ahead and print it. + * sanity.sh (conflicts2-142d2): Adjust to test for fix. Remote is + now like local was in terms of exit status and "C aa.c" message. + +Sun Dec 14 00:27:26 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + Implement tagged text feature: + * update.c (write_letter): Take a single finfo argument rather + than file and update_dir. While we are at it change it to return + void (since the returned value always had been 0). + * update.c: Update callers. + * server.c, cvs.h (cvs_output_tagged): New function. + * client.c (responses): Add "MT" response. + (handle_mt): New function. + * update.c (write_letter): Output via cvs_output_tagged. + +Sun Dec 14 14:13:05 1997 Ian Lance Taylor <ian@cygnus.com> + + * recurse.c (do_dir_proc): Only check for CVS/Repository if + W_LOCAL. + * sanity.sh (devcom-t2, devcom-t3): New tests for above patch. + +Sun Dec 14 00:27:26 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * root.c (parse_cvsroot): Initialize check_hostname (fixes thinko + in GSSAPI changes). + +Sat Dec 13 13:15:35 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * server.c: Use indentation to indicate nesting of #ifdef's. + + * client.c (connect_to_gserver): Reindent (in one place). + +Fri Dec 12 17:38:15 1997 Chris Provenzano <proven@cygnus.com> + and Ian Lance Taylor <ian@cygnus.com> + + * cvs.h (CVSmethod): Add gserver_method. + * root.c (method_names): Add gserver. + (parse_cvsroot): Handle :gserver:. + * client.h (cvsauthenticate): Declare. + (cvs_gssapi_encrypt): Declare if HAVE_GSSAPI and ENCRYPTION. + (cvs_gssapi_wrap_buffer_initialize): Declare if HAVE_GSSAPI. + (connect_to_pserver): Update declaration. + (pserver_authenticate_connection): Declare when HAVE_GSSAPI and + SERVER_SUPPORT is defined in addition to other case. + * client.c: If HAVE_GSSAPI, include GSSAPI header files. + (gcontext): New static variable if HAVE_GSSAPI. + (connect_to_pserver): Add do_gssapi parameter. Change all + callers. Move rejection handling to bottom of function. + (recv_bytes): New static function if HAVE_GSSAPI. + (connect_to_gserver): Likewise. + (start_server): Handle gserver_method. Handle GSSAPI encryption + and authentication. + * server.c: Include <sys/socket.h> if HAVE_GSSAPI, in addition to + existing cases. If HAVE_GSSAPI, include GSSAPI header files. + Include <grp.h> even if AUTH_SERVER_SUPPORT is not defined. + (gcontext, cvs_gssapi_wrapping): New static variables if + HAVE_GSSAPI. + (cvs_gssapi_encrypt): New global variable if HAVE_GSSAPI and + ENCRYPTION. + (serve_gssapi_encrypt): New static function if HAVE_GSSAPI and + ENCRYPTION. + (serve_gssapi_authenticate): New static function if HAVE_GSSAPI. + (requests): Add Gssapi-encrypt if HAVE_GSSAPI and ENCRYPTION. Add + Gssapi-authenticate if HAVE_GSSAPI. + (switch_to_user): Compile if HAVE_GSSAPI, in addition to existing + cases. + (pserver_authenticate_connection): Likewise. Ifdef out part of + the code for AUTH_SERVER_SUPPORT. Handle a GSSAPI request. + (gserver_authenticate_connection): New static function if + HAVE_GSSAPI. + (cvsauthenticate): New global variable. + (struct cvs_gssapi_wrap_data): Define if HAVE_GSSAPI. + (cvs_gssapi_wrap_buffer_initialize): New function if HAVE_GSSAPI. + (cvs_gssapi_wrap_input): New static function if HAVE_GSSAPI. + (cvs_gssapi_wrap_output): Likewise. + * main.c (opt_usage): Mention -a. + (main): Handle -a. Handle pserver if HAVE_GSSAPI, in addition to + existing cases. + * login.c (login): Pass new argument to connect_to_pserver. + +Fri Dec 12 15:33:19 1997 Ian Lance Taylor <ian@cygnus.com> + + * buffer.c (PACKET_SLOP): Define. + (packetizing_buffer_initialize): Use PACKET_SLOP when allocating + holdbuf. + (packetizing_buffer_input): Allow up to PACKET_SLOP bytes in + stackoutbuf. + (packetizing_buffer_output): Use just BUFFER_DATA_SIZE + 2 for + inbuf. Allow PACKET_SLOP + 4 extra bytes in stack_outbuf. + Correct >= to > in test of incoming number of bytes. Use + PACKET_SLOP in other tests. + +Fri Dec 12 10:27:08 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * client.c (start_tcp_server): Revise comment to reflect + SOCK_STRERROR and SOCK_ERRNO now being in use. + +Thu Dec 11 15:32:31 1997 Ian Lance Taylor <ian@cygnus.com> + + * client.c (init_sockaddr): Compile if HAVE_KERBEROS, as well as + if AUTH_CLIENT_SUPPORT. Return a pointer to a struct hostent. + (start_tcp_server): Clean up. Use init_sockaddr. Use + SOCK_STRERROR and SOCK_ERRNO. Don't bind the socket. + + Generalize buffering code used by Kerberos encryption routines + into a generic packetizing buffer. The new code in buffer.c is a + modified version of the code removed from server.c. + * buffer.c (struct packetizing_buffer): Define. + (packetizing_buffer_initialize): New function. + (packetizing_buffer_input): New static function. + (packetizing_buffer_output): New static function. + (packetizing_buffer_flush): New static function. + (packetizing_buffer_block): New static function. + (packetizing_buffer_shutdown): New static function. + * buffer.h (packetizing_buffer_initialize): Declare. + * server.c (struct krb_encrypt_data): Rename from + krb_encrypt_buffer, and remove all fields not related to + encryption. + (krb_encrypt_buffer_initialize): Just call + packetizing_buffer_initialize. + (krb_encrypt_input): New static function. + (krb_encrypt_output): New static function. + (krb_encrypt_buffer_input): Remove. + (krb_encrypt_buffer_output): Remove. + (krb_encrypt_buffer_flush): Remove. + (krb_encrypt_buffer_block): Remove. + (krb_encrypt_buffer_shutdown): Remove. + +Wed Dec 10 15:39:44 1997 Ian Lance Taylor <ian@cygnus.com> + + * buffer.c (stdio_buffer_initialize): Correct formatting. + +Sun Dec 7 09:37:19 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * sanity.sh (basicb-0d0): New test, for checkout on existing + directory. + +Sat Dec 6 00:25:11 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * sanity.sh (binwrap3): Clean up repository too. Clean up working + directory with "rm -r" not "rm -rf". + +Thu Dec 4 17:11:18 1997 Larry Jones <larry.jones@sdrc.com> + + * subr.c (check_numeric): Don't reference argv[1] when argc is 1 + (should be argv[0]). + + * sanity.sh: Fix lines that look like conflict markers but aren't + to prevent problems checking in. + (binwrap3): Remove local CVSROOT when done so that later + tests that expect to create it don't fail. + +Thu Dec 4 18:19:21 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvs.h: Remove mempcpy definition. I think the polite way to + describe my feelings about mempcpy is something like "we don't + have agreement that it is a good idea". + * rcs.c (truncate_revnum): Don't call it. + * sanity.sh: Run multibranch2 test by default. + (multibranch2): Use ${TESTDIR} a few places. + (multibranch2-9): Accept "P file1" as well as "U file1". + + * sanity.sh: Don't add 1997 to the copyright notice. Add GPL + terms. Add discussion of copyright issues. + * rcs.c (truncate_revnum, truncate_revnum_in_place, + compare_truncated_revnums): Reindent. + +1997-12-04 Jim Meyering <meyering@na-net.ornl.gov> + + * subr.c (xstrdup): Use memcpy rather than strcpy. + (compare_revnums): Declare parameters to be `const'. + Remove unnecessary uses of xstrdup and corresponding frees. + (increment_revnum): Declare parameter to be `const'. + Use memcpy rather than strcpy. + (gca): Declare parameters to be `const'. + (check_numeric): Declare REV parameter to be `const'. + (file_has_markers): Declare parameter to be `const'. + (get_file): Declare `char*' parameters to be `const'. + * run.c (run_exec): Declare `char*' parameters to be `const'. + * cvs.h (mempcpy) [! HAVE_MEMPCPY]: Define it. + Add `const' to types in several prototypes. + + * rcs.c (truncate_revnum): New function. + (truncate_revnum_in_place): New function. + (compare_truncated_revnums): New function. + (max_rev): New function. + (RCS_addbranch): Make BRANCH parameter `const'. + Use the above functions rather than open-coding them. + When BRANCH is a revision number, insert it *in order* + in the sorted list of branch numbers, not at the end. + Add assertion that insertion succeeds. + * sanity.sh (multibranch2): Test for this. + (Copyright): Add 1997. + +Dec 1997 Karl Fogel <kfogel@floss.red-bean.com> + + * wrapper.c (wrap_name_has): loop as far as wrap_count + + wrap_temp_count, not wrap_count + wrap_saved_count, otherwise + some wrappers get skipped. + (wrap_matching_entry): same. + * sanity.sh (binwrap3): new test, for import with + CVSROOT/cvswrappers and .cvswrappers specifying -k 'b' options. + +1997-11-30 Jim Meyering <meyering@na-net.ornl.gov> + + * client.c (send_a_repository): Strip trailing slashes from the name + of the update directory. Otherwise, running `cvs update dir/' provokes + this failure `protocol error: illegal directory syntax in dir/' when + running in client/server mode. + + * hash.c (insert_before): New function derived from addnode. + (addnode): Simply return insert_before. + (addnode_at_front): Simply return insert_before. + * hash.h (insert_before): Add prototype. + + * server.c (dirswitch): Compute `strlen(dir)' once and save it, + rather than computing it four times. Also do s/illegal/invalid/ to + this diagnostic: "E protocol error: illegal directory syntax in %s". + +Sun Nov 30 18:03:02 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * admin.c: Fix comment (no longer a front-end to "rcs"). + + * error.c, error.h (rcserror): Remove. + * admin.c, rcs.c: Call error instead of rcserror. This changes + the format of these messages from "rcs: <path>: error" to "cvs + <command>: <path>: error". The former format wasn't quite what + RCS printed anyway (because RCS would sometimes print "ci", "co", + &c, not "rcs"), and preserving RCS's exact output probably is not + a good idea anyway (because it will make people think that the + error was caused by an external program). In two cases, I tidied + up the message in a more drastic fashion ("cannot stat" in + RCS_checkin and "could not diff" in RCS_delete_revs). + + * sanity.sh (basica-o2b, binfiles2-o1, admin-18, admin-22-o10, + admin-22-o17): Look for "cvs <command>" not "rcs". + + * run.c, cvs.h (run_setup): Replace varargs nonsense with a single + argument which gets parsed as the result of the vasprintf + used to. + * client.c, commit.c, logmsg.c, modules.c, rtag.c, tag.c, update.c, + wrapper.c: Update callers, either to do the sprintf themself or to + just call run_arg if it will do the job. + * rcscmds.c: Likewise for call_diff_setup and callers. + + * run.c, cvs.h (run_args): Remove; nowhere used. + +Sat Nov 29 22:15:06 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * options.h.in: Remove declaration of getwd; see lib/ChangeLog for + rationale. + +1997-11-29 Jim Meyering <meyering@na-net.ornl.gov> + + * update.c (checkout_file): Initialize `backup'. + + * diff.c (diff_fileproc): Initialize `tmp' and `fname'. + + * modules.c (do_module): Initialize `server_dir_to_restore'. + (do_module): Initialize `value' in an else clause. + + * rcs.c (RCS_checkin): Initialize `commitpt'. + (RCS_delete_revs): Initialize `revp'. + (RCS_copydeltas): Always initialize `insertbefore'. + + * run.c (run_print): Define `outfn' even in error case. + +Mon Nov 24 17:28:50 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * rcs.c (RCS_findlock_or_tip): Prototype. + (RCS_checkin): Fix call to pass correct number of arguments. + +Sun Nov 23 10:34:03 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * recurse.c (do_dir_proc): Move check for CVS/Repository and + CVS/Entries to before where we call the direntproc. + * client.c (send_dirent_proc): Remove code to check for + CVS/Repository, now that recurse.c does it. + * sanity.sh (conflicts3-18 through conflicts3-19): New tests, for this. + +Sat Nov 22 10:54:16 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * recurse.c (do_dir_proc): Check that CVS/Repository and + CVS/Entries exist. + * sanity.sh (conflicts3-14 through conflicts3-17): New tests, for this. + + * client.c (send_fileproc): Send options field from + vers->entdata->options not vers->options. + * cvs.h (struct entnode): Add comment (options and timestamp must + not be NULL). + * sanity.sh (binfiles-9 through binfiles-13, binfiles-sticky5, + keyword-17): Remove kludges for remote; tests for fix. + + * update.c (update_fileproc): Fix comment; direct checkout is + still faster than patches for local but not for quite the + same reasons. + + * add.c (add): Pass SEND_NO_CONTENTS to send_files. + +Wed Nov 19 18:25:03 1997 Mike Glendinning <mikeg@sequent.com> + + * update.c (patch_file_write): Missing cast provided. + +Wed Nov 19 15:57:59 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * rcs.c (RCS_deltas): Solve trigraph problem (once and for all, I + hope) with 3 calls to cvs_output. + +Wed Nov 19 01:52:57 1997 Andy Piper <andyp@parallax.co.uk> + and Jim Kingdon <kingdon@harvey.cyclic.com> + + * classify.c (Classify_File), cvs.h (struct vers_ts), vers_ts.c + (Version_TS): Clarify NULL versus "" for options in comments. + * vers_ts.c (Version_TS): Treat "" the same way as NULL in options + and vers_ts->options. + * sanity.sh: New tests binfiles-sticky5 through binfiles-17 test + for this. + +1997-11-16 Karl Fogel <kfogel@floss.red-bean.com> + + * client.c (update_entries): parse server-sent entries line even + in the case of "cvs export", because we need to know if -kb option + is set. + Init `options' to NULL like anything else. + +Tue Nov 18 09:20:29 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * version.c: Change version number to 1.9.21. + + * Version 1.9.20. + +Mon Nov 17 14:35:31 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * server.c (server_updated): If scratched_file and noexec are set, + clean up so we don't get a "duplicate Scratch_Entry" warning + later. + * sanity.sh: New tests conflicts3-10 to conflicts3-13, for this. + + * sanity.sh (conflicts3): Don't allow "file1 was lost" messages + here; I don't think CVS actually produced them, and they don't + belong. + +Sun Nov 16 23:19:41 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * sanity.sh: Accept either "U file1" or "P file1". + +Fri Nov 14 12:32:05 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * rcs.c: Add comment about cleaning up ,foo, file on ^C. + +Fri Nov 14 11:56:29 1997 Andy Piper <andyp@parallax.co.uk> + and Jim Kingdon <kingdon@harvey.cyclic.com> + + * filesubr.c (unlink_file_dir): Don't print trace message in the + server. + +Fri Nov 14 11:28:55 1997 Jim Meyering and Jim Kingdon + + * rcs.c (RCS_getdatebranch): If the branch we are looking for + doesn't exist, return a revision which matches the date, not + just NULL. + * sanity.sh (tagdate): New test, for this. + +Thu Nov 13 10:11:48 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * sanity.sh (basicb-21): Fix comment which described a behavior + which no longer exists. + +Wed Nov 12 16:24:45 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + Clean up infrastructure made unnecessary by RCS library: + * rcscmds.c (diff_exec, diff_execv): Use literal "diff" not DIFF. + * options.h.in (DIFF), rcs.h (RCS, RCS_CI, RCS_DIFF, + RCS_RCSMERGE): Removed; no longer used. + * commit.c (commit), patch.c (patch_fileproc), + rcscmds.c (RCS_exec_rcsdiff), start of rcscmds.c: Update comments + to reflect librarification of RCS. + * options.h.in (RCSBIN_DFLT): Removed. + * main.c, cvs.h (Rcsbin, free_Rcsbin): Removed. + * main.c (main): Don't check RCSBIN environment variable. -b + global option is now a noop. + * cvs.h (RCSBIN_ENV): Removed. + * expand_path.c (expand_variable): $RCSBIN is now an error. + * mkmodules.c (config_contents): Remove RCSBIN. + * parseinfo.c (parse_config): RCSBIN now a noop. + * server.c (server): Don't put Rcsbin in PATH. + +Mon, 10 Nov 1997 Jim Kingdon + + * rcs.c (RCS_checkin): Actually, when we get a change text + for a text file using get_file, we want text mode, although + the reasons are kind of subtle (see comment). + + * rcs.c (RCS_checkin): Pass correct mode to get_file for + binary files. + + * rcscmds.c: Declare vasprintf. + +Mon Nov 10 11:11:17 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + This fixes problems with windows-NT/run.c improperly quoting, and + is cleaner anyway. + * rcscmds.c (call_diff_setup, call_diff_arg, call_diff_add_arg, + call_diff_argv, call_diff_argc, call_diff_argc_allocated): New + functions/variables, lightly adapted from src/run.c. + * cvs.h, run.c (call_diff, call_diff3): Move from here... + * rcscmds.c: ...to here. + +Sun, 9 Nov 1997 Jim Kingdon + + * rcs.c (rcs_internal_unlockfile): Call rename_file not rename. + This makes it work on NT again. + +Sun Nov 9 16:54:28 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * sanity.sh (diffmerge2): Protect keywords against unwanted + expansion. They got clobbered and the testcase stopped working + when I checked it in. + +Fri Nov 7 13:23:38 1997 Karl Fogel <kfogel@floss.red-bean.com> + and Jim Kingdon <kingdon@harvey.cyclic.com> + + * sanity.sh (diffmerge1, diffmerge2): new tests, for bugs, or + potential bugs, in ../diff/analyze.c which were fixed by Paul + Eggert's patch. + +Sun Nov 9 10:28:43 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * rcs.c (RCS_settag): Reindent. + + * rcs.c (rcs_internal_lockfile): Fix typo (thow -> throw). + +Sat Nov 8 15:58:53 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * sanity.sh (cvsadm): Remove most of the tests which tested + CVS/Root. This takes the run time for the cvsadm tests from + about 5 minutes 15 seconds to about 4 minutes 10 seconds with no + significant loss in coverage. + + * rcs.c (rcs_internal_lockfile): Check for errors from system + calls. If open() gives an error, don't muck with stat and errno + (I don't know what the RCS code that this comes from was trying to + do, but it clearly isn't accomplishing anything here). + (RCS_rewrite, RCS_delete_revs): Check for errors from system calls. + +Sat Nov 1 14:21:29 1997 Michael L.H. Brouwer <michael@thi.nl> + + * rcs.c (RCS_checkin): Change type of bufsize from int to size_t. + (RCS_delete_revs): Change type of bufsize and len from int to size_t. + (RCS_getdeltatext): Change type of textlen from int to size_t. + * rcs.h (struct deltatext): Change len from int to size_t to keep + the compiler happy on systems where size_t is unsigned int. + [This goes well beyond keeping the compiler happy; if sizeof + (size_t) != sizeof (int), the old code was quite broken -kingdon] + +Sat Nov 1 14:21:29 1997 Michael L.H. Brouwer <michael@thi.nl> + and Jim Kingdon <kingdon@harvey.cyclic.com> + + * rcs.c (RCS_checkin): When checking if we were holding the lock + use delta->author instead of user since the latter might have been + clobbered by a call to getcaller. This resulted in the failure of + test basica-7. + [I don't completely follow the scenario where it gets clobbered, + it but sounds vaguely plausible and the replacement seems + cleaner, precisely because it avoids allocation issues -kingdon] + +Wed Nov 5 20:16:12 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * checkin.c, checkout.c, commit.c, cvs.h, import.c, login.c, + main.c, update.c: Change FALSE to 0 and TRUE to 1 and replace + monstrosities like "cvswrite == TRUE" with just "cvswrite". FALSE + and TRUE sometimes conflicted with system headers (NextStep3.3?), + but more to the point, good old 1 and 0 are fine and were used by + most of CVS already. + +Tue Nov 4 12:19:28 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * rcs.c (RCS_checkin, RCS_lock, RCS_unlock): Rename local variable + quiet to checkin_quiet or some such, to avoid confusion with + global variable quiet. + + * lock.c: Update comment to refer to add_rcs_file rather than "rcs + -i". + + * rcs.h (struct rcsnode): Add comments for all fields. + * rcs.c (RCS_delete_revs): Refuse to delete revisions which have + symbolic names. Fix fencepost bug which caused us to sometimes + check one more revision than we should for locks, branches, and + this. + (findtag): New function, to help above code. + + * admin.c (admin): Take out writelocks not readlocks. This has + been a bug "forever", but may become more noticeable with + rcs_internal_lockfile relying on the writelocks. + +Mon Nov 3 10:17:19 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * rcs.c (RCS_rewrite): Don't write the file if noexec. + * sanity.sh (basica, branches): Test for this. + +Sat Nov 1 10:01:56 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * rcs.h (struct deltatext): Comment text and log fields. + + * admin.c (admin_fileproc): Call RCS_reparsercsfile not + RCS_fully_parse. Don't muck with ->other field in RCSVers (it + doesn't need to be set). + * rcs.h, rcs.c (RCS_reparsercsfile): No longer static. No point + in having this static when RCS_rewrite and RCS_fully_parse are not. + * rcs.c (getdelta): Remove obsolete comment about not storing the + newphrases from the deltas, since we now do. + +Sat Nov 1 10:01:56 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + and Paul Eggert + + * rcs.c (rcs_internal_lockfile): Clarify the comments about O_EXCL + and such matters. + +Sat Nov 1 10:01:56 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * rcs.c (RCS_delete_revs): Pass force_tag_match to RCS_settag. + * sanity.sh (basica-o2a, basica-o2b): Test for this. + +1997-11-01 Peter Brandstrom <d91-pbr@nada.kth.se> + + * sanity.sh: Use ${username} more places. + +Sat Nov 1 00:14:00 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * rcs.c (rcs_internal_lockfile): Add comments about what we are + trying to accomplish here (versus what RCS tries to accomplish). + + * rcs.c (RCS_parsercsfile_i): Clarify/expand comment about + the purpose of having both this and RCS_reparsercsfile. + (RCS_rewrite): Add comment about how this works. + + * admin.c (admin_fileproc): Add comment about call to + RCS_fully_parse not RCS_reparsercsfile. + * rcs.h: Comment on what delta_pos field of struct rcsnode is. + +Fri Oct 31 16:38:39 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + and Abe Feldman + + * client.c (update_entries): If UTIME_EXPECTS_WRITABLE, if + necessary change the file to be writable temporarily to set its + modification time. + +Thu Oct 30 17:42:59 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * admin.c (admin): Deal with new :: syntax for ranges. + * rcs.c, rcs.h (RCS_delete_revs): New arg inclusive (set for the old + behavior, clear to enable new code). + * admin.c (admin_fileproc): Set it if :, clear it if ::. + * sanity.sh (basica, head, branches, log): Add tests for this feature. + + * admin.c (admin_fileproc): Clean up the error message which + happens if one of the RCS_* functions returns an error status; it + is confusing to say that "rcs" failed now that this is implemented + internally. + * sanity.sh (admin): Update accordingly. + +Wed Oct 29 07:07:36 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * sanity.sh (admin-22-o24): New test, tests that admin -o + correctly munged the deltatexts on a branch too. + + * rcs.c (RCS_delete_revs): If we are deleting an entire branch, + delete the node in ->branches rather than setting the ->key to the + bogus value NULL. + * rcs.c (RCS_delete_revs): If "rev1" equals "branchpoint", then set + "before" to the revision on the trunk that we branch from. + * rcs.c (RCS_delete_revs): Don't set rev2 to revp->version (the + code is missing an xstrdup, but it doesn't matter because rev2 + isn't used after this point). + * sanity.sh (binfiles2-o2 to binfiles2-o4): New tests, for this. + +Tue Oct 28 19:30:05 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * rcs.c (RCS_delete_revs): Restore code which passes rev2 to + RCS_getbranchpoint if rev1 is NULL; it still makes sense for the + non-trunk case. Fixes admin-22-o22 in testsuite. + + * sanity.sh (admin-18): Adjust to reflect "rcs failed" no longer + being suppressed by global -q option. + + * rcs.c (RCS_delete_revs): If rev1 == NULL and rev2 is on the + trunk, handle it the same way we do everything else--by swapping + the two. This replaces the code which tried to kludge what we + passed to RCS_getbranchpoint (which didn't work). + * sanity.sh (binfiles2-o1 to binfiles2-o4): New tests, for this fix. + * admin.c (admin_fileproc): Don't have -q global option suppress + "rcs failed" message. + +1997-10-28 Jim Kingdon + + * log.c (printlock_proc), rcs.c (putlock_proc): Prototype. + * rcs.c (rcs_internal_lockfile): Only try to call fchmod if + HAVE_FCHMOD is defined. + +Tue Oct 28 10:27:03 1997 Ian Lance Taylor <ian@cygnus.com> + + * rcs.c (RCS_deltas): Don't use \? in string if __STDC__ is not + defined. + + * rcs.c (make_file_label): Remove extraneous `+'. + +Mon Oct 27 14:40:15 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * status.c (status): Don't pass SEND_NO_CONTENTS to send_files. + +Sat Oct 25 00:33:57 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * rcs.c (RCS_delete_revs): Use : not - for range in error message. + + * rcs.h: Add comment about '\0' in RCS fields. + + * rcs.c (getdelta): Add comment about branches and next field + being mandatory. + + * rcs.c (RCS_reparsercsfile, RCS_deltas), sanity.sh (reserved): + Reindent sections which were misindented as a result of recent + changes. + +Fri Oct 24 10:22:15 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * rcs.c (RCS_findlock_or_tip): Don't worry about file ownership + and nonstrict locking when returning the default branch or head. + The most conspicuous problem with the old code is that in the + error case it would examine rstat.st_uid when it had not been + set. For a discussion of more fundamental reasons, see comment. + + * admin.c (admin_fileproc): In handling -A, don't handle relative + pathnames differently from absolute pathnames. See comment for + rationale. If problem opening the file, give a nice error not a + coredump. + * sanity.sh (admin-19a-admin, admin-19a-log, admin-19a-fix): + New tests, test for traditional "cvs admin -A" behavior with + relative pathnames. + * sanity.sh (admin-19a-nonexist): Test for the core dump fix. + * sanity.sh (admin-22-o1): Look for ${PROG} not cvs. + + * sanity.sh (reserved-16): Remove commitinfo change with "cvs + commit" not "cvs admin -o". In addition to commit being The Right + Thing on general principles, cvs admin -o doesn't work because it + doesn't rebuild the administrative file database. + + * update.c (patch_file): If the first revision does not exist in + the RCS file, fall back to sending entire file. Fixes + admin-22-o15 in make remotecheck. + +1997-10-23 enami tsugutomo <enami@but-b.or.jp> + + * rcs.c (RCS_checkin): Unlink temporary files stored in variable + `tmpfile' and `changefile'. + +Wed Oct 22 12:16:10 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * rcs.c (rcs_lockfilename): Allocate enough memory for terminating + '\0'. + + * admin.c (admin_fileproc): Don't support '-' for ranges in "cvs + admin -o". + (admin): Adjust comment. + + * rcs.h (RCSVers): New field other_delta. + * rcs.c (free_rcsvers_contents): Also free other_delta. + (getdelta): Read newphrases from deltas into other_delta field. + (putdelta): Write those newphrases. + * sanity.sh (rcs-8a): New test, for this fix. + * admin.c (admin_fileproc): If "-b" without argument, then set + branch to NULL, not "" (uncovered by rcs-8a test). + * rcs.c (putrcsfield_proc): Add comment about how we (mis)handle + values in newphrases. + + * sanity.sh (reserved): Instead of looking for rcslock.pl in CVS + distribution, just use our own equivalent. + + * rcs.c (RCS_rewrite): Call ferror before fclose to avoid "Invalid + argument" warnings. + +Mon Oct 20 00:30:16 1997 Tim Pierce <twp@twp.tezcat.com> + + [I removed a ChangeLog entry for a change to sanity.sh (editor), + because the actual change was not made. With this change, CVS no + longer runs RCS. I'll be checking in my cleanups shortly. -kingdon] + + Librarify `ci'. + * rcscmds.c, cvs.h (RCS_checkin): Removed. + * rcs.c, rcs.h (RCS_checkin, RCS_getbranchpoint, RCS_addbranch, + RCS_findlock_or_tip): New functions. RCS_checkin completely + rewritten to eliminate RCS 5.7; change `rcs' parameter from string + to RCSNode, so we can update RCSNode without re-reading from + disk. + * checkin.c (Checkin): Updated RCS_checkin caller, moved RCS_parse + call to before RCS_checkin. + * import.c (add_rev): Updated caller. + * commit.c (remove_file): Updated caller. + (checkaddfile): Updated caller. Parse `rcsfile' after + calling add_rcs_file. Free `rcsfile' instead of asserting it to + be NULL. + + Librarify `rcs'. + * rcscmds.c, cvs.h (RCS_exec_settag, RCS_exec_deltag, + RCS_exec_setbranch, RCS_exec_lock, RCS_exec_unlock): Removed. + + * rcs.c (RCS_settag): Rewritten to eliminate RCS 5.7. + * commit.c (checkaddfile): Call RCS_rewrite after calling RCS_settag. + * import.c (add_tags): Same. + * rtag.c (rtag_fileproc): Same. + * tag.c (tag_fileproc): Same. + + * rcs.c (RCS_deltag): Rewritten to eliminate RCS 5.7. Remove + `quiet' parameter, since this function no longer prints any output. + * commit.c (remove_file): Update caller. Also call RCS_rewrite + after RCS_deltag. + * rtag.c (rtag_delete): Same. + * tag.c (tag_fileproc): Same. + + * rcs.c (RCS_setbranch): Rewritten to eliminate RCS 5.7. + * commit.c (remove_file): Call RCS_rewrite after calling RCS_setbranch. + (fixbranch): Same. + (lock_RCS): Same. + + * rcs.c (RCS_lock): Rewritten to eliminate RCS 5.7. Change third + arg to mean `quiet' and not `noerr', permitting admin_fileproc to + run RCS_lock verbosely. + * commit.c (lock_RCS): Update callers; call + RCS_rewrite after RCS_lock. + (remove_file): Same. Call RCS_lock quietly. + * import.c (add_rev): Same. Do not print `fork failed' error + message, since we're no longer forking. + + * rcs.c (RCS_unlock): Rewritten to eliminate RCS 5.7. Change + `noerr' arg to mean `quiet', permitting admin_fileproc to run + RCS_unlock verbosely. Use notify_do when breaking another user's + lock. Include "edit.h" for notify_do prototype. + * checkin.c (Checkin): Update caller; use RCS_rewrite after RCS_unlock. + * commit.c (unlockrcs): Same. + * import.c (add_rev): Same. + + * rcs.c, rcs.h (RCS_getlocks, RCS_addaccess, RCS_delaccess, + RCS_getaccess, RCS_delete_revs): New functions. + (expand_keywords, RCS_lock, RCS_unlock): Use RCS_getlocks. + * log.c (log_fileproc, log_version): Call RCS_getlocks. Don't add + bogus ";locker" nodes to RCSVers nodes -- walk lock list with + printlock_proc. + (printlock_proc): New function. + + * admin.c (admin_fileproc): Largely rewritten: call internal RCS + library functions instead of forking RCS processes. + (admin, admin_fileproc): Obsolete -V option. + (struct admin_data): Remove `version' member. + * sanity.sh (admin-24): Remove -V test case. + + New functions for reading and writing RCS files. + * rcs.h (struct deltatext, Deltatext): New types. + (struct rcsversnode): New members `text' and `outdated'. + (struct rcsnode): New members `access', `locks', `strict_locks', + `comment', and `desc'. + * rcs.c (RCS_reparsercsfile, expand_keywords): Use new RCSNode members. + (free_rcsnode_contents): Free them. + * log.c (log_fileproc): Use new RCSNode members instead of ->other. + + * rcs.c (getdelta, RCS_getdeltatext, freedeltatext, do_locks, + RCS_putadmin, RCS_putdtree, RCS_putdesc, putdelta, + putrcsfield_proc, putsymbol_proc, RCS_copydeltas, putdeltatext, + RCS_rewrite, getrevnum, rcs_internal_lockfile, + rcs_internal_unlockfile, rcs_lockfilename): New functions. + + (RCS_reparsercsfile): Use getdelta, making sure fp is positioned + correctly before calling it. Skip `head' and `branch' nodes: we + have already parsed them, and they were being added incorrectly to + rcs->other. Do not signal error if the RCS file has an empty + delta tree; this made it impossible for RCS_checkin to perform an + initial checkin. Remove `all' parameter; always store all RCS + fields. + (RCS_fully_parse, RCS_gettag, RCS_getbranch, RCS_getdate, + RCS_getdatebranch, RCS_getrevtime, RCS_symbols, translate_symtag, + RCS_isdead, RCS_getexpand, RCS_checkout, annotate_fileproc): + Update all callers to remove `all' parameter. + + (getrcskey): Do not append trailing whitespace to a value. This + corrupted some log fields and wrecked some sanity.sh test cases. + + (free_rcsvers_contents): New function. + (rcsvers_delproc): Call it. + + * rcs.h (NODELTA): Removed symbol; now obsolete (since RCSNodes + do not go stale). + * import.c (add_rev): Removed NODELTA reference. + * rcs.c (RCS_reparsercsfile, RCS_checkout, RCS_settag, RCS_deltag, + RCS_setbranch, RCS_lock, RCS_unlock, RCS_deltas): Removed NODELTA + references. + + Miscellaneous changes to support RCS librarification and fix some bugs. + * subr.c, cvs.h (line2argv): Add `sepchars' argument. + * modules.c (cat_module, admin_fileproc): Update all callers. + + * subr.c, cvs.h (compare_revnums, increment_revnum): New functions. + (make_message_rcslegal): Strip whitespace from end of + lines and end of string, a la `cleanlogmsg' in RCS 5.7. + (get_file): Terminate buf with \0, extending it if + necessary. Read from stdin if `name' arg is NULL. + * admin.c (admin_fileproc): Call get_file to read -t arg from stdin. + + * error.c, error.h (rcserror): New function, used everywhere. + + * hash.c, hash.h (addnode_at_front): New function. + * rcs.c (RCS_settag, RCS_lock): Call it. + + * import.c, cvs.h (expand_at_signs): Make extern. + * rcs.c (putrcsfield_proc, RCS_putadmin, RCS_putdesc, + putdeltatext): Call it. + + * rcs.c (make_file_label): Use last_component to get file's basename. + + * sanity.sh (srcdir): New variable. + (rcs-7): Remove newphrase warning, no longer produced by CVS. + (rcs-8): Permit random whitespace around newphrase fields. + (admin-22): New test cases for -o options: admin-22-o{1..23}. + (reserved): New test cases for rcslock.pl: reserved-{8..16}. + +Tue Oct 21 16:48:32 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * tag.c (tag_check_valid): Add comment about locking or lack + thereof. + +1997-10-20 Jim Kingdon <kingdon@harvey.cyclic.com> + + * version.c: Change version number to 1.9.19. + +1997-10-19 Jim Kingdon + + * Version 1.9.18. + +Wed Oct 15 15:21:43 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * sanity.sh (username): Add '-' to characters allowed in user name. + + * rcscmds.c (diff_exec): Remove item about external diff + programs. It doesn't really belong here now that diff is + librarified and TODO #191 now mentions this. + + * checkout.c (checkout_proc): Add comment about assuming '/' is + the only path separator. + * options.h.in: Fix thinko (CVS/Repository -> CVS/Root). + +Mon Oct 13 22:46:03 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * commit.c (commit): Add comment about CVS_BADROOT and command + other than "commit". + +1997-10-11 Noel Cragg <noel@swish.red-bean.com> + + * options.h.in: RELATIVE_REPOS has been checked for bitrot -- it + now works again. Change the comment before the #define to say + that we'll be switching to it soon. + + * sanity.sh (basicb-1, basicb-1a): update dotest strings to match + no matter if we're running with RELATIVE_REPOS defined or not. + (basicb-9b, basicb-9c): same. + + * sanity.sh (basicb-9b, basicb-9c): modified tests, since the + checkout.c fix changes the way this test module is checked out. + (basicb-9d, basicb-9e, basicb-9f): new tests, same. + (basicb-18): modify test, same. + (cvsadm): new set of exhaustive tests to check the contents of + CVS/Root and CVS/Repository files under various conditions. As a + side effect, it tests the behavior of the "-d" flags (command line + and modules file). + (modules3-7e through modules3-7h): removed, since these tests were + a small subset of what is tested in the new cvsadm section. + (modules-1b, modules-1c): same. + (modules-2b, modules-2c): same. + (modules-3b, modules-3c, modules-3e, modules-3f): same. + + * create_adm.c (Create_Admin): be a bit more verbose when using + trace mode. + + * checkout.c (checkout_proc): rewrote the code that sets the where + variable and the code that matches directory names with repository + directories. This fixes a long-standing bug in CVS. (It used to + be the case that "cvs co -d foo <mod1> <mod2>" would not properly, + where <mod1> and <mod2> where defined in the modules file. While + the first module would be checked out correctly, the second would + be checked out under the name of the directory to which the module + referred rather than the module name!). This fix also allows us + to check out things into directories that are more than one deep + (e.g. "cvs -d foo/bar/baz co blah" will now work). + (checkout): remove code that performed a CHDIR if the + number of arguments specified was greater than one, since it's no + longer necessary. Also remove the code that prevented us from + doing "cvs co -d <dir1>/<dir2>" without <dir1> existing, since + checkout_proc handles things correctly now. + + * cvs.h: fix typo. + + * rtag.c (rtag): reformat so that we don't run over 80 characters + per line. + (rtag_dirproc): same. + + * sanity.sh: change all old test cases to use pass and fail + functions rather than doing some combination of echo and exit + themselves. + + * commit.c (commit_direntproc): remove the "warm fuzzy" -- this + code never gets called when running in client/server mode, and we + should have CVS' output match as much as possible between the two + modes. Moreover, there is no analogous place to put this same + message when we're running in c/s mode. + (find_direntproc): print the same "fuzzy" as in check_direntproc + so that local and c/s mode have the same messages. + * sanity.sh (187a3): update test case to reflect the above. + +Thu Oct 9 10:57:02 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * parseinfo.c (parse_config): Add comment about compatibility + issues with adding keywords. + +Wed Oct 8 16:40:37 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * recurse.c (do_dir_proc), commit.c (check_direntproc, + commit_direntproc, find_dirent_proc): If this + directory doesn't exist, skip it. + * diff.c (diff_dirproc): Reindent. + * sanity.sh (deep-4b0a, deep-4b0b): Check for this fix. + +Thu Sep 26 16:30:00 1997 Larry Jones <larry.jones@sdrc.com> + and Jim Kingdon <kingdon@harvey.cyclic.com> + + * update.c (checkout_file): Don't set timestamp in noexec mode. + * vers_ts.c (Version_TS): Add comment about ignoring errors from + utime. + * sanity.sh (conflicts3): New tests, for this fix. + +Fri Oct 3 09:47:04 1997 Noel Cragg <noel@swish.red-bean.com> + + * sanity.sh (168): use PROG instead of CVSBASE, since they are + equal. + (importb-2): refer to PROG instead of "cvs" in error message. + + * add.c (add): use PROGRAM_NAME in the error message rather than + "cvs". + * classify.c (Classify_File): same. + * commit.c (find_fileproc): same. + * sanity.sh: change all add notification messages to refer to PROG + rather than "cvs". Fixed nasty quoting in several places at the + same time, replacing older "'command'" forms with newer + ".command." for simplicity. + +Sat Sep 27 01:37:10 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * sanity.sh (rcslib-merge-8): Accept "P file1" as well as "U file1". + +Fri Sep 26 22:24:10 1997 Noel Cragg <noel@swish.red-bean.com> + + * create_adm.c (Create_Admin): assign our duplicate pointer `cp' + after the xrealloc of `reposcopy' because the latter might have + changed addresses. + +Fri Sep 26 14:25:59 1997 Tim Pierce <twp@twp.tezcat.com> + + * run.c (call_diff): Don't reset optind; this is done by diff_run now. + + Librarify rcsmerge/diff3. + * rcscmds.c, cvs.h (RCS_merge): Rewritten from scratch: check out + selected files and diff3 them. Take new `rcs' and `workfile' + arguments, so we can resolve symbolic tags and manipulate the + working file. + * update.c (merge_file, join_file): Update RCS_merge calls. + * run.c, cvs.h (call_diff3): New function. + + * sanity.sh (rcslib): New tests, rcslib-merge-{1..13}. + +Fri Sep 26 22:59:56 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * create_adm.c (Create_Admin): Fix thinko in Noel's change: keep + track of the originally allocated "cp" and free it, rather than + calling free on a pointer which may point halfway into the allocation. + * repos.c (Sanitize_Repository_Name): Per HACKING, assert that + repository != NULL, rather than just silently returning if NULL. + Reindent a line. + +Fri Sep 26 15:40:00 1997 Noel Cragg <noel@swish.red-bean.com> + + * sanity.sh (modules): add tests modules-[123]* that make sure the + administrative files get rebuilt in various cases. + + * add.c (combine_dir): removed function, since we no longer need + to worry about stripping the "." path element out. Changed the + two callers to simply concatenate their two arguments. + + * recurse.c (do_dir_proc): don't bother trying to strip off "." in + the repository name since the below changes fix that behavior -- + simply concatenate the repository and directory names together. + + * checkout.c (checkout_proc): sanitize the repository name after + constructing it (we may create "/path/to/repos/.", but we don't + want that to be passed around). Remove the code that tacks on + "/." when constructing top_repository, since the below changes fix + that behavior. Added comments to the part of this function that + builds administrative files. + + * sanity.sh (basicb): now that the below weirdness is fixed, the + extra "." path element in test basicb-0c doesn't appear when a + top-level file is checked out. Remove it from the expect string. + + * create_adm.c (Create_Admin): now that the repository name isn't + floating around with "." as the last path element, make creation + of the top-level administrative files a special case -- save the + repository name as "/path/to/repos/." Why? I considered not + including the "." but didn't know how it would affect the remote + protocol when RELATIVE_REPOS was defined (do we have a way of + sending "" via the protocol?). After I make sure that the + RELATIVE_REPOS patches still work, I'll check the "" possibility + so we don't have to have a this special case. + + * repos.c (Sanitize_Repository_Name): new function that removes + (if present) the trailing slash and "." component from the + repository name. Many routines break if we don't guarantee this. + See the comment before the function for complete information. + (Name_Repository): call Sanitize_Repository_Name before returning + the value. + * cvs.h: add prototype for Sanitize_Repository_Name. + +Fri Sep 26 14:19:25 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvs.h (CVS_CMD_USES_WORK_DIR): Fix comment (the sense of the + flag is not reversed from what it would seem; when I thought so it + was because I was misreading the lookup_command_attribute code). + +Thu Sep 25 23:14:47 1997 Noel Cragg <noel@swish.red-bean.com> + + * parseinfo.c (Parse_Info): fix typo in the trace message. + +Thu Sep 25 14:22:54 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * build_src.com: Also link with diff.olb. + + * main.c (Make_Date): If gmtime returns NULL, try localtime. + +Wed Sep 24 19:18:40 1997 Noel Cragg <noel@swish.red-bean.com> + + * checkout.c (checkout): fix typo in comment. + +Wed Sep 24 08:31:46 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * update.c (patch_file): Revise comments about diff -a now that + diff is librarified. + +Sun Sep 21 21:28:26 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * run.c (call_diff): Sleep for a second, in hopes of helping with + out of order bugs. + +Sat Sep 20 07:19:18 1997 Tim Pierce <twp@twp.tezcat.com> + + Integrate diff library into CVS. + * run.c, cvs.h (call_diff): New function. + * rcscmds.c (diff_exec, diff_execv): Get diffs from call_diff + instead of running diff as a subprocess. + * Makefile.in (cvs): Add ../diff/libdiff.a. + + * diff.c (longopts, diff): Use 131 for --ifdef, fixing Jim's thinko + (using 147 for both --side-by-side and --ifdef). + + * sanity.sh (rcslib): Added tests rcslib-diffrgx-*, to test + handling of regex diff options. + +1997-09-21 Jim Kingdon <kingdon@harvey.cyclic.com> + + (Note that this requires that DIFF support -L. I'll be checking + in a fix to that in a moment, but I wanted separate checkins in + case that helps with clarity). + Tweaks to rcsdiff librarification: + * sanity.sh (rcslib): Change "cvs" to "${PROG}" and subcommand + names (e.g. "add") to "[a-z]*". Former should deal with ${testcvs} + being "cvs.old" or something; latter fixes make remotecheck. + * rcs.c (make_file_label): Take into account strlen (rev) when + allocating space. Removes a FIXME and probably fixes a buffer + overrun security hole. + * rcscmds.c (RCS_exec_rcsdiff): Remove #if 0'd code to call + rcsdiff. Tim says he has compared the new code with rcsdiff code + and is confident that the behavior is preserved, so we need to + nuke the comment which says this has not been done. #if 0 isn't + really a very good way to document the way it used to work anyway; + the old code is still in CVS. + * diff.c: Add comment about rcsdiff options that we don't support, + which Tim had sent in email. Remove -T and -y, as the + previous meaning had been very confused. + +1997-09-21 Tim Pierce <twp@xochi.tezcat.com> + + Librarify rcsdiff. + + * diff.c (have_rev1_label, have_rev2_label): New variables. + (diff): Generate file labels with make_file_label if necessary; + pass labels, revisions and working file name to RCS_exec_rcsdiff. + * rcscmds.c, cvs.h (RCS_exec_rcsdiff): Completely revised function + to eliminate rcsdiff dependency, based on patch from JimK. + (diff_execv): New function, to exec diff with explicit -L args. + * rcs.c, rcs.h (make_file_label): New function. + (RCS_output_diff_options): New function. + * sanity.sh (rcslib): New test. + +Fri Sep 19 15:08:08 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * rcs.c (RCS_nodeisbranch): Assert that RCS is non-NULL. + * commit.c (remove_file), rcs.c (RCS_getversion), rtag.c + (rtag_fileproc), status.c (status_fileproc, tag_list_proc), tag.c + (tag_fileproc): Call RCS_nodeisbranch not RCS_isbranch + in contexts where we know the RCS argument is non-NULL. + + * commit.c (find_fileproc): Pass tag not NULL to Version_TS for + the tag. + * vers_ts.c (Version_TS): Improve (somewhat) the introductory + comment. + * sanity.sh (editor): New test editor-9 tests for above fix. + Renumber/tweak surrounding tests to fit. + + * log.c (log_version): If p->data is NULL, it is an empty log + message. + * sanity.sh (rcs-14): New test, tests for above fix (previously + this was a coredump). + +Thu Sep 18 08:45:05 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * sanity.sh (rcs-7): Fix stupid ${TESTDIR} omission. + +Wed Sep 17 16:27:41 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * sanity.sh (rcs): New tests rcs-5 through rcs-13 test for + getdate.y fix (rcs-12 and rcs-13 both failed with the buggy + getdate.y). + +Tue Sep 16 00:07:17 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * sanity.sh (editor): Clean up first-dir at end of test. + + * sanity.sh (editor): New tests test do_editor. + + * commit.c (commit): For the client, if we got the log message + from do_editor and there was an error, don't toss the message. + +Mon Sep 15 14:27:54 1997 martin.sjoelin@ubs.com + and Jim Kingdon <kingdon@harvey.cyclic.com> + + * rcs.c (RCS_checkout): fwrite in bite-size pieces, not the whole + file in one fwrite. + +Sun Sep 14 12:23:15 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * commit.c (check_fileproc): If the file has "conflict + indicators", spit a warning and proceed with the checkin. + * sanity.sh (conflicts): Adjust tests conflicts-132, + conflicts-status-3, conflicts-133, and conflicts-status-4 + for new behavior. + +Fri Sep 12 11:12:34 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * add.c, admin.c, checkin.c, checkout.c, classify.c, commit.c, + create_adm.c, cvsrc.c, diff.c, entries.c, find_names.c, hash.c, + import.c, lock.c, log.c, logmsg.c, main.c, modules.c, myndbm.c, + no_diff.c, parseinfo.c, patch.c, rcs.c, rcscmds.c, recurse.c, + remove.c, repos.c, root.c, rtag.c, status.c, subr.c, tag.c, + update.c, vers_ts.c, hash.h, rcs.h, options.h.in: Change "CVS 1.4 + kit" to "CVS source distribution". + + * sanity.sh: Comment out call to "whoami". + +Thu Sep 11 10:09:04 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * commit.c (classify_file_internal): Add comment about saving + quiet vs. saving really_quiet. + + * sanity.sh (newb-123j0): Use two regexps instead of assuming that + expr has "\(", "\|", and "\)". If we want to require the latter, + we should check for it up front, rather than let people get + halfway through and wonder why the test failed. + +Tue Sep 9 19:22:44 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * expand_path.c (expand_path): If GETPWNAM_MISSING is defined, + just give an error instead of calling getpwnam. + + * subr.c (getcaller): If SYSTEM_GETCALLER is defined, call it + instead of all the getlogin/getpwuid/etc. + * wrapper.c (wrap_setup): Call get_homedir not getpwuid. + +Mon Sep 8 17:54:14 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * sanity.sh (basicc): Change ls -1 to echo *; according to + larry.jones@sdrc.com, ls -1 isn't portable. + +Sun Sep 7 07:45:35 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * sanity.sh (basic2): In test basic2-64, match usernames with + ${username}. + + * root.c: Reindent a few things. + * root.c, cvs.h (same_directories): Remove. Never used, + portability hassle. + + * add.c (add_directory): When checking for CVSADM, call fncmp not + strcmp. I actually suspect this code doesn't do much these days, + but fncmp clearly will make more sense than strcmp. + + * rtag.c (rtag_usage), tag.c (tag_usage): Reword to hopefully be + clearer that -r takes either numeric or symbolic revision. + + * ignore.c (ign_dir_add, ignore_directory): Reindent. Tweaks to + comments. + + * update.c (checkout_file): Only ignore existence_error from + unlink_file_dir, not all errors. + + * checkout.c (safe_location): Check for errors from xgetwd. + * create_adm.c (Create_Admin): Remove call to xgetwd; it is just + debugging code anyway and it wasn't checking for errors. + + * sanity.sh: Add comment about default value for TESTDIR. + + * server.c (serve_log): Change "cvslog" to "log". This + (accidental, I presume) error had made it impossible for anonymous + users to run "cvs log". + + * classify.c (sticky_ck): Change to take an finfo argument rather + than several arguments taken from there. Cleans up the way the + calling convention had depended on SERVER_SUPPORT. + (Classify_File): Change callers. + + * version.c: Change version number to 1.9.17. + + * Version 1.9.16. + + * recurse.c (do_dir_proc): In combining repository and dir, omit + trailing "/." from repository. + * sanity.sh (modules3): Adjust test modules3-4 so we test for + this fix (this is not just cosmetic; the bug prevented the + "Rebuilding administrative file database" from happening). + modules2 already tests the "co CVSROOT/modules" usage. + + * checkout.c (checkout_proc): When building top-level CVSADM + directory, continue the process of walking up the repository one + more level, rather than putting in the same repository as for the + first-level directory. + * sanity.sh: Adjust tests basicb-1b, basicb-9b, modules3-7f, + toplevel-9, and toplevel-11 to test for this fix. + + (For reference, this takes CVS's text segment from 344460 to + 344140 bytes. I know, this may seem unimportant, but it is so + unusual for programs to shrink and I think it is so cool when they + do without losing functionality/clarity/etc). + * checkout.c, cvs.h (emptydir_name): New function. + * checkout.c (checkout, checkout_proc), modules.c (do_module): + Call it instead of duplicating the code to do that. + + * sanity.sh (basicc): Clean up first-dir at end of test. + +Sat Sep 6 09:48:39 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * sanity.sh (join): Fix cut and paste error in join-28 + (/home/kingdon/... -> ${TESTDIR}). + + * recurse.c (start_recursion): If there is no CVSADM and no + subdirectories, give an error. + * sanity.sh (basicc): New tests, test for this fix. + + * sanity.sh (join): New tests join-25 through join-29 test merging + from one branch to a different branch. + + * release.c: In comment about CVSROOTADM_IGNORE, also mention + comment just added to entries.c. + * entries.c: Expand this comment, especially the part about + CVS/Template. + + Keep track of what revisions CVS/Base correspond to: + * cvs.h (CVSADM_BASEREV, CVSADM_BASEREVTMP): Added. + * entries.c, cvs.h (base_register, base_deregister, base_get, + base_walk): New functions. + * edit.c (edit_fileproc): Call base_register when setting up CVS/Base. + (unedit_fileproc): When taking a file out of CVS/Base, put its + revision back into entries, and base_deregister it. + * sanity.sh (watch4): New tests watch4-10 through watch4-18 test + for above fix. + +Fri Sep 5 09:14:10 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * client.c: Only declare start_rsh_server if we are going to + define it (!NO_EXT_METHOD). + + * subr.c, cvs.h (check_numeric): New function. + * admin.c (admin): Call it. + * sanity.sh (admin): New tests admin-10a and admin-10b test for fix. + +Thu Sep 4 15:55:39 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * sanity.sh (binwrap2): New tests, test for the ability to specify + all files are binary except certain patterns. + + * sanity.sh (modules3): New tests modules3-16 and modules3-17 test + for another behavior involving '/' in a module name. + +Sun Aug 31 12:03:15 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * add.c (add): Remove checks for '/' in pathnames. + (add): Move code which handles entries and repository inside loop, + since these now might be different for each argument. Add code to + set finfo.update_dir, finfo.file, and finfo.fullname appropriately + even if pathname contains '/'. Replace user variable with + finfo.file or finfo.fullname, depending on which is meant. chdir + into update_dir for each argument. Likewise for the client code + which creates directories. + (add_directory): Replace arguments with a single finfo argument. + Replace dir with finfo->fullname as needed. + (add): Update call to add_directory. + * client.c, client.h (send_a_repository): No longer static. + * sanity.sh (errmsg2): Adjust tests to test for '/' in pathname. + + * sanity.sh (errmsg2): New tests errmsg2-13 through errmsg2-16 + test the status quo with respect to '/' in cvs add argument. + +Sat Aug 30 17:37:29 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * run.c (run_popen): Add comment on return value. + * release.c (release): Check for NULL return from popen. + +Fri Aug 29 17:49:20 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * client.c (get_server_responses): Add comment about "ok^M". + +Thu Aug 28 13:35:12 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * edit.c (edit_fileproc): If file doesn't exist, give an error. + * sanity.sh (devcom2): Tests devcom2-12 through devcom2-17 test + for above fix. + +Tue Aug 26 16:42:28 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * subr.c (xmalloc): Reword error message to clarify that memory, + not disk space or some other resource, is in question. + +Tue Aug 26 01:04:48 1997 Steve Ralston <sralston@ppdpost.ks.symbios.com> + and Jim Kingdon <kingdon@harvey.cyclic.com> + + * add.c (add_directory): In allocating message, also allocate + enough for tag and date related text. + +Tue Aug 26 01:04:48 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * update.c (update_dirent_proc): Use update_dir not dir in "new + directory" message. + * find_names.c (find_dirs): Skip CVSNULLREPOS. + (Find_Directories): Add comment about find_dirs skipping CVSATTIC + and CVSLCK in working directories. + * sanity.sh (basicb): New tests basicb-edir-* test for find_dirs + fix. Change other tests to test that Emptydir is not special in + non-CVSNULLREPOS contexts. + +Sun Aug 17 14:44:57 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * import.c (add_rcs_file): Add comment about -k overriding wrappers. + +Sat Aug 16 18:09:05 1997 Martin Sjoelin <martin.sjoelin@ubs.ch> + and Jim Kingdon <kingdon@harvey.cyclic.com> + + * import.c (add_rcs_file): Before opening the input file + when importing, if options is binary, open the file in + binary mode. + +1997-08-16 enami tsugutomo <enami@ba2.so-net.or.jp> + + * sanity.sh (mcopy): Unset CVSWRAPPERS last of all. + +Fri Aug 15 11:11:44 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * add.c (add_directory): Copy default file attributes from the + parent directory to the directory we are creating. + * fileattr.h, fileattr.c (fileattr_getall, fileattr_setall): + New functions, in support of above. + * fileattr.c (fileattr_free): Add comment about fileattr_write + maybe not clearing attrs_modified. + * sanity.sh (watch4): New test, tests for above fix. + +Thu Aug 14 11:08:40 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * update.c (merge_file, join_file): If wrap_merge_is_copy, treat + files as nonmergeable (as we had been treating binary files). + (join_file, update_fileproc): Remove previous wrap_merge_is_copy + cruft. + * sanity.sh (mcopy): New tests, test for above fix. + (binfiles2): New tests binfiles2-9a-* correct an oversight. + (binfiles, binfiles2): Adjust to reflect wording change from + "binary file" to "nonmergeable file". + (mwrap): Adjust tests mwrap-8 through mwrap-10 for new behavior. + + * main.c (main): Reword copyright notices to include the latest + year, to refer to "other authors" in addition to the ones listed, + and to be more concisely formatted. + +Wed Aug 13 13:50:00 1997 Larry Jones <larry.jones@sdrc.com> + + * sanity.sh: Replace hard-coded directory with ${TESTDIR}, add + join3 to default tests + +Wed Aug 13 11:42:24 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * rcscmds.c: Adjust comment to reflect progress on removing RCS + execs outside this file. + +Mon Aug 11 10:14:47 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * vers_ts.c (Version_TS): If vers_ts->vn_rcs == NULL, skip setting + modification time in server case as well as local case. + * server.c (server_modtime): Add assertion to clarify that caller + must assure that vers_ts->vn_rcs != NULL. + * sanity.sh (join3): Add file "file2" to test for above fix. + + * modules.c (save_d): When parsing -s option, don't assume that + we will hit a space before we hit the '\0'. + (struct sortrec): Document allocation policies (status quo except + status field is now malloc'd). + (cat_module): No longer need to set the '\0' at the end of the + status field back to ' ', as it no longer shares storage with the + rest field. + * sanity.sh (modules): Add "statusmod" to test for above fix. + +Sun Aug 10 12:18:31 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * sanity.sh: Remove TODO item about more keyword expansion tests. + The keyword test and others cover it pretty well, and such an item + isn't useful unless it is specific. + + * sanity.sh (importb): New tests test "cvs import -b". + + * mkmodules.c: Update comment with more reasons why having + CVSROOT/passwd be a regular administrative file would be a Bad + Idea. + + * server.c (switch_to_user): Add comment about checking for errors + from setuid and friends. + +Wed Aug 6 13:48:29 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * main.c (main): Add comment about errors writing CVS/Root in + need_to_create_root code. + +Tue Aug 5 22:05:20 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * entries.c (write_entries): If trouble writing Entries.Backup, + make it a warning not an error. + +Wed Jul 30 08:42:04 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * parseinfo.c (parse_config): If AUTH_SERVER_SUPPORT is not + defined, don't set system_auth. + + * version.c: Change version number to 1.9.15. + + * Version 1.9.14. + + * create_adm.c, cvs.h (Create_Admin): If new argument WARN is set, + then make creating the CVS directory itself a warning not a fatal + error. New return value indicates whether we did this. + * checkout.c (build_one_dir), client.c (call_in_directory): + Pass WARN as one. + * add.c, client.c, checkout.c, modules.c, update.c: Pass WARN as + zero for all other Create_Admin callers. + * sanity.sh (toplevel): New test toplevel-12 tests for this fix. + * filesubr.c (mkdir_if_needed): Also check EACCES/isdir. Needed + to make toplevel-12 test work. + + * sanity.sh (toplevel): New test toplevel-11 and friends test for + another variation of the toplevel-9 bug. + +Tue Jul 29 12:11:16 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * login.c (construct_cvspass_filename): Revert this change. The + main reason is procedural; Karl is not a current CVS developer. + The other thing is that the new text doesn't say anything about + HOMEDRIVE and HOMEPATH. + +Tue Jul 29 11:36:22 1997 Karl Fogel <kfogel@harvey.cyclic.com> + + * login.c (construct_cvspass_filename): error message informs user + she may need to set HOME environment variable by hand. + +Sun Jul 27 15:36:44 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * admin.c (admin): Remove comment "XXX send -ko too with i = 0". + It turns out to be a description of a bugfix which was applied on + 8 Oct 1995, and never should have been in a comment in the first + place. + + * admin.c (admin, admin_fileproc): Parse options ourself rather + than blindly passing them to RCS. + Accordingly, add struct admin_data and function arg_add, and delete + global variables ac and av. + * sanity.sh (admin): Change admin-3 test to reflect cvs admin -i + now being an error. + (basicb): Change basicb-21 test to relect the improved error + message here. + +Sat Jul 26 11:34:51 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * sanity.sh (join3): New tests, test a new branch topology and + greatest common ancestor. + +Fri Jul 25 09:51:49 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * server.c (serve_directory): Repository must start with + CVSroot_directory rather than some random pathname. + + * remove.c (remove_fileproc): If there is a numeric sticky tag, + don't allow the remove. + * commit.c (check_fileproc): Add comment about this case. + * sanity.sh (sticky): New tests sticky-15 through sticky-23 + test for this behavior and the analogous behavior with + non-branch sticky tags (which is unchanged). + + * client.c (update_entries): Clear the stored mode, modtime, and + checksum even on an error. + * sanity.sh (contents2-142d*): Also test cvs status. Also test + the case in which the contents of the file are unchanged. Also + test running diff to see the conflict, and resolving the conflict. + Without the fix above, the new contents2-142d2 test would get a + "duplicate Mod-time" warning. + +Thu Jul 24 13:29:15 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * server.c (pserver_authenticate_connection): Call parse_config + here too. + * parseinfo.c (parse_config): If we are called several times, the + times beyond the first do nothing. + * cvs.h, parseinfo.c (parse_config): New argument cvsroot. + * server.c, main.c: Update callers. + * server.c, server.h (system_auth): New variable. + * parseinfo.c (parse_config): Parse new keyword SystemAuth. + * mkmodules.c (config_contents): Add comments for SystemAuth. + * server.c (check_password): If !system_auth, then skip the check + for a system username/password. + + * main.c (main): No fatal error if parse_config returned an error. + * server.c (serve_root): Likewise. + * error.c (error): Add comment about calling from the server. + * parseinfo.c, cvs.h (parse_config): Remove NOERR crock. + Closer reading of server.c makes it seem like calling error + here is OK after all. + * sanity.sh (config): New test, tests for above fix. + + * server.c (serve_root): Fix typo ("doign" -> "doing"). + +Wed Jul 23 13:55:09 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * vers_ts.c (Version_TS): If entdata is for a directory, don't set + vn_user and friends. + * server.c (dirswitch): Add comment about why Subdir_Register is + sometimes a noop here. + * cvs.h (struct vers_ts): Fix comments about NULL vs. "" in vn_user. + * sanity.sh (errmsg2): New tests errmsg2-10 through errmsg2-12 test + for above fix. + * add.c (add_directory): Call cvs_output not printf. This fixes + an out-of-order bug which was showing up in the testcase. + +21 Jul 1997 Jim Kingdon + + * subr.c (get_file): Put st_size into an unsigned variable to + avoid signed/unsigned warnings. + +Mon Jul 21 00:19:30 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * version.c: Change version number to 1.9.13. + + * Version 1.9.12. + + * sanity.sh (toplevel, head): Delete our files from the repository + when done with them. + +Sun Jul 20 15:53:08 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * sanity.sh (admin, reserved): New tests, test most cvs admin + behaviors. + (log2): New tests log2-5 through log2-10 test setting the + description via cvs admin. + +Thu Jul 17 12:39:27 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * client.c (socket_buffer_input, socket_buffer_output): Add + comment regarding size of of buffer we pass to send and recv. + +Sat Jul 12 15:21:24 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * import.c, rcs.h (add_rcs_file): New argument key_opt replaces + access to global variable keyword_opt. New arguments desctext and + desclen allow one to set the description. If add_vhead is NULL, + then omit a revision, like rcs -i. + * import.c (process_import_file), mkmodules.c (init): Change + callers. + * subr.c, cvs.h (get_file): New function, adapted from code in + update_entries. + * client.c (update_entries): Call it. + * commit.c (checkaddfile): Create new RCS files with add_rcs_file + rather than rcs -i. + +Fri Jul 11 12:14:54 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * update.c (join_file): Handle binary files ourself rather than + passing them to RCS_merge (which sort of tries to handle binary + files, but does so badly). + * sanity.sh (binfile2): New "brmod", "brmod-trmod", and + "brmod-wdmod" tests test for this fix. + + * add.c (add): Exit status is now nonzero if any of the arguments + failed (already was mostly true, make it true for the new sanity + check). Move check for '/' (now ISDIRSEP) up to sanity check, so + the client does it too. + * sanity.sh (errmsg2): Test for this fix. + +Thu Jul 10 00:02:54 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * add.c (add): Check for CVSADM, ".", and "..", and skip any + attempt to add them. + * sanity.sh (errmsg2): New tests, tests for above fix. + + * main.c (main): In text printed upon --version, also refer + people to --help. + + * rcscmds.c (RCS_exec_rcsdiff): Add comment about timezones. + + * server.c, cvs.h (cvs_output_binary): New function. + * rcs.c (RCS_checkout): For a binary file, call cvs_output_binary + rather than cvs_output. + * client.c (handle_mbinary): New function. + (responses): Add "Mbinary". + +Tue Jul 8 12:18:16 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * filesubr.c (get_homedir): Add comment about root vs. user + directory in pserver server. + +Mon Jul 7 14:39:33 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * sanity.sh (big): Also test Rcs-diff case. + + * client.c (update_entries): Reindent a line. + + * sanity.sh (death2): Add comment about Sun diff. Thanks to + Warren Jones <wjones@TC.FLUKE.COM> for reporting this. + + * client.c (update_entries): If DONT_USE_PATCH, then just treat a + Patched response as an indication to try again with complete files. + * update.c (update): Remove DONT_USE_PATCH ifdefs, since a CVS + with DONT_USE_PATCH defined can still handle Rcs-diff. + * sanity.sh (serverpatch): Add comment about this coming up in + real life if the user modifies the file while CVS is running. + + * client.c (start_server): Add comment about logfiles if there are + several connections to the server. + (log_buffer_shutdown): Close the logfile after shutting down the + underlying buffer. This way at least we get the last set of + logfiles rather than a bizarre mishmash. + +1997-07-06 enami tsugutomo <enami@but-b.or.jp> + + * logmsg.c (do_verify): Unlink temporary file before call error(). + Remove unneeded `return' statement. Fix comment. + +Sun Jul 6 13:36:32 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * diff.c (diff_fileproc): Change message from "during rcsdiff of" + to "while diffing". For a while now, that message might be + printed after a call to DIFF instead of rcsdiff. + + * diff.c (diff_fileproc): Call cvs_output not printf. Remove + calls to fflush (should be handled now by call to cvs_outflush in + recurse.c). + * patch.c (patch_fileproc): Likewise. + + * rcscmds.c, cvs.h (diff_exec): New function. + * diff.c (diff_fileproc), patch.c (patch_fileproc), + update.c (patch_file): Call it. + + * rcscmds.c: Adjust comments concerning diff library to point to + new, expanded comments at diff_exec. Remove comments concerning + patch library; Rcs-diff should be adequate. + + * client.c (update_entries): Add comment about GNU patch usage (-b + option and so on). + +Sat Jul 5 04:13:28 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * rcscmds.c, cvs.h (RCS_exec_rcsdiff): New function. + * diff.c (diff_fileproc): Call it. + +Thu Jul 3 09:50:07 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * main.c (main): Add comment about how long we should keep the + deprecated "cvs rlog" alias. + + * server.c (cvs_output): Add comment about whether to fflush. + +Wed Jul 2 18:57:29 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * sanity.sh (join2): New tests join2-19 and friends test for a + case that we can't readily get right (see comments). + +Tue Jul 1 09:52:09 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * main.c (cmd_usage): Say "specify" --help rather than the vague + "use". + (opt_usage, cmd_synonyms): Mention --help here too. + * add.c, admin.c, checkout.c, commit.c, diff.c, edit.c, import.c, + log.c, login.c, mkmodules.c, patch.c, rcs.c, release.c, remove.c, + rtag.c, status.c, tag.c, update.c, watch.c: Likewise, for all the + other help messages. + + * sanity.sh (join2): New tests. + + * repos.c (Name_Repository): Check for errors from fclose. + +Fri Jun 27 10:27:48 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * scramble.c, login.c: Reindent. + + * client.c (connect_to_pserver): Check for errors from send(). + If socket() fails, include SOCK_STRERROR (SOCK_ERRNO) in message. + +Wed Jun 25 11:21:52 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * main.c: New option --help-options, with much of the text + from --help. Fix a few capitalization and punctuation problems. + Rewrite text for --help to be an intro to all the --help-* + options. + + * sanity.sh (head): New tests, concerning meaning of HEAD. + +Tue Jun 24 10:14:18 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * client.c (recv_line): New function. + (connect_to_pserver): Call it, and rewrite accordingly. Also + accept new "E" and "error" responses. Change \n to \012. + * server.c (pserver_authenticate_connection): Adjust comment + accordingly, concerning sending I HATE YOU not "error". + +Sun, 22 Jun 1997 Jim Kingdon + + * main.c (main): Move setting of server_active inside #ifdef + SERVER_SUPPORT; otherwise the variable doesn't exist. + * main.c (main): Call return after exit to shut up warning. + +Fri Jun 20 22:56:34 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * client.c (connect_to_pserver): On "I HATE YOU", give + "authorization failed" fatal error regardless of verify_only. + * login.c (login): Don't print that "incorrect password" message; + it now is possible with an --allow-root failure as well as an + incorrect password. cvsclient.texi doesn't really specify what I + HATE YOU means in any detail, and it seems a little silly for + login to give different messages than the other commands. + * client.c, client.h (connect_to_pserver): Return type now void. + +Thu Jun 19 12:16:10 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * server.c (serve_root): Give error on duplicate Root request. + Call parse_config. + * parseinfo.c, cvs.h (parse_config): New function. + * cvs.h (CVSROOTADM_CONFIG): Added. + * main.c (main): Set server_active here... + * server.c (server): ...not here. That seems cleaner than + strcmp's between command_name and "server" in main.c. + * main.c (main): Call parse_config. + * main.c, cvs.h (free_Rcsbin): Make global. + * mkmodules.c (filelist): Add CVSROOTADM_CONFIG. + +Wed Jun 18 11:24:31 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * version.c: Change version number to 1.9.11. + + * Version 1.9.10. + +Tue Jun 17 22:48:00 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * main.c (main): Add --allow-root=ROOT argument; call + root_allow_add for each time it is specified. Call + root_allow_free before exiting. + * root.c, cvs.h (root_allow_add, root_allow_free, root_allow_ok): + New function. + * server.c (pserver_authenticate_connection): If root_allow_ok + doesn't like the CVSROOT directory, don't allow access. + +Tue Jun 17 14:30:14 1997 Jim Kingdon (unknown@beezley) + + * client.c: Add "copyright" notice. If NO_EXT_METHOD, omit + start_rsh_method. + * client.c (update_entries): Cast argument to MD5Update from + char * to unsigned char *. + +Mon Jun 16 16:46:28 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * run.c (piped_child, filter_stream_through_program): + If USE_SETMODE_BINARY, then put the pipes into binary mode. + * find_names.c, ignore.c, lock.c, wrapper.c: Change fnmatch to + CVS_FNMATCH. + * client.c (start_server): If NO_EXT_METHOD, then give a fatal + error on any use of :ext:. + +Sun Jun 15 22:30:27 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * sanity.sh (toplevel): Match U CVSROOT/* lines with DOTSTAR in + test toplevel-9. + +Thu Jun 12 10:27:51 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * sanity.sh (toplevel): Remove Emptydir before starting. + + * sanity.sh: Change "rm -rf" to "rm -r" when deleting working + directories (except a few watches cases). Helps detect cases + where the testsuite has cd'd to somewhere other than where we + think it has. + (basic2): Remove "rm -r first-dir" between tests 49 and 50. The + directory was already deleted in test 45.5. + (rcs): Add "cd .." at end of tests. + (stamps): No longer cd to TESTDIR; shouldn't be necessary with + fix to "rcs" test. + +Wed Jun 11 22:28:38 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * sanity.sh (basicb): Also remove CVSROOT/Emptydir at end of + test. Otherwise it affects the toplevel-9 test for remote. + +Tue Jun 10 14:03:32 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * sanity.sh (toplevel): Change "update" and "checkout" to "[a-z]*" + as these read "server" instead for "make remotecheck". Change + expect strings for toplevel-9 to accept the behavior of remote CVS + (see comments for more discussion). + + * sanity.sh: New tests stamps-9 through stamps-11 test timestamp + behavior on cvs update. + +Mon Jun 9 22:42:50 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * sanity.sh: Remove "#! /bin/zsh" line at end. I assume it was + added accidentally. + +Tue Jun 10 03:08:46 1997 Norbert Kiesel <nk@psycho.de> + + * sanity.sh: new tests "toplevel" for the new toplevel CVS + directory creation (including one test which shows an error in + this area). + +Sun Jun 8 20:52:00 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * rcs.c (getrcsrev): Before printing error, check whether it was + feof or ferror. + + * rcs.h, import.c (add_rcs_file): No longer static. New arguments + add_vbranch, add_vhead, and add_logfp replace access to static + variables vbranch, vhead, and logfp. + * mkmodules.c: Call it instead of RCS_CI. + * import.c (process_import_file): Adjust call to add_rcs_file. + +Tue Jun 3 10:18:33 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * sanity.sh (basicb): Match "." with "\." not ".". + +Tue Jun 3 13:02:37 1997 Norbert Kiesel <nk@cosa.de> + + * checkout.c (checkout): Removed restriction of not sending -k in + remote export (I think this was introduced while the -k handling + was still broken in remote mode). Give better error texts + regarding -c and -s options. Use error() instead of usage() for + reporting errors in all places. Reindented some lines. Free + xmalloc'd space of options. + +Thu May 29 16:32:47 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * rcscmds.c (RCS_checkin), mkmodules.c (init): Pass -w option to + "ci", specifying getcaller (). + * server.h, server.c (CVS_Username): Now extern. + * subr.c (getcaller): Return CVS_Username if it is set. + +Wed May 28 22:31:38 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * update.c (update_fileproc): If wrap_merge_is_copy and we would + like to do a merge, give a fatal error. See comment for why. + * sanity.sh (mwrap): New tests, tests for above fix. + +Tue May 27 21:59:32 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * sanity.sh (stamps): cd to ${TESTDIR} before starting. + +Mon May 26 15:31:30 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * client.c (handle_mod_time): New function. + (responses): Add "Mod-time". + (stored_modtime_valid, stored_modtime): New variables. + (update_entries): If it is set, change the file's modtime. + * server.c, server.h (server_modtime): New function. + * vers_ts.c (Version_TS): Call it. + * patch.c (patch_fileproc): Add comment about why we don't. + * sanity.sh (stamps): Added, tests for above fix. + +Fri May 16 13:14:30 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * subr.c (free_names): Update documentation to reflect fact that + free_names is now called to free vectors allocated by expand_wild + as well as by line2argv. + + * main.c (main): Use "xstrdup (foo)" not "xstrdup(foo)" as + specified in HACKING. + +Fri May 16 15:10:37 1997 Norbert Kiesel <nk@cosa.de> + + * modules.c (do_module): initialize optind to 0. use local copies + of optarg's (because they might me freed within free_names). + +Thu May 15 11:50:15 1997 Norbert Kiesel <nk@cosa.de> + + * main.c (main): initialize optind to 0. use local copies of + optarg's (because they might me freed within read_cvsrc). + + * cvsrc.c (read_cvsrc): free old argv after constructing a new + one. This fixes a memory leak. + + * recurse.c (start_recursion): use free_names() instead of + reimplementing it + + * rcs.c (RCS_deltas): free branchversion (memory leak). + + * parseinfo.c (Parse_Info): free some vars (3 memory leaks). + + * logmsg.c (logfile_write): free str_list_format (memory leak). + + * watch.c (watch_addremove), (watchers), update.c (update), tag.c + (cvstag), status.c (status), rtag.c (rtag), remove.c (cvsremove), + release.c (release), patch.c (patch), log.c (cvslog), import.c + (import), history.c (history), edit.c (watch_onoff), (edit), + (unedit), (editors), diff.c (diff), commit.c (commit), checkout.c + (checkout), add.c (add): initialize optind to 0 + + * diff.c (diff_fileproc): cosmetic change (whitespace added). + + * checkout.c (checkout): move local variable definition into the + block where the variable is used. + + * client.c (update_entries): initialize some local variables to shut up + gcc -O -Wall. + + * buffer.c (buf_read_line): initialize a local variable to shut up + gcc -O -Wall. + + +Wed May 14 16:29:50 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * admin.c (admin): When sending options to server, don't try to + send av[ac]. It may contain one of the names that we'll send in + send_file_names (which caused tests like keyword-6 to work, + sort of accidentally), or it may contain NULL (which would tend to + cause a coredump). + * sanity.sh (basicb): New test basicb-21 tests for above fix. + +Mon May 12 16:22:00 1997 Larry Jones <larry.jones@sdrc.com> + + * add.c (add): Free message and repository in client code. + * checkout.c (checkout): Don't free repository unless allocated. + * client.c (start_rsh_server): Free command. + +Sun May 11 11:43:54 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * client.c: Remove all references to USE_DIRECT_TCP; see + ../ChangeLog for rationale. + +Fri May 9 22:19:36 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * main.c (main): Add comment explaining why we call exit. Pass 0 + not EXIT_SUCCESS, because lib/system.h has portability cruft for + EXIT_FAILURE but not EXIT_SUCCESS. + +Fri May 9 17:25:00 1997 Larry Jones <larry.jones@sdrc.com> + + Fix miscellaneous memory allocation problems: + * add.c (add): Free repository. + * client.c (notified_a_file): Free getline buffer. + * edit.c (notify_check): Free getline buffer. + * hash.c (dellist): Free header node when not caching. + * login.c (login): Don't continually free & allocate getline + buffer, use xstrdup instead of xmalloc/strcpy, free getline + buffer before returning. + * main.c (main): Call exit instead of returning so tools like + Purify won't consider permanently allocated memory as leaks. + * mkmodules.c (mkmodules): Free getline buffer. + * modules.c (cat_module): Call close_module. + * rcs.c (rcsvers_delproc): Free state. + * recurse.c (start_recursion): Free files_by_dir. + (unroll_files_proc): NULL out p->data after using it to set + filelist to avoid multiple frees. + * server.c (check_command_legal_p): Don't continually free & + allocate getline buffer, free getline buffer before returning. + (check_repository_password): Ditto, use xstrdup instead of + xmalloc/strcpy. + * wrapper.c (wrap_add_file): Free getline buffer. + +Thu May 8 14:21:00 1997 Larry Jones <larry.jones@sdrc.com> + and Jim Kingdon <kingdon@harvey.cyclic.com> + + * checkout.c (checkout_proc): Free finfo.rcs (memory leak). + +8 May 1997 Larry Jones <larry.jones@sdrc.com> + and Jim Kingdon <kingdon@harvey.cyclic.com> + + * hash.c: Add #ifdef's to disable caching. This makes it easier + to track down memory allocation problems. + +Thu May 8 11:40:39 1997 Larry Jones <larry.jones@sdrc.com> + + * sanity.sh: In setting "tests" use a number of statements rather + than one very long line. + +Thu May 8 11:40:39 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvsbug.sh: Remove $Id; we decided to get rid of these some time + ago. + +Thu May 8 11:34:02 1997 Larry Jones <larry.jones@sdrc.com> + + * cvsbug.sh: Put separate statements on separate lines, so it + works if awk is AT&T nawk. + +Tue May 6 16:56:00 1997 Larry Jones <larry.jones@sdrc.com> + and Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvsrc.c (read_cvsrc): Fix various memory allocation problems: + rearrange code to avoid leaks, use xrealloc instead of xmalloc/ + copy/free, make sure there's room for the remaining args before + appending them. + +Tue May 6 14:20:00 1997 Larry Jones <larry.jones@sdrc.com> + + * edit.c (watch_onoff, edit, unedit, editors): Add -R like + other things with -l. + * watch.c (watch_addremove, watchers): Ditto. + +Mon May 5 18:10:37 1997 larry.jones@sdrc.com + and Jim Kingdon <kingdon@harvey.cyclic.com> + + * sanity.sh: Change all /tmp/cvs-sanity to TESTDIR. If TESTDIR + environment variable is set, use it instead of /tmp/cvs-sanity. + * sanity.sh: Make TMPPWD the pwd equivalent of TESTDIR, not of /tmp. + +4 May 1997 Larry jones <larry.jones@sdrc.com> + and Jim Kingdon + + * checkout.c, diff.c, patch.c, rcs.c: Update usage messages. + * rcs.c (annotate): Add -R like other things with -l. + +Sat May 3 14:57:40 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * sanity.sh (basic1): Rewrite test (use dotest, unroll the loops + which IMHO makes the test a zillion times more understandable, and + only do the variant which tests for 4 files at a time--we test one + file at a time lots of places). + +2 May 1997 Ziv Gigus <ziv@rest.home.net> + and Jim Kingdon + + * client.c, client.h (client_process_import_file): New argument + all_files_binary means treat all files as binary. + * import.c (import_descend): Pass it if -kb is specified. + * client.c (client_process_import_file): In the + non-all_files_binary case, call wrap_rcsoption to determine + whether the file is binary. + +Thu May 1 13:44:51 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * sanity.sh (binfiles2): New tests, for update -j and binary files. + +Wed Apr 30 11:18:36 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * recurse.c (start_recursion): Also free reposfile. + Don't look in repository if client_active (latter bug reported by Paul + Sanders <p.sanders@dial.pipex.com>). + +Mon Apr 28 22:36:39 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * diff.c (diff_file_nodiff): Remove SERVER_SUPPORT ifdefs. They + were not based on server_active, which doesn't really make any + sense (it meant that compiling --disable-server could affect the + behavior of the non-client/server CVS). This affected the output + in tests death2-diff-11 and death2-diff-12 in the testsuite. + * sanity.sh (newb-123j0): Also accept "Needs Checkout", for a + --disable-server CVS. + + * main.c (cmd_usage): Change "run diffs" to "show differences"; + the former is jargon. + * edit.c (edit_usage): Fix typo ("." -> ","). + * edit.c (editors_usage), watch.c (watchers_usage): Mention -l. + * checkout.c (export_usage): Say what -P does. + * history.c (history_usg): Add comment about message wording. + +Mon Apr 28 14:47:45 1997 Norbert Kiesel <nk@cosa.de> + + * checkin.c (Checkin): use filename without path when calling + wrapper (bug found by Michal Schmitz <ms@cosa.de>). + +Fri Apr 25 13:28:55 1997 Ian Lance Taylor <ian@cygnus.com> + + * client.c (update_entries): In UPDATE_ENTRIES_RCS_DIFF case, + write to a temporary file and then rename it. + +Thu Apr 24 11:35:40 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * subr.c, cvs.h (pathname_levels): New function, from a piece of + send_file_names. + * client.c (send_file_names): Call pathname_levels in place of the + code which was moved there. + * server.c, server.h (server_pathname_check): New function. + * recurse.c (start_recursion): Call it. + * sanity.sh (modules3): New test modules3-11b tests for above fix. + + * filesubr.c: Do not define L_tmpnam. It is in ANSI and SunOS4, + so I don't think there will be a problem with it being missing. + Defining it too small can cause memory corruption. + (cvs_temp_name): Do not use L_tmpnam in the mktemp code; this + could cause a buffer overflow if the -T global option was in use. + +Thu Apr 24 13:21:15 1997 Norbert Kiesel <nk@cosa.de> + + * filesubr.c (cvs_temp_name): Use tempnam if available, else + mktemp, else tmpnam. See the comment for rationale. + + * sanity.sh: use "tar cf - ." instead of "tar cf - *" for + directory copies. + +Wed Apr 23 23:41:47 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * server.c (serve_update_prog): If in readonly mode, give an error. + +Wed Apr 23 19:07:41 1997 Norbert Kiesel <nk@cosa.de> + + * subr.c (line2argv): Allocate at least 4 slots for argv. + + * checkout.c (checkout_proc): Add a comment which says why the + above change was necessary to avoid writing to unallocated memory. + +Wed Apr 23 11:20:40 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * entries.c (ParseTag): Always set *NONBRANCHP. + +21 Apr 1997 Jim Kingdon + + * client.c (update_entries), rcs.c (expand_keywords): Rewrite + test to avoid signed/unsigned warning. + +Mon Apr 21 09:02:22 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * update.c (patch_file): Add comment about whether auto-detecting + features of the DIFF program is a good idea. + +Mon Apr 21 00:03:34 1997 Ian Lance Taylor <ian@cygnus.com> + + Don't require the patch program: + * client.c (struct update_entries_data): Add + UPDATE_ENTRIES_RCS_DIFF to contents enum. + (update_entries): Handle UPDATE_ENTRIES_RCS_DIFF. + (handle_rcs_diff): New static function. + (responses): Add "Rcs-diff". + * server.c (server_updated): Handle SERVER_RCS_DIFF. + (server_use_rcs_diff): New function. + * server.h (enum server_updated_arg4): Add SERVER_RCS_DIFF. + (server_use_rcs_diff): Declare. + * update.c (rcs_diff_patches): New static variable. + (update): Set rcs_diff_patches. + (update_fileproc): If rcs_diff_patches, pass SERVER_RCS_DIFF + rather than SERVER_PATCHED to server_updated. + (patch_file): Correct initial comment to say diff rather than + rcsdiff. If rcs_diff_options, pass -n to diff rather than -c. + * rcs.c (rcs_change_text): New function. + * rcs.h (rcs_change_text): Declare. + +Mon Apr 21 00:08:59 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * diff.c (diff_fileproc): Add comment concerning updating the + client timestamp. + +Sun Apr 20 23:20:37 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * commit.c (commit): Add comment regarding SEND_FORCE rationale. + +Sat Apr 19 17:10:36 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * server.c (dirswitch): If directory ends in '/', complain. + +Fri Apr 18 18:09:57 1997 Ian Lance Taylor <ian@cygnus.com> + + * rcs.c (apply_rcs_changes): New static function, broken out of + RCS_deltas. + (RCS_deltas): Call it. + (linevector_add): Change return type to int. Return an indication + of an error for an invalid add, rather than calling error. + +Fri Apr 18 11:24:26 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * version.c: Change version number to 1.9.9. + + * version.c: Version 1.9.8. + + * commit.c (struct find_data): Add field force. + (find_fileproc, commit): Use it instead of force_ci to decide + whether to send files to server. + (commit): Set it if either -f or -r is specified. + * sanity.sh (basica): Add tests basica-8a0, basica-8a1, and + basica-8a2; tests for above fix. + +Wed Apr 16 11:50:59 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * zlib.c: Remove paragraph with Free Software Foundation address. + See 2 Jan 1997 entry in ../ChangeLog for rationale. + +Tue Apr 15 00:36:23 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * update.c (patch_file_write): Always assign to final_nl, so that + it ends up reflecting whether the data from the last call had a + newline, not whether the data from any of the calls ended in a + newline. Doesn't matter with the current RCS_checkout + implementation, but it will if RCS_checkout is changed to pass + less than the entire file. + + * rcs.c (RCS_cmp_file): Change NULL to RUN_TTY in passing sout to + RCS_checkout, for clarity. + + * import.c (update_rcs_file): Remove unused variable ierrno. + + * add.c, checkout.c, commit.c, diff.c, edit.c, import.c, + history.c, log.c, main.c, patch.c, release.c, remove.c, rtag.c, + status.c, tag.c, update.c, watch.c: Pass "+" to all calls to + getopt. This ensures that we maintain existing behavior even with + glibc2. + + * filesubr.c (fopen_case): Don't set *PATHP if we return an + error. Since the 9 Apr 1997 change, the behavior has been to + sometimes set it and sometimes not. + * rcs.c (RCS_parse): Adjust callers to not free it. Without this + change, they could call free() on an uninitialized variable. + + * checkout.c (checkout): Add comment about export -k. + + * root.c (check_root_consistent): Add comment about wording of + message. + +Mon Apr 14 11:51:49 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * client.c (call_in_directory): If rdirp reaches the end of + reposdirname, then just set it to NULL. If server does not create + directories one at a time, give a warning. + * sanity.sh (modules3): Enable tests modules3-8 through + modules3-11 for remote; tests for above fix. + + * client.c (call_in_directory): Don't set short_pathname to + pathname for a while; just use pathname itself (cleans up a relic + of the old "Repository" (not "Directory") code). Add comment + explaining short_pathname. + +Sun Apr 13 18:07:50 1997 Ian Lance Taylor <ian@cygnus.com> + + * rcs.c (RCS_checkout): Add pfn and callerdat parameters. Change + all callers. Move setting of expand after retrieval of file + data. + (struct cmp_file_data): Define. + (RCS_cmp_file): New function. + (cmp_file_buffer): New static function. + * rcs.h (RCSCHECKOUTPROC): Define type. + (RCS_checkout): Update declaration. + (RCS_cmp_file): Define. + * diff.c (diff_file_nodiff): Call RCS_cmp_file rather than + RCS_checkout and xcmp. + * import.c (update_rcs_file): Likewise. + * no_diff.c (No_Difference): Likewise. + * update.c (struct patch_file_data): Define. + (patch_file): Just return if noexec, or if binary file. Pass + patch_file_write to RCS_checkout. Don't check for newlines or + compute checksums here. Stat RCS file to set modes. + (patch_file_write): New static function. + + * update.c (patch_file): Checkout directly to file2, rather than + to finfo->file followed by rename. Remove check for whether + result of checkout is readable; that was for an old, obsolete, + form of death support. + +Sun Apr 13 13:16:40 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * checkout.c (build_one_dir): New function. + (struct dir_to_build): New structure. + (build_dirs_and_chir): Rewritten to accept a linked list of struct + dir_to_build rather than the silly string processing we had been + doing before. + (checkout_proc): Rewrite code that calls build_dirs_and_chdir + accordingly. + * sanity.sh: Enable tests modules3-10 and modules3-11 for local CVS; + tests for above fix. + + * rcs.h (RCS_CO): Removed; no longer used. + +Sun Apr 13 00:04:34 1997 Ian Lance Taylor <ian@cygnus.com> + + Expand RCS keywords internally; never call co: + * rcs.h (struct rcsversnode): Add state field. + * rcs.c (kflags): Move out of RCS_check_kflag, and make file + static. + (enum kflag): Define. + (RCS_reparsercsfile): Always save lock information. Save state in + new state field, rather than other field. + (struct rcs_keyword): Define. + (keywords): New static variable. + (enum keyword): Define. + (printable_date, escape_keyword_value): New static functions. + (expand_keywords): New static function. + (RCS_checkout): Call expand_keywords. Don't call + RCS_exec_checkout. + (RCS_deltas): Add log and loglen parameters. Change all callers. + * log.c (log_version_requested): Use new state field. + (log_version): Likewise. + * cvs.h (RCS_exec_checkout): Don't declare. + * rcscmds.c (RCS_exec_checkout): Remove. + +Sat Apr 12 17:32:59 1997 Ian Lance Taylor <ian@cygnus.com> + + * sanity.sh (modules3): Remove second-dir at end of tests. + (sticky): Correct removal of directories at end of tests. + + * sanity.sh (keyword): New tests for RCS keyword expansion. + +Sat Apr 12 16:47:13 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * sanity.sh (basicb): New tests basicb-1b, basicb-1c, basicb-9b, + basic-9c test current build_dirs_and_chdir behavior. + +Fri Apr 11 23:54:56 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * sanity.sh (modules3): New tests modules3-7* test for ability to + supply a path in -d in modules. Similar to modules3-8 through + modules3-11 except because the nesting is different, these ones + work. + +Thu Apr 10 00:14:47 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * sanity.sh (modules3): New tests modules3-12 through modules3-15 + test use of a module name which contains a slash. + + * sanity.sh (basicb): New tests basicb-14 to basicb-20 test use of + co -d with two or more arguments. + + * rcscmds.c: Refer to doc/RCSFILES in comment. + +Wed Apr 9 09:49:17 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * sanity.sh (basicb): New tests basicb-11 through basicb-13 test + ability to specify several directory levels in co -d (commented + out). + + * filesubr.c (fopen_case): If CVS_OPENDIR gives an + existence_error, return it to the caller instead of giving a fatal + error. + + * client.c (update_entries): Fix typo in call to error (1 -> errno). + +Tue Apr 8 23:02:22 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * error.h, error.c: Test for #ifdef __STDC__, not #if __STDC__. + This is consistent with other parts of CVS; it means that the + declaration for fperror will match the definition even if __STDC__ + is defined to 0 as the SunPro 4.0 compiler does. Reported by + Richard Smith <rjsmith@cisco.com>. + +2 Apr 1997 Jim Kingdon + + * entries.c (ParseTag): Add "break;" after "default:" to avoid + error from Visual C++. + +Wed Apr 2 12:06:44 1997 Vince Del Vecchio <vdelvecc@spd.analog.com> + and Jim Kingdon + + * client.c: In reporting errors from socket calls, use + SOCK_STRERROR and SOCK_ERRNO since strerror(errno) doesn't work + for Win32. + +Tue Apr 8 10:45:32 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * sanity.sh (modules3): Add tests modules3-8 to modules3-11, to + test for ability to supply a path to -d in modules. Mostly + commented out as CVS is buggy in this area. + +Mon Apr 7 12:41:44 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * add.c (add): Add comment about SEND_NO_CONTENTS. + +Sun Apr 6 21:46:32 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * update.c (update): Add comment about noexec and SEND_NO_CONTENTS. + +Sun Apr 6 17:34:08 1997 Robert Bihlmeyer <robbe@orcus.priv.at> + + * Pass +f not f to getopt_long to prevent options from being + permuted with glibc 2.0.1. + +Sun Mar 30 00:07:05 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvs.h (struct vers_ts): Adjust comment regarding ts_user. + * server.c (serve_is_modified): New function. Set entries to show + that the file is modified but we don't know the contents. + * server.c (requests): Add "Is-modified" request. + * vers_ts.c (time_stamp_server): If the timestamp in entdata is + "M" or "D", just copy that over into ts_user. + * vers_ts.c (Version_TS): If timestamp is "D", use the entries + line for the sole purpose of passing it to time_stamp_server. + * no_diff.c (No_Difference): If ts_user is "M", conclude the files + are different. + * client.h, client.c (send_files): Replace arguments build_dirs + and force with argument flags. Add flag SEND_NO_CONTENTS and add + to struct send_data. + (send_fileproc): If no_contents, then send Is-modified instead of + Modified. + * add.c, admin.c, client.c, commit.c, diff.c, edit.c, log.c, + rcs.c, remove.c, status.c, tag.c, update.c, watch.c: Change all + send_files callers. + +Fri Mar 28 22:32:25 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * server.c (requests): Change "Repository" to rq_optional. I'm + not sure whether I overlooked this when I removed support for + Repository, or whether I was thinking that servers would need to + support it anyway, for CVS 1.5 to 1.9 clients, but making it + optional doesn't prevent the server from supporting it and it + seems silly for the client to complain about absence of a request + that it never will use. + +Fri Mar 28 10:06:59 1997 Steven Miller <Miller@wingra.com> + + * entries.c (Subdirs_Known): Don't create Entries.Log if noexec. + +Thu Mar 27 18:14:12 1997 Ian Lance Taylor <ian@cygnus.com> + + * sanity.sh (death2): Remove commented out test death2-21. It + would now pass, but it duplicates the new test sticky-11. + +Thu Mar 27 10:21:19 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * sanity.sh (dotest_internal): Write test output to logfile even + if test succeeds. This was the behavior prior to 30 Sep 1996. + See the comment for rationale. + +Tue Mar 25 13:26:52 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvs.h, entries.c (WriteTag): Add arguments nonbranch, + update_dir, and repository. Move the server_set_sticky call from + callers to here. + * cvs.h, create_adm.c (Create_Admin): New argument nonbranch. + * cvs.h, entries.c (ParseTag): Add argument nonbranchp. + * cvs.h (struct stickydirtag): Add field nonbranch. + * entries.c (Entries_Open): Set it. + * cvs.h (Vers_TS): Add field nonbranch. + * vers_ts.c (Version_TS): Copy it from struct stickydirtag. + * server.c, server.h (server_set_sticky): Add argument nonbranch. + * add.c, client.c, checkout.c, modules.c, update.c, create_adm.c, + commit.c: Update callers. + * add.c (add): If nonbranch, don't add the file on that "branch". + * commit.c (write_dirnonbranch): New variable. + (commit_fileproc, commit): Set it. + (commit_dirleaveproc): Pass it to WriteTag. + * update.c (rewrite_tag, nonbranch): New variables. + (update, update_dirent_proc, update_fileproc): Set them. + (update_filesdoneproc): If rewrite_tag, call WriteTag. + * sanity.sh (sticky): New tests, test for above fix. + + * version.c: Change version number to 1.9.7. + + * version.c: Version 1.9.6. + +Mon Mar 24 13:02:04 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * entries.c (ParseTag): Add comment about unrecognized characters + in CVS/Tag file. + + * classify.c (Classify_File): Add comment about how specifying a + tag (bogusly?) suppresses certain messages. + +Fri Mar 21 13:37:46 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * rcs.h (struct rcsnode): Add comment about case of PATH. + * rcs.c (RCS_parse): If ign_case, then try opening the file with + fopen_case. + * ignore.c (ign_case): Adjust comment. + * cvs.h, filesubr.c (cvs_casecmp, fopen_case): New functions. + +20 Mar 1997 Jim Kingdon + + * client.c (send_repository): When sending Directory request, + send any ISDIRSEP character as '/'. Fixes + "cvs log foo\bar\baz.c" on NT & friends. + + * client.c (send_file_names): Don't try to read Entries file if + CVSADM directory does not exist. Fixes fairly serious regression + (warning on all fresh checkouts) introduced by 1997-01-08 change. + +Tue Mar 18 13:03:33 1997 Jim Meyering <meyering@totoro.cyclic.com> + + * sanity.sh (RCSINIT): Define to be empty and export, to hide any + existing value that might cause spurious failures. + + * Makefile.in: (install): Depend on installdirs. + Remove `CYGNUS LOCAL' comment saying not to. + +Tue Mar 18 09:36:26 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * recurse.c (struct recursion_frame): Reindent. + (do_dir_proc): Print message if we try to recurse into a CVSADM + directory. + * sanity.sh (basicb): New test basicb-4a tests for above fix. + +Sun Mar 16 10:18:28 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * sanity.sh (death2): Replace regexp matching temporary file name + with new variable ${tempname}. For most of the tests this is a + cosmetic change, but death2-diff-6 had been missing _ which caused + it to fail on Solaris (at least sometimes). + + * sanity.sh (modes): Don't use export -n; it doesn't seem + to be sufficiently portable. + + * version.c: Change version number to 1.9.5. + + * version.c: Version 1.9.4. + + * rcscmds.c (RCS_checkin): Preserve the mode of the rcsfile. + RCS_CI usually, but not always, does this for us. + * commit.c (fix_rcs_modes): Replace algorithm with a more + CVSUMASK-friendly one. + * sanity.sh (modes): Update tests modes-5, modes-7, modes-10, and + modes-15 so they test that CVSUMASK is honored. + +Sun Mar 16 10:18:28 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * sanity.sh (modes): New tests modes-7a and modes-7b test behavior + if one manually changes the modes in the repository. + + * server.c (server): Revise code which checks for errors creating + temporary directory. This won't solve the intermittent + can't create temporary directory + Unknown error -1 + but it will mean (a) the right message based on errno gets + printed, instead of "unknown error -1", and (b) the message says + that it happened in chmod instead of mkdir_p. + +Sat Mar 15 16:47:12 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * sanity.sh (modes): New tests. Note that (for now) these are + just testing how CVS already behaves; I want to record that before + I move on to changing CVS's behavior with modes of RCS files. + +13 Mar 1997 Jim Kingdon + + * subr.c (line2argv): Change argv_allocated from size_t to int. + +Wed Mar 12 22:16:44 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * add.c (add_directory): If repository has an extraneous "." + directory at the end, strip it off. This fixes a bug which was + introduced when strip_path was nuked (this fix is much more + limited in scope than strip_path was; I _think_ that is a good + thing). + (add): Likewise, for client. + (combine_dir): New function, helps with above. + * sanity.sh (modules3): Reenable tests for this behavior. + (basica-0b, basicb-0e): Adjust test to reflect "foo/bar" instead + of "foo/./bar" in message. As with the rest of this, I believe + this is just restoring the behavior prior to the strip_path nuking + (I tried it with CVS 1.9). + +Sun Mar 9 10:06:29 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * root.c (parse_cvsroot), server.c (serve_root, serve_init): + If CVSroot_directory is not an absolute pathname, give a fatal error. + * sanity.sh (crerepos): New tests crerepos-6* test for above fixes. + +Sat Mar 8 22:06:17 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + This cleans up the last known code which can overflow its buffers + (except the Mac client). I've skimmed through much of CVS looking + for other such places; but I didn't read everything. If I missed + any please report it to bug-cvs. + * logmsg.c (logfile_write, title_proc): Realloc str_list as + needed; don't assume MAXLISTLEN is enough. + * cvs.h (MAXLISTLEN, MAXFILEPERDIR): Removed; no longer used. + * add.c, myndbm.c, parseinfo.c, update.c: Nuke MAXLINELEN limit. + * parseinfo.c, update.c, mkmodules.c: Check for errors reading file. + * cvs.h (MAXLINELEN): Removed; no longer used. + * logmsg (MAXHOSTNAMELEN): Removed; not used. + * main.c (cmd_synonyms): Allocate based on fullname, nick1, and + nick2, just in case someone makes those big enough so that 100 + bytes is not enough. + (Make_Date): Use MAXDATELEN rather than our own fixed size. + * mkmodules.c (mkmodules): Nuke arbitrary limit on line length. + * rcs.c (ALLOCINCR): Remove; not used. + (RCS_check_kflag): Add comment concerning karg size. + * run.c: Allocate run_prog to the needed size, rather than + allocating a fixed size buffer. + +Fri Mar 7 22:39:08 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * logmsg.c (logfile_write): Allocate prog to needed length rather + than assuming MAXPROGLEN is enough. + * cvs.h (MAXPROGLEN): Removed; no longer used. + * subr.c (MIN_INCR): Update comment to reflect MAXPROGLEN's demise. + + * subr.c (free_names): Fix comment: this function is not used to + free memory allocated by Find_Names (at least it hasn't for a long + time). + * subr.c, cvs.h (line2argv): Change calling convention so that we + allocate argv array rather than the caller. The previous one had + no way of checking whether we overflowed the passed-in buffer. + * subr.c (free_names): Free the argv array too. + * modules.c (do_module, cat_module): Update callers. + +Thu Mar 6 12:44:42 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * import.c: Allocate vhead and vbranch dynamically; removes + arbitrary limit. + * history.c: Likewise (since_rev, since_tag, backto, rec_types). + * ignore.c: Likewise (line). Also check for errors from getline + and add 'copyright' notice to top of file. + * wrapper.c (wrap_add_file): Likewise (line). Also check for + errors from various calls and add 'copyright' notice to top of file. + +Tue Mar 4 17:39:15 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * client.c (update_entries): Add comment about "move away <file>" + message. + +Mon Mar 3 21:51:40 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * sanity.sh (basicb): Clean up topfile,v at end of test. Fixes + failure in modules-155b. + +Sun Mar 2 18:11:09 1997 Dan Wilder <dan@gasboy.com> + and Jim Kingdon + + * admin.c (admin): Arrange to perform recursion if "cvs admin" + is passed only options. + +Sun Mar 2 18:11:09 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * sanity.sh (basicb): New tests basicb-0* test for files at top + level. + + * error.c (error): Add newline to "out of memory" message. I think + that its omission probably could cause the message to be lost in + the bowels of server.c and never passed to the user. + + * client.c (start_rsh_server): Add comment about "remsh" vs. "rsh". + + * cvs.h: Move copyright notice to top of file. + +Sun Mar 2 13:44:36 1997 Ian Lance Taylor <ian@cygnus.com> + + * sanity.sh: Use -n when testing whether rsh works. + + * server.c (serve_root): Free path. + +Sun Mar 2 13:12:46 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + The following are things that I noticed in the process of trying + to track down: + can't create temporary directory + Unknown error -1 + FAIL: test 28 + from nightly testing. I'm not sure that either item explains that + message however. + * server.c (server): Allocate pending_error_text; + print_pending_error will try to free it so + pending_error_text = "foo" + won't work. + (mkdir_p): Don't assume that isdir will leave errno unmolested. + +Thu Feb 27 15:29:58 1997 Ian Lance Taylor <ian@cygnus.com> + + * remove.c (cvsremove): When forcing removal in client mode, use + start_recursion rather than calling CVS_UNLINK on each argument. + (remove_force_fileproc): New static function. + * sanity.sh (deep): Add tests deep-rm7 through deep-rm10 for above + patch. + + * sanity.sh (death): Enable death-76a0 and death-76a1 tests for + remote, since they now work. + +Wed Feb 26 16:13:26 1997 Ian Lance Taylor <ian@cygnus.com> + + * client.c (add_prune_candidate): Skip adding this directory if + it is the same as the first directory already on the list. + +Mon Feb 24 21:36:43 1997 Noel Cragg <noel@gargle.rain.org> + + * main.c (lookup_command_attribute): Add the "init" command to the + list of commands that don't use the current working directory. + +Sun Feb 23 09:54:49 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * sanity.sh (devcom3): Clean up at end of test. + + * sanity.sh (basicb): Add commented out test basicb-8a0, for + whether CVS can print an error on bad numeric revision to diff. + Commented out until we get around to fixing CVS. + * diff.c (diff_file_nodiff): Add comment about this case. + + * fileattr.c (fileattr_read): If a filename is duplicated, + continue to ignore subsequent lines but free the node so that we + don't leak memory. + * sanity.sh (devcom3): New tests devcom3-8 and devcom3-9 test for + behavior on duplicated filenames. + + * fileattr.h: Add comment about unrecognized ENT-TYPE and order of + lines in fileattr file. + * fileattr.c (struct unrecog, unrecog_head): New variables, to + record unrecognized lines. + (fileattr_startdir): Assert that unrecog_head == NULL. + (fileattr_read): Record unrecognized lines in unrecog_head linked + list rather than ignoring them. + (fileattr_write): Also write out unrecognized lines, if any. + * sanity.sh (devcom3): New tests, test for above fix. + + * fileattr.h (fileattr_modify): Fix example in comment. + +Sat Feb 22 08:30:27 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * sanity.sh: Add variable username. + (basica rdiff multibranch log log2): Use it instead of our own + (inconsistent) ways of matching an author name. + + * filesubr.c, root.c, rtag.c, server.c, subr.c, update.c, + wrapper.c: Nuke PATH_MAX. + * cvs.h, wrapper.c (wrap_fromcvs_process_file): Now returns void + (return value had been unused). + * cvs.h: Adjust comment to reflect the fact that PATH_MAX is + gone, at least from src/*.c (except safe_location, as noted). + +22 Feb 1997 patch by Tom Hageman <tom@basil.icce.rug.nl> (4 Jun 1996) + updated and commented by Jim Kingdon <kingdon@harvey.cyclic.com> + + * update.c (checkout_file): Call unlink_file_dir on backup, not + unlink_file. + +Fri Feb 21 16:40:03 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * Makefile.in (DISTFILES): Remove NOTES. + + * NOTES: Removed. bcopy->memcpy is done. "static buffers" I + assume refers to what is covered by reentrancy text in HACKING. + Obstack idea moved to comment in hash.c (at nodecache). Checking + system calls for error returns largely done, and isn't a very + helpful suggestion unless you know where the bogus calls are + anyway. Sizing limits--we're in the progress of removing them + (assuming it meant things like PATH_MAX and earlier, already + nuked, limits). Removed various items about changes which were + done a long time ago (I realize that the ChangeLog's probably + aren't reliable that far back, but I'm not convinced anyone cares + anymore). CONFIRM_DIRECTORY_ADDS: I assume this is a + reference to the #if 0'd code in add_directory which asks for + confirmation--a better way of making it harder to accidentally add + directories would be to have to add and commit directories like + for files. I don't know what FORCE_MESSAGE_ON_ADD meant. + + * rcs.c (RCS_getrevtime): Fix documentation (in particular, the + size of the array that DATE must point to, but many other things + too). + * patch.c, recurse.c, release.c, remove.c, repos.c: Nuke PATH_MAX. + (patch_fileproc): Use MAXDATELEN not hardcoded 50. + +Sun Feb 16 12:00:44 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * client.c (client_process_import_file): New variable fullname; + pass it to send_modified. This finishes the job of untangling the + old short_pathname variable into update_dir vs. fullname. + + * client.c (client_process_import_file): Nuke first_time. If + toplevel_repos were ever NULL here, the code would dump core in + strncmp a few lines down. And client_import_setup ensures + toplevel_repos is not NULL. + +Sun Feb 16 08:16:48 1997 Ian Lance Taylor <ian@cygnus.com> + + * client.c (client_process_import_file): Rename short_pathname to + update_dir (to reflect its function) and make sure that it doesn't + point to uninitialized memory if repository and toplevel_repos + contain the same string. + +Sun Feb 16 08:16:48 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * client.c (start_rsh_server): Nuke comment about weirdnesses with + pre-1.5 versions of CVS and .bashrc/.cshrc. The remote protocol + is interoperable only back to 1.5, and people who need to know are + unlikely to see this comment anyway. + +Sun Dec 15 13:12:30 1996 Michael Douglass <mikedoug@texas.net> + and Jim Kingdon <kingdon@harvey.cyclic.com> + + * main.c (cmds): Added an entry for new logout command. + (cmd_usage): Added an entry for new logout command. + (lookup_command_attribute): Added 'logout' to list of commands + that set need_to_crate_root to 1. + * login.c, cvs.h (logout): New command for removing entries from + the .cvspass file. + (logout_usage): Usage information on the logout command. + +Wed Feb 12 11:19:42 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * client.c (struct send_data): Fix indentation. + +Wed Feb 12 08:48:04 1997 Greg A. Woods <woods@most.weird.com> + + * mkmodules.c (loginfo_contents): add missing comma in + initializer statement (caused syntax error on SunOS-4). + +Tue Feb 11 21:14:28 1997 Ian Lance Taylor <ian@cygnus.com> + + * commit.c (find_fileproc): If force_ci is set, set the status to + T_MODIFIED even if the file hasn't changed. + (commit): Pass force_ci to send_files as new force argument. + * client.c (struct send_data): Define. + (send_fileproc): The callerdat parameter now points to a send_data + struct. If force is set, always call send_modified. + (send_dirent_proc): The callerdat parameter now points to a + send_data struct. + (send_files): Add force parameter. Change all callers. Set up a + send_data struct and pass it to start_recursion as callerdat. + * client.h (send_files): Update declaration. + * sanity.sh (basica): Add a simple test for the above patch. + +Sun Feb 9 12:58:59 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * tag.c (cvstag), rtag.c (rtag): Pass -f to server if specified in + the client. I haven't tried to come up with a test case because + the fix seems obvious. + + * import.c (add_rcs_file): Change size of altdate1 and altdate2 to + MAXDATELEN. + * cvs.h (MAXDATELEN): Fix comments; describe what this is for. + + * diff.c (diff_usage): Document --ifdef and try to briefly say + what "rcsdiff-options" means. + + * update.c (update): If update had a nonzero status and we haven't + yet tried to fetch unpatchable files, go ahead and try it again. + The previous behavior was to quit, which meant that updates would + keep failing until you hacked around the problem. Patch and bug + report by Ian; comment, ChangeLog entry, and willingness to take + the flak if checking it is premature by Jim. + + * server.c (alloc_pending): New function. + * server.c: Call it. Fixes places where we had neglected to + check for NULL return from malloc. + + * sanity.sh (binwrap): Add test binwrap-0, tests for import.c fix + below. + +Sun, 9 Feb 1997 (submitted 19 Jul 1996) John Polstra <jdp@polstra.com> + + * import.c (import): Give error if the same tag is specified more + than once. The previous behavior was to write an RCS file which + had the same tag listed twice, once pointing to each revision, + which is not legal. + +Sun Feb 9 12:37:09 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * checkin.c (Checkin): Use cvs_output to print message (should + make out of order bugs no worse, as it merely substitues a + protocol_pipe vs. stderr_pipe race instead of a stdout_pipe + vs. stderr_pipe race). Add comment about stdout vs. stderr. + +Fri Feb 7 08:29:52 1997 Josef Nelissen <josef.nelissen@munich.ixos.de> + + * server.c (check_command_legal_p): Don't use ANSI-style definition. + +Thu Feb 6 10:55:37 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * patch.c (patch): Give a fatal error for -V option (see comment + for rationale). + + * diff.c (diff): Also send "options" to server. Pretty much the + patch submitted independently by josef.nelissen@munich.ixos.de and + Ronald Khoo <ronald@demon.net>. + +Wed Feb 5 18:57:14 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * modules.c (do_module): Fix typo in 30 Jan 97 PATH_MAX nuking + (free -> free_cwd). Testsuite test 151 gets credit for catching + this one. + +Mon Feb 3 16:14:54 1997 Ian Lance Taylor <ian@cygnus.com> + + * main.c (lookup_command_attribute): Don't use an ANSI prototype + when defining the function. + +Fri Jan 31 12:49:02 1997 Ian Lance Taylor <ian@cygnus.com> + + * modules.c (do_module): Actually goto found if is_found is set + (fixes thinko in PATH_MAX nuking of 30 Jan 97). + +Fri Jan 31 12:49:02 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * sanity.sh: Add modules3 and big to list of tests to run + by default; they were omitted by accident. + +Thu Jan 30 11:46:33 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * logmsg.c, main.c, mkmodules.c, modules.c, parseinfo.c, patch.c: + Nuke more PATH_MAX. + + * server.c (server_updated): After we send Created or + Update-existing for a file, mark it as unchanged, in case we + process it again. + * sanity.sh (modules3): New tests, test for above fix. + + * logmsg.c (do_verify): Error return from fopen is NULL, not -1. + Pass errno to error(). + + * login.c [_CRAY]: Don't declare getpass. + +Mon Jan 27 17:25:27 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * import.c (process_import_file): Fix freeing of rcs (Don't free + it before we are done using it, and don't free it twice). + + * modules.c (cat_module): Allocate line right before we use + it. The previous code was wrong because the length of the + s_h->rest changes between the time we allocate line and the time we + sprintf s_h->rest into it. + +Sun Jan 26 21:58:16 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * expand_path.c (expand_path): Revise to call expand_string as + needed. Nuke PATH_MAX. + * find_names.c (find_dirs): Likewise. + * import.c, lock.c: Nuke more PATH_MAX. + + * server.c (mkdir_p): Set retval to 0 at start of function. + Previously it had been uninitialized for some cases. Thanks are + due to nightly testing for catching this one. + +Sat Jan 25 21:34:19 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * subr.c, cvs.h (expand_string): New function. + * rcs.c (getrcskey, getrcsrev): Call it. This greatly reduces the + number of calls to realloc if there is a very large file in the + RCS file. Credit goes to Mike Heath <mike@pswtech.com> for + pointing out the problem and the basic solution (MIN_INCR, + MAX_INCR); I adapted it into the separate function expand_string. + * sanity.sh (big): New test helps insure this hasn't broken + anything obvious. + +Wed Jan 22 10:06:13 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * status.c (status_fileproc): Change message which is printed for + T_MODIFIED and ts_conflict set, so that it doesn't say "unresolved + confict". This message occurs whether the conflict is resolved or + not. + * sanity.sh (conflicts): Add tests conflicts-status-* to test + output of "cvs status" in the context of conflicts. Tests for + above fix. + + * rtag.c (rtag): Send -n if run_module_prog is NOT true. + +Thu Jan 16 00:06:00 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * version.c: Change version number to 1.9.3. + + * version.c: Version 1.9.2. + +Wed Jan 15 09:14:38 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * client.c (call_in_directory): Take code that creates CVSADM at + top level, move it before the CVS_CHDIR (dir_name) call, and do it + regardless of whether dir_name is ".". Pass "." not dir_name to + Create_Admin (when the code was written they were always the + same). Don't add reposdirname to the repository we pass to + Create_Admin (when the code was written, I think reposdirname + probably would always be "."). Don't create CVSADM if + reposdirname_absolute. + * sanity.sh (basicb): Enable tests basicb-1a and basicb-9a for + remote; tests for above fix. + (basic1): Do entire test within a "1" directory to deal with + creation of CVS directories at top level. Support --keep. + (conflicts): In test conflicts-136, only update first-dir. + (basica): Uncomment the part that tests "cvs co -l .". That tests + the existing functionality which I might have (but hopefully did not) + perturbed with the call_in_directory changes. + +Mon Jan 13 11:04:32 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * server.c (check_command_legal_p): Do not call error (1, ...) + here; that will always cause a protocol violation by shutting down + the connection prematurely. Remove croak_on_illegal arg. + (do_cvs_command): Move call to check_command_legal_p until after + the call to print_pending_error. Print the error message ourself. + + * mkmodules.c (filelist): Add readers and writers. Add comment + about why passwd is not included. Add comment about meaning of + NULL contents field. + +Fri Jan 10 13:23:09 1997 Norbert Kiesel <nk@col.sw-ley.de> + + * release.c (release): Initialize delete_flag before reading it + (found by running purify) + + * logmsg.c (do_verify): Fix reading unallocated memory (found by + running purify) + +Thu Jan 9 16:32:47 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * checkout.c (build_dirs_and_chdir): Partially revert 3 Jan + change--move call to Subdir_Register back above the CVS_CHDIR call + (we need to register in the old, not the new, directory). Instead + of calling CVS_MKDIR and ignoring errors, call mkdir_if_needed; + this is an effort to catch errors there rather than catching them + in the CVS_CHDIR. This makes test 27-add-add in sanity.sh work + again. + + * find_names.c (Find_Directories): Remove code inside + #ifdef ATTIC_DIR_SUPPORT and replace it with a comment explaining + why we don't look in the attic. ATTIC_DIR_SUPPORT was never defined. + + * find_names.c (find_dirs): Add comment about tmp being unset. + + * commit.c (checkaddfile): Report errors with errno and specific + error messages. + + * rcs.c, commit.c, create_adm.c, entries.c, find_names.c, + ignore.c, history.c: Nuke PATH_MAX arbitrary limits. + +Wed Jan 8 23:07:41 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * add.c (add): Reindent a portion which needed it. + +1997-01-08 Jim Kingdon + + * client.c (send_file_names): When looking name up in Entries, + call Entries_Open and Entries_Close. This has two effects: + (1) we look at Entries.Log, and (2) we don't skip 'D' entries, + both of which are needed to make us get the right (command + line) name for a directory we are adding. + +Wed Jan 8 14:50:47 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * Makefile.in, cvs.h, hash.h, myndbm.h, rcs.h: Remove CVSid; we + decided to get rid of these some time ago. + +Tue Jan 7 12:56:10 1997 Karl Fogel <kfogel@ynu38.ynu.edu.cn> + + * root.c (check_root_consistent): new func, compares below new + global var with CVSroot_directory, assuming both set. + (set_local_cvsroot): use above new func for security check. + (parse_cvsroot): same. + But do all of above only #ifdef AUTH_SERVER_SUPPORT. + + * server.c: (Pserver_Repos): new global var, init to NULL. + (pserver_authenticate_connection): set above new global. + (check_repository_password): be a good scout and use + CVSROOTADM and CVSROOTADM_PASSWD, now that they are the standard. + Make sure all of above is in #ifdef AUTH_SERVER_SUPPORT. + (check_command_legal_p): wrap most of body in #ifdef + AUTH_SERVER_SUPPORT. + Everywhere: wrap all references to CVS_Username in #ifdef + AUTH_SERVER_SUPPORT. + + * cvs.h (Pserver_Repos): new var, used in consistency [security] + check. Defined only #ifdef AUTH_SERVER_SUPPORT. + (CVSROOTADM_PASSWD): new #define, trying to get with the program. + +Fri Jan 3 18:10:39 1997 Ian Lance Taylor <ian@cygnus.com> + + * checkout.c (build_dirs_and_chdir): Move call to Subdir_Register + until after we know that the directory exists. + +Thu Jan 2 13:30:56 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * Makefile.in, cvsbug.sh, edit.c, edit.h, error.c, error.h, + fileattr.c, fileattr.h, filesubr.c, run.c, update.h, watch.c, + watch.h: Remove "675" paragraph; see ../ChangeLog for rationale. + +Thu Jan 2 12:27:46 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * sanity.sh (info): New test info-cleanup-verifymsg gets rid of + verifymsg when we are done with it. + + * sanity.sh (basicb): Skip tests basicb-1a and basicb-9a for remote. + * sanity.sh (modules-155a4): It is OK if a CVS directory exists. + * sanity.sh (ignore): Do everything inside a "1" directory. The + change to create CVS directories at top-level causes messages such as + "? home" otherwise. In test 191, specify -I CVS so that new CVS + directory is ignored. + * sanity.sh (crerepos): Manually remove CVS directory which had not + existed before. + +Thu Jan 2 09:06:20 1997 Karl Fogel <kfogel@ynu38.ynu.edu.cn> + + * server.c: Changes for pserver read-only repository access: + (check_command_legal_p): new func. Right now, just checks if + repository modification is permitted, and that only if pserver is + active. + (do_cvs_command): take new parameter `cmd_name', a string. All + callers changed. Pass it on to new func check_command_legal_p() + before executing the command. + (CVS_Username): new global, init to NULL. Used by + check_command_legal_p(), set in check_password(). + (check_password): set above new global CVS_Username; reorganized a + bit to facilitate this. + (check_repository_password): give *host_user_ptr permanent + storage iff success. + + * main.c: Changes for pserver read-only repository access: + (lookup_command_attribute): new func. + (main): use new func lookup_command_attribute() to establish if + CVS_CMD_IGNORE_ADMROOT and CVS_CMD_USES_WORK_DIR. + + * cvs.h: Changes for pserver read-only repository access: + (CVSROOTADM_READERS, CVSROOTADM_WRITERS): new #defines. + Prototype lookup_command_attribute(). + (CVS_CMD_IGNORE_ADMROOT, CVS_CMD_USES_WORK_DIR, + CVS_CMD_MODIFIES_REPOSITORY): new #defines for + lookup_command_attribute() and its callers. + +Wed Jan 1 19:50:38 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * options.h.in: Reword comment for TMPDIR_DFLT to make it clear + that this isn't specific to the pserver server. + + * modules.c (do_module): Give an error message if one tries to + specify -a together with another option. + * sanity.sh (modules2): New tests modules2-a* test for above fix. + + * sanity.sh (devcom): Add tests devcom-a-nonexist and + devcom-t-nonexist for "cvs watchers" on nonexistent argument. + +1997-01-01 Fred Fish <fnf@ninemoons.com> + + * run.c (piped_child, filter_stream_through_program): Actually + install these HAVE_VFORK patches that got missed. + (There was a log entry for these changes for 29 Nov 1996 but it + seems I accidentally forgot to actually check them in -kingdon). + +Wed Jan 1 18:32:44 1997 Jim Kingdon <kingdon@harvey.cyclic.com> + + * Makefile.in: Add ChangeLog-96. + * ChangeLog-96: New file, contains former contents of ChangeLog. + * ChangeLog: Now just contains 1997 changes. + + +For older changes see ChangeLog-96. diff --git a/contrib/cvs/src/Makefile.in b/contrib/cvs/src/Makefile.in index f02edf2..296554a 100644 --- a/contrib/cvs/src/Makefile.in +++ b/contrib/cvs/src/Makefile.in @@ -60,7 +60,7 @@ HEADERS = buffer.h cvs.h rcs.h hash.h myndbm.h \ TAGFILES = $(HEADERS) options.h.in $(SOURCES) DISTFILES = .cvsignore Makefile.in \ - ChangeLog ChangeLog-96 ChangeLog-9395 ChangeLog-9194 \ + ChangeLog ChangeLog-97 ChangeLog-96 ChangeLog-9395 ChangeLog-9194 \ sanity.sh cvsbug.sh $(TAGFILES) build_src.com PROGS = cvs cvsbug @@ -144,10 +144,10 @@ dist-dir: # Linking rules. -$(PROGS): ../lib/libcvs.a ../zlib/libz.a +$(PROGS): ../lib/libcvs.a ../zlib/libz.a ../diff/libdiff.a cvs: $(OBJECTS) - $(CC) $(OBJECTS) ../lib/libcvs.a ../zlib/libz.a $(LIBS) $(LDFLAGS) -o $@ + $(CC) $(OBJECTS) ../lib/libcvs.a ../zlib/libz.a ../diff/libdiff.a $(LIBS) $(LDFLAGS) -o $@ xlint: $(SOURCES) files= ; \ diff --git a/contrib/cvs/src/add.c b/contrib/cvs/src/add.c index 9220930..ab667df 100644 --- a/contrib/cvs/src/add.c +++ b/contrib/cvs/src/add.c @@ -3,7 +3,7 @@ * Copyright (c) 1989-1992, Brian Berliner * * You may distribute under the terms of the GNU General Public License as - * specified in the README file that comes with the CVS 1.4 kit. + * specified in the README file that comes with the CVS source distribution. * * Add * @@ -26,8 +26,9 @@ #include "cvs.h" #include "savecwd.h" +#include "fileattr.h" -static int add_directory PROTO((char *repository, List *, char *dir)); +static int add_directory PROTO ((struct file_info *finfo)); static int build_entry PROTO((char *repository, char *user, char *options, char *message, List * entries, char *tag)); @@ -36,57 +37,16 @@ static const char *const add_usage[] = "Usage: %s %s [-k rcs-kflag] [-m message] files...\n", "\t-k\tUse \"rcs-kflag\" to add the file with the specified kflag.\n", "\t-m\tUse \"message\" for the creation log.\n", + "(Specify the --help global option for a list of other help options)\n", NULL }; -static char *combine_dir PROTO ((char *, char *)); - -/* Given a directory DIR and a subdirectory within it, SUBDIR, combine - the two into a new directory name. Returns a newly malloc'd string. - For now this is a fairly simple affair, but perhaps it will want - to have grander ambitions in the context of VMS or others (or perhaps - not, perhaps that should all be hidden inside CVS_FOPEN and libc and so - on, and CVS should just see foo/bar/baz style pathnames). */ -static char * -combine_dir (dir, subdir) - char *dir; - char *subdir; -{ - char *retval; - size_t dir_len; - - dir_len = strlen (dir); - retval = xmalloc (dir_len + strlen (subdir) + 10); - if (dir_len >= 2 - && dir[dir_len - 1] == '.' - && ISDIRSEP (dir[dir_len - 2])) - { - /* The dir name has an extraneous "." at the end. - I'm not completely sure that this is the best place - to strip it off--it is possible that Name_Repository - should do so, or it shouldn't be in the CVS/Repository - file in the first place. Fixing it here seems like - a safe, small change, but I'm not sure it catches - all the cases. */ - strncpy (retval, dir, dir_len - 2); - retval[dir_len - 2] = '\0'; - } - else - { - strcpy (retval, dir); - } - strcat (retval, "/"); - strcat (retval, subdir); - return retval; -} - int add (argc, argv) int argc; char **argv; { char *message = NULL; - char *user; int i; char *repository; int c; @@ -95,6 +55,7 @@ add (argc, argv) char *options = NULL; List *entries; Vers_TS *vers; + struct saved_cwd cwd; if (argc == 1 || argc == -1) usage (add_usage); @@ -128,17 +89,64 @@ add (argc, argv) if (argc <= 0) usage (add_usage); - /* find the repository associated with our current dir */ - repository = Name_Repository ((char *) NULL, (char *) NULL); + /* First some sanity checks. I know that the CVS case is (sort of) + also handled by add_directory, but we need to check here so the + client won't get all confused in send_file_names. */ + for (i = 0; i < argc; i++) + { + int skip_file = 0; + + /* If it were up to me I'd probably make this a fatal error. + But some people are really fond of their "cvs add *", and + don't seem to object to the warnings. + Whatever. */ + strip_trailing_slashes (argv[i]); + if (strcmp (argv[i], ".") == 0 + || strcmp (argv[i], "..") == 0 + || fncmp (argv[i], CVSADM) == 0) + { + error (0, 0, "cannot add special file `%s'; skipping", argv[i]); + skip_file = 1; + } + + if (skip_file) + { + int j; + + /* FIXME: We don't do anything about free'ing argv[i]. But + the problem is that it is only sometimes allocated (see + cvsrc.c). */ + + for (j = i; j < argc - 1; ++j) + argv[j] = argv[j + 1]; + --argc; + /* Check the new argv[i] again. */ + --i; + ++err; + } + } #ifdef CLIENT_SUPPORT if (client_active) { int i; + + if (argc == 0) + /* We snipped out all the arguments in the above sanity + check. We can just forget the whole thing (and we + better, because if we fired up the server and passed it + nothing, it would spit back a usage message). */ + return err; + start_server (); ign_setup (); if (options) send_arg(options); option_with_arg ("-m", message); + + repository = Name_Repository (NULL, NULL); + send_a_repository ("", repository, ""); + free (repository); + for (i = 0; i < argc; ++i) /* FIXME: Does this erroneously call Create_Admin in error conditions which are only detected once the server gets its @@ -149,16 +157,48 @@ add (argc, argv) char *date; int nonbranch; char *rcsdir; + char *p; + char *update_dir; + /* This is some mungeable storage into which we can point + with p and/or update_dir. */ + char *filedir; + + if (save_cwd (&cwd)) + error_exit (); + + filedir = xstrdup (argv[i]); + p = last_component (filedir); + if (p == filedir) + { + update_dir = ""; + } + else + { + p[-1] = '\0'; + update_dir = filedir; + if (CVS_CHDIR (update_dir) < 0) + error (1, errno, + "could not chdir to %s", update_dir); + } + + /* find the repository associated with our current dir */ + repository = Name_Repository (NULL, update_dir); /* before we do anything else, see if we have any per-directory tags */ ParseTag (&tag, &date, &nonbranch); - rcsdir = combine_dir (repository, argv[i]); + rcsdir = xmalloc (strlen (repository) + strlen (p) + 5); + sprintf (rcsdir, "%s/%s", repository, p); + + Create_Admin (p, argv[i], rcsdir, tag, date, + nonbranch, 0); - strip_trailing_slashes (argv[i]); + send_a_repository ("", repository, update_dir); - Create_Admin (argv[i], argv[i], rcsdir, tag, date, nonbranch); + if (restore_cwd (&cwd, NULL)) + error_exit (); + free_cwd (&cwd); if (tag) free (tag); @@ -166,32 +206,24 @@ add (argc, argv) free (date); free (rcsdir); - if (strchr (argv[i], '/') == NULL) + if (p == filedir) Subdir_Register ((List *) NULL, (char *) NULL, argv[i]); else { - char *cp, *b; - - cp = xstrdup (argv[i]); - b = strrchr (cp, '/'); - *b++ = '\0'; - Subdir_Register ((List *) NULL, cp, b); - free (cp); + Subdir_Register ((List *) NULL, update_dir, p); } + free (repository); + free (filedir); } send_file_names (argc, argv, SEND_EXPAND_WILD); - /* FIXME: should be able to pass SEND_NO_CONTENTS, I think. */ - send_files (argc, argv, 0, 0, SEND_BUILD_DIRS); + send_files (argc, argv, 0, 0, SEND_BUILD_DIRS | SEND_NO_CONTENTS); send_to_server ("add\012", 0); if (message) free (message); - free (repository); - return get_responses_and_close (); + return err + get_responses_and_close (); } #endif - entries = Entries_Open (0); - /* walk the arg list adding files/dirs */ for (i = 0; i < argc; i++) { @@ -200,24 +232,42 @@ add (argc, argv) int begin_added_files = added_files; #endif struct file_info finfo; + char *p; + + memset (&finfo, 0, sizeof finfo); - user = argv[i]; - strip_trailing_slashes (user); - if (strchr (user, '/') != NULL) + if (save_cwd (&cwd)) + error_exit (); + + finfo.fullname = xstrdup (argv[i]); + p = last_component (argv[i]); + if (p == argv[i]) { - error (0, 0, - "cannot add files with '/' in their name; %s not added", user); - err++; - continue; + finfo.update_dir = ""; + finfo.file = p; + } + else + { + p[-1] = '\0'; + finfo.update_dir = argv[i]; + finfo.file = p; + if (CVS_CHDIR (finfo.update_dir) < 0) + error (1, errno, "could not chdir to %s", finfo.update_dir); } - memset (&finfo, 0, sizeof finfo); - finfo.file = user; - finfo.update_dir = ""; - finfo.fullname = user; + /* Add wrappers for this directory. They exist only until + the next call to wrap_add_file. */ + wrap_add_file (CVSDOTWRAPPER, 1); + + finfo.rcs = NULL; + + /* Find the repository associated with our current dir. */ + repository = Name_Repository (NULL, finfo.update_dir); + + entries = Entries_Open (0); + finfo.repository = repository; finfo.entries = entries; - finfo.rcs = NULL; /* We pass force_tag_match as 1. If the directory has a sticky branch tag, and there is already an RCS file which @@ -233,23 +283,25 @@ add (argc, argv) if (vers->ts_user == NULL) { /* There is no user file either */ - error (0, 0, "nothing known about %s", user); + error (0, 0, "nothing known about %s", finfo.fullname); err++; } - else if (!isdir (user) || wrap_name_has (user, WRAP_TOCVS)) + else if (!isdir (finfo.file) + || wrap_name_has (finfo.file, WRAP_TOCVS)) { /* * See if a directory exists in the repository with * the same name. If so, blow this request off. */ - char *dname = xmalloc (strlen (repository) + strlen (user) + char *dname = xmalloc (strlen (repository) + + strlen (finfo.file) + 10); - (void) sprintf (dname, "%s/%s", repository, user); + (void) sprintf (dname, "%s/%s", repository, finfo.file); if (isdir (dname)) { error (0, 0, "cannot add file `%s' since the directory", - user); + finfo.fullname); error (0, 0, "`%s' already exists in the repository", dname); error (1, 0, "illegal filename overlap"); @@ -262,11 +314,11 @@ add (argc, argv) rcs file if it existed, e.g. the file exists on another branch). Check for a value from the wrapper stuff. */ - if (wrap_name_has (user, WRAP_RCSOPTION)) + if (wrap_name_has (finfo.file, WRAP_RCSOPTION)) { if (vers->options) free (vers->options); - vers->options = wrap_rcsoption (user, 1); + vers->options = wrap_rcsoption (finfo.file, 1); } } @@ -280,7 +332,7 @@ add (argc, argv) else { /* There is a user file, so build the entry for it */ - if (build_entry (repository, user, vers->options, + if (build_entry (repository, finfo.file, vers->options, message, entries, vers->tag) != 0) err++; else @@ -291,17 +343,19 @@ add (argc, argv) if (vers->tag) error (0, 0, "\ scheduling %s `%s' for addition on branch `%s'", - (wrap_name_has (user, WRAP_TOCVS) + (wrap_name_has (finfo.file, + WRAP_TOCVS) ? "wrapper" : "file"), - user, vers->tag); + finfo.fullname, vers->tag); else error (0, 0, "scheduling %s `%s' for addition", - (wrap_name_has (user, WRAP_TOCVS) + (wrap_name_has (finfo.file, + WRAP_TOCVS) ? "wrapper" : "file"), - user); + finfo.fullname); } } } @@ -309,10 +363,11 @@ scheduling %s `%s' for addition on branch `%s'", } else if (RCS_isdead (vers->srcfile, vers->vn_rcs)) { - if (isdir (user) && !wrap_name_has (user, WRAP_TOCVS)) + if (isdir (finfo.file) + && !wrap_name_has (finfo.file, WRAP_TOCVS)) { error (0, 0, "\ -the directory `%s' cannot be added because a file of the", user); +the directory `%s' cannot be added because a file of the", finfo.fullname); error (1, 0, "\ same name already exists in the repository."); } @@ -330,7 +385,7 @@ same name already exists in the repository."); if (vers->tag) error (0, 0, "\ file `%s' will be added on branch `%s' from version %s", - user, vers->tag, vers->vn_rcs); + finfo.fullname, vers->tag, vers->vn_rcs); else /* I'm not sure that mentioning vers->vn_rcs makes any sense here; I @@ -338,8 +393,9 @@ file `%s' will be added on branch `%s' from version %s", message which is not confusing. */ error (0, 0, "\ re-adding file %s (in place of dead revision %s)", - user, vers->vn_rcs); - Register (entries, user, "0", vers->ts_user, NULL, + finfo.fullname, vers->vn_rcs); + Register (entries, finfo.file, "0", vers->ts_user, + NULL, vers->tag, NULL, NULL); ++added_files; } @@ -351,7 +407,8 @@ re-adding file %s (in place of dead revision %s)", * There is an RCS file already, so somebody else must've * added it */ - error (0, 0, "%s added independently by second party", user); + error (0, 0, "%s added independently by second party", + finfo.fullname); err++; } } @@ -362,7 +419,7 @@ re-adding file %s (in place of dead revision %s)", * An entry for a new-born file, ts_rcs is dummy, but that is * inappropriate here */ - error (0, 0, "%s has already been entered", user); + error (0, 0, "%s has already been entered", finfo.fullname); err++; } else if (vers->vn_user[0] == '-') @@ -379,7 +436,7 @@ re-adding file %s (in place of dead revision %s)", * it from under us */ error (0, 0, "\ -cannot resurrect %s; RCS file removed by second party", user); +cannot resurrect %s; RCS file removed by second party", finfo.fullname); err++; } else @@ -389,12 +446,13 @@ cannot resurrect %s; RCS file removed by second party", user); * There is an RCS file, so remove the "-" from the * version number and restore the file */ - char *tmp = xmalloc (strlen (user) + 50); + char *tmp = xmalloc (strlen (finfo.file) + 50); (void) strcpy (tmp, vers->vn_user + 1); (void) strcpy (vers->vn_user, tmp); - (void) sprintf (tmp, "Resurrected %s", user); - Register (entries, user, vers->vn_user, tmp, vers->options, + (void) sprintf (tmp, "Resurrected %s", finfo.file); + Register (entries, finfo.file, vers->vn_user, tmp, + vers->options, vers->tag, vers->date, vers->ts_conflict); free (tmp); @@ -404,12 +462,13 @@ cannot resurrect %s; RCS file removed by second party", user); check the file out. */ if (update (2, argv + i - 1) == 0) { - error (0, 0, "%s, version %s, resurrected", user, + error (0, 0, "%s, version %s, resurrected", + finfo.fullname, vers->vn_user); } else { - error (0, 0, "could not resurrect %s", user); + error (0, 0, "could not resurrect %s", finfo.fullname); err++; } } @@ -418,14 +477,15 @@ cannot resurrect %s; RCS file removed by second party", user); { /* The user file shouldn't be there */ error (0, 0, "\ -%s should be removed and is still there (or is back again)", user); +%s should be removed and is still there (or is back again)", finfo.fullname); err++; } } else { /* A normal entry, ts_rcs is valid, so it must already be there */ - error (0, 0, "%s already exists, with version number %s", user, + error (0, 0, "%s already exists, with version number %s", + finfo.fullname, vers->vn_user); err++; } @@ -433,26 +493,34 @@ cannot resurrect %s; RCS file removed by second party", user); /* passed all the checks. Go ahead and add it if its a directory */ if (begin_err == err - && isdir (user) - && !wrap_name_has (user, WRAP_TOCVS)) + && isdir (finfo.file) + && !wrap_name_has (finfo.file, WRAP_TOCVS)) { - err += add_directory (repository, entries, user); - continue; + err += add_directory (&finfo); } + else + { #ifdef SERVER_SUPPORT - if (server_active && begin_added_files != added_files) - server_checked_in (user, ".", repository); + if (server_active && begin_added_files != added_files) + server_checked_in (finfo.file, finfo.update_dir, repository); #endif + } + free (repository); + Entries_Close (entries); + + if (restore_cwd (&cwd, NULL)) + error_exit (); + free_cwd (&cwd); + + free (finfo.fullname); } if (added_files) - error (0, 0, "use 'cvs commit' to add %s permanently", + error (0, 0, "use '%s commit' to add %s permanently", + program_name, (added_files == 1) ? "this file" : "these files"); - Entries_Close (entries); - if (message) free (message); - free (repository); return (err); } @@ -465,24 +533,28 @@ cannot resurrect %s; RCS file removed by second party", user); * Returns 1 on failure, 0 on success. */ static int -add_directory (repository, entries, dir) - char *repository; - List *entries; - char *dir; +add_directory (finfo) + struct file_info *finfo; { + char *repository = finfo->repository; + List *entries = finfo->entries; + char *dir = finfo->file; + char *rcsdir = NULL; struct saved_cwd cwd; char *message = NULL; char *tag, *date; int nonbranch; + char *attrs; if (strchr (dir, '/') != NULL) { + /* "Can't happen". */ error (0, 0, "directory %s not added; must be a direct sub-directory", dir); return (1); } - if (strcmp (dir, CVSADM) == 0) + if (fncmp (dir, CVSADM) == 0) { error (0, 0, "cannot add a `%s' directory", CVSADM); return (1); @@ -491,12 +563,18 @@ add_directory (repository, entries, dir) /* before we do anything else, see if we have any per-directory tags */ ParseTag (&tag, &date, &nonbranch); + /* Remember the default attributes from this directory, so we can apply + them to the new directory. */ + fileattr_startdir (repository); + attrs = fileattr_getall (NULL); + fileattr_free (); + /* now, remember where we were, so we can get back */ if (save_cwd (&cwd)) return (1); if ( CVS_CHDIR (dir) < 0) { - error (0, errno, "cannot chdir to %s", dir); + error (0, errno, "cannot chdir to %s", finfo->fullname); return (1); } #ifdef SERVER_SUPPORT @@ -505,19 +583,24 @@ add_directory (repository, entries, dir) if (isfile (CVSADM)) #endif { - error (0, 0, "%s/%s already exists", dir, CVSADM); + error (0, 0, "%s/%s already exists", finfo->fullname, CVSADM); goto out; } - rcsdir = combine_dir (repository, dir); + rcsdir = xmalloc (strlen (repository) + strlen (dir) + 5); + sprintf (rcsdir, "%s/%s", repository, dir); if (isfile (rcsdir) && !isdir (rcsdir)) { - error (0, 0, "%s is not a directory; %s not added", rcsdir, dir); + error (0, 0, "%s is not a directory; %s not added", rcsdir, + finfo->fullname); goto out; } /* setup the log message */ - message = xmalloc (strlen (rcsdir) + 80); + message = xmalloc (strlen (rcsdir) + + 80 + + (tag == NULL ? 0 : strlen (tag) + 80) + + (date == NULL ? 0 : strlen (date) + 80)); (void) sprintf (message, "Directory %s added to the repository\n", rcsdir); if (tag) { @@ -559,6 +642,15 @@ add_directory (repository, entries, dir) (void) umask (omask); } + /* Now set the default file attributes to the ones we inherited + from the parent directory. */ + fileattr_startdir (rcsdir); + fileattr_setall (NULL, attrs); + fileattr_write (); + fileattr_free (); + if (attrs != NULL) + free (attrs); + /* * Set up an update list with a single title node for Update_Logfile */ @@ -579,9 +671,9 @@ add_directory (repository, entries, dir) #ifdef SERVER_SUPPORT if (!server_active) - Create_Admin (".", dir, rcsdir, tag, date, nonbranch); + Create_Admin (".", finfo->fullname, rcsdir, tag, date, nonbranch, 0); #else - Create_Admin (".", dir, rcsdir, tag, date, nonbranch); + Create_Admin (".", finfo->fullname, rcsdir, tag, date, nonbranch, 0); #endif if (tag) free (tag); @@ -594,7 +686,8 @@ add_directory (repository, entries, dir) Subdir_Register (entries, (char *) NULL, dir); - (void) printf ("%s", message); + cvs_output (message, 0); + free (rcsdir); free (message); diff --git a/contrib/cvs/src/admin.c b/contrib/cvs/src/admin.c index d1401f4..a78bada 100644 --- a/contrib/cvs/src/admin.c +++ b/contrib/cvs/src/admin.c @@ -3,18 +3,17 @@ * Copyright (c) 1989-1992, Brian Berliner * * You may distribute under the terms of the GNU General Public License as - * specified in the README file that comes with the CVS 1.4 kit. + * specified in the README file that comes with the CVS source distribution. * - * Administration + * Administration ("cvs admin") * - * For now, this is basically a front end for rcs. All options are passed - * directly on. */ #include "cvs.h" #ifdef CVS_ADMIN_GROUP #include <grp.h> #endif +#include <assert.h> static Dtype admin_dirproc PROTO ((void *callerdat, char *dir, char *repos, char *update_dir, @@ -24,11 +23,89 @@ static int admin_fileproc PROTO ((void *callerdat, struct file_info *finfo)); static const char *const admin_usage[] = { "Usage: %s %s rcs-options files...\n", + "(Specify the --help global option for a list of other help options)\n", NULL }; -static int ac; -static char **av; +/* This structure is used to pass information through start_recursion. */ +struct admin_data +{ + /* Set default branch (-b). It is "-b" followed by the value + given, or NULL if not specified, or merely "-b" if -b is + specified without a value. */ + char *branch; + + /* Set comment leader (-c). It is "-c" followed by the value + given, or NULL if not specified. The comment leader is + relevant only for old versions of RCS, but we let people set it + anyway. */ + char *comment; + + /* Set strict locking (-L). */ + int set_strict; + + /* Set nonstrict locking (-U). */ + int set_nonstrict; + + /* Delete revisions (-o). It is "-o" followed by the value specified. */ + char *delete_revs; + + /* Keyword substitution mode (-k), e.g. "-kb". */ + char *kflag; + + /* Description (-t). See sanity.sh for various moanings about + files and stdin and such. "" if -t specified without an + argument. It is "-t" followed by the argument. */ + char *desc; + + /* Interactive (-I). Problematic with client/server. */ + int interactive; + + /* Quiet (-q). Not the same as the global -q option, which is a bit + on the confusing side, perhaps. */ + int quiet; + + /* This is the cheesy part. It is a vector with the options which + we don't deal with above (e.g. "-afoo" "-abar,baz"). In the future + this presumably will be replaced by other variables which break + out the data in a more convenient fashion. AV as well as each of + the strings it points to is malloc'd. */ + int ac; + char **av; + int av_alloc; +}; + +/* Add an argument. OPT is the option letter, e.g. 'a'. ARG is the + argument to that option, or NULL if omitted (whether NULL can actually + happen depends on whether the option was specified as optional to + getopt). */ +static void +arg_add (dat, opt, arg) + struct admin_data *dat; + int opt; + char *arg; +{ + char *newelt = xmalloc ((arg == NULL ? 0 : strlen (arg)) + 3); + strcpy (newelt, "-"); + newelt[1] = opt; + if (arg == NULL) + newelt[2] = '\0'; + else + strcpy (newelt + 2, arg); + + if (dat->av_alloc == 0) + { + dat->av_alloc = 1; + dat->av = (char **) xmalloc (dat->av_alloc * sizeof (*dat->av)); + } + else if (dat->ac >= dat->av_alloc) + { + dat->av_alloc *= 2; + dat->av = (char **) xrealloc (dat->av, + dat->av_alloc * sizeof (*dat->av)); + } + dat->av[dat->ac++] = newelt; +} int admin (argc, argv) @@ -40,6 +117,10 @@ admin (argc, argv) struct group *grp; struct group *getgrnam(); #endif + struct admin_data admin_data; + int c; + int i; + if (argc <= 1) usage (admin_usage); @@ -70,39 +151,301 @@ admin (argc, argv) wrap_setup (); - /* skip all optional arguments to see if we have any file names */ - for (ac = 1; ac < argc; ac++) - if (argv[ac][0] != '-') - break; - argc -= ac; - av = argv + 1; - argv += ac; - ac--; + memset (&admin_data, 0, sizeof admin_data); + + /* TODO: get rid of `-' switch notation in admin_data. For + example, admin_data->branch should be not `-bfoo' but simply `foo'. */ + + optind = 0; + while ((c = getopt (argc, argv, + "+ib::c:a:A:e:l::u::LUn:N:m:o:s:t::IqxV:k:")) != -1) + { + switch (c) + { + case 'i': + /* This has always been documented as useless in cvs.texinfo + and it really is--admin_fileproc silently does nothing + if vers->vn_user is NULL. */ + error (0, 0, "the -i option to admin is not supported"); + error (0, 0, "run add or import to create an RCS file"); + goto usage_error; + + case 'b': + if (admin_data.branch != NULL) + { + error (0, 0, "duplicate 'b' option"); + goto usage_error; + } + if (optarg == NULL) + admin_data.branch = xstrdup ("-b"); + else + { + admin_data.branch = xmalloc (strlen (optarg) + 5); + strcpy (admin_data.branch, "-b"); + strcat (admin_data.branch, optarg); + } + break; + + case 'c': + if (admin_data.comment != NULL) + { + error (0, 0, "duplicate 'c' option"); + goto usage_error; + } + admin_data.comment = xmalloc (strlen (optarg) + 5); + strcpy (admin_data.comment, "-c"); + strcat (admin_data.comment, optarg); + break; + + case 'a': + arg_add (&admin_data, 'a', optarg); + break; + + case 'A': + /* In the client/server case, this is cheesy because + we just pass along the name of the RCS file, which + then will want to exist on the server. This is + accidental; having the client specify a pathname on + the server is not a design feature of the protocol. */ + arg_add (&admin_data, 'A', optarg); + break; + + case 'e': + arg_add (&admin_data, 'e', optarg); + break; + + case 'l': + /* Note that multiple -l options are legal. */ + arg_add (&admin_data, 'l', optarg); + break; + + case 'u': + /* Note that multiple -u options are legal. */ + arg_add (&admin_data, 'u', optarg); + break; + + case 'L': + /* Probably could also complain if -L is specified multiple + times, although RCS doesn't and I suppose it is reasonable + just to have it mean the same as a single -L. */ + if (admin_data.set_nonstrict) + { + error (0, 0, "-U and -L are incompatible"); + goto usage_error; + } + admin_data.set_strict = 1; + break; + + case 'U': + /* Probably could also complain if -U is specified multiple + times, although RCS doesn't and I suppose it is reasonable + just to have it mean the same as a single -U. */ + if (admin_data.set_strict) + { + error (0, 0, "-U and -L are incompatible"); + goto usage_error; + } + admin_data.set_nonstrict = 1; + break; + + case 'n': + /* Mostly similar to cvs tag. Could also be parsing + the syntax of optarg, although for now we just pass + it to rcs as-is. Note that multiple -n options are + legal. */ + arg_add (&admin_data, 'n', optarg); + break; + + case 'N': + /* Mostly similar to cvs tag. Could also be parsing + the syntax of optarg, although for now we just pass + it to rcs as-is. Note that multiple -N options are + legal. */ + arg_add (&admin_data, 'N', optarg); + break; + + case 'm': + /* Change log message. Could also be parsing the syntax + of optarg, although for now we just pass it to rcs + as-is. Note that multiple -m options are legal. */ + arg_add (&admin_data, 'm', optarg); + break; + + case 'o': + /* Delete revisions. Probably should also be parsing the + syntax of optarg, so that the client can give errors + rather than making the server take care of that. + Other than that I'm not sure whether it matters much + whether we parse it here or in admin_fileproc. + + Note that multiple -o options are illegal, in RCS + as well as here. */ + + if (admin_data.delete_revs != NULL) + { + error (0, 0, "duplicate '-o' option"); + goto usage_error; + } + admin_data.delete_revs = xmalloc (strlen (optarg) + 5); + strcpy (admin_data.delete_revs, "-o"); + strcat (admin_data.delete_revs, optarg); + break; + + case 's': + /* Note that multiple -s options are legal. */ + arg_add (&admin_data, 's', optarg); + break; + + case 't': + if (admin_data.desc != NULL) + { + error (0, 0, "duplicate 't' option"); + goto usage_error; + } + if (optarg == NULL) + admin_data.desc = xstrdup ("-t"); + else + { + admin_data.desc = xmalloc (strlen (optarg) + 5); + strcpy (admin_data.desc, "-t"); + strcat (admin_data.desc, optarg); + } + break; + + case 'I': + /* At least in RCS this can be specified several times, + with the same meaning as being specified once. */ + admin_data.interactive = 1; + break; + + case 'q': + admin_data.quiet = 1; + break; + + case 'x': + error (0, 0, "the -x option has never done anything useful"); + error (0, 0, "RCS files in CVS always end in ,v"); + goto usage_error; + + case 'V': + /* No longer supported. */ + error (0, 0, "the `-V' option is obsolete"); + break; + + case 'k': + if (admin_data.kflag != NULL) + { + error (0, 0, "duplicate '-k' option"); + goto usage_error; + } + admin_data.kflag = RCS_check_kflag (optarg); + break; + default: + case '?': + /* getopt will have printed an error message. */ + + usage_error: + /* Don't use command_name; it might be "server". */ + error (1, 0, "specify %s -H admin for usage information", + program_name); + } + } + argc -= optind; + argv += optind; + + for (i = 0; i < admin_data.ac; ++i) + { + assert (admin_data.av[i][0] == '-'); + switch (admin_data.av[i][1]) + { + case 'm': + case 'l': + case 'u': + check_numeric (&admin_data.av[i][2], argc, argv); + break; + default: + break; + } + } + if (admin_data.branch != NULL) + check_numeric (admin_data.branch + 2, argc, argv); + if (admin_data.delete_revs != NULL) + { + char *p; + + check_numeric (admin_data.delete_revs + 2, argc, argv); + p = strchr (admin_data.delete_revs + 2, ':'); + if (p != NULL && isdigit (p[1])) + check_numeric (p + 1, argc, argv); + else if (p != NULL && p[1] == ':' && isdigit(p[2])) + check_numeric (p + 2, argc, argv); + } #ifdef CLIENT_SUPPORT if (client_active) { - int i; - /* We're the client side. Fire up the remote server. */ start_server (); ign_setup (); - for (i = 0; i < ac; ++i) /* XXX send -ko too with i = 0 */ - send_arg (av[i]); + /* Note that option_with_arg does not work for us, because some + of the options must be sent without a space between the option + and its argument. */ + if (admin_data.interactive) + error (1, 0, "-I option not useful with client/server"); + if (admin_data.branch != NULL) + send_arg (admin_data.branch); + if (admin_data.comment != NULL) + send_arg (admin_data.comment); + if (admin_data.set_strict) + send_arg ("-L"); + if (admin_data.set_nonstrict) + send_arg ("-U"); + if (admin_data.delete_revs != NULL) + send_arg (admin_data.delete_revs); + if (admin_data.desc != NULL) + send_arg (admin_data.desc); + if (admin_data.quiet) + send_arg ("-q"); + if (admin_data.kflag != NULL) + send_arg (admin_data.kflag); + + for (i = 0; i < admin_data.ac; ++i) + send_arg (admin_data.av[i]); send_file_names (argc, argv, SEND_EXPAND_WILD); send_files (argc, argv, 0, 0, SEND_NO_CONTENTS); send_to_server ("admin\012", 0); - return get_responses_and_close (); + err = get_responses_and_close (); + goto return_it; } #endif /* CLIENT_SUPPORT */ - /* start the recursion processor */ + lock_tree_for_write (argc, argv, 0, 0); + err = start_recursion (admin_fileproc, (FILESDONEPROC) NULL, admin_dirproc, - (DIRLEAVEPROC) NULL, NULL, argc, argv, 0, - W_LOCAL, 0, 1, (char *) NULL, 1); + (DIRLEAVEPROC) NULL, (void *)&admin_data, + argc, argv, 0, + W_LOCAL, 0, 0, (char *) NULL, 1); + Lock_Cleanup (); + + return_it: + if (admin_data.branch != NULL) + free (admin_data.branch); + if (admin_data.comment != NULL) + free (admin_data.comment); + if (admin_data.delete_revs != NULL) + free (admin_data.delete_revs); + if (admin_data.kflag != NULL) + free (admin_data.kflag); + if (admin_data.desc != NULL) + free (admin_data.desc); + for (i = 0; i < admin_data.ac; ++i) + free (admin_data.av[i]); + if (admin_data.av != NULL) + free (admin_data.av); + return (err); } @@ -115,12 +458,12 @@ admin_fileproc (callerdat, finfo) void *callerdat; struct file_info *finfo; { + struct admin_data *admin_data = (struct admin_data *) callerdat; Vers_TS *vers; char *version; - char **argv; - int argc; - int retcode = 0; + int i; int status = 0; + RCSNode *rcs, *rcs2; vers = Version_TS (finfo, NULL, NULL, NULL, 0, 0); @@ -133,18 +476,326 @@ admin_fileproc (callerdat, finfo) goto exitfunc; } - run_setup ("%s%s -x,v/", Rcsbin, RCS); - for (argc = ac, argv = av; argc; argc--, argv++) - run_arg (*argv); - run_arg (vers->srcfile->path); - if ((retcode = run_exec (RUN_TTY, RUN_TTY, RUN_TTY, RUN_NORMAL)) != 0) + rcs = vers->srcfile; + if (rcs->flags & PARTIAL) + RCS_reparsercsfile (rcs, NULL); + + status = 0; + + if (!admin_data->quiet) { - if (!quiet) - error (0, retcode == -1 ? errno : 0, - "%s failed for `%s'", RCS, finfo->file); - status = 1; - goto exitfunc; + cvs_output ("RCS file: ", 0); + cvs_output (rcs->path, 0); + cvs_output ("\n", 1); + } + + if (admin_data->branch != NULL) + RCS_setbranch (rcs, (admin_data->branch[2] == '\0' + ? NULL + : admin_data->branch + 2)); + if (admin_data->comment != NULL) + { + if (rcs->comment != NULL) + free (rcs->comment); + rcs->comment = xstrdup (admin_data->comment + 2); + } + if (admin_data->set_strict) + rcs->strict_locks = 1; + if (admin_data->set_nonstrict) + rcs->strict_locks = 0; + if (admin_data->delete_revs != NULL) + { + char *s, *t, *rev1, *rev2; + /* Set for :, clear for ::. */ + int inclusive; + char *t2; + + s = admin_data->delete_revs + 2; + inclusive = 1; + t = strchr (s, ':'); + if (t != NULL) + { + if (t[1] == ':') + { + inclusive = 0; + t2 = t + 2; + } + else + t2 = t + 1; + } + + /* Note that we don't support '-' for ranges. RCS considers it + obsolete and it is problematic with tags containing '-'. "cvs log" + has made the same decision. */ + + if (t == NULL) + { + /* -orev */ + rev1 = xstrdup (s); + rev2 = xstrdup (s); + } + else if (t == s) + { + /* -o:rev2 */ + rev1 = NULL; + rev2 = xstrdup (t2); + } + else + { + *t = '\0'; + rev1 = xstrdup (s); + *t = ':'; /* probably unnecessary */ + if (*t2 == '\0') + /* -orev1: */ + rev2 = NULL; + else + /* -orev1:rev2 */ + rev2 = xstrdup (t2); + } + + if (rev1 == NULL && rev2 == NULL) + { + /* RCS segfaults if `-o:' is given */ + error (0, 0, "no valid revisions specified in `%s' option", + admin_data->delete_revs); + status = 1; + } + else + { + status |= RCS_delete_revs (rcs, rev1, rev2, inclusive); + if (rev1) + free (rev1); + if (rev2) + free (rev2); + } + } + if (admin_data->desc != NULL) + { + free (rcs->desc); + rcs->desc = NULL; + if (admin_data->desc[2] == '-') + rcs->desc = xstrdup (admin_data->desc + 3); + else + { + char *descfile = admin_data->desc + 2; + size_t bufsize = 0; + size_t len; + + /* If -t specified with no argument, read from stdin. */ + if (*descfile == '\0') + descfile = NULL; + get_file (descfile, descfile, "r", &rcs->desc, &bufsize, &len); + } + } + if (admin_data->kflag != NULL) + { + char *kflag = admin_data->kflag + 2; + if (!rcs->expand || strcmp (rcs->expand, kflag) != 0) + { + if (rcs->expand) + free (rcs->expand); + rcs->expand = xstrdup (kflag); + } } + + /* Handle miscellaneous options. TODO: decide whether any or all + of these should have their own fields in the admin_data + structure. */ + for (i = 0; i < admin_data->ac; ++i) + { + char *arg; + char *p, *rev, *revnum, *tag, *msg; + char **users; + int argc, u; + Node *n; + RCSVers *delta; + + arg = admin_data->av[i]; + switch (arg[1]) + { + case 'a': /* fall through */ + case 'e': + line2argv (&argc, &users, arg + 2, " ,\t\n"); + if (arg[1] == 'a') + for (u = 0; u < argc; ++u) + RCS_addaccess (rcs, users[u]); + else + for (u = 0; u < argc; ++u) + RCS_delaccess (rcs, users[u]); + free_names (&argc, users); + break; + case 'A': + + /* See admin-19a-admin and friends in sanity.sh for + relative pathnames. It makes sense to think in + terms of a syntax which give pathnames relative to + the repository or repository corresponding to the + current directory or some such (and perhaps don't + include ,v), but trying to worry about such things + is a little pointless unless you first worry about + whether "cvs admin -A" as a whole makes any sense + (currently probably not, as access lists don't + affect the behavior of CVS). */ + + rcs2 = RCS_parsercsfile (arg + 2); + if (rcs2 == NULL) + error (1, 0, "cannot continue"); + + p = xstrdup (RCS_getaccess (rcs2)); + line2argv (&argc, &users, p, " \t\n"); + free (p); + freercsnode (&rcs2); + + for (u = 0; u < argc; ++u) + RCS_addaccess (rcs, users[u]); + free_names (&argc, users); + break; + case 'n': /* fall through */ + case 'N': + if (arg[2] == '\0') + { + cvs_outerr ("missing symbolic name after ", 0); + cvs_outerr (arg, 0); + cvs_outerr ("\n", 1); + break; + } + p = strchr (arg, ':'); + if (p == NULL) + { + if (RCS_deltag (rcs, arg + 2) != 0) + { + error (0, 0, "%s: Symbolic name %s is undefined.", + rcs->path, + arg + 2); + status = 1; + continue; + } + break; + } + *p = '\0'; + tag = xstrdup (arg + 2); + *p++ = ':'; + + /* Option `n' signals an error if this tag is already bound. */ + if (arg[1] == 'n') + { + n = findnode (RCS_symbols (rcs), tag); + if (n != NULL) + { + error (0, 0, + "%s: symbolic name %s already bound to %s", + rcs->path, + tag, n->data); + status = 1; + continue; + } + } + + /* Expand rev if necessary. */ + rev = RCS_gettag (rcs, p, 0, NULL); + RCS_settag (rcs, tag, rev); + if (rev != NULL) + free (rev); + free (tag); + break; + case 's': + p = strchr (arg, ':'); + if (p == NULL) + { + tag = xstrdup (arg + 2); + rev = RCS_head (rcs); + } + else + { + *p = '\0'; + tag = xstrdup (arg + 2); + *p++ = ':'; + rev = xstrdup (p); + } + revnum = RCS_gettag (rcs, rev, 0, NULL); + free (rev); + if (revnum != NULL) + n = findnode (rcs->versions, revnum); + if (revnum == NULL || n == NULL) + { + error (0, 0, + "%s: can't set state of nonexisting revision %s", + rcs->path, + rev); + if (revnum != NULL) + free (revnum); + status = 1; + continue; + } + delta = (RCSVers *) n->data; + free (delta->state); + delta->state = tag; + break; + + case 'm': + p = strchr (arg, ':'); + if (p == NULL) + { + error (0, 0, "%s: -m option lacks revision number", + rcs->path); + status = 1; + continue; + } + *p = '\0'; + rev = RCS_gettag (rcs, arg + 2, 0, NULL); + if (rev == NULL) + { + error (0, 0, "%s: no such revision %s", rcs->path, rev); + status = 1; + continue; + } + *p++ = ':'; + msg = p; + + n = findnode (rcs->versions, rev); + delta = (RCSVers *) n->data; + if (delta->text == NULL) + { + delta->text = (Deltatext *) xmalloc (sizeof (Deltatext)); + memset ((void *) delta->text, 0, sizeof (Deltatext)); + } + delta->text->version = xstrdup (delta->version); + delta->text->log = make_message_rcslegal (msg); + break; + + case 'l': + status |= RCS_lock (rcs, arg[2] ? arg + 2 : NULL, 0); + break; + case 'u': + status |= RCS_unlock (rcs, arg[2] ? arg + 2 : NULL, 0); + break; + default: assert(0); /* can't happen */ + } + } + + /* TODO: reconcile the weird discrepancies between + admin_data->quiet and quiet. */ + if (status == 0) + { + RCS_rewrite (rcs, NULL, NULL); + if (!admin_data->quiet) + cvs_output ("done\n", 5); + } + else + { + /* Note that this message should only occur after another + message has given a more specific error. The point of this + additional message is to make it clear that the previous problems + caused CVS to forget about the idea of modifying the RCS file. */ + error (0, 0, "cannot modify RCS file for `%s'", finfo->file); + + /* Upon failure, we want to abandon any changes made to the + RCS data structure. Forcing a reparse does the trick, + but leaks memory and is kludgey. Should we export + free_rcsnode_contents for this purpose? */ + RCS_reparsercsfile (rcs, NULL); + } + exitfunc: freevers_ts (&vers); return status; diff --git a/contrib/cvs/src/buffer.c b/contrib/cvs/src/buffer.c index d6ea895..0042e4c 100644 --- a/contrib/cvs/src/buffer.c +++ b/contrib/cvs/src/buffer.c @@ -1167,8 +1167,8 @@ static int stdio_buffer_flush PROTO((void *)); /* Initialize a buffer built on a stdio FILE. */ -struct buffer -*stdio_buffer_initialize (fp, input, memory) +struct buffer * +stdio_buffer_initialize (fp, input, memory) FILE *fp; int input; void (*memory) PROTO((struct buffer *)); @@ -1291,4 +1291,438 @@ stdio_buffer_flush (closure) return 0; } +/* Certain types of communication input and output data in packets, + where each packet is translated in some fashion. The packetizing + buffer type supports that, given a buffer which handles lower level + I/O and a routine to translate the data in a packet. + + This code uses two bytes for the size of a packet, so packets are + restricted to 65536 bytes in total. + + The translation functions should just translate; they may not + significantly increase or decrease the amount of data. The actual + size of the initial data is part of the translated data. The + output translation routine may add up to PACKET_SLOP additional + bytes, and the input translation routine should shrink the data + correspondingly. */ + +#define PACKET_SLOP (100) + +/* This structure is the closure field of a packetizing buffer. */ + +struct packetizing_buffer +{ + /* The underlying buffer. */ + struct buffer *buf; + /* The input translation function. Exactly one of inpfn and outfn + will be NULL. The input translation function should + untranslate the data in INPUT, storing the result in OUTPUT. + SIZE is the amount of data in INPUT, and is also the size of + OUTPUT. This should return 0 on success, or an errno code. */ + int (*inpfn) PROTO((void *fnclosure, const char *input, char *output, + int size)); + /* The output translation function. This should translate the + data in INPUT, storing the result in OUTPUT. The first two + bytes in INPUT will be the size of the data, and so will SIZE. + This should set *TRANSLATED to the amount of translated data in + OUTPUT. OUTPUT is large enough to hold SIZE + PACKET_SLOP + bytes. This should return 0 on success, or an errno code. */ + int (*outfn) PROTO((void *fnclosure, const char *input, char *output, + int size, int *translated)); + /* A closure for the translation function. */ + void *fnclosure; + /* For an input buffer, we may have to buffer up data here. */ + /* This is non-zero if the buffered data has been translated. + Otherwise, the buffered data has not been translated, and starts + with the two byte packet size. */ + int translated; + /* The amount of buffered data. */ + int holdsize; + /* The buffer allocated to hold the data. */ + char *holdbuf; + /* The size of holdbuf. */ + int holdbufsize; + /* If translated is set, we need another data pointer to track + where we are in holdbuf. If translated is clear, then this + pointer is not used. */ + char *holddata; +}; + +static int packetizing_buffer_input PROTO((void *, char *, int, int, int *)); +static int packetizing_buffer_output PROTO((void *, const char *, int, int *)); +static int packetizing_buffer_flush PROTO((void *)); +static int packetizing_buffer_block PROTO((void *, int)); +static int packetizing_buffer_shutdown PROTO((void *)); + +/* Create a packetizing buffer. */ + +struct buffer * +packetizing_buffer_initialize (buf, inpfn, outfn, fnclosure, memory) + struct buffer *buf; + int (*inpfn) PROTO ((void *, const char *, char *, int)); + int (*outfn) PROTO ((void *, const char *, char *, int, int *)); + void *fnclosure; + void (*memory) PROTO((struct buffer *)); +{ + struct packetizing_buffer *pb; + + pb = (struct packetizing_buffer *) xmalloc (sizeof *pb); + memset (pb, 0, sizeof *pb); + + pb->buf = buf; + pb->inpfn = inpfn; + pb->outfn = outfn; + pb->fnclosure = fnclosure; + + if (inpfn != NULL) + { + /* Add PACKET_SLOP to handle larger translated packets, and + add 2 for the count. This buffer is increased if + necessary. */ + pb->holdbufsize = BUFFER_DATA_SIZE + PACKET_SLOP + 2; + pb->holdbuf = xmalloc (pb->holdbufsize); + } + + return buf_initialize (inpfn != NULL ? packetizing_buffer_input : NULL, + inpfn != NULL ? NULL : packetizing_buffer_output, + inpfn != NULL ? NULL : packetizing_buffer_flush, + packetizing_buffer_block, + packetizing_buffer_shutdown, + memory, + pb); +} + +/* Input data from a packetizing buffer. */ + +static int +packetizing_buffer_input (closure, data, need, size, got) + void *closure; + char *data; + int need; + int size; + int *got; +{ + struct packetizing_buffer *pb = (struct packetizing_buffer *) closure; + + *got = 0; + + if (pb->holdsize > 0 && pb->translated) + { + int copy; + + copy = pb->holdsize; + + if (copy > size) + { + memcpy (data, pb->holddata, size); + pb->holdsize -= size; + pb->holddata += size; + *got = size; + return 0; + } + + memcpy (data, pb->holddata, copy); + pb->holdsize = 0; + pb->translated = 0; + + data += copy; + need -= copy; + size -= copy; + *got = copy; + } + + while (need > 0 || *got == 0) + { + int get, status, nread, count, tcount; + char *bytes; + char stackoutbuf[BUFFER_DATA_SIZE + PACKET_SLOP]; + char *inbuf, *outbuf; + + /* If we don't already have the two byte count, get it. */ + if (pb->holdsize < 2) + { + get = 2 - pb->holdsize; + status = buf_read_data (pb->buf, get, &bytes, &nread); + if (status != 0) + { + /* buf_read_data can return -2, but a buffer input + function is only supposed to return -1, 0, or an + error code. */ + if (status == -2) + status = ENOMEM; + return status; + } + + if (nread == 0) + { + /* The buffer is in nonblocking mode, and we didn't + manage to read anything. */ + return 0; + } + + if (get == 1) + pb->holdbuf[1] = bytes[0]; + else + { + pb->holdbuf[0] = bytes[0]; + if (nread < 2) + { + /* We only got one byte, but we needed two. Stash + the byte we got, and try again. */ + pb->holdsize = 1; + continue; + } + pb->holdbuf[1] = bytes[1]; + } + pb->holdsize = 2; + } + + /* Read the packet. */ + + count = (((pb->holdbuf[0] & 0xff) << 8) + + (pb->holdbuf[1] & 0xff)); + + if (count + 2 > pb->holdbufsize) + { + char *n; + + /* We didn't allocate enough space in the initialize + function. */ + + n = realloc (pb->holdbuf, count + 2); + if (n == NULL) + { + (*pb->buf->memory_error) (pb->buf); + return ENOMEM; + } + pb->holdbuf = n; + pb->holdbufsize = count + 2; + } + + get = count - (pb->holdsize - 2); + + status = buf_read_data (pb->buf, get, &bytes, &nread); + if (status != 0) + { + /* buf_read_data can return -2, but a buffer input + function is only supposed to return -1, 0, or an error + code. */ + if (status == -2) + status = ENOMEM; + return status; + } + + if (nread == 0) + { + /* We did not get any data. Presumably the buffer is in + nonblocking mode. */ + return 0; + } + + if (nread < get) + { + /* We did not get all the data we need to fill the packet. + buf_read_data does not promise to return all the bytes + requested, so we must try again. */ + memcpy (pb->holdbuf + pb->holdsize, bytes, nread); + pb->holdsize += nread; + continue; + } + + /* We have a complete untranslated packet of COUNT bytes. */ + + if (pb->holdsize == 2) + { + /* We just read the entire packet (the 2 bytes in + PB->HOLDBUF are the size). Save a memcpy by + translating directly from BYTES. */ + inbuf = bytes; + } + else + { + /* We already had a partial packet in PB->HOLDBUF. We + need to copy the new data over to make the input + contiguous. */ + memcpy (pb->holdbuf + pb->holdsize, bytes, nread); + inbuf = pb->holdbuf + 2; + } + + if (count <= sizeof stackoutbuf) + outbuf = stackoutbuf; + else + { + outbuf = malloc (count); + if (outbuf == NULL) + { + (*pb->buf->memory_error) (pb->buf); + return ENOMEM; + } + } + + status = (*pb->inpfn) (pb->fnclosure, inbuf, outbuf, count); + if (status != 0) + return status; + + /* The first two bytes in the translated buffer are the real + length of the translated data. */ + tcount = ((outbuf[0] & 0xff) << 8) + (outbuf[1] & 0xff); + + if (tcount > count) + error (1, 0, "Input translation failure"); + + if (tcount > size) + { + /* We have more data than the caller has provided space + for. We need to save some of it for the next call. */ + + memcpy (data, outbuf + 2, size); + *got += size; + + pb->holdsize = tcount - size; + memcpy (pb->holdbuf, outbuf + 2 + size, tcount - size); + pb->holddata = pb->holdbuf; + pb->translated = 1; + + if (outbuf != stackoutbuf) + free (outbuf); + + return 0; + } + + memcpy (data, outbuf + 2, tcount); + + if (outbuf != stackoutbuf) + free (outbuf); + + pb->holdsize = 0; + + data += tcount; + need -= tcount; + size -= tcount; + *got += tcount; + } + + return 0; +} + +/* Output data to a packetizing buffer. */ + +static int +packetizing_buffer_output (closure, data, have, wrote) + void *closure; + const char *data; + int have; + int *wrote; +{ + struct packetizing_buffer *pb = (struct packetizing_buffer *) closure; + char inbuf[BUFFER_DATA_SIZE + 2]; + char stack_outbuf[BUFFER_DATA_SIZE + PACKET_SLOP + 4]; + struct buffer_data *outdata; + char *outbuf; + int size, status, translated; + + if (have > BUFFER_DATA_SIZE) + { + /* It would be easy to malloc a buffer, but I don't think this + case can ever arise. */ + abort (); + } + + inbuf[0] = (have >> 8) & 0xff; + inbuf[1] = have & 0xff; + memcpy (inbuf + 2, data, have); + + size = have + 2; + + /* The output function is permitted to add up to PACKET_SLOP + bytes, and we need 2 bytes for the size of the translated data. + If we can guarantee that the result will fit in a buffer_data, + we translate directly into one to avoid a memcpy in buf_output. */ + if (size + PACKET_SLOP + 2 > BUFFER_DATA_SIZE) + outbuf = stack_outbuf; + else + { + outdata = get_buffer_data (); + if (outdata == NULL) + { + (*pb->buf->memory_error) (pb->buf); + return ENOMEM; + } + + outdata->next = NULL; + outdata->bufp = outdata->text; + + outbuf = outdata->text; + } + + status = (*pb->outfn) (pb->fnclosure, inbuf, outbuf + 2, size, + &translated); + if (status != 0) + return status; + + /* The output function is permitted to add up to PACKET_SLOP + bytes. */ + if (translated > size + PACKET_SLOP) + abort (); + + outbuf[0] = (translated >> 8) & 0xff; + outbuf[1] = translated & 0xff; + + if (outbuf == stack_outbuf) + buf_output (pb->buf, outbuf, translated + 2); + else + { + outdata->size = translated + 2; + buf_append_data (pb->buf, outdata, outdata); + } + + *wrote = have; + + /* We will only be here because buf_send_output was called on the + packetizing buffer. That means that we should now call + buf_send_output on the underlying buffer. */ + return buf_send_output (pb->buf); +} + +/* Flush data to a packetizing buffer. */ + +static int +packetizing_buffer_flush (closure) + void *closure; +{ + struct packetizing_buffer *pb = (struct packetizing_buffer *) closure; + + /* Flush the underlying buffer. Note that if the original call to + buf_flush passed 1 for the BLOCK argument, then the buffer will + already have been set into blocking mode, so we should always + pass 0 here. */ + return buf_flush (pb->buf, 0); +} + +/* The block routine for a packetizing buffer. */ + +static int +packetizing_buffer_block (closure, block) + void *closure; + int block; +{ + struct packetizing_buffer *pb = (struct packetizing_buffer *) closure; + + if (block) + return set_block (pb->buf); + else + return set_nonblock (pb->buf); +} + +/* Shut down a packetizing buffer. */ + +static int +packetizing_buffer_shutdown (closure) + void *closure; +{ + struct packetizing_buffer *pb = (struct packetizing_buffer *) closure; + + return buf_shutdown (pb->buf); +} + #endif /* defined (SERVER_SUPPORT) || defined (CLIENT_SUPPORT) */ diff --git a/contrib/cvs/src/buffer.h b/contrib/cvs/src/buffer.h index b62456c..c632490 100644 --- a/contrib/cvs/src/buffer.h +++ b/contrib/cvs/src/buffer.h @@ -110,6 +110,10 @@ extern struct buffer *stdio_buffer_initialize PROTO((FILE *, int, void (*) (struct buffer *))); extern struct buffer *compress_buffer_initialize PROTO((struct buffer *, int, int, void (*) (struct buffer *))); +extern struct buffer *packetizing_buffer_initialize + PROTO((struct buffer *, int (*) (void *, const char *, char *, int), + int (*) (void *, const char *, char *, int, int *), void *, + void (*) (struct buffer *))); extern int buf_empty_p PROTO((struct buffer *)); extern void buf_output PROTO((struct buffer *, const char *, int)); extern void buf_output0 PROTO((struct buffer *, const char *)); diff --git a/contrib/cvs/src/checkin.c b/contrib/cvs/src/checkin.c index 0da220c..1d89ae1 100644 --- a/contrib/cvs/src/checkin.c +++ b/contrib/cvs/src/checkin.c @@ -3,7 +3,7 @@ * Copyright (c) 1989-1992, Brian Berliner * * You may distribute under the terms of the GNU General Public License as - * specified in the README file that comes with the CVS 1.4 kit. + * specified in the README file that comes with the CVS source distribution. * * Check In * @@ -69,7 +69,10 @@ Checkin (type, finfo, rcs, rev, tag, options, message) } } - switch (RCS_checkin (rcs, NULL, message, rev, 0)) + if (finfo->rcs == NULL) + finfo->rcs = RCS_parse (finfo->file, finfo->repository); + + switch (RCS_checkin (finfo->rcs, NULL, message, rev, 0)) { case 0: /* everything normal */ @@ -85,12 +88,6 @@ Checkin (type, finfo, rcs, rev, tag, options, message) if (strcmp (options, "-V4") == 0) /* upgrade to V5 now */ options[0] = '\0'; - /* Reparse the RCS file, so that we can safely call - RCS_checkout. FIXME: We could probably calculate - all the changes. */ - freercsnode (&finfo->rcs); - finfo->rcs = RCS_parse (finfo->file, finfo->repository); - /* FIXME: should be checking for errors. */ (void) RCS_checkout (finfo->rcs, finfo->file, rev, (char *) NULL, options, RUN_TTY, @@ -117,7 +114,7 @@ Checkin (type, finfo, rcs, rev, tag, options, message) * If we want read-only files, muck the permissions here, before * getting the file time-stamp. */ - if (cvswrite == FALSE || fileattr_get (finfo->file, "_watched")) + if (!cvswrite || fileattr_get (finfo->file, "_watched")) xchmod (finfo->file, 0); /* Re-register with the new data. */ @@ -173,6 +170,7 @@ Checkin (type, finfo, rcs, rev, tag, options, message) if (rev) { (void) RCS_unlock (finfo->rcs, NULL, 1); + RCS_rewrite (finfo->rcs, NULL, NULL); } #ifdef SERVER_SUPPORT diff --git a/contrib/cvs/src/checkout.c b/contrib/cvs/src/checkout.c index e36e729..3c1eef7 100644 --- a/contrib/cvs/src/checkout.c +++ b/contrib/cvs/src/checkout.c @@ -3,7 +3,7 @@ * Copyright (c) 1989-1992, Brian Berliner * * You may distribute under the terms of the GNU General Public License as - * specified in the README file that comes with the CVS 1.4 kit. + * specified in the README file that comes with the CVS source distribution. * * Create Version * @@ -61,6 +61,7 @@ static const char *const checkout_usage[] = "\t-d dir\tCheck out into dir instead of module name.\n", "\t-k kopt\tUse RCS kopt -k option on checkout.\n", "\t-j rev\tMerge in changes made between current revision and rev.\n", + "(Specify the --help global option for a list of other help options)\n", NULL }; @@ -76,6 +77,7 @@ static const char *const export_usage[] = "\t-D date\tExport revisions as of date.\n", "\t-d dir\tExport into dir instead of module name.\n", "\t-k kopt\tUse RCS kopt -k option on checkout.\n", + "(Specify the --help global option for a list of other help options)\n", NULL }; @@ -257,7 +259,7 @@ checkout (argc, argv) server send the check-in and update programs for the various modules/dirs requested. If we turn this off and simply request the names of the modules and directories (as - below in !expand_modules), those files (CVS/Checking.prog + below in !expand_modules), those files (CVS/Checkin.prog or CVS/Update.prog) don't get created. Grrr. */ expand_modules = (!cat && !status && !pipeout @@ -332,54 +334,16 @@ checkout (argc, argv) } db = open_module (); - /* - * if we have more than one argument and where was specified, we make the - * where, cd into it, and try to shorten names as much as possible. - * Otherwise, we pass the where as a single argument to do_module. - */ - if (argc > 1 && where != NULL) - { - (void) CVS_MKDIR (where, 0777); - if ( CVS_CHDIR (where) < 0) - error (1, errno, "cannot chdir to %s", where); - preload_update_dir = xstrdup (where); - where = (char *) NULL; - if (!isfile (CVSADM)) - { - char *repository; - repository = xmalloc (strlen (CVSroot_directory) + 80); - (void) sprintf (repository, "%s/%s/%s", CVSroot_directory, - CVSROOTADM, CVSNULLREPOS); - if (!isfile (repository)) - { - mode_t omask; - omask = umask (cvsumask); - (void) CVS_MKDIR (repository, 0777); - (void) umask (omask); - } + /* If we've specified something like "cvs co foo/bar baz/quux" + don't try to shorten names. There are a few cases in which we + could shorten (e.g. "cvs co foo/bar foo/baz"), but we don't + handle those yet. Better to have an extra directory created + than the thing checked out under the wrong directory name. */ - /* I'm not sure whether this check is redundant. */ - if (!isdir (repository)) - error (1, 0, "there is no repository %s", repository); + if (argc > 1) + shorten = 0; - Create_Admin (".", preload_update_dir, repository, - (char *) NULL, (char *) NULL, 0); - if (!noexec) - { - FILE *fp; - - fp = open_file (CVSADM_ENTSTAT, "w+"); - if (fclose(fp) == EOF) - error(1, errno, "cannot close %s", CVSADM_ENTSTAT); -#ifdef SERVER_SUPPORT - if (server_active) - server_set_entstat (preload_update_dir, repository); -#endif - } - free (repository); - } - } /* If we will be calling history_write, work out the name to pass it. */ @@ -396,29 +360,6 @@ checkout (argc, argv) history_name = date; } - /* - * if where was specified (-d) and we have not taken care of it already - * with the multiple arg stuff, and it was not a simple directory name - * but rather a path, we strip off everything but the last component and - * attempt to cd to the indicated place. where then becomes simply the - * last component - */ - if (where != NULL && strchr (where, '/') != NULL) - { - char *slash; - - slash = strrchr (where, '/'); - *slash = '\0'; - - if ( CVS_CHDIR (where) < 0) - error (1, errno, "cannot chdir to %s", where); - - preload_update_dir = xstrdup (where); - - where = slash + 1; - if (*where == '\0') - where = NULL; - } for (i = 0; i < argc; i++) err += do_module (db, argv[i], m_type, "Updating", checkout_proc, @@ -456,6 +397,8 @@ safe_location () hardpath[x] = '\0'; } current = xgetwd (); + if (current == NULL) + error (1, errno, "could not get working directory"); hardpath_len = strlen (hardpath); if (strlen (current) >= hardpath_len && strncmp (current, hardpath, hardpath_len) == 0) @@ -506,17 +449,18 @@ build_one_dir (repository, dirpath, sticky) if (!isdir (repository)) error (1, 0, "there is no repository %s", repository); - Create_Admin (".", dirpath, repository, - sticky ? (char *) NULL : tag, - sticky ? (char *) NULL : date, + if (Create_Admin (".", dirpath, repository, + sticky ? (char *) NULL : tag, + sticky ? (char *) NULL : date, - /* FIXME? This is a guess. If it is important - for nonbranch to be set correctly here I - think we need to write it one way now and - then rewrite it later via WriteTag, once - we've had a chance to call RCS_nodeisbranch - on each file. */ - 0); + /* FIXME? This is a guess. If it is important + for nonbranch to be set correctly here I + think we need to write it one way now and + then rewrite it later via WriteTag, once + we've had a chance to call RCS_nodeisbranch + on each file. */ + 0, 1)) + return; if (!noexec) { @@ -536,11 +480,11 @@ build_one_dir (repository, dirpath, sticky) */ /* ARGSUSED */ static int -checkout_proc (pargc, argv, where, mwhere, mfile, shorten, +checkout_proc (pargc, argv, where_orig, mwhere, mfile, shorten, local_specified, omodule, msg) int *pargc; char **argv; - char *where; + char *where_orig; char *mwhere; char *mfile; int shorten; @@ -551,11 +495,9 @@ checkout_proc (pargc, argv, where, mwhere, mfile, shorten, int err = 0; int which; char *cp; - char *cp2; char *repository; - char *xwhere = NULL; char *oldupdate = NULL; - char *prepath; + char *where; /* * OK, so we're doing the checkout! Our args are as follows: @@ -563,152 +505,172 @@ checkout_proc (pargc, argv, where, mwhere, mfile, shorten, * where contains where to put it (if supplied by checkout) * mwhere contains the module name or -d from module file * mfile says do only that part of the module - * shorten = TRUE says shorten as much as possible + * shorten = 1 says shorten as much as possible * omodule is the original arg to do_module() */ - /* set up the repository (maybe) for the bottom directory */ - repository = xmalloc (strlen (CVSroot_directory) + strlen (argv[0]) + 5); + /* Set up the repository (maybe) for the bottom directory. + Allocate more space than we need so we don't need to keep + reallocating this string. */ + repository = xmalloc (strlen (CVSroot_directory) + + strlen (argv[0]) + + (mfile == NULL ? 0 : strlen (mfile)) + + 10); (void) sprintf (repository, "%s/%s", CVSroot_directory, argv[0]); + Sanitize_Repository_Name (repository); + /* save the original value of preload_update_dir */ if (preload_update_dir != NULL) oldupdate = xstrdup (preload_update_dir); - /* fix up argv[] for the case of partial modules */ - if (mfile != NULL) - { - char *file; - /* if mfile is really a path, straighten it out first */ - if ((cp = strrchr (mfile, '/')) != NULL) + /* Allocate space and set up the where variable. We allocate more + space than necessary here so that we don't have to keep + reallocaing it later on. */ + + where = xmalloc (strlen (argv[0]) + + (mfile == NULL ? 0 : strlen (mfile)) + + (mwhere == NULL ? 0 : strlen (mwhere)) + + (where_orig == NULL ? 0 : strlen (where_orig)) + + 10); + + /* Yes, this could be written in a less verbose way, but in this + form it is quite easy to read. + + FIXME? The following code that sets should probably be moved + to do_module in modules.c, since there is similar code in + patch.c and rtag.c. */ + + if (shorten) + { + if (where_orig != NULL) { - *cp = 0; - repository = xrealloc (repository, - strlen (repository) + strlen (mfile) + 10); - (void) strcat (repository, "/"); - (void) strcat (repository, mfile); - - /* - * Now we need to fill in the where correctly. if !shorten, tack - * the rest of the path onto where if where is filled in - * otherwise tack the rest of the path onto mwhere and make that - * the where - * - * If shorten is enabled, we might use mwhere to set where if - * nobody set it yet, so we'll need to setup mwhere as the last - * component of the path we are tacking onto repository - */ - if (!shorten) - { - if (where != NULL) - { - xwhere = xmalloc (strlen (where) + strlen (mfile) + 5); - (void) sprintf (xwhere, "%s/%s", where, mfile); - } - else - { - xwhere = xmalloc (strlen (mwhere) + strlen (mfile) + 5); - (void) sprintf (xwhere, "%s/%s", mwhere, mfile); - } - where = xwhere; - } - else - { - char *slash; - - if ((slash = strrchr (mfile, '/')) != NULL) - mwhere = slash + 1; - else - mwhere = mfile; - } - mfile = cp + 1; + /* If the user has specified a directory with `-d' on the + command line, use it preferentially, even over the `-d' + flag in the modules file. */ + + (void) strcpy (where, where_orig); } - - file = xmalloc (strlen (repository) + strlen (mfile) + 5); - (void) sprintf (file, "%s/%s", repository, mfile); - if (isdir (file)) + else if (mwhere != NULL) { + /* Second preference is the value of mwhere, which is from + the `-d' flag in the modules file. */ - /* - * The portion of a module was a directory, so kludge up where to - * be the subdir, and fix up repository - */ - free (repository); - repository = xstrdup (file); - - /* - * At this point, if shorten is not enabled, we make where either - * where with mfile concatenated, or if where hadn't been set we - * set it to mwhere with mfile concatenated. - * - * If shorten is enabled and where hasn't been set yet, then where - * becomes mfile - */ - if (!shorten) - { - if (where != NULL) - { - xwhere = xmalloc (strlen (where) + strlen (mfile) + 5); - (void) sprintf (xwhere, "%s/%s", where, mfile); - } - else - { - xwhere = xmalloc (strlen (mwhere) + strlen (mfile) + 5); - (void) sprintf (xwhere, "%s/%s", mwhere, mfile); - } - where = xwhere; - } - else if (where == NULL) - where = mfile; + (void) strcpy (where, mwhere); } else { - int i; - - /* - * The portion of a module was a file, so kludge up argv to be - * correct - */ - for (i = 1; i < *pargc; i++)/* free the old ones */ - free (argv[i]); - /* FIXME: Normally one has to realloc argv to make sure - argv[1] exists. But this argv does not points to the - beginning of an allocated block. For now we allocate - at least 4 entries for argv (in line2argv). */ - argv[1] = xstrdup (mfile); /* set up the new one */ - *pargc = 2; - - /* where gets mwhere if where isn't set */ - if (where == NULL) - where = mwhere; + /* Third preference is the directory specified in argv[0] + which is this module'e directory in the repository. */ + + (void) strcpy (where, argv[0]); } - free (file); } - - /* - * if shorten is enabled and where isn't specified yet, we pluck the last - * directory component of argv[0] and make it the where - */ - if (shorten && where == NULL) + else { - if ((cp = strrchr (argv[0], '/')) != NULL) + /* Use the same preferences here, bug don't shorten -- that + is, tack on where_orig if it exists. */ + + *where = '\0'; + + if (where_orig != NULL) { - xwhere = xstrdup (cp + 1); - where = xwhere; + (void) strcat (where, where_orig); + (void) strcat (where, "/"); } + + if (mwhere != NULL) + (void) strcat (where, mwhere); + else + (void) strcat (where, argv[0]); } + strip_trailing_slashes (where); /* necessary? */ + - /* if where is still NULL, use mwhere if set or the argv[0] dir */ - if (where == NULL) + /* At this point, the user may have asked for a single file or + directory from within a module. In that case, we should modify + where, repository, and argv as appropriate. */ + + if (mfile != NULL) { - if (mwhere) - where = mwhere; + /* The mfile variable can have one or more path elements. If + it has multiple elements, we want to tack those onto both + repository and where. The last element may refer to either + a file or directory. Here's what to do: + + it refers to a directory + -> simply tack it on to where and repository + it refers to a file + -> munge argv to contain `basename mfile` */ + + char *cp; + char *path; + + + /* Paranoia check. */ + + if (mfile[strlen (mfile) - 1] == '/') + { + error (0, 0, "checkout_proc: trailing slash on mfile (%s)!", + mfile); + } + + + /* Does mfile have multiple path elements? */ + + cp = strrchr (mfile, '/'); + if (cp != NULL) + { + *cp = '\0'; + (void) strcat (repository, "/"); + (void) strcat (repository, mfile); + (void) strcat (where, "/"); + (void) strcat (where, mfile); + mfile = cp + 1; + } + + + /* Now mfile is a single path element. */ + + path = xmalloc (strlen (repository) + strlen (mfile) + 5); + (void) sprintf (path, "%s/%s", repository, mfile); + if (isdir (path)) + { + /* It's a directory, so tack it on to repository and + where, as we did above. */ + + (void) strcat (repository, "/"); + (void) strcat (repository, mfile); + (void) strcat (where, "/"); + (void) strcat (where, mfile); + } else { - xwhere = xstrdup (argv[0]); - where = xwhere; + /* It's a file, which means we have to screw around with + argv. */ + + int i; + + + /* Paranoia check. */ + + if (*pargc > 1) + { + error (0, 0, "checkout_proc: trashing argv elements!"); + for (i = 1; i < *pargc; i++) + { + error (0, 0, "checkout_proc: argv[%d] `%s'", + i, argv[i]); + } + } + + for (i = 1; i < *pargc; i++) + free (argv[i]); + argv[1] = xstrdup (mfile); + (*pargc) = 2; } + free (path); } if (preload_update_dir != NULL) @@ -725,6 +687,12 @@ checkout_proc (pargc, argv, where, mwhere, mfile, shorten, /* * At this point, where is the directory we want to build, repository is * the repository for the lowest level of the path. + * + * We need to tell build_dirs not only the path we want it to + * build, but also the repositories we want it to populate the + * path with. To accomplish this, we walk the path backwards, one + * pathname component at a time, constucting a linked list of + * struct dir_to_build. */ /* @@ -733,20 +701,11 @@ checkout_proc (pargc, argv, where, mwhere, mfile, shorten, */ if (!pipeout) { - size_t root_len; struct dir_to_build *head; + char *reposcopy; - /* We need to tell build_dirs not only the path we want it to - build, but also the repositories we want it to populate the - path with. To accomplish this, we walk the path backwards, - one pathname component at a time, constucting a linked - list of struct dir_to_build. */ - prepath = xstrdup (repository); - - /* We don't want to start stripping elements off prepath after we - get to CVSROOT. */ - root_len = strlen (CVSroot_directory); - if (strncmp (repository, CVSroot_directory, root_len) != 0) + if (strncmp (repository, CVSroot_directory, + strlen (CVSroot_directory)) != 0) error (1, 0, "\ internal error: %s doesn't start with %s in checkout_proc", repository, CVSroot_directory); @@ -760,9 +719,14 @@ internal error: %s doesn't start with %s in checkout_proc", head->dirpath = xstrdup (where); head->next = NULL; - cp = strrchr (where, '/'); - cp2 = strrchr (prepath, '/'); + /* Make a copy of the repository name to play with. */ + reposcopy = xstrdup (repository); + + /* FIXME: this should be written in terms of last_component instead + of hardcoding '/'. This presumably affects OS/2, NT, &c, if + the user specifies '\'. Likewise for the call to findslash. */ + cp = strrchr (where, '/'); while (cp != NULL) { struct dir_to_build *new; @@ -771,42 +735,97 @@ internal error: %s doesn't start with %s in checkout_proc", new->dirpath = xmalloc (strlen (where)); strncpy (new->dirpath, where, cp - where); new->dirpath[cp - where] = '\0'; - if (cp2 == NULL || cp2 < prepath + root_len) + + /* Now figure out what repository directory to generate. + The most complete case would be something like this: + + The modules file contains + foo -d bar/baz quux + + The command issued was: + cvs co -d what/ever -N foo + + The results in the CVS/Repository files should be: + . -> . (this is where we executed the cmd) + what -> Emptydir (generated dir -- not in repos) + ever -> . (same as "cd what/ever; cvs co -N foo") + bar -> Emptydir (generated dir -- not in repos) + baz -> quux (finally!) */ + + if (strcmp (reposcopy, CVSroot_directory) == 0) { - /* Don't walk up past CVSROOT; instead put in CVSNULLREPOS. */ - new->repository = - xmalloc (strlen (CVSroot_directory) + 80); - (void) sprintf (new->repository, "%s/%s/%s", - CVSroot_directory, - CVSROOTADM, CVSNULLREPOS); - if (!isfile (new->repository)) - { - mode_t omask; - omask = umask (cvsumask); - if (CVS_MKDIR (new->repository, 0777) < 0) - error (0, errno, "cannot create %s", - new->repository); - (void) umask (omask); - } + /* We can't walk up past CVSROOT. Instead, the + repository should be Emptydir. */ + new->repository = emptydir_name (); } else { - new->repository = xmalloc (strlen (prepath)); - strncpy (new->repository, prepath, cp2 - prepath); - new->repository[cp2 - prepath] = '\0'; + if ((where_orig != NULL) + && (strcmp (new->dirpath, where_orig) == 0)) + { + /* It's the case that the user specified a + * destination directory with the "-d" flag. The + * repository in this directory should be "." + * since the user's command is equivalent to: + * + * cd <dir>; cvs co blah */ + + strcpy (reposcopy, CVSroot_directory); + goto allocate_repos; + } + else if (mwhere != NULL) + { + /* This is a generated directory, so point to + CVSNULLREPOS. */ + + new->repository = emptydir_name (); + } + else + { + /* It's a directory in the repository! */ + + char *rp = strrchr (reposcopy, '/'); + + /* We'll always be below CVSROOT, but check for + paranoia's sake. */ + if (rp == NULL) + error (1, 0, + "internal error: %s doesn't contain a slash", + reposcopy); + + *rp = '\0'; + + allocate_repos: + new->repository = xmalloc (strlen (reposcopy) + 5); + (void) strcpy (new->repository, reposcopy); + + if (strcmp (reposcopy, CVSroot_directory) == 0) + { + /* Special case -- the repository name needs + to be "/path/to/repos/." (the trailing dot + is important). We might be able to get rid + of this after the we check out the other + code that handles repository names. */ + (void) strcat (new->repository, "/."); + } + } } + new->next = head; head = new; cp = findslash (where, cp - 1); - cp2 = findslash (prepath, cp2 - 1); } - /* First build the top-level CVSADM directory. The value we - pass in here for repository is probably wrong; see modules3-7f - in the testsuite. */ - build_one_dir (head->repository != NULL ? head->repository : prepath, - ".", *pargc <= 1); + /* clean up */ + free (reposcopy); + + /* The top-level CVSADM directory should always be + CVSroot_directory. Create it. + + It may be argued that we shouldn't set any sticky bits for + the top-level repository. FIXME? */ + build_one_dir (CVSroot_directory, ".", *pargc <= 1); /* * build dirs on the path if necessary and leave us in the bottom @@ -817,14 +836,10 @@ internal error: %s doesn't start with %s in checkout_proc", if (build_dirs_and_chdir (head, *pargc <= 1) != 0) { error (0, 0, "ignoring module %s", omodule); - free (prepath); err = 1; goto out; } - /* clean up */ - free (prepath); - /* set up the repository (or make sure the old one matches) */ if (!isfile (CVSADM)) { @@ -837,7 +852,7 @@ internal error: %s doesn't start with %s in checkout_proc", error (1, 0, "there is no repository %s", repository); Create_Admin (".", preload_update_dir, repository, - (char *) NULL, (char *) NULL, 0); + (char *) NULL, (char *) NULL, 0, 0); fp = open_file (CVSADM_ENTSTAT, "w+"); if (fclose(fp) == EOF) error(1, errno, "cannot close %s", CVSADM_ENTSTAT); @@ -860,7 +875,7 @@ internal error: %s doesn't start with %s in checkout_proc", then rewrite it later via WriteTag, once we've had a chance to call RCS_nodeisbranch on each file. */ - 0); + 0, 0); } } else @@ -1004,8 +1019,7 @@ internal error: %s doesn't start with %s in checkout_proc", out: free (preload_update_dir); preload_update_dir = oldupdate; - if (xwhere != NULL) - free (xwhere); + free (where); free (repository); return (err); } @@ -1026,6 +1040,32 @@ findslash (start, p) return (p); } +/* Return a newly malloc'd string containing a pathname for CVSNULLREPOS, + and make sure that it exists. If there is an error creating the + directory, give a fatal error. Otherwise, the directory is guaranteed + to exist when we return. */ +char * +emptydir_name () +{ + char *repository; + + repository = xmalloc (strlen (CVSroot_directory) + + sizeof (CVSROOTADM) + + sizeof (CVSNULLREPOS) + + 10); + (void) sprintf (repository, "%s/%s/%s", CVSroot_directory, + CVSROOTADM, CVSNULLREPOS); + if (!isfile (repository)) + { + mode_t omask; + omask = umask (cvsumask); + if (CVS_MKDIR (repository, 0777) < 0) + error (1, errno, "cannot create %s", repository); + (void) umask (omask); + } + return repository; +} + /* Build all the dirs along the path to DIRS with CVS subdirs with appropriate repositories. If ->repository is NULL, do not create a CVSADM directory for that subdirectory; just CVS_CHDIR into it. */ diff --git a/contrib/cvs/src/classify.c b/contrib/cvs/src/classify.c index 55851f7..57c23cd 100644 --- a/contrib/cvs/src/classify.c +++ b/contrib/cvs/src/classify.c @@ -3,19 +3,14 @@ * Copyright (c) 1989-1992, Brian Berliner * * You may distribute under the terms of the GNU General Public License as - * specified in the README file that comes with the CVS 1.4 kit. + * specified in the README file that comes with the CVS source distribution. * */ #include "cvs.h" -#ifdef SERVER_SUPPORT -static void sticky_ck PROTO((char *file, int aflag, Vers_TS * vers, - List * entries, - char *repository, char *update_dir)); -#else -static void sticky_ck PROTO((char *file, int aflag, Vers_TS * vers, List * entries)); -#endif +static void sticky_ck PROTO ((struct file_info *finfo, int aflag, + Vers_TS * vers)); /* * Classify the state of a file @@ -26,7 +21,11 @@ Classify_File (finfo, tag, date, options, force_tag_match, aflag, versp, struct file_info *finfo; char *tag; char *date; + + /* Keyword expansion options. Can be either NULL or "" to + indicate none are specified here. */ char *options; + int force_tag_match; int aflag; Vers_TS **versp; @@ -68,8 +67,8 @@ Classify_File (finfo, tag, date, options, force_tag_match, aflag, versp, is what I would expect. */ if (!force_tag_match || !(vers->tag || vers->date)) if (!really_quiet) - error (0, 0, "use `cvs add' to create an entry for %s", - finfo->fullname); + error (0, 0, "use `%s add' to create an entry for %s", + program_name, finfo->fullname); ret = T_UNKNOWN; } } @@ -79,8 +78,8 @@ Classify_File (finfo, tag, date, options, force_tag_match, aflag, versp, ret = T_UPTODATE; else { - error (0, 0, "use `cvs add' to create an entry for %s", - finfo->fullname); + error (0, 0, "use `%s add' to create an entry for %s", + program_name, finfo->fullname); ret = T_UNKNOWN; } } @@ -308,12 +307,7 @@ conflict: %s created independently by second party", ret = T_CHECKOUT; else { -#ifdef SERVER_SUPPORT - sticky_ck (finfo->file, aflag, vers, finfo->entries, - finfo->repository, finfo->update_dir); -#else - sticky_ck (finfo->file, aflag, vers, finfo->entries); -#endif + sticky_ck (finfo, aflag, vers); ret = T_UPTODATE; } } @@ -339,12 +333,7 @@ conflict: %s created independently by second party", ret = T_NEEDS_MERGE; #else ret = T_MODIFIED; -#ifdef SERVER_SUPPORT - sticky_ck (finfo->file, aflag, vers, finfo->entries, - finfo->repository, finfo->update_dir); -#else - sticky_ck (finfo->file, aflag, vers, finfo->entries); -#endif /* SERVER_SUPPORT */ + sticky_ck (finfo, aflag, vers); #endif } else @@ -434,19 +423,10 @@ conflict: %s created independently by second party", } static void -#ifdef SERVER_SUPPORT -sticky_ck (file, aflag, vers, entries, repository, update_dir) -#else -sticky_ck (file, aflag, vers, entries) -#endif - char *file; +sticky_ck (finfo, aflag, vers) + struct file_info *finfo; int aflag; Vers_TS *vers; - List *entries; -#ifdef SERVER_SUPPORT - char *repository; - char *update_dir; -#endif { if (aflag || vers->tag || vers->date) { @@ -458,7 +438,7 @@ sticky_ck (file, aflag, vers, entries) (entdate && vers->date && strcmp (entdate, vers->date)) || ((entdate && !vers->date) || (!entdate && vers->date))) { - Register (entries, file, vers->vn_user, vers->ts_rcs, + Register (finfo->entries, finfo->file, vers->vn_user, vers->ts_rcs, vers->options, vers->tag, vers->date, vers->ts_conflict); #ifdef SERVER_SUPPORT @@ -468,7 +448,7 @@ sticky_ck (file, aflag, vers, entries) It is possible we will later update it again via server_updated or some such, but that is OK. */ server_update_entries - (file, update_dir, repository, + (finfo->file, finfo->update_dir, finfo->repository, strcmp (vers->ts_rcs, vers->ts_user) == 0 ? SERVER_UPDATED : SERVER_MERGED); } diff --git a/contrib/cvs/src/client.c b/contrib/cvs/src/client.c index a1ed876..e0239bb 100644 --- a/contrib/cvs/src/client.c +++ b/contrib/cvs/src/client.c @@ -75,6 +75,18 @@ static Key_schedule sched; #endif /* HAVE_KERBEROS */ #endif /* HAVE_KERBEROS */ + +#ifdef HAVE_GSSAPI + +#include <gssapi/gssapi.h> +#include <gssapi/gssapi_generic.h> + +/* This is needed for GSSAPI encryption. */ +static gss_ctx_id_t gcontext; + +static int connect_to_gserver PROTO((int, struct hostent *)); + +#endif /* HAVE_GSSAPI */ static void add_prune_candidate PROTO((char *)); @@ -450,8 +462,12 @@ log_buffer_shutdown (closure) void *closure; { struct log_buffer *lb = (struct log_buffer *) closure; + int retval; - return buf_shutdown (lb->buf); + retval = buf_shutdown (lb->buf); + if (fclose (lb->log) < 0) + error (0, errno, "closing log file"); + return retval; } #ifdef NO_SOCKET_TO_FD @@ -538,6 +554,17 @@ socket_buffer_input (closure, data, need, size, got) do { + + /* Note that for certain (broken?) networking stacks, like + VMS's UCX (not sure what version, problem reported with + recv() in 1997), and (according to windows-NT/config.h) + Windows NT 3.51, we must call recv or send with a + moderately sized buffer (say, less than 200K or something), + or else there may be network errors (somewhat hard to + produce, e.g. WAN not LAN or some such). buf_read_data + makes sure that we only recv() BUFFER_DATA_SIZE bytes at + a time. */ + nbytes = recv (sb->socket, data, size, 0); if (nbytes < 0) error (1, 0, "reading from server: %s", SOCK_STRERROR (SOCK_ERRNO)); @@ -575,6 +602,9 @@ socket_buffer_output (closure, data, have, wrote) *wrote = have; + /* See comment in socket_buffer_input regarding buffer size we pass + to send and recv. */ + #ifdef SEND_NEVER_PARTIAL /* If send() never will produce a partial write, then just do it. This is needed for systems where its return value is something other than @@ -941,7 +971,7 @@ call_in_directory (pathname, func, data) strcpy (r, "/."); Create_Admin (".", ".", repo, (char *) NULL, - (char *) NULL, 0); + (char *) NULL, 0, 1); free (repo); } @@ -1078,7 +1108,7 @@ warning: server is not creating directories one at a time"); strcpy (r, reposdirname); Create_Admin (dir, dir, repo, - (char *)NULL, (char *)NULL, 0); + (char *)NULL, (char *)NULL, 0, 0); free (repo); b = strrchr (dir, '/'); @@ -1251,6 +1281,25 @@ protocol error: compressed files not supported for that operation"); error (1, errno, "cannot close %s", fullname); } +/* OK, we want to swallow the "U foo.c" response and then output it only + if we can update the file. In the future we probably want some more + systematic approach to parsing tagged text, but for now we keep it + ad hoc. "Why," I hear you cry, "do we not just look at the + Update-existing and Created responses?" That is an excellent question, + and the answer is roughly conservatism/laziness--I haven't read through + update.c enough to figure out the exact correspondence or lack thereof + between those responses and a "U foo.c" line (note that Merged, from + join_file, can be either "C foo" or "U foo" depending on the context). */ +/* Nonzero if we have seen +updated and not -updated. */ +static int updated_seen; +/* Filename from an "fname" tagged response within +updated/-updated. */ +static char *updated_fname; + + +/* Nonzero if we should arrange to return with a failure exit status. */ +static int failure_exit; + + /* * The time stamp of the last file we registered. */ @@ -1398,61 +1447,55 @@ update_entries (data_arg, ent_list, short_pathname, filename) char *vn; /* Timestamp field. Always empty according to the protocol. */ char *ts; - char *options; + char *options = NULL; char *tag = NULL; char *date = NULL; char *tag_or_date; char *scratch_entries = NULL; int bin; +#ifdef UTIME_EXPECTS_WRITABLE + int change_it_back = 0; +#endif + read_line (&entries_line); /* * Parse the entries line. */ - if (strcmp (command_name, "export") != 0) - { - scratch_entries = xstrdup (entries_line); - - if (scratch_entries[0] != '/') - error (1, 0, "bad entries line `%s' from server", entries_line); - user = scratch_entries + 1; - if ((cp = strchr (user, '/')) == NULL) - error (1, 0, "bad entries line `%s' from server", entries_line); - *cp++ = '\0'; - vn = cp; - if ((cp = strchr (vn, '/')) == NULL) - error (1, 0, "bad entries line `%s' from server", entries_line); - *cp++ = '\0'; - - ts = cp; - if ((cp = strchr (ts, '/')) == NULL) - error (1, 0, "bad entries line `%s' from server", entries_line); - *cp++ = '\0'; - options = cp; - if ((cp = strchr (options, '/')) == NULL) - error (1, 0, "bad entries line `%s' from server", entries_line); - *cp++ = '\0'; - tag_or_date = cp; - - /* If a slash ends the tag_or_date, ignore everything after it. */ - cp = strchr (tag_or_date, '/'); - if (cp != NULL) - *cp = '\0'; - if (*tag_or_date == 'T') - tag = tag_or_date + 1; - else if (*tag_or_date == 'D') - date = tag_or_date + 1; - } - else - /* For cvs export, assume it is a text file. FIXME: This is - broken behavior--we should be having the server tell us - whether it is text or binary and dealing accordingly. I - think maybe we can parse the entries line, get the options, - and then ignore the entries line otherwise, but I haven't - checked to see whether the server sends the entries line - correctly in this case. */ - options = NULL; + scratch_entries = xstrdup (entries_line); + + if (scratch_entries[0] != '/') + error (1, 0, "bad entries line `%s' from server", entries_line); + user = scratch_entries + 1; + if ((cp = strchr (user, '/')) == NULL) + error (1, 0, "bad entries line `%s' from server", entries_line); + *cp++ = '\0'; + vn = cp; + if ((cp = strchr (vn, '/')) == NULL) + error (1, 0, "bad entries line `%s' from server", entries_line); + *cp++ = '\0'; + + ts = cp; + if ((cp = strchr (ts, '/')) == NULL) + error (1, 0, "bad entries line `%s' from server", entries_line); + *cp++ = '\0'; + options = cp; + if ((cp = strchr (options, '/')) == NULL) + error (1, 0, "bad entries line `%s' from server", entries_line); + *cp++ = '\0'; + tag_or_date = cp; + + /* If a slash ends the tag_or_date, ignore everything after it. */ + cp = strchr (tag_or_date, '/'); + if (cp != NULL) + *cp = '\0'; + if (*tag_or_date == 'T') + tag = tag_or_date + 1; + else if (*tag_or_date == 'D') + date = tag_or_date + 1; + + /* Done parsing the entries line. */ if (data->contents == UPDATE_ENTRIES_UPDATE || data->contents == UPDATE_ENTRIES_PATCH @@ -1528,6 +1571,13 @@ update_entries (data_arg, ent_list, short_pathname, filename) I hope the above paragraph makes it clear that making this clearer is not a one-line fix. */ error (0, 0, "move away %s; it is in the way", short_pathname); + if (updated_fname != NULL) + { + cvs_output ("C ", 0); + cvs_output (updated_fname, 0); + cvs_output ("\n", 1); + } + failure_exit = 1; discard_file_and_return: /* Now read and discard the file contents. */ @@ -1546,6 +1596,21 @@ update_entries (data_arg, ent_list, short_pathname, filename) free (mode_string); free (entries_line); + + /* The Mode, Mod-time, and Checksum responses should not carry + over to a subsequent Created (or whatever) response, even + in the error case. */ + stored_mode_valid = 0; + if (stored_mode != NULL) + free (stored_mode); + stored_modtime_valid = 0; + stored_checksum_valid = 0; + + if (updated_fname != NULL) + { + free (updated_fname); + updated_fname = NULL; + } return; } @@ -1590,7 +1655,6 @@ update_entries (data_arg, ent_list, short_pathname, filename) else { int fd; - pid_t gzip_pid = 0; fd = CVS_OPEN (temp_filename, (O_WRONLY | O_CREAT | O_TRUNC @@ -1610,84 +1674,50 @@ update_entries (data_arg, ent_list, short_pathname, filename) goto discard_file_and_return; } - if (use_gzip) - fd = filter_through_gunzip (fd, 0, &gzip_pid); - if (size > 0) { read_from_server (buf, size); - if (write (fd, buf, size) != size) + if (use_gzip) + gunzip_and_write (fd, short_pathname, buf, size); + else if (write (fd, buf, size) != size) error (1, errno, "writing %s", short_pathname); } if (close (fd) < 0) error (1, errno, "writing %s", short_pathname); - if (gzip_pid > 0) - { - int gzip_status; - - if (waitpid (gzip_pid, &gzip_status, 0) == -1) - error (1, errno, "waiting for gzip process %ld", - (long) gzip_pid); - else if (gzip_status != 0) - error (1, 0, "gzip process exited %d", gzip_status); - } - - gzip_pid = -1; } - /* Since gunzip writes files without converting LF to CRLF - (a reasonable behavior), we now have a patch file in LF - format. Leave the file as is if we're just going to feed - it to patch; patch can handle it. However, if it's the - final source file, convert it. */ + /* This is after we have read the file from the net (a change + from previous versions, where the server would send us + "M U foo.c" before Update-existing or whatever), but before + we finish writing the file (arguably a bug). The timing + affects a user who wants status info about how far we have + gotten, and also affects whether "U foo.c" appears in addition + to various error messages. */ + if (updated_fname != NULL) + { + cvs_output ("U ", 0); + cvs_output (updated_fname, 0); + cvs_output ("\n", 1); + free (updated_fname); + updated_fname = 0; + } patch_failed = 0; if (data->contents == UPDATE_ENTRIES_UPDATE) { -#ifdef LINES_CRLF_TERMINATED - - /* `bin' is non-zero iff `options' contains "-kb", meaning - treat this file as binary. */ - - if (use_gzip && (! bin)) - { - convert_file (temp_filename, O_RDONLY | OPEN_BINARY, - filename, O_WRONLY | O_CREAT | O_TRUNC); - if ( CVS_UNLINK (temp_filename) < 0) - error (0, errno, "warning: couldn't delete %s", - temp_filename); - } - else -#ifdef BROKEN_READWRITE_CONVERSION - { - /* If only stdio, not open/write/etc., do text/binary - conversion, use convert_file which can compensate - (FIXME: we could just use stdio instead which would - avoid the whole problem). */ - if (!bin) - { - convert_file (temp_filename, O_RDONLY | OPEN_BINARY, - filename, O_WRONLY | O_CREAT | O_TRUNC); - if (CVS_UNLINK (temp_filename) < 0) - error (0, errno, "warning: couldn't delete %s", - temp_filename); - } - else - rename_file (temp_filename, filename); - } -#else - rename_file (temp_filename, filename); -#endif - -#else /* ! LINES_CRLF_TERMINATED */ rename_file (temp_filename, filename); -#endif /* LINES_CRLF_TERMINATED */ } else if (data->contents == UPDATE_ENTRIES_PATCH) { +#ifdef DONT_USE_PATCH + /* Hmm. We support only Rcs-diff, and the server supports + only Patched (or else it would have sent Rcs-diff instead). + Fall back to transmitting entire files. */ + patch_failed = 1; +#else /* Use patch. */ int retcode; char *backup; struct stat s; @@ -1705,8 +1735,26 @@ update_entries (data_arg, ent_list, short_pathname, filename) retcode = 0; else { - run_setup ("%s -f -s -b ~ %s %s", PATCH_PROGRAM, - filename, temp_filename); + /* This behavior (in which -b takes an argument) is + supported by GNU patch 2.1. Apparently POSIX.2 + specifies a -b option without an argument. GNU + patch 2.1.5 implements this and therefore won't + work here. GNU patch versions after 2.1.5 are said + to have a kludge which checks if the last 4 args + are `-b SUFFIX ORIGFILE PATCHFILE' and if so emit a + warning (I think -s suppresses it), and then behave + as CVS expects. + + Of course this is yet one more reason why in the long + run we want Rcs-diff to replace Patched. */ + + run_setup (PATCH_PROGRAM); + run_arg ("-f"); + run_arg ("-s"); + run_arg ("-b"); + run_arg ("~"); + run_arg (filename); + run_arg (temp_filename); retcode = run_exec (DEVNULL, RUN_TTY, RUN_TTY, RUN_NORMAL); } /* FIXME: should we really be silently ignoring errors? */ @@ -1739,13 +1787,12 @@ update_entries (data_arg, ent_list, short_pathname, filename) patch_failed = 1; } free (backup); +#endif /* Use patch. */ } else { - struct stat s; - char *filebuf, *tobuf; + char *filebuf; size_t filebufsize; - FILE *e; size_t nread; char *patchedbuf; size_t patchedlen; @@ -1755,50 +1802,12 @@ update_entries (data_arg, ent_list, short_pathname, filename) if (!isfile (filename)) error (1, 0, "patch original file %s does not exist", short_pathname); - if (CVS_STAT (filename, &s) < 0) - error (1, errno, "can't stat %s", short_pathname); - - filebufsize = s.st_size; - filebuf = xmalloc (filebufsize); - - e = open_file (filename, bin ? FOPEN_BINARY_READ : "r"); - - tobuf = filebuf; + filebuf = NULL; + filebufsize = 0; nread = 0; - while (1) - { - size_t got; - - got = fread (tobuf, 1, filebufsize - (tobuf - filebuf), e); - if (ferror (e)) - error (1, errno, "can't read %s", short_pathname); - nread += got; - tobuf += got; - - if (feof (e)) - break; - - /* It's probably paranoid to think S.ST_SIZE might be - too small to hold the entire file contents, but we - handle it just in case. */ - if (tobuf == filebuf + filebufsize) - { - int c; - long off; - - c = getc (e); - if (c == EOF) - break; - off = tobuf - filebuf; - expand_string (&filebuf, &filebufsize, filebufsize + 100); - tobuf = filebuf + off; - *tobuf++ = c; - ++nread; - } - } - - fclose (e); + get_file (filename, short_pathname, bin ? FOPEN_BINARY_READ : "r", + &filebuf, &filebufsize, &nread); /* At this point the contents of the existing file are in FILEBUF, and the length of the contents is in NREAD. The contents of the patch from the network are in BUF, @@ -1834,6 +1843,8 @@ update_entries (data_arg, ent_list, short_pathname, filename) if (! patch_failed) { + FILE *e; + e = open_file (temp_filename, bin ? FOPEN_BINARY_WRITE : "w"); if (fwrite (patchedbuf, 1, patchedlen, e) != patchedlen) @@ -1938,8 +1949,26 @@ update_entries (data_arg, ent_list, short_pathname, filename) /* There is probably little point in trying to preserved the actime (or is there? What about Checked-in?). */ t.modtime = t.actime = stored_modtime; + +#ifdef UTIME_EXPECTS_WRITABLE + if (!iswritable (filename)) + { + xchmod (filename, 1); + change_it_back = 1; + } +#endif /* UTIME_EXPECTS_WRITABLE */ + if (utime (filename, &t) < 0) error (0, errno, "cannot set time on %s", filename); + +#ifdef UTIME_EXPECTS_WRITABLE + if (change_it_back == 1) + { + xchmod (filename, 0); + change_it_back = 0; + } +#endif /* UTIME_EXPECTS_WRITABLE */ + stored_modtime_valid = 0; } @@ -2674,9 +2703,8 @@ send_repository (dir, repos, update_dir) } /* Send a Repository line and set toplevel_repos. */ -static void send_a_repository PROTO((char *, char *, char *)); -static void +void send_a_repository (dir, repository, update_dir) char *dir; char *repository; @@ -2722,6 +2750,14 @@ send_a_repository (dir, repository, update_dir) int slashes_skipped; char *p; + /* + * Strip trailing slashes from the name of the update directory. + * Otherwise, running `cvs update dir/' provokes the failure + * `protocol error: illegal directory syntax in dir/' when + * running in client/server mode. + */ + strip_trailing_slashes (update_dir); + slashes_in_update_dir = 0; for (p = update_dir; *p != '\0'; ++p) if (*p == '/') @@ -2857,12 +2893,52 @@ handle_m (args, len) /* In the case where stdout and stderr point to the same place, fflushing stderr will make output happen in the correct order. Often stderr will be line-buffered and this won't be needed, - but not always. */ + but not always (is that true? I think the comment is probably + based on being confused between default buffering between + stdout and stderr. But I'm not sure). */ fflush (stderr); fwrite (args, len, sizeof (*args), stdout); putc ('\n', stdout); } +static void handle_mbinary PROTO ((char *, int)); + +static void +handle_mbinary (args, len) + char *args; + int len; +{ + char *size_string; + size_t size; + size_t totalread; + size_t nread; + size_t toread; + char buf[8192]; + + /* See comment at handle_m about (non)flush of stderr. */ + + /* Get the size. */ + read_line (&size_string); + size = atoi (size_string); + free (size_string); + + /* OK, now get all the data. The algorithm here is that we read + as much as the network wants to give us in + try_read_from_server, and then we output it all, and then + repeat, until we get all the data. */ + totalread = 0; + while (totalread < size) + { + toread = size - totalread; + if (toread > sizeof buf) + toread = sizeof buf; + + nread = try_read_from_server (buf, toread); + cvs_output_binary (buf, nread); + totalread += nread; + } +} + static void handle_e (args, len) char *args; @@ -2884,6 +2960,67 @@ handle_f (args, len) fflush (stderr); } +static void handle_mt PROTO ((char *, int)); + +static void +handle_mt (args, len) + char *args; + int len; +{ + char *p; + char *tag = args; + char *text; + + /* See comment at handle_m for more details. */ + fflush (stderr); + + p = strchr (args, ' '); + if (p == NULL) + text = NULL; + else + { + *p++ = '\0'; + text = p; + } + + switch (tag[0]) + { + case '+': + if (strcmp (tag, "+updated") == 0) + updated_seen = 1; + break; + case '-': + if (strcmp (tag, "-updated") == 0) + updated_seen = 0; + break; + default: + if (updated_seen) + { + if (strcmp (tag, "fname") == 0) + { + if (updated_fname != NULL) + { + /* Output the previous message now. This can happen + if there was no Update-existing or other such + response, due to the -n global option. */ + cvs_output ("U ", 0); + cvs_output (updated_fname, 0); + cvs_output ("\n", 1); + free (updated_fname); + } + updated_fname = xstrdup (text); + } + /* Swallow all other tags. Either they are extraneous + or they reflect future extensions that we can + safely ignore. */ + } + else if (strcmp (tag, "newline") == 0) + printf ("\n"); + else if (text != NULL) + printf ("%s", text); + } +} + #endif /* CLIENT_SUPPORT */ #if defined(CLIENT_SUPPORT) || defined(SERVER_SUPPORT) @@ -2937,8 +3074,10 @@ struct response responses[] = RSP_LINE("Module-expansion", handle_module_expansion, response_type_normal, rs_optional), RSP_LINE("M", handle_m, response_type_normal, rs_essential), + RSP_LINE("Mbinary", handle_mbinary, response_type_normal, rs_optional), RSP_LINE("E", handle_e, response_type_normal, rs_essential), RSP_LINE("F", handle_f, response_type_normal, rs_optional), + RSP_LINE("MT", handle_mt, response_type_normal, rs_optional), /* Possibly should be response_type_error. */ RSP_LINE(NULL, NULL, response_type_normal, rs_essential) @@ -3059,12 +3198,39 @@ get_server_responses () } if (rs->name == NULL) /* It's OK to print just to the first '\0'. */ + /* We might want to handle control characters and the like + in some other way other than just sending them to stdout. + One common reason for this error is if people use :ext: + with a version of rsh which is doing CRLF translation or + something, and so the client gets "ok^M" instead of "ok". + Right now that will tend to print part of this error + message over the other part of it. It seems like we could + do better (either in general, by quoting or omitting all + control characters, and/or specifically, by detecting the CRLF + case and printing a specific error message). */ error (0, 0, "warning: unrecognized response `%s' from cvs server", cmd); free (cmd); } while (rs->type == response_type_normal); - return rs->type == response_type_error ? 1 : 0; + + if (updated_fname != NULL) + { + /* Output the previous message now. This can happen + if there was no Update-existing or other such + response, due to the -n global option. */ + cvs_output ("U ", 0); + cvs_output (updated_fname, 0); + cvs_output ("\n", 1); + free (updated_fname); + updated_fname = NULL; + } + + if (rs->type == response_type_error) + return 1; + if (failure_exit) + return 1; + return 0; } /* Get the responses and then close the connection. */ @@ -3184,7 +3350,9 @@ get_responses_and_close () return errs; } +#ifndef NO_EXT_METHOD static void start_rsh_server PROTO((int *, int *)); +#endif int supported_request (name) @@ -3201,18 +3369,18 @@ supported_request (name) } -#ifdef AUTH_CLIENT_SUPPORT -static void init_sockaddr PROTO ((struct sockaddr_in *, char *, - unsigned int)); +#if defined (AUTH_CLIENT_SUPPORT) || defined (HAVE_KERBEROS) +static struct hostent *init_sockaddr PROTO ((struct sockaddr_in *, char *, + unsigned int)); -static void +static struct hostent * init_sockaddr (name, hostname, port) struct sockaddr_in *name; char *hostname; unsigned int port; { struct hostent *hostinfo; - unsigned short shortport = port; + unsigned short shortport = port; memset (name, 0, sizeof (*name)); name->sin_family = AF_INET; @@ -3224,8 +3392,12 @@ init_sockaddr (name, hostname, port) error_exit (); } name->sin_addr = *(struct in_addr *) hostinfo->h_addr; + return hostinfo; } +#endif /* defined (AUTH_CLIENT_SUPPORT) || defined (HAVE_KERBEROS) */ + +#ifdef AUTH_CLIENT_SUPPORT static int auth_server_port_number PROTO ((void)); @@ -3241,21 +3413,83 @@ auth_server_port_number () } -/* - * Connect to the authenticating server. - * - * If VERIFY_ONLY is non-zero, then just verify that the password is - * correct and then shutdown the connection. In this case, the return - * values is 1 if the password was correct, 0 if not. - * - * If VERIFY_ONLY is 0, then really connect to the server. In this - * case the return value is 1 on succees, but is probably ignored. If - * fail to connect, then die with error. - */ -int -connect_to_pserver (tofdp, fromfdp, verify_only) +/* Read a line from socket SOCK. Result does not include the + terminating linefeed. This is only used by the authentication + protocol, which we call before we set up all the buffering stuff. + It is possible it should use the buffers too, which would be faster + (unlike the server, there isn't really a security issue in terms of + separating authentication from the rest of the code). + + Space for the result is malloc'd and should be freed by the caller. + + Returns number of bytes read. */ +static int +recv_line (sock, resultp) + int sock; + char **resultp; +{ + int c; + char *result; + size_t input_index = 0; + size_t result_size = 80; + + result = (char *) xmalloc (result_size); + + while (1) + { + char ch; + if (recv (sock, &ch, 1, 0) < 0) + error (1, 0, "recv() from server %s: %s", CVSroot_hostname, + SOCK_STRERROR (SOCK_ERRNO)); + c = ch; + + if (c == EOF) + { + free (result); + + /* It's end of file. */ + error (1, 0, "end of file from server"); + } + + if (c == '\012') + break; + + result[input_index++] = c; + while (input_index + 1 >= result_size) + { + result_size *= 2; + result = (char *) xrealloc (result, result_size); + } + } + + if (resultp) + *resultp = result; + + /* Terminate it just for kicks, but we *can* deal with embedded NULs. */ + result[input_index] = '\0'; + + if (resultp == NULL) + free (result); + return input_index; +} + +/* Connect to the authenticating server. + + If VERIFY_ONLY is non-zero, then just verify that the password is + correct and then shutdown the connection. + + If VERIFY_ONLY is 0, then really connect to the server. + + If DO_GSSAPI is non-zero, then we use GSSAPI authentication rather + than the pserver password authentication. + + If we fail to connect or if access is denied, then die with fatal + error. */ +void +connect_to_pserver (tofdp, fromfdp, verify_only, do_gssapi) int *tofdp, *fromfdp; int verify_only; + int do_gssapi; { int sock; #ifndef NO_SOCKET_TO_FD @@ -3263,32 +3497,32 @@ connect_to_pserver (tofdp, fromfdp, verify_only) #endif int port_number; struct sockaddr_in client_sai; + struct hostent *hostinfo; sock = socket (AF_INET, SOCK_STREAM, 0); if (sock == -1) { - fprintf (stderr, "socket() failed\n"); - error_exit (); + error (1, 0, "cannot create socket: %s", SOCK_STRERROR (SOCK_ERRNO)); } port_number = auth_server_port_number (); - init_sockaddr (&client_sai, CVSroot_hostname, port_number); + hostinfo = init_sockaddr (&client_sai, CVSroot_hostname, port_number); if (connect (sock, (struct sockaddr *) &client_sai, sizeof (client_sai)) < 0) error (1, 0, "connect to %s:%d failed: %s", CVSroot_hostname, port_number, SOCK_STRERROR (SOCK_ERRNO)); /* Run the authorization mini-protocol before anything else. */ + if (do_gssapi) + { +#ifdef HAVE_GSSAPI + if (! connect_to_gserver (sock, hostinfo)) + goto rejected; +#else + error (1, 0, "This client does not support GSSAPI authentication"); +#endif + } + else { - int i; - char ch; - - /* Long enough to hold I LOVE YOU or I HATE YOU. Using a fixed-size - buffer seems better than letting an apeshit server chew up our - memory with illegal responses, and the value comes from - the protocol itself; it is not an arbitrary limit on data sent. */ -#define LARGEST_RESPONSE 80 - char read_buf[LARGEST_RESPONSE]; - char *begin = NULL; char *repository = CVSroot_directory; char *username = CVSroot_username; @@ -3297,91 +3531,103 @@ connect_to_pserver (tofdp, fromfdp, verify_only) if (verify_only) { - begin = "BEGIN VERIFICATION REQUEST\n"; - end = "END VERIFICATION REQUEST\n"; + begin = "BEGIN VERIFICATION REQUEST\012"; + end = "END VERIFICATION REQUEST\012"; } else { - begin = "BEGIN AUTH REQUEST\n"; - end = "END AUTH REQUEST\n"; + begin = "BEGIN AUTH REQUEST\012"; + end = "END AUTH REQUEST\012"; } /* Get the password, probably from ~/.cvspass. */ password = get_cvs_password (); /* Announce that we're starting the authorization protocol. */ - send (sock, begin, strlen (begin), 0); + if (send (sock, begin, strlen (begin), 0) < 0) + error (1, 0, "cannot send: %s", SOCK_STRERROR (SOCK_ERRNO)); /* Send the data the server needs. */ - send (sock, repository, strlen (repository), 0); - send (sock, "\n", 1, 0); - send (sock, username, strlen (username), 0); - send (sock, "\n", 1, 0); - send (sock, password, strlen (password), 0); - send (sock, "\n", 1, 0); + if (send (sock, repository, strlen (repository), 0) < 0) + error (1, 0, "cannot send: %s", SOCK_STRERROR (SOCK_ERRNO)); + if (send (sock, "\012", 1, 0) < 0) + error (1, 0, "cannot send: %s", SOCK_STRERROR (SOCK_ERRNO)); + if (send (sock, username, strlen (username), 0) < 0) + error (1, 0, "cannot send: %s", SOCK_STRERROR (SOCK_ERRNO)); + if (send (sock, "\012", 1, 0) < 0) + error (1, 0, "cannot send: %s", SOCK_STRERROR (SOCK_ERRNO)); + if (send (sock, password, strlen (password), 0) < 0) + error (1, 0, "cannot send: %s", SOCK_STRERROR (SOCK_ERRNO)); + if (send (sock, "\012", 1, 0) < 0) + error (1, 0, "cannot send: %s", SOCK_STRERROR (SOCK_ERRNO)); /* Announce that we're ending the authorization protocol. */ - send (sock, end, strlen (end), 0); + if (send (sock, end, strlen (end), 0) < 0) + error (1, 0, "cannot send: %s", SOCK_STRERROR (SOCK_ERRNO)); /* Paranoia. */ memset (password, 0, strlen (password)); + } - /* Get ACK or NACK from the server. - * - * We could avoid this careful read-char loop by having the ACK - * and NACK cookies be of the same length, so we'd simply read - * that length and see what we got. But then there'd be Yet - * Another Protocol Requirement floating around, and someday - * someone would make a change that breaks it and spend a hellish - * day tracking it down. Therefore, we use "\n" to mark off the - * end of both ACK and NACK, and we loop, reading until "\n". - */ - ch = 0; - memset (read_buf, 0, LARGEST_RESPONSE); - for (i = 0; (i < (LARGEST_RESPONSE - 1)) && (ch != '\n'); i++) - { - if (recv (sock, &ch, 1, 0) < 0) - error (1, 0, "recv() from server %s: %s", CVSroot_hostname, - SOCK_STRERROR (SOCK_ERRNO)); - - read_buf[i] = ch; - } + { + char *read_buf; - if (strcmp (read_buf, "I HATE YOU\n") == 0) + /* Loop, getting responses from the server. */ + while (1) { - /* Authorization not granted. */ - if (shutdown (sock, 2) < 0) + recv_line (sock, &read_buf); + + if (strcmp (read_buf, "I HATE YOU") == 0) { - error (0, 0, - "authorization failed: server %s rejected access", - CVSroot_hostname); - error (1, 0, - "shutdown() failed (server %s): %s", CVSroot_hostname, - SOCK_STRERROR (SOCK_ERRNO)); + /* Authorization not granted. */ + goto rejected; } + else if (strncmp (read_buf, "E ", 2) == 0) + { + fprintf (stderr, "%s\n", read_buf + 2); - if (verify_only) - return 0; + /* Continue with the authentication protocol. */ + } + else if (strncmp (read_buf, "error ", 6) == 0) + { + char *p; + + /* First skip the code. */ + p = read_buf + 6; + while (*p != ' ' && *p != '\0') + ++p; + + /* Skip the space that follows the code. */ + if (*p == ' ') + ++p; + + /* Now output the text. */ + fprintf (stderr, "%s\n", p); + goto rejected; + } + else if (strcmp (read_buf, "I LOVE YOU") == 0) + { + free (read_buf); + break; + } else - error (1, 0, - "authorization failed: server %s rejected access", - CVSroot_hostname); - } - else if (strcmp (read_buf, "I LOVE YOU\n") != 0) - { - /* Unrecognized response from server. */ - if (shutdown (sock, 2) < 0) { - error (0, 0, + /* Unrecognized response from server. */ + if (shutdown (sock, 2) < 0) + { + error (0, 0, + "unrecognized auth response from %s: %s", + CVSroot_hostname, read_buf); + error (1, 0, + "shutdown() failed, server %s: %s", + CVSroot_hostname, + SOCK_STRERROR (SOCK_ERRNO)); + } + error (1, 0, "unrecognized auth response from %s: %s", CVSroot_hostname, read_buf); - error (1, 0, - "shutdown() failed, server %s: %s", CVSroot_hostname, - SOCK_STRERROR (SOCK_ERRNO)); } - error (1, 0, - "unrecognized auth response from %s: %s", - CVSroot_hostname, read_buf); + free (read_buf); } } @@ -3390,7 +3636,7 @@ connect_to_pserver (tofdp, fromfdp, verify_only) if (shutdown (sock, 2) < 0) error (0, 0, "shutdown() failed, server %s: %s", CVSroot_hostname, SOCK_STRERROR (SOCK_ERRNO)); - return 1; + return; } else { @@ -3410,57 +3656,48 @@ connect_to_pserver (tofdp, fromfdp, verify_only) #endif /* NO_SOCKET_TO_FD */ } - return 1; + return; + + rejected: + if (shutdown (sock, 2) < 0) + { + error (0, 0, + "authorization failed: server %s rejected access", + CVSroot_hostname); + error (1, 0, + "shutdown() failed (server %s): %s", + CVSroot_hostname, + SOCK_STRERROR (SOCK_ERRNO)); + } + + error (1, 0, + "authorization failed: server %s rejected access", + CVSroot_hostname); } #endif /* AUTH_CLIENT_SUPPORT */ #if HAVE_KERBEROS -/* - * FIXME: this function has not been changed to deal with - * NO_SOCKET_TO_FD (i.e., systems on which sockets cannot be converted - * to file descriptors) or with SOCK_ERRNO/SOCK_STRERROR. The first - * person to try building a kerberos client on such a system (OS/2, - * Windows 95, and maybe others) will have to make take care of this. - */ +/* This function has not been changed to deal with NO_SOCKET_TO_FD + (i.e., systems on which sockets cannot be converted to file + descriptors). The first person to try building a kerberos client + on such a system (OS/2, Windows 95, and maybe others) will have to + make take care of this. */ void start_tcp_server (tofdp, fromfdp) int *tofdp, *fromfdp; { - int tofd = -1, fromfd; - - struct hostent *hp; - char *hname; + int s; const char *portenv; int port; + struct hostent *hp; struct sockaddr_in sin; - int s; - -#if HAVE_KERBEROS - KTEXT_ST ticket; - const char *realm; -#endif /* HAVE_KERBEROS */ - - int status; + char *hname; - /* - * We look up the host to give a better error message if it - * does not exist. However, we then pass CVSroot_hostname to - * krb_sendauth, rather than the canonical name, because - * krb_sendauth is going to do its own canonicalization anyhow - * and that lets us not worry about the static storage used by - * gethostbyname. - */ - hp = gethostbyname (CVSroot_hostname); - if (hp == NULL) - error (1, 0, "%s: unknown host", CVSroot_hostname); - hname = xmalloc (strlen (hp->h_name) + 1); - strcpy (hname, hp->h_name); - -#if HAVE_KERBEROS - realm = krb_realmofhost (hname); -#endif /* HAVE_KERBEROS */ + s = socket (AF_INET, SOCK_STREAM, 0); + if (s < 0) + error (1, 0, "cannot create socket: %s", SOCK_STRERROR (SOCK_ERRNO)); /* Get CVS_CLIENT_PORT or look up cvs/tcp with CVS_PORT as default */ portenv = getenv ("CVS_CLIENT_PORT"); @@ -3476,7 +3713,6 @@ start_tcp_server (tofdp, fromfdp) } if (trace) fprintf(stderr, "Using TCP port %d to contact server.\n", port); - port = htons (port); } else { @@ -3484,85 +3720,160 @@ start_tcp_server (tofdp, fromfdp) sp = getservbyname ("cvs", "tcp"); if (sp == NULL) - port = htons (CVS_PORT); + port = CVS_PORT; else - port = sp->s_port; + port = ntohs (sp->s_port); } - s = socket (AF_INET, SOCK_STREAM, 0); - if (s < 0) - error (1, errno, "socket"); - - memset (&sin, 0, sizeof sin); - sin.sin_family = AF_INET; - sin.sin_addr.s_addr = INADDR_ANY; - sin.sin_port = 0; - - if (bind (s, (struct sockaddr *) &sin, sizeof sin) < 0) - error (1, errno, "bind"); - - memcpy (&sin.sin_addr, hp->h_addr, hp->h_length); - sin.sin_port = port; + hp = init_sockaddr (&sin, CVSroot_hostname, port); + hname = xmalloc (strlen (hp->h_name) + 1); + strcpy (hname, hp->h_name); + if (connect (s, (struct sockaddr *) &sin, sizeof sin) < 0) - { - error (0, errno, "connect"); - close (s); - } - else - { + error (1, 0, "connect to %s:%d failed: %s", CVSroot_hostname, + port, SOCK_STRERROR (SOCK_ERRNO)); + #ifdef HAVE_KERBEROS + { + const char *realm; struct sockaddr_in laddr; int laddrlen; + KTEXT_ST ticket; MSG_DAT msg_data; CREDENTIALS cred; + int status; + + realm = krb_realmofhost (hname); laddrlen = sizeof (laddr); if (getsockname (s, (struct sockaddr *) &laddr, &laddrlen) < 0) - error (1, errno, "getsockname"); + error (1, 0, "getsockname failed: %s", SOCK_STRERROR (SOCK_ERRNO)); /* We don't care about the checksum, and pass it as zero. */ status = krb_sendauth (KOPT_DO_MUTUAL, s, &ticket, "rcmd", hname, realm, (unsigned long) 0, &msg_data, &cred, sched, &laddr, &sin, "KCVSV1.0"); if (status != KSUCCESS) - { - error (0, 0, "kerberos: %s", krb_get_err_text(status)); - close (s); - } - else - { - memcpy (kblock, cred.session, sizeof (C_Block)); - + error (1, 0, "kerberos authentication failed: %s", + krb_get_err_text (status)); + memcpy (kblock, cred.session, sizeof (C_Block)); + } #endif /* HAVE_KERBEROS */ - server_fd = s; - close_on_exec (server_fd); - tofd = fromfd = s; + server_fd = s; + close_on_exec (server_fd); + + free (hname); + + /* Give caller the values it wants. */ + *tofdp = s; + *fromfdp = s; +} -#ifdef HAVE_KERBEROS - } #endif /* HAVE_KERBEROS */ - } - - if (tofd == -1) + +#ifdef HAVE_GSSAPI + +/* Receive a given number of bytes. */ + +static void +recv_bytes (sock, buf, need) + int sock; + char *buf; + int need; +{ + while (need > 0) { -#ifdef HAVE_KERBEROS - error (0, 0, "Kerberos connect failed"); -#else - error (0, 0, "Direct TCP connect failed"); -#endif - error (1, 0, "couldn't connect to remote host %s", CVSroot_hostname); + int got; + + got = recv (sock, buf, need, 0); + if (got < 0) + error (1, 0, "recv() from server %s: %s", CVSroot_hostname, + SOCK_STRERROR (SOCK_ERRNO)); + buf += got; + need -= got; } +} - free (hname); +/* Connect to the server using GSSAPI authentication. */ - /* Give caller the values it wants. */ - *tofdp = tofd; - *fromfdp = fromfd; +static int +connect_to_gserver (sock, hostinfo) + int sock; + struct hostent *hostinfo; +{ + char *str; + char buf[1024]; + gss_buffer_desc *tok_in_ptr, tok_in, tok_out; + OM_uint32 stat_min, stat_maj; + gss_name_t server_name; + + str = "BEGIN GSSAPI REQUEST\012"; + + if (send (sock, str, strlen (str), 0) < 0) + error (1, 0, "cannot send: %s", SOCK_STRERROR (SOCK_ERRNO)); + + sprintf (buf, "cvs@%s", hostinfo->h_name); + tok_in.length = strlen (buf); + tok_in.value = buf; + gss_import_name (&stat_min, &tok_in, gss_nt_service_name, &server_name); + + tok_in_ptr = GSS_C_NO_BUFFER; + gcontext = GSS_C_NO_CONTEXT; + + do + { + stat_maj = gss_init_sec_context (&stat_min, GSS_C_NO_CREDENTIAL, + &gcontext, server_name, + GSS_C_NULL_OID, + (GSS_C_MUTUAL_FLAG + | GSS_C_REPLAY_FLAG), + 0, NULL, tok_in_ptr, NULL, &tok_out, + NULL, NULL); + if (stat_maj != GSS_S_COMPLETE && stat_maj != GSS_S_CONTINUE_NEEDED) + { + OM_uint32 message_context; + + message_context = 0; + gss_display_status (&stat_min, stat_maj, GSS_C_GSS_CODE, + GSS_C_NULL_OID, &message_context, &tok_out); + error (1, 0, "GSSAPI authentication failed: %s", + (char *) tok_out.value); + } + + if (tok_out.length == 0) + { + tok_in.length = 0; + } + else + { + char cbuf[2]; + int need; + + cbuf[0] = (tok_out.length >> 8) & 0xff; + cbuf[1] = tok_out.length & 0xff; + if (send (sock, cbuf, 2, 0) < 0) + error (1, 0, "cannot send: %s", SOCK_STRERROR (SOCK_ERRNO)); + if (send (sock, tok_out.value, tok_out.length, 0) < 0) + error (1, 0, "cannot send: %s", SOCK_STRERROR (SOCK_ERRNO)); + + recv_bytes (sock, cbuf, 2); + need = ((cbuf[0] & 0xff) << 8) | (cbuf[1] & 0xff); + assert (need <= sizeof buf); + recv_bytes (sock, buf, need); + tok_in.length = need; + } + + tok_in.value = buf; + tok_in_ptr = &tok_in; + } + while (stat_maj == GSS_S_CONTINUE_NEEDED); + + return 1; } -#endif /* HAVE_KERBEROS */ +#endif /* HAVE_GSSAPI */ static int send_variable_proc PROTO ((Node *, void *)); @@ -3598,7 +3909,7 @@ start_server () case pserver_method: /* Toss the return value. It will die with error if anything goes wrong anyway. */ - connect_to_pserver (&tofd, &fromfd, 0); + connect_to_pserver (&tofd, &fromfd, 0, 0); break; #endif @@ -3608,6 +3919,13 @@ start_server () break; #endif +#if HAVE_GSSAPI + case gserver_method: + /* GSSAPI authentication is handled by the pserver. */ + connect_to_pserver (&tofd, &fromfd, 0, 1); + break; +#endif + case ext_method: #if defined (NO_EXT_METHOD) error (0, 0, ":ext: method not supported by this port of CVS"); @@ -3702,6 +4020,9 @@ the :server: access method is not supported by this port of CVS"); exactly what was transmitted and received (that is more important than that they be maximally convenient to view). */ + /* Note that if we create several connections in a single CVS client + (currently used by update.c), then the last set of logfiles will + overwrite the others. There is currently no way around this. */ strcpy (p, ".in"); fp = open_file (buf, "wb"); if (fp == NULL) @@ -3839,6 +4160,7 @@ the :server: access method is not supported by this port of CVS"); "This server does not support the global -l option."); } } + if (cvsencrypt) { #ifdef ENCRYPTION @@ -3862,11 +4184,28 @@ the :server: access method is not supported by this port of CVS"); } else #endif /* HAVE_KERBEROS */ - error (1, 0, "Encryption is only supported when using Kerberos"); +#ifdef HAVE_GSSAPI + if (CVSroot_method == gserver_method) + { + if (! supported_request ("Gssapi-encrypt")) + error (1, 0, "This server does not support encryption"); + send_to_server ("Gssapi-encrypt\012", 0); + to_server = cvs_gssapi_wrap_buffer_initialize (to_server, 0, + gcontext, + buf_memory_error); + from_server = cvs_gssapi_wrap_buffer_initialize (from_server, 1, + gcontext, + buf_memory_error); + cvs_gssapi_encrypt = 1; + } + else +#endif /* HAVE_GSSAPI */ + error (1, 0, "Encryption is only supported when using GSSAPI or Kerberos"); #else /* ! ENCRYPTION */ error (1, 0, "This client does not support encryption"); #endif /* ! ENCRYPTION */ } + if (gzip_level) { if (supported_request ("Gzip-stream")) @@ -3909,6 +4248,34 @@ the :server: access method is not supported by this port of CVS"); } } + if (cvsauthenticate && ! cvsencrypt) + { + /* Turn on authentication after turning on compression, so + that we can compress the authentication information. We + assume that encrypted data is always authenticated--the + ability to decrypt the data stream is itself a form of + authentication. */ +#ifdef HAVE_GSSAPI + if (CVSroot_method == gserver_method) + { + if (! supported_request ("Gssapi-authenticate")) + error (1, 0, + "This server does not support stream authentication"); + send_to_server ("Gssapi-authenticate\012", 0); + to_server = cvs_gssapi_wrap_buffer_initialize (to_server, 0, + gcontext, + buf_memory_error); + from_server = cvs_gssapi_wrap_buffer_initialize (from_server, 1, + gcontext, + buf_memory_error); + } + else + error (1, 0, "Stream authentication is only supported when using GSSAPI"); +#else /* ! HAVE_GSSAPI */ + error (1, 0, "This client does not support stream authentication"); +#endif /* ! HAVE_GSSAPI */ + } + #ifdef FILENAMES_CASE_INSENSITIVE if (supported_request ("Case")) send_to_server ("Case\012", 0); @@ -4138,7 +4505,7 @@ send_modified (file, short_pathname, vers) int fd; char *buf; char *mode_string; - int bufsize; + size_t bufsize; int bin; if (trace) @@ -4191,106 +4558,15 @@ send_modified (file, short_pathname, vers) if (file_gzip_level && sb.st_size > 100) { - int nread, newsize = 0, gzip_status; - pid_t gzip_pid; - char *bufp = buf; - int readsize = 8192; -#ifdef LINES_CRLF_TERMINATED - char *tempfile; - int converting; -#endif /* LINES_CRLF_TERMINATED */ - -#ifdef LINES_CRLF_TERMINATED - if (vers == NULL) - /* "Can't happen". */ - converting = 1; - else - /* Otherwise, we convert things unless they're binary. */ - converting = (! bin); - - if (converting) - { - /* gzip reads and writes files without munging CRLF - sequences, as it should, but files should be - transmitted in LF form. Convert CRLF to LF before - gzipping, on systems where this is necessary. - - If Windows NT supported fork, we could do this by - pushing another filter on in front of gzip. But it - doesn't. I'd have to write a trivial little program to - do the conversion and have CVS spawn it off. But - little executables like that always get lost. - - Alternatively, this cruft could go away if we switched - to a gzip library instead of a subprocess; then we - could tell gzip to open the file with CRLF translation - enabled. */ - if (close (fd) < 0) - error (0, errno, "warning: can't close %s", short_pathname); - - tempfile = cvs_temp_name (); - convert_file (file, O_RDONLY, - tempfile, - O_WRONLY | O_CREAT | O_TRUNC | OPEN_BINARY); - - /* This OPEN_BINARY doesn't make any difference, I think, because - gzip will deal with the inherited handle as it pleases. But I - do remember something obscure in the manuals about propagating - the translation mode to created processes via environment - variables, ick. */ - fd = CVS_OPEN (tempfile, O_RDONLY | OPEN_BINARY); - if (fd < 0) - error (1, errno, "reading %s", short_pathname); - } -#endif /* LINES_CRLF_TERMINATED */ + size_t newsize = 0; - fd = filter_through_gzip (fd, 1, file_gzip_level, &gzip_pid); + read_and_gzip (fd, short_pathname, (unsigned char **)&buf, + &bufsize, &newsize, + file_gzip_level); - /* FIXME: is there any reason to go through all this realloc'ing - when we could just be writing the data to the network as we read - it from gzip? */ - while (1) - { - if ((bufp - buf) + readsize >= bufsize) - { - /* - * We need to expand the buffer if gzip ends up expanding - * the file. - */ - newsize = bufp - buf; - while (newsize + readsize >= bufsize) - bufsize *= 2; - buf = xrealloc (buf, bufsize); - bufp = buf + newsize; - } - nread = read (fd, bufp, readsize); - if (nread < 0) - error (1, errno, "reading from gzip pipe"); - else if (nread == 0) - /* eof */ - break; - bufp += nread; - } - newsize = bufp - buf; if (close (fd) < 0) error (0, errno, "warning: can't close %s", short_pathname); - if (waitpid (gzip_pid, &gzip_status, 0) != gzip_pid) - error (1, errno, "waiting for gzip proc %ld", (long) gzip_pid); - else if (gzip_status != 0) - error (1, errno, "gzip exited %d", gzip_status); - -#if LINES_CRLF_TERMINATED - if (converting) - { - if ( CVS_UNLINK (tempfile) < 0) - error (0, errno, - "warning: can't remove temp file %s", tempfile); - free (tempfile); - tempfile = NULL; - } -#endif /* LINES_CRLF_TERMINATED */ - { char tmp[80]; @@ -4401,24 +4677,26 @@ send_fileproc (callerdat, finfo) if (vers->vn_user != NULL) { - char *tmp; - - tmp = xmalloc (strlen (filename) + strlen (vers->vn_user) - + strlen (vers->options) + 200); - sprintf (tmp, "Entry /%s/%s/%s%s/%s/", - filename, vers->vn_user, - vers->ts_conflict == NULL ? "" : "+", - (vers->ts_conflict == NULL ? "" - : (vers->ts_user != NULL && - strcmp (vers->ts_conflict, vers->ts_user) == 0 - ? "=" - : "modified")), - vers->options); - /* The Entries request. */ - /* Not sure about whether this deals with -k and stuff right. */ - send_to_server (tmp, 0); - free (tmp); + send_to_server ("Entry /", 0); + send_to_server (filename, 0); + send_to_server ("/", 0); + send_to_server (vers->vn_user, 0); + send_to_server ("/", 0); + if (vers->ts_conflict != NULL) + { + if (vers->ts_user != NULL && + strcmp (vers->ts_conflict, vers->ts_user) == 0) + send_to_server ("+=", 0); + else + send_to_server ("+modified", 0); + } + send_to_server ("/", 0); + send_to_server (vers->entdata != NULL + ? vers->entdata->options + : vers->options, + 0); + send_to_server ("/", 0); if (vers->entdata != NULL && vers->entdata->tag) { send_to_server ("T", 0); @@ -4431,6 +4709,41 @@ send_fileproc (callerdat, finfo) } send_to_server ("\012", 1); } + else + { + /* It seems a little silly to re-read this on each file, but + send_dirent_proc doesn't get called if filenames are specified + explicitly on the command line. */ + wrap_add_file (CVSDOTWRAPPER, 1); + + if (wrap_name_has (filename, WRAP_RCSOPTION)) + { + /* No "Entry", but the wrappers did give us a kopt so we better + send it with "Kopt". As far as I know this only happens + for "cvs add". Question: is there any reason why checking + for options from wrappers isn't done in Version_TS? + + Note: it might have been better to just remember all the + kopts on the client side, rather than send them to the server, + and have it send us back the same kopts. But that seemed like + a bigger change than I had in mind making now. */ + + if (supported_request ("Kopt")) + { + char *opt; + + send_to_server ("Kopt ", 0); + opt = wrap_rcsoption (filename, 1); + send_to_server (opt, 0); + send_to_server ("\012", 1); + free (opt); + } + else + error (0, 0, + "\ +warning: ignoring -k options due to server limitations"); + } + } if (vers->ts_user == NULL) { @@ -4540,7 +4853,6 @@ send_dirent_proc (callerdat, dir, repository, update_dir, entries) struct send_data *args = (struct send_data *) callerdat; int dir_exists; char *cvsadm_name; - char *cvsadm_repos_name; if (ignore_directory (update_dir)) { @@ -4571,9 +4883,7 @@ send_dirent_proc (callerdat, dir, repository, update_dir, entries) * newly-created directory), the server still needs to know about it. */ - cvsadm_repos_name = xmalloc (strlen (dir) + sizeof (CVSADM_REP) + 80); - sprintf (cvsadm_repos_name, "%s/%s", dir, CVSADM_REP); - if (dir_exists && isreadable (cvsadm_repos_name)) + if (dir_exists) { /* * Get the repository from a CVS/Repository file whenever possible. @@ -4586,14 +4896,23 @@ send_dirent_proc (callerdat, dir, repository, update_dir, entries) } else { + /* It doesn't make sense to send a non-existent directory, + because there is no way to get the correct value for + the repository (I suppose maybe via the expand-modules + request). In the case where the "obvious" choice for + repository is correct, the server can figure out whether + to recreate the directory; in the case where it is wrong + (that is, does not match what modules give us), we might as + well just fail to recreate it. + + Checking for noexec is a kludge for "cvs -n add dir". */ /* Don't send a non-existent directory unless we are building new directories (build_dirs is true). Otherwise, CVS may see a D line in an Entries file, and recreate a directory which the user removed by hand. */ - if (dir_exists || args->build_dirs) + if (args->build_dirs && noexec) send_a_repository (dir, repository, update_dir); } - free (cvsadm_repos_name); return (dir_exists ? R_PROCESS : R_SKIP_ALL); } @@ -4862,6 +5181,18 @@ client_process_import_file (message, vfile, vtag, targc, targv, repository, { vers.options = wrap_rcsoption (vfile, 1); } + if (vers.options != NULL) + { + if (supported_request ("Kopt")) + { + send_to_server ("Kopt ", 0); + send_to_server (vers.options, 0); + send_to_server ("\012", 1); + } + else + error (0, 0, + "warning: ignoring -k options due to server limitations"); + } send_modified (vfile, fullname, &vers); if (vers.options != NULL) free (vers.options); @@ -4905,7 +5236,10 @@ notified_a_file (data, ent_list, short_pathname, filename) fp = open_file (CVSADM_NOTIFY, "r"); if (getline (&line, &line_len, fp) < 0) { - error (0, errno, "cannot read %s", CVSADM_NOTIFY); + if (feof (fp)) + error (0, 0, "cannot read %s: end of file", CVSADM_NOTIFY); + else + error (0, errno, "cannot read %s", CVSADM_NOTIFY); goto error_exit; } cp = strchr (line, '\t'); @@ -5060,11 +5394,6 @@ client_senddate (date) error (1, 0, "diff_client_senddate: sscanf failed on date"); } -#ifndef HAVE_RCS5 - /* We need to fix the timezone in this case; see Make_Date. */ - abort (); -#endif /* HAVE_RCS5 */ - sprintf (buf, "%d/%d/%d %d:%d:%d GMT", month, day, year, hour, minute, second); option_with_arg ("-D", buf); diff --git a/contrib/cvs/src/client.h b/contrib/cvs/src/client.h index 1f9c27f..7097ea8 100644 --- a/contrib/cvs/src/client.h +++ b/contrib/cvs/src/client.h @@ -11,9 +11,14 @@ extern int filter_through_gunzip PROTO((int, int, pid_t *)); #if defined (CLIENT_SUPPORT) || defined (SERVER_SUPPORT) +/* Whether the connection should be encrypted. */ extern int cvsencrypt; +/* Whether the connection should use per-packet authentication. */ +extern int cvsauthenticate; + #ifdef ENCRYPTION + #ifdef HAVE_KERBEROS /* We can't declare the arguments without including krb.h, and I don't @@ -21,8 +26,24 @@ extern int cvsencrypt; extern struct buffer *krb_encrypt_buffer_initialize (); #endif /* HAVE_KERBEROS */ + +#ifdef HAVE_GSSAPI + +/* Set this to turn on GSSAPI encryption. */ +extern int cvs_gssapi_encrypt; + +#endif /* HAVE_GSSAPI */ + #endif /* ENCRYPTION */ +#ifdef HAVE_GSSAPI + +/* We can't declare the arguments without including gssapi.h, and I + don't want to do that in every file. */ +extern struct buffer *cvs_gssapi_wrap_buffer_initialize (); + +#endif /* HAVE_GSSAPI */ + #endif /* defined (CLIENT_SUPPORT) || defined (SERVER_SUPPORT) */ #ifdef CLIENT_SUPPORT @@ -37,13 +58,14 @@ extern int client_prune_dirs; #ifdef AUTH_CLIENT_SUPPORT extern int use_authenticating_server; -int connect_to_pserver PROTO((int *tofdp, int* fromfdp, int verify_only)); +void connect_to_pserver PROTO ((int *tofdp, int* fromfdp, int verify_only, + int do_gssapi)); # ifndef CVS_AUTH_PORT # define CVS_AUTH_PORT 2401 # endif /* CVS_AUTH_PORT */ #endif /* AUTH_CLIENT_SUPPORT */ -#ifdef AUTH_SERVER_SUPPORT +#if defined (AUTH_SERVER_SUPPORT) || (defined (SERVER_SUPPORT) && defined (HAVE_GSSAPI)) extern void pserver_authenticate_connection PROTO ((void)); #endif @@ -98,6 +120,8 @@ send_arg PROTO((char *string)); void send_option_string PROTO((char *string)); +extern void send_a_repository PROTO ((char *, char *, char *)); + #endif /* CLIENT_SUPPORT */ /* diff --git a/contrib/cvs/src/commit.c b/contrib/cvs/src/commit.c index c43e35f..a7fec5f 100644 --- a/contrib/cvs/src/commit.c +++ b/contrib/cvs/src/commit.c @@ -3,7 +3,7 @@ * Copyright (c) 1989-1992, Brian Berliner * * You may distribute under the terms of the GNU General Public License as - * specified in the README file that comes with the CVS 1.4 kit. + * specified in the README file that comes with the CVS source distribution. * * Commit Files * @@ -92,6 +92,7 @@ static const char *const commit_usage[] = "\t-F file\tRead the log message from file.\n", "\t-m msg\tLog message.\n", "\t-r rev\tCommit to this branch or trunk revision.\n", + "(Specify the --help global option for a list of other help options)\n", NULL }; @@ -144,8 +145,22 @@ find_dirent_proc (callerdat, dir, repository, update_dir, entries) { struct find_data *find_data = (struct find_data *)callerdat; + /* This check seems to slowly be creeping throughout CVS (update + and send_dirent_proc by CVS 1.5, diff in 31 Oct 1995. My guess + is that it (or some variant thereof) should go in all the + dirent procs. Unless someone has some better idea... */ + if (!isdir (dir)) + return (R_SKIP_ALL); + /* initialize the ignore list for this directory */ find_data->ignlist = getlist (); + + /* Print the same warm fuzzy as in check_direntproc, since that + code will never be run during client/server operation and we + want the messages to match. */ + if (!quiet) + error (0, 0, "Examining %s", update_dir); + return R_PROCESS; } @@ -232,7 +247,7 @@ find_fileproc (callerdat, finfo) xfinfo.repository = NULL; xfinfo.rcs = NULL; - vers = Version_TS (&xfinfo, NULL, NULL, NULL, 0, 0); + vers = Version_TS (&xfinfo, NULL, tag, NULL, 0, 0); if (vers->ts_user == NULL && vers->vn_user != NULL && vers->vn_user[0] == '-') @@ -246,8 +261,8 @@ find_fileproc (callerdat, finfo) if (vers->ts_user == NULL) error (0, 0, "nothing known about `%s'", finfo->fullname); else - error (0, 0, "use `cvs add' to create an entry for %s", - finfo->fullname); + error (0, 0, "use `%s add' to create an entry for %s", + program_name, finfo->fullname); return 1; } else if (vers->ts_user != NULL @@ -321,6 +336,9 @@ commit (argc, argv) * For log purposes, do not allow "root" to commit files. If you look * like root, but are really logged in as a non-root user, it's OK. */ + /* FIXME: Shouldn't this check be much more closely related to the + readonly user stuff (CVSROOT/readers, &c). That is, why should + root be able to "cvs init", "cvs import", &c, but not "cvs ci"? */ if (geteuid () == (uid_t) 0) { struct passwd *pw; @@ -342,9 +360,9 @@ commit (argc, argv) break; case 'm': #ifdef FORCE_USE_EDITOR - use_editor = TRUE; + use_editor = 1; #else - use_editor = FALSE; + use_editor = 0; #endif if (message) { @@ -371,9 +389,9 @@ commit (argc, argv) break; case 'F': #ifdef FORCE_USE_EDITOR - use_editor = TRUE; + use_editor = 1; #else - use_editor = FALSE; + use_editor = 0; #endif logfile = optarg; break; @@ -425,6 +443,7 @@ commit (argc, argv) #ifdef CLIENT_SUPPORT if (client_active) { + int err; struct find_data find_args; ign_setup (); @@ -489,6 +508,8 @@ commit (argc, argv) do_verify (message, (char *)NULL); /* We always send some sort of message, even if empty. */ + /* FIXME: is that true? There seems to be some code in do_editor + which can leave the message NULL. */ option_with_arg ("-m", message); /* OK, now process all the questionable files we have been saving @@ -553,14 +574,39 @@ commit (argc, argv) "cvs commit -r 2" across a whole bunch of files a very slow operation (and it isn't documented in cvsclient.texi). I haven't looked at the server code carefully enough to be - _sure_ why this is needed, but if it is because RCS_CI - wants the file to exist, then it would be relatively simple - (but not trivial) to fix in the server. */ + _sure_ why this is needed, but if it is because the "ci" + program, which we used to call, wanted the file to exist, + then it would be relatively simple to fix in the server. */ send_files (find_args.argc, find_args.argv, local, 0, find_args.force ? SEND_FORCE : 0); send_to_server ("ci\012", 0); - return get_responses_and_close (); + err = get_responses_and_close (); + if (err != 0 && use_editor && message != NULL) + { + /* If there was an error, don't nuke the user's carefully + constructed prose. This is something of a kludge; a better + solution is probably more along the lines of #150 in TODO + (doing a second up-to-date check before accepting the + log message has also been suggested, but that seems kind of + iffy because the real up-to-date check could still fail, + another error could occur, &c. Also, a second check would + slow things down). */ + + char *fname; + FILE *fp; + + fname = cvs_temp_name (); + fp = CVS_FOPEN (fname, "w+"); + if (fp == NULL) + error (1, 0, "cannot create temporary file %s", fname); + if (fwrite (message, 1, strlen (message), fp) != strlen (message)) + error (1, errno, "cannot write temporary file %s", fname); + if (fclose (fp) < 0) + error (0, errno, "cannot close temporary file %s", fname); + error (0, 0, "saving log message in %s", fname); + } + return err; } #endif @@ -633,7 +679,10 @@ classify_file_internal (finfo, vers) { int save_noexec, save_quiet, save_really_quiet; Ctype status; - + + /* FIXME: Do we need to save quiet as well as really_quiet? Last + time I glanced at Classify_File I only saw it looking at really_quiet + not quiet. */ save_noexec = noexec; save_quiet = quiet; save_really_quiet = really_quiet; @@ -817,16 +866,30 @@ check_fileproc (callerdat, finfo) if (file_has_markers (finfo)) { + /* Make this a warning, not an error, because we have + no way of knowing whether the "conflict indicators" + are really from a conflict or whether they are part + of the document itself (cvs.texinfo and sanity.sh in + CVS itself, for example, tend to want to have strings + like ">>>>>>>" at the start of a line). Making people + kludge this the way they need to kludge keyword + expansion seems undesirable. And it is worse than + keyword expansion, because there is no -ko + analogue. */ error (0, 0, - "file `%s' still contains conflict indicators", + "\ +warning: file `%s' seems to still contain conflict indicators", finfo->fullname); - freevers_ts (&vers); - return (1); } } if (status == T_REMOVED && vers->tag && isdigit (*vers->tag)) { + /* Remove also tries to forbid this, but we should check + here. I'm only _sure_ about somewhat obscure cases + (hacking the Entries file, using an old version of + CVS for the remove and a new one for the commit), but + there might be other cases. */ error (0, 0, "cannot remove file `%s' which has a numeric sticky tag of `%s'", finfo->fullname, vers->tag); @@ -946,7 +1009,8 @@ check_fileproc (callerdat, finfo) } /* - * Print warm fuzzies while examining the dirs + * By default, return the code that tells do_recursion to examine all + * directories */ /* ARGSUSED */ static Dtype @@ -957,6 +1021,9 @@ check_direntproc (callerdat, dir, repos, update_dir, entries) char *update_dir; List *entries; { + if (!isdir (dir)) + return (R_SKIP_ALL); + if (!quiet) error (0, 0, "Examining %s", update_dir); @@ -1013,7 +1080,8 @@ precommit_proc (repository, filter) free (s); } - run_setup ("%s %s", filter, repository); + run_setup (filter); + run_arg (repository); (void) walklist (ulist, precommit_list_proc, NULL); return (run_exec (RUN_TTY, RUN_TTY, RUN_TTY, RUN_NORMAL|RUN_REALLY)); } @@ -1333,7 +1401,8 @@ commit_filesdoneproc (callerdat, err, repository, update_dir, entries) if (line[line_length - 1] == '\n') line[--line_length] = '\0'; repository = Name_Repository ((char *) NULL, update_dir); - run_setup ("%s %s", line, repository); + run_setup (line); + run_arg (repository); cvs_output (program_name, 0); cvs_output (" ", 1); cvs_output (command_name, 0); @@ -1365,7 +1434,7 @@ commit_filesdoneproc (callerdat, err, repository, update_dir, entries) } /* - * Get the log message for a dir and print a warm fuzzy + * Get the log message for a dir */ /* ARGSUSED */ static Dtype @@ -1380,6 +1449,9 @@ commit_direntproc (callerdat, dir, repos, update_dir, entries) List *ulist; char *real_repos; + if (!isdir (dir)) + return (R_SKIP_ALL); + /* find the update list for this dir */ p = findnode (mulist, update_dir); if (p != NULL) @@ -1391,10 +1463,6 @@ commit_direntproc (callerdat, dir, repos, update_dir, entries) if (ulist == NULL || ulist->list->next == ulist->list) return (R_SKIP_FILES); - /* print the warm fuzzy */ - if (!quiet) - error (0, 0, "Committing %s", update_dir); - /* get commit message */ real_repos = Name_Repository (dir, update_dir); got_message = 1; @@ -1489,10 +1557,10 @@ remove_file (finfo, tag, message) error (1, 0, "internal error: no parsed RCS file"); branch = 0; - if (tag && !(branch = RCS_isbranch (finfo->rcs, tag))) + if (tag && !(branch = RCS_nodeisbranch (finfo->rcs, tag))) { /* a symbolic tag is specified; just remove the tag from the file */ - if ((retcode = RCS_deltag (finfo->rcs, tag, 1)) != 0) + if ((retcode = RCS_deltag (finfo->rcs, tag)) != 0) { if (!quiet) error (0, retcode == -1 ? errno : 0, @@ -1500,6 +1568,7 @@ remove_file (finfo, tag, message) finfo->fullname); return (1); } + RCS_rewrite (finfo->rcs, NULL, NULL); Scratch_Entry (finfo->entries, finfo->file); return (0); } @@ -1556,6 +1625,7 @@ remove_file (finfo, tag, message) finfo->fullname); return (1); } + RCS_rewrite (finfo->rcs, NULL, NULL); } #ifdef SERVER_SUPPORT @@ -1584,12 +1654,15 @@ remove_file (finfo, tag, message) /* Except when we are creating a branch, lock the revision so that we can check in the new revision. */ if (lockflag) - RCS_lock (finfo->rcs, rev ? corev : NULL, 0); + { + if (RCS_lock (finfo->rcs, rev ? corev : NULL, 1) == 0) + RCS_rewrite (finfo->rcs, NULL, NULL); + } if (corev != NULL) free (corev); - retcode = RCS_checkin (finfo->rcs->path, finfo->file, message, rev, + retcode = RCS_checkin (finfo->rcs, finfo->file, message, rev, RCS_FLAGS_DEAD | RCS_FLAGS_QUIET); if (retcode != 0) { @@ -1690,6 +1763,8 @@ unlockrcs (rcs) if ((retcode = RCS_unlock (rcs, NULL, 0)) != 0) error (retcode == -1 ? 1 : 0, retcode == -1 ? errno : 0, "could not unlock %s", rcs->path); + else + RCS_rewrite (rcs, NULL, NULL); } /* @@ -1730,6 +1805,7 @@ fixbranch (rcs, branch) if ((retcode = RCS_setbranch (rcs, branch)) != 0) error (retcode == -1 ? 1 : 0, retcode == -1 ? errno : 0, "cannot restore branch to %s for %s", branch, rcs->path); + RCS_rewrite (rcs, NULL, NULL); } } @@ -1841,29 +1917,63 @@ internal error: `%s' didn't move out of the attic", { /* this is the first time we have ever seen this file; create an rcs file. */ - run_setup ("%s%s -x,v/ -i", Rcsbin, RCS); + char *desc; + size_t descalloc; + size_t desclen; + + char *opt; + + desc = NULL; + descalloc = 0; + desclen = 0; fname = xmalloc (strlen (file) + sizeof (CVSADM) + sizeof (CVSEXT_LOG) + 10); (void) sprintf (fname, "%s/%s%s", CVSADM, file, CVSEXT_LOG); /* If the file does not exist, no big deal. In particular, the server does not (yet at least) create CVSEXT_LOG files. */ if (isfile (fname)) - run_args ("-t%s/%s%s", CVSADM, file, CVSEXT_LOG); + /* FIXME: Should be including update_dir in the appropriate + place here. */ + get_file (fname, fname, "r", &desc, &descalloc, &desclen); free (fname); + /* From reading the RCS 5.7 source, "rcs -i" adds a newline to the + end of the log message if the message is nonempty. + Do it. RCS also deletes certain whitespace, in cleanlogmsg, + which we don't try to do here. */ + if (desclen > 0) + { + expand_string (&desc, &descalloc, desclen + 1); + desc[desclen++] = '\012'; + } + /* Set RCS keyword expansion options. */ if (options && options[0] == '-' && options[1] == 'k') - run_arg (options); - run_arg (rcs); - if ((retcode = run_exec (RUN_TTY, RUN_TTY, RUN_TTY, RUN_NORMAL)) != 0) + opt = options + 2; + else + opt = NULL; + + /* This message is an artifact of the time when this + was implemented via "rcs -i". It should be revised at + some point (does the "initial revision" in the message from + RCS_checkin indicate that this is a new file? Or does the + "RCS file" message serve some function?). */ + cvs_output ("RCS file: ", 0); + cvs_output (rcs, 0); + cvs_output ("\ndone\n", 0); + + if (add_rcs_file (NULL, rcs, file, NULL, opt, + NULL, NULL, 0, NULL, + desc, desclen, NULL) != 0) { - error (retcode == -1 ? 1 : 0, retcode == -1 ? errno : 0, - "could not create %s", rcs); retval = 1; goto out; } + rcsfile = RCS_parsercsfile (rcs); newfile = 1; + if (desc != NULL) + free (desc); } /* when adding a file for the first time, and using a tag, we need @@ -1883,7 +1993,7 @@ internal error: `%s' didn't move out of the attic", /* commit a dead revision. */ (void) sprintf (tmp, "file %s was initially added on branch %s.", file, tag); - retcode = RCS_checkin (rcs, NULL, tmp, NULL, + retcode = RCS_checkin (rcsfile, NULL, tmp, NULL, RCS_FLAGS_DEAD | RCS_FLAGS_QUIET); free (tmp); if (retcode != 0) @@ -1898,7 +2008,8 @@ internal error: `%s' didn't move out of the attic", rename_file (fname, file); free (fname); - assert (rcsfile == NULL); + /* double-check that the file was written correctly */ + freercsnode (&rcsfile); rcsfile = RCS_parse (file, repository); if (rcsfile == NULL) { @@ -1952,6 +2063,7 @@ internal error: `%s' didn't move out of the attic", magicrev = RCS_magicrev (rcsfile, head); retcode = RCS_settag (rcsfile, tag, magicrev); + RCS_rewrite (rcsfile, NULL, NULL); free (head); free (magicrev); @@ -1984,7 +2096,14 @@ internal error: `%s' didn't move out of the attic", fileattr_newfile (file); + /* I don't think fix_rcs_modes is needed any more. In the + add_rcs_file case, the algorithms used by add_rcs_file and + fix_rcs_modes are the same, so there is no need to go through + it all twice. In the other cases, I think we want to just + preserve the mode that the file had before we started. That is + a behavior change, but I would think a desirable one. */ fix_rcs_modes (rcs, file); + retval = 0; out: @@ -2031,12 +2150,13 @@ lock_RCS (user, rcs, rev, repository) return (1); } } - err = RCS_lock(rcs, NULL, 0); + err = RCS_lock(rcs, NULL, 1); } else { (void) RCS_lock(rcs, rev, 1); } + RCS_rewrite (rcs, NULL, NULL); if (err == 0) { diff --git a/contrib/cvs/src/create_adm.c b/contrib/cvs/src/create_adm.c index 0ef6e57..c1772b2 100644 --- a/contrib/cvs/src/create_adm.c +++ b/contrib/cvs/src/create_adm.c @@ -3,7 +3,7 @@ * Copyright (c) 1989-1992, Brian Berliner * * You may distribute under the terms of the GNU General Public License as - * specified in the README file that comes with the CVS 1.4 kit. + * specified in the README file that comes with the CVS source distribution. * * Create Administration. * @@ -13,35 +13,41 @@ #include "cvs.h" -/* update_dir includes dir as its last component. */ +/* update_dir includes dir as its last component. -void -Create_Admin (dir, update_dir, repository, tag, date, nonbranch) + Return value is 0 for success, or 1 if we printed a warning message. + Note that many errors are still fatal; particularly for unlikely errors + a fatal error is probably better than a warning which might be missed + or after which CVS might do something non-useful. If WARN is zero, then + don't print warnings; all errors are fatal then. */ + +int +Create_Admin (dir, update_dir, repository, tag, date, nonbranch, warn) char *dir; char *update_dir; char *repository; char *tag; char *date; int nonbranch; + int warn; { FILE *fout; char *cp; + char *reposcopy; char *tmp; #ifdef SERVER_SUPPORT if (trace) { - char *wd = xgetwd (); - fprintf (stderr, "%c-> Create_Admin (%s, %s, %s, %s, %s) in %s\n", + fprintf (stderr, "%c-> Create_Admin (%s, %s, %s, %s, %s, %d, %d)\n", (server_active) ? 'S' : ' ', - dir, update_dir, repository, tag ? tag : "", - date ? date : "", wd); - free (wd); + dir, update_dir, repository, tag ? tag : "", + date ? date : "", nonbranch, warn); } #endif if (noexec) - return; + return 0; tmp = xmalloc (strlen (dir) + 100); if (dir != NULL) @@ -51,7 +57,21 @@ Create_Admin (dir, update_dir, repository, tag, date, nonbranch) if (isfile (tmp)) error (1, 0, "there is a version in %s already", update_dir); - make_directory (tmp); + if (CVS_MKDIR (tmp, 0777) < 0) + { + if (warn) + { + /* The reason that this is a warning, rather than silently + just skipping creating the directory, is that we don't want + CVS's behavior to vary subtly based on factors (like directory + permissions) which are not made clear to the user. With + the warning at least we let them know what is going on. */ + error (0, errno, "warning: cannot make directory %s", tmp); + return 1; + } + else + error (1, errno, "cannot make directory %s", tmp); + } /* record the current cvs root for later use */ @@ -68,8 +88,22 @@ Create_Admin (dir, update_dir, repository, tag, date, nonbranch) else error (1, errno, "cannot open %s/%s", update_dir, CVSADM_REP); } - cp = repository; - strip_trailing_slashes (cp); + reposcopy = xstrdup (repository); + Sanitize_Repository_Name (reposcopy); + + /* The top level of the repository is a special case -- we need to + write it with an extra dot at the end. This trailing `.' stuff + rubs me the wrong way -- on the other hand, I don't want to + spend the time making sure all of the code can handle it if we + don't do it. */ + + if (strcmp (reposcopy, CVSroot_directory) == 0) + { + reposcopy = xrealloc (reposcopy, strlen (reposcopy) + 3); + strcat (reposcopy, "/."); + } + + cp = reposcopy; #ifdef RELATIVE_REPOS /* @@ -81,8 +115,8 @@ Create_Admin (dir, update_dir, repository, tag, date, nonbranch) char *path = xmalloc (strlen (CVSroot_directory) + 10); (void) sprintf (path, "%s/", CVSroot_directory); - if (strncmp (repository, path, strlen (path)) == 0) - cp = repository + strlen (path); + if (strncmp (cp, path, strlen (path)) == 0) + cp += strlen (path); free (path); } #endif @@ -139,5 +173,7 @@ Create_Admin (dir, update_dir, repository, tag, date, nonbranch) } #endif + free (reposcopy); free (tmp); + return 0; } diff --git a/contrib/cvs/src/cvs.h b/contrib/cvs/src/cvs.h index 80bb468..b243e88 100644 --- a/contrib/cvs/src/cvs.h +++ b/contrib/cvs/src/cvs.h @@ -127,6 +127,8 @@ extern int errno; #define CVSADM_NOTIFY "CVS/Notify." #define CVSADM_NOTIFYTMP "CVS/Notify.tmp" #define CVSADM_BASE "CVS/Base" +#define CVSADM_BASEREV "CVS/Baserev." +#define CVSADM_BASEREVTMP "CVS/Baserev.tmp" #define CVSADM_TEMPLATE "CVS/Template." #else /* USE_VMS_FILENAMES */ #define CVSADM "CVS" @@ -144,6 +146,8 @@ extern int errno; /* A directory in which we store base versions of files we currently are editing with "cvs edit". */ #define CVSADM_BASE "CVS/Base" +#define CVSADM_BASEREV "CVS/Baserev" +#define CVSADM_BASEREVTMP "CVS/Baserev.tmp" /* File which contains the template for use in log messages. */ #define CVSADM_TEMPLATE "CVS/Template" #endif /* USE_VMS_FILENAMES */ @@ -182,6 +186,7 @@ extern int errno; #define CVSROOTADM_READERS "readers" #define CVSROOTADM_WRITERS "writers" #define CVSROOTADM_PASSWD "passwd" +#define CVSROOTADM_CONFIG "config" #define CVSNULLREPOS "Emptydir" /* an empty directory */ @@ -206,11 +211,10 @@ extern int errno; /* Command attributes -- see function lookup_command_attribute(). */ #define CVS_CMD_IGNORE_ADMROOT 1 -/* Set if CVS does _not_ need to create a CVS/Root file upon - completion of this command. The name is confusing, both because - the meaning is closer to "does not use working directory" than - "uses working directory" and because the flag isn't really as - general purpose as it seems (cvs release sets it). */ +/* Set if CVS needs to create a CVS/Root file upon completion of this + command. The name may be slightly confusing, because the flag + isn't really as general purpose as it seems (it is not set for cvs + release). */ #define CVS_CMD_USES_WORK_DIR 2 @@ -240,9 +244,6 @@ extern int errno; #endif #endif /* USE_VMS_FILENAMES */ -#define FALSE 0 -#define TRUE 1 - /* * Special tags. -rHEAD refers to the head of an RCS file, regardless of any * sticky tags. -rBASE refers to the current revision the user has checked @@ -253,10 +254,7 @@ extern int errno; /* Environment variable used by CVS */ #define CVSREAD_ENV "CVSREAD" /* make files read-only */ -#define CVSREAD_DFLT FALSE /* writable files by default */ - -#define RCSBIN_ENV "RCSBIN" /* RCS binary directory */ -/* #define RCSBIN_DFLT Set by options.h */ +#define CVSREAD_DFLT 0 /* writable files by default */ #define TMPDIR_ENV "TMPDIR" /* Temporary directory */ /* #define TMPDIR_DFLT Set by options.h */ @@ -300,8 +298,13 @@ struct entnode enum ent_type type; char *user; char *version; + + /* Timestamp, or "" if none (never NULL). */ char *timestamp; + + /* Keyword expansion options, or "" if none (never NULL). */ char *options; + char *tag; char *date; char *conflict; @@ -353,7 +356,7 @@ typedef enum direnter_type Dtype; #endif extern char *program_name, *program_path, *command_name; -extern char *Rcsbin, *Tmpdir, *Editor; +extern char *Tmpdir, *Editor; extern int cvsadmin_root; extern char *CurDir; extern int really_quiet, quiet; @@ -363,7 +366,8 @@ extern mode_t cvsumask; /* Access method specified in CVSroot. */ typedef enum { - local_method, server_method, pserver_method, kserver_method, ext_method + local_method, server_method, pserver_method, kserver_method, gserver_method, + ext_method } CVSmethod; extern char *method_names[]; /* change this in root.c if you change the enum above */ @@ -375,6 +379,8 @@ extern char *CVSroot_username; /* the username or NULL if method == local */ extern char *CVSroot_hostname; /* the hostname or NULL if method == local */ extern char *CVSroot_directory; /* the directory name */ +extern char *emptydir_name PROTO ((void)); + extern int trace; /* Show all commands */ extern int noexec; /* Don't modify disk anywhere */ extern int logoff; /* Don't write history entry */ @@ -389,20 +395,24 @@ extern char hostname[]; /* Externs that are included directly in the CVS sources */ -int RCS_exec_settag PROTO((const char *, const char *, const char *)); -int RCS_exec_deltag PROTO((const char *, const char *, int)); -int RCS_exec_setbranch PROTO((const char *, const char *)); -int RCS_exec_lock PROTO((const char *, const char *, int)); -int RCS_exec_unlock PROTO((const char *, const char *, int)); -int RCS_merge PROTO((const char *, const char *, const char *, const char *)); +int RCS_merge PROTO((RCSNode *, char *, char *, char *, char *, char *)); /* Flags used by RCS_* functions. See the description of the individual functions for which flags mean what for each function. */ #define RCS_FLAGS_FORCE 1 #define RCS_FLAGS_DEAD 2 #define RCS_FLAGS_QUIET 4 #define RCS_FLAGS_MODTIME 8 -int RCS_checkin PROTO ((char *rcsfile, char *workfile, char *message, - char *rev, int flags)); + +extern int RCS_exec_rcsdiff PROTO ((RCSNode *rcsfile, + char *opts, char *options, + char *rev1, char *rev2, + char *label1, char *label2, + char *workfile)); +extern int diff_exec PROTO ((char *file1, char *file2, char *options, + char *out)); +extern int diff_execv PROTO ((char *file1, char *file2, + char *label1, char *label2, + char *options, char *out)); @@ -416,9 +426,11 @@ List *Entries_Open PROTO((int aflag)); void Subdirs_Known PROTO((List *entries)); void Subdir_Register PROTO((List *, const char *, const char *)); void Subdir_Deregister PROTO((List *, const char *, const char *)); + char *Make_Date PROTO((char *rawdate)); char *Name_Repository PROTO((char *dir, char *update_dir)); - +char *Short_Repository PROTO((char *repository)); +void Sanitize_Repository_Name PROTO((char *repository)); char *Name_Root PROTO((char *dir, char *update_dir)); int parse_cvsroot PROTO((char *CVSroot)); @@ -428,9 +440,8 @@ void root_allow_add PROTO ((char *)); void root_allow_free PROTO ((void)); int root_allow_ok PROTO ((char *)); -int same_directories PROTO((char *dir1, char *dir2)); -char *Short_Repository PROTO((char *repository)); -char *gca PROTO((char *rev1, char *rev2)); +char *gca PROTO((const char *rev1, const char *rev2)); +extern void check_numeric PROTO ((const char *, int, char **)); char *getcaller PROTO((void)); char *time_stamp PROTO((char *file)); @@ -443,6 +454,8 @@ int pathname_levels PROTO ((char *path)); typedef int (*CALLPROC) PROTO((char *repository, char *value)); int Parse_Info PROTO((char *infofile, char *repository, CALLPROC callproc, int all)); +extern int parse_config PROTO ((char *)); + typedef RETSIGTYPE (*SIGCLEANUPPROC) PROTO(()); int SIG_register PROTO((int sig, SIGCLEANUPPROC sigcleanup)); int isdir PROTO((const char *file)); @@ -457,6 +470,8 @@ char *get_homedir PROTO ((void)); char *cvs_temp_name PROTO ((void)); int numdots PROTO((const char *s)); +char *increment_revnum PROTO ((const char *)); +int compare_revnums PROTO ((const char *, const char *)); int unlink_file PROTO((const char *f)); int link_file PROTO ((const char *from, const char *to)); int unlink_file_dir PROTO((const char *f)); @@ -465,9 +480,10 @@ int xcmp PROTO((const char *file1, const char *file2)); int yesno PROTO((void)); void *valloc PROTO((size_t bytes)); time_t get_date PROTO((char *date, struct timeb *now)); -void Create_Admin PROTO((char *dir, char *update_dir, - char *repository, char *tag, char *date, - int nonbranch)); +extern int Create_Admin PROTO ((char *dir, char *update_dir, + char *repository, char *tag, char *date, + int nonbranch, int warn)); +extern int expand_at_signs PROTO ((char *, off_t, FILE *)); /* Locking subsystem (implemented in lock.c). */ @@ -505,7 +521,7 @@ extern int ign_case; #include "update.h" -void line2argv PROTO ((int *pargc, char ***argv, char *line)); +void line2argv PROTO ((int *pargc, char ***argv, char *line, char *sepchars)); void make_directories PROTO((const char *name)); void make_directory PROTO((const char *name)); extern int mkdir_if_needed PROTO ((char *name)); @@ -542,7 +558,7 @@ void do_editor PROTO((char *dir, char **messagep, void do_verify PROTO((char *message, char *repository)); typedef int (*CALLBACKPROC) PROTO((int *pargc, char *argv[], char *where, - char *mwhere, char *mfile, int horten, int local_specified, + char *mwhere, char *mfile, int shorten, int local_specified, char *omodule, char *msg)); /* This is the structure that the recursion processor passes to the @@ -603,7 +619,9 @@ void SIG_endCrSect PROTO((void)); void read_cvsrc PROTO((int *argc, char ***argv, char *cmdname)); char *make_message_rcslegal PROTO((char *message)); -extern int file_has_markers PROTO ((struct file_info *)); +extern int file_has_markers PROTO ((const struct file_info *)); +extern void get_file PROTO ((const char *, const char *, const char *, + char **, size_t *, size_t *)); /* flags for run_exec(), the fast system() for CVS */ #define RUN_NORMAL 0x0000 /* no special behaviour */ @@ -616,14 +634,9 @@ extern int file_has_markers PROTO ((struct file_info *)); void run_arg PROTO((const char *s)); void run_print PROTO((FILE * fp)); -#ifdef HAVE_VPRINTF -void run_setup PROTO((const char *fmt,...)); -void run_args PROTO((const char *fmt,...)); -#else -void run_setup (); -void run_args (); -#endif -int run_exec PROTO((char *stin, char *stout, char *sterr, int flags)); +void run_setup PROTO ((const char *prog)); +int run_exec PROTO((const char *stin, const char *stout, const char *sterr, + int flags)); /* other similar-minded stuff from run.c. */ FILE *run_popen PROTO((const char *, const char *)); @@ -643,10 +656,16 @@ pid_t waitpid PROTO((pid_t, int *, int)); struct vers_ts { /* rcs version user file derives from, from CVS/Entries. - * it can have the following special values: - * empty = no user file - * 0 = user file is new - * -vers = user file to be removed. */ + It can have the following special values: + + NULL = file is not mentioned in Entries (this is also used for a + directory). + "" = ILLEGAL! The comment used to say that it meant "no user file" + but as far as I know CVS didn't actually use it that way. + Note that according to cvs.texinfo, "" is not legal in the + Entries file. + 0 = user file is new + -vers = user file to be removed. */ char *vn_user; /* Numeric revision number corresponding to ->vn_tag (->vn_tag @@ -669,7 +688,8 @@ struct vers_ts and if they differ it is modified. */ char *ts_rcs; - /* Options from CVS/Entries (keyword expansion). */ + /* Options from CVS/Entries (keyword expansion), malloc'd. If none, + then it is an empty string (never NULL). */ char *options; /* If non-NULL, there was a conflict (or merely a merge? See merge_file) @@ -708,6 +728,11 @@ int Checkin PROTO ((int type, struct file_info *finfo, char *rcs, char *rev, char *tag, char *options, char *message)); int No_Difference PROTO ((struct file_info *finfo, Vers_TS *vers)); +/* CVSADM_BASEREV stuff, from entries.c. */ +extern char *base_get PROTO ((struct file_info *)); +extern void base_register PROTO ((struct file_info *, char *)); +extern void base_deregister PROTO ((struct file_info *)); + /* * defines for Classify_File() to determine the current state of a file. * These are also used as types in the data field for the list we make for @@ -818,10 +843,13 @@ extern void tag_check_valid PROTO ((char *, int, char **, int, int, char *)); extern void tag_check_valid_join PROTO ((char *, int, char **, int, int, char *)); +/* From server.c and documented there. */ extern void cvs_output PROTO ((const char *, size_t)); +extern void cvs_output_binary PROTO ((char *, size_t)); extern void cvs_outerr PROTO ((const char *, size_t)); extern void cvs_flusherr PROTO ((void)); extern void cvs_flushout PROTO ((void)); +extern void cvs_output_tagged PROTO ((char *, char *)); #if defined(SERVER_SUPPORT) || defined(CLIENT_SUPPORT) #include "server.h" diff --git a/contrib/cvs/src/cvsbug.sh b/contrib/cvs/src/cvsbug.sh index fd6ae7c..ee3b7bb 100755 --- a/contrib/cvs/src/cvsbug.sh +++ b/contrib/cvs/src/cvsbug.sh @@ -28,7 +28,7 @@ SUBMITTER=net ## GNATS_ROOT=/usr/local/lib/gnats/gnats-db # The default mail address for PR submissions. -GNATS_ADDR=bug-cvs@prep.ai.mit.edu +GNATS_ADDR=bug-cvs@gnu.org ## # Where the gnats category tree lives. ## DATADIR=/usr/local/lib diff --git a/contrib/cvs/src/cvsrc.c b/contrib/cvs/src/cvsrc.c index 5e9cfa5..e35ec21 100644 --- a/contrib/cvs/src/cvsrc.c +++ b/contrib/cvs/src/cvsrc.c @@ -1,10 +1,10 @@ /* - * Copyright (c) 1993 david d zuhn - * - * written by david d `zoo' zuhn while at Cygnus Support - * - * You may distribute under the terms of the GNU General Public License - * as specified in the README file that comes with the CVS 1.4 kit. + * Copyright (c) 1993 david d zuhn + * + * Written by david d `zoo' zuhn while at Cygnus Support + * + * You may distribute under the terms of the GNU General Public License as + * specified in the README file that comes with the CVS source distribution. * */ @@ -103,6 +103,9 @@ read_cvsrc (argc, argv, cmdname) } } + if (line_length < 0 && !feof (cvsrcfile)) + error (0, errno, "cannot read %s", homeinit); + fclose (cvsrcfile); /* setup the new options list */ diff --git a/contrib/cvs/src/diff.c b/contrib/cvs/src/diff.c index 608a00f..a894c5b 100644 --- a/contrib/cvs/src/diff.c +++ b/contrib/cvs/src/diff.c @@ -3,7 +3,7 @@ * Copyright (c) 1989-1992, Brian Berliner * * You may distribute under the terms of the GNU General Public License as - * specified in the README file that comes with the CVS 1.4 kit. + * specified in the README file that comes with the CVS source distribution. * * Difference * @@ -43,6 +43,7 @@ static void diff_mark_errors PROTO((int err)); static char *diff_rev1, *diff_rev2; static char *diff_date1, *diff_date2; static char *use_rev1, *use_rev2; +static int have_rev1_label, have_rev2_label; /* Revision of the user file, if it is unchanged from something in the repository and we want to use that fact. */ @@ -71,6 +72,7 @@ static const char *const diff_usage[] = "\t--ifdef=arg\tOutput diffs in ifdef format.\n", "(consult the documentation for your diff program for rcsdiff-options.\n", "The most popular is -c for context diffs but there are many more).\n", + "(Specify the --help global option for a list of other help options)\n", NULL }; @@ -103,13 +105,13 @@ static struct option const longopts[] = { {"ignore-blank-lines", 0, 0, 'B'}, {"context", 2, 0, 143}, - {"ifdef", 1, 0, 147}, + {"ifdef", 1, 0, 131}, {"show-function-line", 1, 0, 'F'}, {"speed-large-files", 0, 0, 'H'}, {"ignore-matching-lines", 1, 0, 'I'}, {"label", 1, 0, 'L'}, {"new-file", 0, 0, 'N'}, - {"initial-tab", 0, 0, 'T'}, + {"initial-tab", 0, 0, 148}, {"width", 1, 0, 'W'}, {"text", 0, 0, 'a'}, {"ignore-space-change", 0, 0, 'b'}, @@ -130,7 +132,7 @@ static struct option const longopts[] = {"report-identical-files", 0, 0, 's'}, {"expand-tabs", 0, 0, 't'}, {"ignore-all-space", 0, 0, 'w'}, - {"side-by-side", 0, 0, 'y'}, + {"side-by-side", 0, 0, 147}, {"unified", 2, 0, 146}, {"left-column", 0, 0, 129}, {"suppress-common-lines", 0, 0, 130}, @@ -147,6 +149,37 @@ static struct option const longopts[] = {0, 0, 0, 0} }; +/* CVS 1.9 and similar versions seemed to have pretty weird handling + of -y and -T. In the cases where it called rcsdiff, + they would have the meanings mentioned below. In the cases where it + called diff, they would have the meanings mentioned in "longopts". + Noone seems to have missed them, so I think the right thing to do is + just to remove the options altogether (which I have done). + + In the case of -z and -q, "cvs diff" did not accept them even back + when we called rcsdiff (at least, it hasn't accepted them + recently). + + In comparing rcsdiff to the new CVS implementation, I noticed that + the following rcsdiff flags are not handled by CVS diff: + + -y: perform diff even when the requested revisions are the + same revision number + -q: run quietly + -T: preserve modification time on the RCS file + -z: specify timezone for use in file labels + + I think these are not really relevant. -y is undocumented even in + RCS 5.7, and seems like a minor change at best. According to RCS + documentation, -T only applies when a RCS file has been modified + because of lock changes; doesn't CVS sidestep RCS's entire lock + structure? -z seems to be unsupported by CVS diff, and has a + different meaning as a global option anyway. (Adding it could be + a feature, but if it is left out for now, it should not break + anything.) For the purposes of producing output, CVS diff appears + mostly to ignore -q. Maybe this should be fixed, but I think it's + a larger issue than the changes included here. */ + static void strcat_and_allocate PROTO ((char **, size_t *, const char *)); /* *STR is a pointer to a malloc'd string. *LENP is its allocated @@ -183,6 +216,8 @@ diff (argc, argv) if (argc == -1) usage (diff_usage); + have_rev1_label = have_rev2_label = 0; + /* * Note that we catch all the valid arguments here, so that we can * intercept the -r arguments for doing revision diffs; and -l/-R for a @@ -201,33 +236,44 @@ diff (argc, argv) optind = 0; while ((c = getopt_long (argc, argv, - "+abcdefhilnpstuwy0123456789BHNRTC:D:F:I:L:U:V:W:k:r:", + "+abcdefhilnpstuw0123456789BHNRC:D:F:I:L:U:V:W:k:r:", longopts, &option_index)) != -1) { switch (c) { case 'a': case 'b': case 'c': case 'd': case 'e': case 'f': case 'h': case 'i': case 'n': case 'p': case 's': case 't': - case 'u': case 'w': case 'y': case '0': case '1': case '2': + case 'u': case 'w': case '0': case '1': case '2': case '3': case '4': case '5': case '6': case '7': case '8': - case '9': case 'B': case 'H': case 'T': + case '9': case 'B': case 'H': (void) sprintf (tmp, " -%c", (char) c); strcat_and_allocate (&opts, &opts_allocated, tmp); break; - case 'C': case 'F': case 'I': case 'L': case 'U': case 'V': - case 'W': + case 'L': + if (have_rev1_label++) + if (have_rev2_label++) + { + error (0, 0, "extra -L arguments ignored"); + break; + } + + strcat_and_allocate (&opts, &opts_allocated, " -L"); + strcat_and_allocate (&opts, &opts_allocated, optarg); + break; + case 'C': case 'F': case 'I': case 'U': case 'V': case 'W': (void) sprintf (tmp, " -%c", (char) c); strcat_and_allocate (&opts, &opts_allocated, tmp); strcat_and_allocate (&opts, &opts_allocated, optarg); break; - case 147: + case 131: /* --ifdef. */ strcat_and_allocate (&opts, &opts_allocated, " -D"); strcat_and_allocate (&opts, &opts_allocated, optarg); break; - case 129: case 130: case 131: case 132: case 133: case 134: + case 129: case 130: case 132: case 133: case 134: case 135: case 136: case 137: case 138: case 139: case 140: case 141: case 142: case 143: case 144: case 145: case 146: + case 147: case 148: strcat_and_allocate (&opts, &opts_allocated, " --"); strcat_and_allocate (&opts, &opts_allocated, longopts[option_index].name); @@ -359,6 +405,11 @@ diff_fileproc (callerdat, finfo) char *tocvsPath; char *fname; + /* Initialize these solely to avoid warnings from gcc -Wall about + variables that might be used uninitialized. */ + tmp = NULL; + fname = NULL; + user_file_rev = 0; vers = Version_TS (finfo, NULL, NULL, NULL, 1, 0); @@ -534,9 +585,9 @@ diff_fileproc (callerdat, finfo) } /* Output an "Index:" line for patch to use */ - (void) fflush (stdout); - (void) printf ("Index: %s\n", finfo->fullname); - (void) fflush (stdout); + cvs_output ("Index: ", 0); + cvs_output (finfo->fullname, 0); + cvs_output ("\n", 1); tocvsPath = wrap_tocvs_process_file(finfo->file); if (tocvsPath) @@ -559,14 +610,20 @@ diff_fileproc (callerdat, finfo) { /* This is file, not fullname, because it is the "Index:" line which is supposed to contain the directory. */ - (void) printf ("===================================================================\nRCS file: %s\n", - finfo->file); - (void) printf ("diff -N %s\n", finfo->file); + cvs_output ("\ +===================================================================\n\ +RCS file: ", 0); + cvs_output (finfo->file, 0); + cvs_output ("\n", 1); + + cvs_output ("diff -N ", 0); + cvs_output (finfo->file, 0); + cvs_output ("\n", 1); if (empty_file == DIFF_ADDED) { if (use_rev2 == NULL) - run_setup ("%s %s %s %s", DIFF, opts, DEVNULL, finfo->file); + status = diff_exec (DEVNULL, finfo->file, opts, RUN_TTY); else { int retcode; @@ -587,7 +644,7 @@ diff_fileproc (callerdat, finfo) } /* FIXME: what if retcode > 0? */ - run_setup ("%s %s %s %s", DIFF, opts, DEVNULL, tmp); + status = diff_exec (DEVNULL, tmp, opts, RUN_TTY); } } else @@ -608,30 +665,36 @@ diff_fileproc (callerdat, finfo) } /* FIXME: what if retcode > 0? */ - run_setup ("%s %s %s %s", DIFF, opts, tmp, DEVNULL); + status = diff_exec (tmp, DEVNULL, opts, RUN_TTY); } } else { - if (use_rev2) - { - run_setup ("%s%s -x,v/ %s %s -r%s -r%s", Rcsbin, RCS_DIFF, - opts, *options ? options : vers->options, - use_rev1, use_rev2); - } - else - { - run_setup ("%s%s -x,v/ %s %s -r%s", Rcsbin, RCS_DIFF, opts, - *options ? options : vers->options, use_rev1); - } - run_arg (vers->srcfile->path); + char *label1 = NULL; + char *label2 = NULL; + + if (!have_rev1_label) + label1 = + make_file_label (finfo->fullname, use_rev1, vers->srcfile); + + if (!have_rev2_label) + label2 = + make_file_label (finfo->fullname, use_rev2, vers->srcfile); + + status = RCS_exec_rcsdiff (vers->srcfile, opts, + *options ? options : vers->options, + use_rev1, use_rev2, + label1, label2, + finfo->file); + + if (label1) free (label1); + if (label2) free (label2); } - switch ((status = run_exec (RUN_TTY, RUN_TTY, RUN_TTY, - RUN_REALLY|RUN_COMBINED))) + switch (status) { case -1: /* fork failed */ - error (1, errno, "fork failed during rcsdiff of %s", + error (1, errno, "fork failed while diffing %s", vers->srcfile->path); case 0: /* everything ok */ err = 0; @@ -660,7 +723,6 @@ diff_fileproc (callerdat, finfo) free (tmp); } - (void) fflush (stdout); freevers_ts (&vers); diff_mark_errors (err); return (err); @@ -694,9 +756,9 @@ diff_dirproc (callerdat, dir, pos_repos, update_dir, entries) /* XXX - check for dirs we don't want to process??? */ /* YES ... for instance dirs that don't exist!!! -- DW */ - if (!isdir (dir) ) - return (R_SKIP_ALL); - + if (!isdir (dir)) + return (R_SKIP_ALL); + if (!quiet) error (0, 0, "Diffing %s", update_dir); return (R_PROCESS); @@ -853,9 +915,9 @@ diff_file_nodiff (finfo, vers, empty_file) { /* drop user_file_rev into first unused use_rev */ if (!use_rev1) - use_rev1 = xstrdup (user_file_rev); + use_rev1 = xstrdup (user_file_rev); else if (!use_rev2) - use_rev2 = xstrdup (user_file_rev); + use_rev2 = xstrdup (user_file_rev); /* and if not, it wasn't needed anyhow */ user_file_rev = 0; } diff --git a/contrib/cvs/src/edit.c b/contrib/cvs/src/edit.c index 33e9c61..6c6f040 100644 --- a/contrib/cvs/src/edit.c +++ b/contrib/cvs/src/edit.c @@ -284,6 +284,18 @@ edit_fileproc (callerdat, finfo) if (noexec) return 0; + /* This is a somewhat screwy way to check for this, because it + doesn't help errors other than the nonexistence of the file + (e.g. permissions problems). It might be better to rearrange + the code so that CVSADM_NOTIFY gets written only after the + various actions succeed (but what if only some of them + succeed). */ + if (!isfile (finfo->file)) + { + error (0, 0, "no such file %s; ignored", finfo->fullname); + return 0; + } + fp = open_file (CVSADM_NOTIFY, "a"); (void) time (&now); @@ -326,6 +338,14 @@ edit_fileproc (callerdat, finfo) copy_file (finfo->file, basefilename); free (basefilename); + { + Node *node; + + node = findnode_fn (finfo->entries, finfo->file); + if (node != NULL) + base_register (finfo, ((Entnode *) node->data)->version); + } + return 0; } @@ -336,6 +356,7 @@ static const char *const edit_usage[] = "-R: Process directories recursively\n", "-a: Specify what actions for temporary watch, one of\n", " edit,unedit,commit,all,none\n", + "(Specify the --help global option for a list of other help options)\n", NULL }; @@ -475,6 +496,39 @@ unedit_fileproc (callerdat, finfo) CVSADM_NOTIFY); } + /* Now update the revision number in CVS/Entries from CVS/Baserev. + The basic idea here is that we are reverting to the revision + that the user edited. If we wanted "cvs update" to update + CVS/Base as we go along (so that an unedit could revert to the + current repository revision), we would need: + + update (or all send_files?) (client) needs to send revision in + new Entry-base request. update (server/local) needs to check + revision against repository and send new Update-base response + (like Update-existing in that the file already exists. While + we are at it, might try to clean up the syntax by having the + mode only in a "Mode" response, not in the Update-base itself). */ + { + char *baserev; + Node *node; + Entnode *entdata; + + baserev = base_get (finfo); + node = findnode_fn (finfo->entries, finfo->file); + /* The case where node is NULL probably should be an error or + something, but I don't want to think about it too hard right + now. */ + if (node != NULL) + { + entdata = (Entnode *) node->data; + Register (finfo->entries, finfo->file, baserev, entdata->timestamp, + entdata->options, entdata->tag, entdata->date, + entdata->conflict); + } + free (baserev); + base_deregister (finfo); + } + xchmod (finfo->file, 0); return 0; } @@ -552,14 +606,14 @@ editor_set (filename, editor, val) edlist = fileattr_get0 (filename, "_editors"); newlist = fileattr_modify (edlist, editor, val, '>', ','); - if (edlist != NULL) - free (edlist); /* If the attributes is unchanged, don't rewrite the attribute file. */ if (!((edlist == NULL && newlist == NULL) || (edlist != NULL && newlist != NULL && strcmp (edlist, newlist) == 0))) fileattr_set (filename, "_editors", newlist); + if (edlist != NULL) + free (edlist); if (newlist != NULL) free (newlist); } @@ -916,6 +970,7 @@ static const char *const editors_usage[] = "Usage: %s %s [-lR] [files...]\n", "\t-l\tProcess this directory only (not recursive).\n", "\t-R\tProcess directories recursively.\n", + "(Specify the --help global option for a list of other help options)\n", NULL }; diff --git a/contrib/cvs/src/entries.c b/contrib/cvs/src/entries.c index 03e29de..538cd21 100644 --- a/contrib/cvs/src/entries.c +++ b/contrib/cvs/src/entries.c @@ -3,7 +3,7 @@ * Copyright (c) 1989-1992, Brian Berliner * * You may distribute under the terms of the GNU General Public License as - * specified in the README file that comes with the CVS 1.4 kit. + * specified in the README file that comes with the CVS source distribution. * * Entries file to Files file * @@ -117,7 +117,26 @@ write_entries (list) /* open the new one and walk the list writing entries */ entfilename = CVSADM_ENTBAK; - entfile = open_file (entfilename, "w+"); + entfile = CVS_FOPEN (entfilename, "w+"); + if (entfile == NULL) + { + /* Make this a warning, not an error. For example, one user might + have checked out a working directory which, for whatever reason, + contains an Entries.Log file. A second user, without write access + to that working directory, might want to do a "cvs log". The + problem rewriting Entries shouldn't affect the ability of "cvs log" + to work, although the warning is probably a good idea so that + whether Entries gets rewritten is not an inexplicable process. */ + /* FIXME: should be including update_dir in message. */ + error (0, errno, "cannot rewrite %s", entfilename); + + /* Now just return. We leave the Entries.Log file around. As far + as I know, there is never any data lying around in 'list' that + is not in Entries.Log at this time (if there is an error writing + Entries.Log that is a separate problem). */ + return; + } + (void) walklist (list, write_ent_proc, (void *) &sawdir); if (! sawdir) { @@ -262,6 +281,9 @@ freesdt (p) free ((char *) sdtp); } +/* Return the next real Entries line. On end of file, returns NULL. + On error, prints an error message and returns NULL. */ + static Entnode * fgetentent(fpin, cmd, sawdir) FILE *fpin; @@ -275,12 +297,13 @@ fgetentent(fpin, cmd, sawdir) enum ent_type type; char *l, *user, *vn, *ts, *options; char *tag_or_date, *tag, *date, *ts_conflict; + int line_length; line = NULL; line_chars_allocated = 0; ent = NULL; - while (getline (&line, &line_chars_allocated, fpin) > 0) + while ((line_length = getline (&line, &line_chars_allocated, fpin)) > 0) { l = line; @@ -375,6 +398,9 @@ fgetentent(fpin, cmd, sawdir) break; } + if (line_length < 0 && !feof (fpin)) + error (0, errno, "cannot read entries file"); + free (line); return ent; } @@ -668,7 +694,10 @@ WriteTag (dir, tag, date, nonbranch, update_dir, repository) If it does not exist, or contains something unrecognized by this version of CVS, set *DATEP and *TAGP to NULL and *NONBRANCHP to - an unspecified value. */ + an unspecified value. + + If there is an error, print an error message, set *DATEP and *TAGP + to NULL, and return. */ void ParseTag (tagp, datep, nonbranchp) char **tagp; @@ -724,9 +753,25 @@ ParseTag (tagp, datep, nonbranchp) break; } } - (void) fclose (fp); + + if (line_length < 0) + { + /* FIXME-update-dir: should include update_dir in messages. */ + if (feof (fp)) + error (0, 0, "cannot read %s: end of file", CVSADM_TAG); + else + error (0, errno, "cannot read %s", CVSADM_TAG); + } + + if (fclose (fp) < 0) + /* FIXME-update-dir: should include update_dir in message. */ + error (0, errno, "cannot close %s", CVSADM_TAG); + free (line); } + else if (!existence_error (errno)) + /* FIXME-update-dir: should include update_dir in message. */ + error (0, errno, "cannot open %s", CVSADM_TAG); } /* @@ -887,3 +932,230 @@ Subdir_Deregister (entries, parent, dir) delnode (p); } } + + + +/* OK, the following base_* code tracks the revisions of the files in + CVS/Base. We do this in a file CVS/Baserev. Separate from + CVS/Entries because it needs to go in separate data structures + anyway (the name in Entries must be unique), so this seemed + cleaner. The business of rewriting the whole file in + base_deregister and base_register is the kind of thing we used to + do for Entries and which turned out to be slow, which is why there + is now the Entries.Log machinery. So maybe from that point of + view it is a mistake to do this separately from Entries, I dunno. + + We also need something analogous for: + + 1. CVS/Template (so we can update the Template file automagically + without the user needing to check out a new working directory). + Updating would probably print a message (that part might be + optional, although probably it should be visible because not all + cvs commands would make the update happen and so it is a + user-visible behavior). Constructing version number for template + is a bit hairy (base it on the timestamp on the server? Or see if + the template is in checkoutlist and if yes use its versioning and + if no don't version it?).... + + 2. cvsignore (need to keep a copy in the working directory to do + "cvs release" on the client side; see comment at src/release.c + (release). Would also allow us to stop needing Questionable. */ + +enum base_walk { + /* Set the revision for FILE to *REV. */ + BASE_REGISTER, + /* Get the revision for FILE and put it in a newly malloc'd string + in *REV, or put NULL if not mentioned. */ + BASE_GET, + /* Remove FILE. */ + BASE_DEREGISTER +}; + +static void base_walk PROTO ((enum base_walk, struct file_info *, char **)); + +/* Read through the lines in CVS/Baserev, taking the actions as documented + for CODE. */ + +static void +base_walk (code, finfo, rev) + enum base_walk code; + struct file_info *finfo; + char **rev; +{ + FILE *fp; + char *line; + size_t line_allocated; + FILE *newf; + char *baserev_fullname; + char *baserevtmp_fullname; + + line = NULL; + line_allocated = 0; + newf = NULL; + + /* First compute the fullnames for the error messages. This + computation probably should be broken out into a separate function, + as recurse.c does it too and places like Entries_Open should be + doing it. */ + baserev_fullname = xmalloc (sizeof (CVSADM_BASEREV) + + strlen (finfo->update_dir) + + 2); + baserev_fullname[0] = '\0'; + baserevtmp_fullname = xmalloc (sizeof (CVSADM_BASEREVTMP) + + strlen (finfo->update_dir) + + 2); + baserevtmp_fullname[0] = '\0'; + if (finfo->update_dir[0] != '\0') + { + strcat (baserev_fullname, finfo->update_dir); + strcat (baserev_fullname, "/"); + strcat (baserevtmp_fullname, finfo->update_dir); + strcat (baserevtmp_fullname, "/"); + } + strcat (baserev_fullname, CVSADM_BASEREV); + strcat (baserevtmp_fullname, CVSADM_BASEREVTMP); + + fp = CVS_FOPEN (CVSADM_BASEREV, "r"); + if (fp == NULL) + { + if (!existence_error (errno)) + { + error (0, errno, "cannot open %s for reading", baserev_fullname); + goto out; + } + } + + switch (code) + { + case BASE_REGISTER: + case BASE_DEREGISTER: + newf = CVS_FOPEN (CVSADM_BASEREVTMP, "w"); + if (newf == NULL) + { + error (0, errno, "cannot open %s for writing", + baserevtmp_fullname); + goto out; + } + break; + case BASE_GET: + *rev = NULL; + break; + } + + if (fp != NULL) + { + while (getline (&line, &line_allocated, fp) >= 0) + { + char *linefile; + char *p; + char *linerev; + + if (line[0] != 'B') + /* Ignore, for future expansion. */ + continue; + + linefile = line + 1; + p = strchr (linefile, '/'); + if (p == NULL) + /* Syntax error, ignore. */ + continue; + linerev = p + 1; + p = strchr (linerev, '/'); + if (p == NULL) + continue; + + linerev[-1] = '\0'; + if (fncmp (linefile, finfo->file) == 0) + { + switch (code) + { + case BASE_REGISTER: + case BASE_DEREGISTER: + /* Don't copy over the old entry, we don't want it. */ + break; + case BASE_GET: + *p = '\0'; + *rev = xstrdup (linerev); + *p = '/'; + goto got_it; + } + } + else + { + linerev[-1] = '/'; + switch (code) + { + case BASE_REGISTER: + case BASE_DEREGISTER: + if (fprintf (newf, "%s\n", line) < 0) + error (0, errno, "error writing %s", + baserevtmp_fullname); + break; + case BASE_GET: + break; + } + } + } + if (ferror (fp)) + error (0, errno, "cannot read %s", baserev_fullname); + } + got_it: + + if (code == BASE_REGISTER) + { + if (fprintf (newf, "B%s/%s/\n", finfo->file, *rev) < 0) + error (0, errno, "error writing %s", + baserevtmp_fullname); + } + + out: + + if (line != NULL) + free (line); + + if (fp != NULL) + { + if (fclose (fp) < 0) + error (0, errno, "cannot close %s", baserev_fullname); + } + if (newf != NULL) + { + if (fclose (newf) < 0) + error (0, errno, "cannot close %s", baserevtmp_fullname); + rename_file (CVSADM_BASEREVTMP, CVSADM_BASEREV); + } + + free (baserev_fullname); + free (baserevtmp_fullname); +} + +/* Return, in a newly malloc'd string, the revision for FILE in CVS/Baserev, + or NULL if not listed. */ + +char * +base_get (finfo) + struct file_info *finfo; +{ + char *rev; + base_walk (BASE_GET, finfo, &rev); + return rev; +} + +/* Set the revision for FILE to REV. */ + +void +base_register (finfo, rev) + struct file_info *finfo; + char *rev; +{ + base_walk (BASE_REGISTER, finfo, &rev); +} + +/* Remove FILE. */ + +void +base_deregister (finfo) + struct file_info *finfo; +{ + base_walk (BASE_DEREGISTER, finfo, NULL); +} diff --git a/contrib/cvs/src/error.c b/contrib/cvs/src/error.c index 5c7eef5..cb69bde 100644 --- a/contrib/cvs/src/error.c +++ b/contrib/cvs/src/error.c @@ -83,7 +83,13 @@ error_exit PROTO ((void)) format string with optional args. If ERRNUM is nonzero, print its corresponding system error message. Exit with status EXIT_FAILURE if STATUS is nonzero. If MESSAGE is "", - no need to print a message. */ + no need to print a message. + + I think this is largely cleaned up to the point where it does the right + thing for the server, whether the normal server_active (child process) + case or the error_use_protocol (parent process) case. The one exception + is that STATUS nonzero for error_use_protocol probably doesn't work yet; + in that case still need to use the pending_error machinery in server.c. */ /* VARARGS */ void #if defined (HAVE_VPRINTF) && defined (__STDC__) diff --git a/contrib/cvs/src/expand_path.c b/contrib/cvs/src/expand_path.c index 7d0bc39..5cf414e 100644 --- a/contrib/cvs/src/expand_path.c +++ b/contrib/cvs/src/expand_path.c @@ -184,6 +184,19 @@ expand_path (name, file, line) t = get_homedir (); else { +#ifdef GETPWNAM_MISSING + for (; *p!='/' && *p; p++) + ; + *p = 0; + if (line != 0) + error (0, 0, + "%s:%d:tilde expansion not supported on this system", + file, line); + else + error (0, 0, "%s:tilde expansion not supported on this system", + file); + return NULL; +#else struct passwd *ps; for (; *p!='/' && *p; p++) ; @@ -199,6 +212,7 @@ expand_path (name, file, line) return NULL; } t = ps->pw_dir; +#endif } doff = d - buf; expand_string (&buf, &buf_size, doff + 1); @@ -256,8 +270,11 @@ expand_variable (name, file, line) { if (strcmp (name, CVSROOT_ENV) == 0) return CVSroot_original; - else if (strcmp (name, RCSBIN_ENV) == 0) - return Rcsbin; + else if (strcmp (name, "RCSBIN") == 0) + { + error (0, 0, "RCSBIN internal variable is no longer supported"); + return NULL; + } else if (strcmp (name, EDITOR1_ENV) == 0) return Editor; else if (strcmp (name, EDITOR2_ENV) == 0) diff --git a/contrib/cvs/src/fileattr.c b/contrib/cvs/src/fileattr.c index eda7753..a5abea0 100644 --- a/contrib/cvs/src/fileattr.c +++ b/contrib/cvs/src/fileattr.c @@ -376,6 +376,86 @@ fileattr_set (filename, attrname, attrval) attrs_modified = 1; } +char * +fileattr_getall (filename) + const char *filename; +{ + Node *node; + char *p; + + if (attrlist == NULL) + fileattr_read (); + if (attrlist == NULL) + /* Either nothing has any attributes, or fileattr_read already printed + an error message. */ + return NULL; + + if (filename == NULL) + p = fileattr_default_attrs; + else + { + node = findnode (attrlist, filename); + if (node == NULL) + /* A file not mentioned has no attributes. */ + return NULL; + p = node->data; + } + return xstrdup (p); +} + +void +fileattr_setall (filename, attrs) + const char *filename; + const char *attrs; +{ + Node *node; + + if (filename == NULL) + { + if (fileattr_default_attrs != NULL) + free (fileattr_default_attrs); + fileattr_default_attrs = xstrdup (attrs); + attrs_modified = 1; + return; + } + if (attrlist == NULL) + fileattr_read (); + if (attrlist == NULL) + { + /* Not sure this is a graceful way to handle things + in the case where fileattr_read was unable to read the file. */ + /* No attributes existed previously. */ + attrlist = getlist (); + } + + node = findnode (attrlist, filename); + if (node == NULL) + { + /* The file had no attributes. Add them if we have any to add. */ + if (attrs != NULL) + { + node = getnode (); + node->type = FILEATTR; + node->delproc = fileattr_delproc; + node->key = xstrdup (filename); + node->data = xstrdup (attrs); + addnode (attrlist, node); + } + } + else + { + if (attrs == NULL) + delnode (node); + else + { + free (node->data); + node->data = xstrdup (attrs); + } + } + + attrs_modified = 1; +} + void fileattr_newfile (filename) const char *filename; @@ -550,6 +630,10 @@ fileattr_write () void fileattr_free () { + /* Note that attrs_modified will ordinarily be zero, but there are + a few cases in which fileattr_write will fail to zero it (if + noexec is set, or error conditions). This probably is the way + it should be. */ dellist (&attrlist); if (fileattr_stored_repos != NULL) free (fileattr_stored_repos); diff --git a/contrib/cvs/src/fileattr.h b/contrib/cvs/src/fileattr.h index c6362af..7e02b3a 100644 --- a/contrib/cvs/src/fileattr.h +++ b/contrib/cvs/src/fileattr.h @@ -115,6 +115,17 @@ extern char *fileattr_modify PROTO ((char *list, const char *attrname, extern void fileattr_set PROTO ((const char *filename, const char *attrname, const char *attrval)); +/* Get all the attributes for file FILENAME. They are returned as malloc'd + data in an unspecified format which is guaranteed only to be good for + passing to fileattr_setall, or NULL if no attributes. If FILENAME is + NULL, get default attributes. */ +extern char *fileattr_getall PROTO ((const char *filename)); + +/* Set the attributes for file FILENAME to ATTRS, overwriting all previous + attributes for that file. ATTRS was obtained from a previous call to + fileattr_getall (malloc'd data or NULL). */ +extern void fileattr_setall PROTO ((const char *filename, const char *attrs)); + /* Set the attributes for file FILENAME in whatever manner is appropriate for a newly created file. */ extern void fileattr_newfile PROTO ((const char *filename)); diff --git a/contrib/cvs/src/filesubr.c b/contrib/cvs/src/filesubr.c index 71df566..b5121a7 100644 --- a/contrib/cvs/src/filesubr.c +++ b/contrib/cvs/src/filesubr.c @@ -287,7 +287,8 @@ mkdir_if_needed (name) { if (mkdir (name, 0777) < 0) { - if (errno != EEXIST) + if (!(errno == EEXIST + || (errno == EACCES && isdir (name)))) error (1, errno, "cannot make directory %s", name); return 1; } @@ -416,13 +417,16 @@ int unlink_file_dir (f) const char *f; { - if (trace) + if (trace #ifdef SERVER_SUPPORT - (void) fprintf (stderr, "%c-> unlink_file_dir(%s)\n", - (server_active) ? 'S' : ' ', f); -#else - (void) fprintf (stderr, "-> unlink_file_dir(%s)\n", f); + /* This is called by the server parent process in contexts where + it is not OK to send output (e.g. after we sent "ok" to the + client). */ + && !server_active #endif + ) + (void) fprintf (stderr, "-> unlink_file_dir(%s)\n", f); + if (noexec) return (0); @@ -690,7 +694,26 @@ last_component (path) /* Return the home directory. Returns a pointer to storage managed by this function or its callees (currently getenv). This function will return the same thing every time it is - called. */ + called. Returns NULL if there is no home directory. + + Note that for a pserver server, this may return root's home + directory. What typically happens is that upon being started from + inetd, before switching users, the code in cvsrc.c calls + get_homedir which remembers root's home directory in the static + variable. Then the switch happens and get_homedir might return a + directory that we don't even have read or execute permissions for + (which is bad, when various parts of CVS try to read there). One + fix would be to make the value returned by get_homedir only good + until the next call (which would free the old value). Another fix + would be to just always malloc our answer, and let the caller free + it (that is best, because some day we may need to be reentrant). + + The workaround is to put -f in inetd.conf which means that + get_homedir won't get called until after the switch in user ID. + + The whole concept of a "home directory" on the server is pretty + iffy, although I suppose some people probably are relying on it for + .cvsrc and such, in the cases where it works. */ char * get_homedir () { diff --git a/contrib/cvs/src/find_names.c b/contrib/cvs/src/find_names.c index 5d2a79e..ed6c5c4 100644 --- a/contrib/cvs/src/find_names.c +++ b/contrib/cvs/src/find_names.c @@ -3,7 +3,7 @@ * Copyright (c) 1989-1992, Brian Berliner * * You may distribute under the terms of the GNU General Public License as - * specified in the README file that comes with the CVS 1.4 kit. + * specified in the README file that comes with the CVS source distribution. * * Find Names * @@ -200,6 +200,15 @@ Find_Directories (repository, which, entries) information is not recorded in the Entries file. Find the subdirectories the hard way, and, if possible, add it to the Entries file for next time. */ + + /* FIXME-maybe: find_dirs is bogus for this usage because + it skips CVSATTIC and CVSLCK directories--those names + should be special only in the repository. However, in + the interests of not perturbing this code, we probably + should leave well enough alone unless we want to write + a sanity.sh test case (which would operate by manually + hacking on the CVS/Entries file). */ + if (find_dirs (".", dirlist, 1, tmpentries) != 0) error (1, errno, "cannot open current directory"); if (tmpentries != NULL) @@ -292,6 +301,16 @@ find_dirs (dir, list, checkadm, entries) size_t tmp_size = 0; struct dirent *dp; DIR *dirp; + int skip_emptydir = 0; + + /* First figure out whether we need to skip directories named + Emptydir. Except in the CVSNULLREPOS case, Emptydir is just + a normal directory name. */ + if (isabsolute (dir) + && strncmp (dir, CVSroot_directory, strlen (CVSroot_directory)) == 0 + && ISDIRSEP (dir[strlen (CVSroot_directory)]) + && strcmp (dir + strlen (CVSroot_directory) + 1, CVSROOTADM) == 0) + skip_emptydir = 1; /* set up to read the dir */ if ((dirp = CVS_OPENDIR (dir)) == NULL) @@ -313,6 +332,10 @@ find_dirs (dir, list, checkadm, entries) if (entries != NULL && findnode (entries, dp->d_name) != NULL) continue; + if (skip_emptydir + && strcmp (dp->d_name, CVSNULLREPOS) == 0) + continue; + #ifdef DT_DIR if (dp->d_type != DT_DIR) { diff --git a/contrib/cvs/src/hash.c b/contrib/cvs/src/hash.c index a978d1f..ff3f122 100644 --- a/contrib/cvs/src/hash.c +++ b/contrib/cvs/src/hash.c @@ -2,7 +2,7 @@ * Copyright (c) 1992, Brian Berliner and Jeff Polk * * You may distribute under the terms of the GNU General Public License as - * specified in the README file that comes with the CVS 1.4 kit. + * specified in the README file that comes with the CVS source distribution. * * Polk's hash list manager. So cool. */ @@ -220,21 +220,23 @@ freenode (p) } /* - * insert item p at end of list "list" (maybe hash it too) if hashing and it - * already exists, return -1 and don't actually put it in the list + * Link item P into list LIST before item MARKER. If P->KEY is non-NULL and + * that key is already in the hash table, return -1 without modifying any + * parameter. * * return 0 on success */ int -addnode (list, p) +insert_before (list, marker, p) List *list; + Node *marker; Node *p; { - int hashval; - Node *q; - if (p->key != NULL) /* hash it too? */ { + int hashval; + Node *q; + hashval = hashp (p->key); if (list->hasharray[hashval] == NULL) /* make a header for list? */ { @@ -257,15 +259,40 @@ addnode (list, p) q->hashprev = p; } - /* put it into the regular list */ - p->prev = list->list->prev; - p->next = list->list; - list->list->prev->next = p; - list->list->prev = p; + p->next = marker; + p->prev = marker->prev; + marker->prev->next = p; + marker->prev = p; return (0); } +/* + * insert item p at end of list "list" (maybe hash it too) if hashing and it + * already exists, return -1 and don't actually put it in the list + * + * return 0 on success + */ +int +addnode (list, p) + List *list; + Node *p; +{ + return insert_before (list, list->list, p); +} + +/* + * Like addnode, but insert p at the front of `list'. This bogosity is + * necessary to preserve last-to-first output order for some RCS functions. + */ +int +addnode_at_front (list, p) + List *list; + Node *p; +{ + return insert_before (list, list->list->next, p); +} + /* Look up an entry in hash list table and return a pointer to the node. Return NULL if not found. Abort with a fatal error for errors. */ diff --git a/contrib/cvs/src/hash.h b/contrib/cvs/src/hash.h index a22bc10..d29c757 100644 --- a/contrib/cvs/src/hash.h +++ b/contrib/cvs/src/hash.h @@ -2,7 +2,7 @@ * Copyright (c) 1992, Brian Berliner and Jeff Polk * * You may distribute under the terms of the GNU General Public License as - * specified in the README file that comes with the CVS 1.4 kit. + * specified in the README file that comes with the CVS source distribution. */ /* @@ -47,7 +47,9 @@ List *getlist PROTO((void)); Node *findnode PROTO((List * list, const char *key)); Node *findnode_fn PROTO((List * list, const char *key)); Node *getnode PROTO((void)); +int insert_before PROTO((List * list, Node * marker, Node * p)); int addnode PROTO((List * list, Node * p)); +int addnode_at_front PROTO((List * list, Node * p)); int walklist PROTO((List * list, int (*)(Node *n, void *closure), void *closure)); int list_isempty PROTO ((List *list)); void dellist PROTO((List ** listp)); diff --git a/contrib/cvs/src/history.c b/contrib/cvs/src/history.c index ae13409..223e5a7 100644 --- a/contrib/cvs/src/history.c +++ b/contrib/cvs/src/history.c @@ -230,13 +230,9 @@ static short repos_sort; static short file_sort; static short module_sort; -#ifdef HAVE_RCS5 static short tz_local; static time_t tz_seconds_east_of_GMT; static char *tz_name = "+0000"; -#else -static char tz_name[] = "LT"; -#endif /* -r, -t, or -b options, malloc'd. These are "" if the option in question is not specified or is overridden by another option. The @@ -497,9 +493,6 @@ history (argc, argv) rec_types = xstrdup (optarg); break; case 'z': -#ifndef HAVE_RCS5 - error (0, 0, "-z not supported with RCS 4"); -#else tz_local = (optarg[0] == 'l' || optarg[0] == 'L') && (optarg[1] == 't' || optarg[1] == 'T') @@ -530,7 +523,6 @@ history (argc, argv) tz_name = optarg; } } -#endif break; case '?': default: @@ -1431,15 +1423,14 @@ report_hrecs () continue; ty = *(lr->type); -#ifdef HAVE_RCS5 if (!tz_local) { time_t t = lr->date + tz_seconds_east_of_GMT; tm = gmtime (&t); } else -#endif - tm = localtime (&(lr->date)); + tm = localtime (&(lr->date)); + (void) printf ("%c %02d/%02d %02d:%02d %s %-*s", ty, tm->tm_mon + 1, tm->tm_mday, tm->tm_hour, tm->tm_min, tz_name, user_len, lr->user); diff --git a/contrib/cvs/src/ignore.c b/contrib/cvs/src/ignore.c index 908b5de..5d7ca61 100644 --- a/contrib/cvs/src/ignore.c +++ b/contrib/cvs/src/ignore.c @@ -304,49 +304,54 @@ ign_name (name) } } -/* FIXME: This list of dirs to ignore stuff seems not to be used. */ +/* FIXME: This list of dirs to ignore stuff seems not to be used. + Really? send_dirent_proc and update_dirent_proc both call + ignore_directory and do_module calls ign_dir_add. No doubt could + use some documentation/testsuite work. */ static char **dir_ign_list = NULL; static int dir_ign_max = 0; static int dir_ign_current = 0; -/* add a directory to list of dirs to ignore */ -void ign_dir_add (name) - char *name; +/* Add a directory to list of dirs to ignore. */ +void +ign_dir_add (name) + char *name; { - /* make sure we've got the space for the entry */ - if (dir_ign_current <= dir_ign_max) + /* Make sure we've got the space for the entry. */ + if (dir_ign_current <= dir_ign_max) { - dir_ign_max += IGN_GROW; - dir_ign_list = (char **) xrealloc ((char *) dir_ign_list, (dir_ign_max+1) * sizeof(char*)); + dir_ign_max += IGN_GROW; + dir_ign_list = + (char **) xrealloc (dir_ign_list, + (dir_ign_max + 1) * sizeof (char *)); } - dir_ign_list[dir_ign_current] = name; + dir_ign_list[dir_ign_current] = name; - dir_ign_current += 1 ; + dir_ign_current += 1 ; } -/* this function returns 1 (true) if the given directory name is part of - * the list of directories to ignore - */ +/* Return nonzero if NAME is part of the list of directories to ignore. */ -int ignore_directory (name) - char *name; +int +ignore_directory (name) + char *name; { - int i; + int i; - if (!dir_ign_list) - return 0; + if (!dir_ign_list) + return 0; - i = dir_ign_current; - while (i--) + i = dir_ign_current; + while (i--) { - if (strncmp(name, dir_ign_list[i], strlen(dir_ign_list[i])) == 0) - return 1; + if (strncmp (name, dir_ign_list[i], strlen (dir_ign_list[i])) == 0) + return 1; } - return 0; + return 0; } /* diff --git a/contrib/cvs/src/import.c b/contrib/cvs/src/import.c index 3243a96..0a2af7f 100644 --- a/contrib/cvs/src/import.c +++ b/contrib/cvs/src/import.c @@ -3,7 +3,7 @@ * Copyright (c) 1989-1992, Brian Berliner * * You may distribute under the terms of the GNU General Public License as - * specified in the README file that comes with the CVS 1.4 kit. + * specified in the README file that comes with the CVS source distribution. * * "import" checks in the vendor release located in the current directory into * the CVS source repository. The CVS vendor branch support is utilized. @@ -23,7 +23,6 @@ #define FILE_HOLDER ".#cvsxxx" static char *get_comment PROTO((char *user)); -static int expand_at_signs PROTO((char *buf, off_t size, FILE *fp)); static int add_rev PROTO((char *message, RCSNode *rcs, char *vfile, char *vers)); static int add_tags PROTO((RCSNode *rcs, char *vfile, char *vtag, int targc, @@ -56,6 +55,7 @@ static const char *const import_usage[] = "\t-b bra\tVendor branch id.\n", "\t-m msg\tLog message.\n", "\t-W spec\tWrappers specification line.\n", + "(Specify the --help global option for a list of other help options)\n", NULL }; @@ -104,9 +104,9 @@ import (argc, argv) break; case 'm': #ifdef FORCE_USE_EDITOR - use_editor = TRUE; + use_editor = 1; #else - use_editor = FALSE; + use_editor = 0; #endif message = xstrdup(optarg); break; @@ -199,6 +199,7 @@ import (argc, argv) if (msglen == 0 || message[msglen - 1] != '\n') { char *nm = xmalloc (msglen + 2); + *nm = '\0'; if (message != NULL) { (void) strcpy (nm, message); @@ -467,6 +468,8 @@ process_import_file (message, vfile, vtag, targc, targv) if (!isfile (attic_name)) { int retval; + char *free_opt = NULL; + char *our_opt = keyword_opt; free (attic_name); /* @@ -474,8 +477,42 @@ process_import_file (message, vfile, vtag, targc, targv) * repository nor in the Attic -- create it anew. */ add_log ('N', vfile); - retval = add_rcs_file (message, rcs, vfile, vhead, vbranch, - vtag, targc, targv, logfp); + +#ifdef SERVER_SUPPORT + /* The most reliable information on whether the file is binary + is what the client told us. That is because if the client had + the wrong idea about binaryness, it corrupted the file, so + we might as well believe the client. */ + if (server_active) + { + Node *node; + List *entries; + + /* Reading all the entries for each file is fairly silly, and + probably slow. But I am too lazy at the moment to do + anything else. */ + entries = Entries_Open (0); + node = findnode_fn (entries, vfile); + if (node != NULL) + { + Entnode *entdata = (Entnode *) node->data; + if (entdata->type == ENT_FILE) + { + assert (entdata->options[0] == '-' + && entdata->options[1] == 'k'); + our_opt = xstrdup (entdata->options + 2); + free_opt = our_opt; + } + } + Entries_Close (entries); + } +#endif + + retval = add_rcs_file (message, rcs, vfile, vhead, our_opt, + vbranch, vtag, targc, targv, + NULL, 0, logfp); + if (free_opt != NULL) + free (free_opt); free (rcs); return retval; } @@ -602,12 +639,14 @@ add_rev (message, rcs, vfile, vers) /* Before RCS_lock existed, we were directing stdout, as well as stderr, from the RCS command, to DEVNULL. I wouldn't guess that was necessary, but I don't know for sure. */ - if (RCS_lock (rcs, vbranch, 1) != 0) - { - error (0, errno, "fork failed"); - return (1); - } + /* Earlier versions of this function printed a `fork failed' error + when RCS_lock returned an error code. That's not appropriate + now that RCS_lock is librarified, but should the error text be + preserved? */ + if (RCS_lock (rcs, vbranch, 1) != 0) + return 1; locked = 1; + RCS_rewrite (rcs, NULL, NULL); } tocvsPath = wrap_tocvs_process_file (vfile); if (tocvsPath == NULL) @@ -632,7 +671,7 @@ add_rev (message, rcs, vfile, vers) } } - status = RCS_checkin (rcs->path, tocvsPath == NULL ? vfile : tocvsPath, + status = RCS_checkin (rcs, tocvsPath == NULL ? vfile : tocvsPath, message, vbranch, (RCS_FLAGS_QUIET | (use_file_modtime ? RCS_FLAGS_MODTIME : 0))); @@ -656,6 +695,7 @@ add_rev (message, rcs, vfile, vers) if (locked) { (void) RCS_unlock(rcs, vbranch, 0); + RCS_rewrite (rcs, NULL, NULL); } return (1); } @@ -693,6 +733,7 @@ add_tags (rcs, vfile, vtag, targc, targv) "ERROR: Failed to set tag %s in %s", vtag, rcs->path); return (1); } + RCS_rewrite (rcs, NULL, NULL); memset (&finfo, 0, sizeof finfo); finfo.file = vfile; @@ -705,7 +746,9 @@ add_tags (rcs, vfile, vtag, targc, targv) vers = Version_TS (&finfo, NULL, vtag, NULL, 1, 0); for (i = 0; i < targc; i++) { - if ((retcode = RCS_settag (rcs, targv[i], vers->vn_rcs)) != 0) + if ((retcode = RCS_settag (rcs, targv[i], vers->vn_rcs)) == 0) + RCS_rewrite (rcs, NULL, NULL); + else { ierrno = errno; fperror (logfp, 0, retcode == -1 ? ierrno : 0, @@ -879,23 +922,33 @@ get_comment (user) /* Create a new RCS file from scratch. This probably should be moved to rcs.c now that it is called from - places outside import.c. */ + places outside import.c. + + Return value is 0 for success, or nonzero for failure (in which + case an error message will have already been printed). */ int -add_rcs_file (message, rcs, user, add_vhead, add_vbranch, vtag, targc, targv, - add_logfp) - /* Log message for the addition. */ +add_rcs_file (message, rcs, user, add_vhead, key_opt, + add_vbranch, vtag, targc, targv, + desctext, desclen, add_logfp) + /* Log message for the addition. Not used if add_vhead == NULL. */ char *message; /* Filename of the RCS file to create. */ char *rcs; /* Filename of the file to serve as the contents of the initial - revision. */ + revision. Even if add_vhead is NULL, we use this to determine + the modes to give the new RCS file. */ char *user; /* Revision number of head that we are adding. Normally 1.1 but could be another revision as long as ADD_VBRANCH is a branch - from it. */ + from it. If NULL, then just add an empty file without any + revisions (similar to the one created by "rcs -i"). */ char *add_vhead; + /* Keyword expansion mode, e.g., "b" for binary. NULL means the + default behavior. */ + char *key_opt; + /* Vendor branch to import to, or NULL if none. If non-NULL, then vtag should also be non-NULL. */ char *add_vbranch; @@ -903,6 +956,11 @@ add_rcs_file (message, rcs, user, add_vhead, add_vbranch, vtag, targc, targv, int targc; char *targv[]; + /* If non-NULL, description for the file. If NULL, the description + will be empty. */ + char *desctext; + size_t desclen; + /* Write errors to here as well as via error (), or NULL if we should use only error (). */ FILE *add_logfp; @@ -912,20 +970,24 @@ add_rcs_file (message, rcs, user, add_vhead, add_vbranch, vtag, targc, targv, struct tm *ftm; time_t now; char altdate1[MAXDATELEN]; -#ifndef HAVE_RCS5 - char altdate2[MAXDATELEN]; -#endif char *author; int i, ierrno, err = 0; mode_t mode; char *tocvsPath; char *userfile; - char *local_opt = keyword_opt; + char *local_opt = key_opt; char *free_opt = NULL; if (noexec) return (0); + /* Note that as the code stands now, the -k option overrides any + settings in wrappers (whether CVSROOT/cvswrappers, -W, or + whatever). Some have suggested this should be the other way + around. As far as I know the documentation doesn't say one way + or the other. Before making a change of this sort, should think + about what is best, document it (in cvs.texinfo and NEWS), &c. */ + if (local_opt == NULL) { if (wrap_name_has (user, WRAP_RCSOPTION)) @@ -936,7 +998,17 @@ add_rcs_file (message, rcs, user, add_vhead, add_vbranch, vtag, targc, targv, tocvsPath = wrap_tocvs_process_file (user); userfile = (tocvsPath == NULL ? user : tocvsPath); - fpuser = CVS_FOPEN (userfile, "r"); + + /* Opening in text mode is probably never the right thing for the + server (because the protocol encodes text files in a fashion + which does not depend on what the client or server OS is, as + documented in cvsclient.texi), but as long as the server just + runs on unix it is a moot point. */ + fpuser = CVS_FOPEN (userfile, + ((local_opt != NULL && strcmp (local_opt, "b") == 0) + ? "rb" + : "r") + ); if (fpuser == NULL) { /* not fatal, continue import */ @@ -954,8 +1026,17 @@ add_rcs_file (message, rcs, user, add_vhead, add_vbranch, vtag, targc, targv, /* * putadmin() */ - if (fprintf (fprcs, "head %s;\012", add_vhead) < 0) - goto write_error; + if (add_vhead != NULL) + { + if (fprintf (fprcs, "head %s;\012", add_vhead) < 0) + goto write_error; + } + else + { + if (fprintf (fprcs, "head ;\012") < 0) + goto write_error; + } + if (add_vbranch != NULL) { if (fprintf (fprcs, "branch %s;\012", add_vbranch) < 0) @@ -1001,125 +1082,125 @@ add_rcs_file (message, rcs, user, add_vhead, add_vbranch, vtag, targc, targv, if (fprintf (fprcs, "\012") < 0) goto write_error; - /* - * puttree() - */ + /* Get information on modtime and mode. */ if (fstat (fileno (fpuser), &sb) < 0) error (1, errno, "cannot fstat %s", user); - if (use_file_modtime) - now = sb.st_mtime; - else - (void) time (&now); -#ifdef HAVE_RCS5 - ftm = gmtime (&now); -#else - ftm = localtime (&now); -#endif - (void) sprintf (altdate1, DATEFORM, - ftm->tm_year + (ftm->tm_year < 100 ? 0 : 1900), - ftm->tm_mon + 1, ftm->tm_mday, ftm->tm_hour, - ftm->tm_min, ftm->tm_sec); -#ifdef HAVE_RCS5 -#define altdate2 altdate1 -#else - /* - * If you don't have RCS V5 or later, you need to lie about the ci - * time, since RCS V4 and earlier insist that the times differ. - */ - now++; - ftm = localtime (&now); - (void) sprintf (altdate2, DATEFORM, - ftm->tm_year + (ftm->tm_year < 100 ? 0 : 1900), - ftm->tm_mon + 1, ftm->tm_mday, ftm->tm_hour, - ftm->tm_min, ftm->tm_sec); -#endif - author = getcaller (); - if (fprintf (fprcs, "\012%s\012", add_vhead) < 0 || + /* Write the revision(s), with the date and author and so on + (that is "delta" rather than "deltatext" from rcsfile(5)). */ + if (add_vhead != NULL) + { + if (use_file_modtime) + now = sb.st_mtime; + else + (void) time (&now); + ftm = gmtime (&now); + (void) sprintf (altdate1, DATEFORM, + ftm->tm_year + (ftm->tm_year < 100 ? 0 : 1900), + ftm->tm_mon + 1, ftm->tm_mday, ftm->tm_hour, + ftm->tm_min, ftm->tm_sec); + author = getcaller (); + + if (fprintf (fprcs, "\012%s\012", add_vhead) < 0 || fprintf (fprcs, "date %s; author %s; state Exp;\012", altdate1, author) < 0) goto write_error; - if (fprintf (fprcs, "branches") < 0) - goto write_error; - if (add_vbranch != NULL) - { - if (fprintf (fprcs, " %s.1", add_vbranch) < 0) + if (fprintf (fprcs, "branches") < 0) + goto write_error; + if (add_vbranch != NULL) + { + if (fprintf (fprcs, " %s.1", add_vbranch) < 0) + goto write_error; + } + if (fprintf (fprcs, ";\012") < 0) goto write_error; - } - if (fprintf (fprcs, ";\012") < 0) - goto write_error; - if (fprintf (fprcs, "next ;\012") < 0) - goto write_error; - if (add_vbranch != NULL) - { - if (fprintf (fprcs, "\012%s.1\012", add_vbranch) < 0 || - fprintf (fprcs, "date %s; author %s; state Exp;\012", - altdate2, author) < 0 || - fprintf (fprcs, "branches ;\012") < 0 || - fprintf (fprcs, "next ;\012\012") < 0) + if (fprintf (fprcs, "next ;\012") < 0) goto write_error; + if (add_vbranch != NULL) + { + if (fprintf (fprcs, "\012%s.1\012", add_vbranch) < 0 || + fprintf (fprcs, "date %s; author %s; state Exp;\012", + altdate1, author) < 0 || + fprintf (fprcs, "branches ;\012") < 0 || + fprintf (fprcs, "next ;\012\012") < 0) + goto write_error; + } } - if ( - /* - * putdesc() - */ - fprintf (fprcs, "\012desc\012") < 0 || - fprintf (fprcs, "@@\012\012\012") < 0 || - /* - * putdelta() - */ - fprintf (fprcs, "\012%s\012", add_vhead) < 0 || - fprintf (fprcs, "log\012@") < 0) + + /* Now write the description (possibly empty). */ + if (fprintf (fprcs, "\012desc\012") < 0 || + fprintf (fprcs, "@") < 0) goto write_error; - if (add_vbranch != NULL) - { - /* We are going to put the log message in the revision on the - branch. So putting it here too seems kind of redundant, I - guess (and that is what CVS has always done, anyway). */ - if (fprintf (fprcs, "Initial revision\012") < 0) - goto write_error; - } - else + if (desctext != NULL) { - if (expand_at_signs (message, (off_t) strlen (message), fprcs) < 0) + /* The use of off_t not size_t for the second argument is very + strange, since we are dealing with something which definitely + fits in memory. */ + if (expand_at_signs (desctext, (off_t) desclen, fprcs) < 0) goto write_error; } - if (fprintf (fprcs, "@\012") < 0 || - fprintf (fprcs, "text\012@") < 0) - { + if (fprintf (fprcs, "@\012\012\012") < 0) goto write_error; - } - /* Now copy over the contents of the file, expanding at signs. */ + /* Now write the log messages and contents for the revision(s) (that + is, "deltatext" rather than "delta" from rcsfile(5)). */ + if (add_vhead != NULL) { - char buf[8192]; - unsigned int len; + if (fprintf (fprcs, "\012%s\012", add_vhead) < 0 || + fprintf (fprcs, "log\012@") < 0) + goto write_error; + if (add_vbranch != NULL) + { + /* We are going to put the log message in the revision on the + branch. So putting it here too seems kind of redundant, I + guess (and that is what CVS has always done, anyway). */ + if (fprintf (fprcs, "Initial revision\012") < 0) + goto write_error; + } + else + { + if (expand_at_signs (message, (off_t) strlen (message), fprcs) < 0) + goto write_error; + } + if (fprintf (fprcs, "@\012") < 0 || + fprintf (fprcs, "text\012@") < 0) + { + goto write_error; + } - while (1) + /* Now copy over the contents of the file, expanding at signs. */ { - len = fread (buf, 1, sizeof buf, fpuser); - if (len == 0) + char buf[8192]; + unsigned int len; + + while (1) { - if (ferror (fpuser)) - error (1, errno, "cannot read file %s for copying", user); - break; + len = fread (buf, 1, sizeof buf, fpuser); + if (len == 0) + { + if (ferror (fpuser)) + error (1, errno, "cannot read file %s for copying", + user); + break; + } + if (expand_at_signs (buf, len, fprcs) < 0) + goto write_error; } - if (expand_at_signs (buf, len, fprcs) < 0) - goto write_error; } - } - if (fprintf (fprcs, "@\012\012") < 0) - goto write_error; - if (add_vbranch != NULL) - { - if (fprintf (fprcs, "\012%s.1\012", add_vbranch) < 0 || - fprintf (fprcs, "log\012@") < 0 || - expand_at_signs (message, (off_t) strlen (message), fprcs) < 0 || - fprintf (fprcs, "@\012text\012") < 0 || - fprintf (fprcs, "@@\012") < 0) + if (fprintf (fprcs, "@\012\012") < 0) goto write_error; + if (add_vbranch != NULL) + { + if (fprintf (fprcs, "\012%s.1\012", add_vbranch) < 0 || + fprintf (fprcs, "log\012@") < 0 || + expand_at_signs (message, + (off_t) strlen (message), fprcs) < 0 || + fprintf (fprcs, "@\012text\012") < 0 || + fprintf (fprcs, "@@\012") < 0) + goto write_error; + } } if (fclose (fprcs) == EOF) @@ -1184,7 +1265,7 @@ read_error: * signs. If an error occurs, return a negative value and set errno * to indicate the error. If not, return a nonnegative value. */ -static int +int expand_at_signs (buf, size, fp) char *buf; off_t size; diff --git a/contrib/cvs/src/lock.c b/contrib/cvs/src/lock.c index babadef..be2dd1c 100644 --- a/contrib/cvs/src/lock.c +++ b/contrib/cvs/src/lock.c @@ -3,7 +3,7 @@ * Copyright (c) 1989-1992, Brian Berliner * * You may distribute under the terms of the GNU General Public License as - * specified in the README file that comes with the CVS 1.4 kit. + * specified in the README file that comes with the CVS source distribution. * * Set Lock * @@ -39,9 +39,9 @@ be. * Readlocks ensure that we won't find the file in the state in - which it is in between the "rcs -i" and the RCS_checkin in commit.c - (when a file is being added). This state is a state in which the - RCS file parsing routines in rcs.c cannot parse the file. + which it is in between the calls to add_rcs_file and RCS_checkin in + commit.c (when a file is being added). This state is a state in + which the RCS file parsing routines in rcs.c cannot parse the file. * Readlocks ensure that a reader won't try to look at a half-written fileattr file (fileattr is not updated atomically). diff --git a/contrib/cvs/src/log.c b/contrib/cvs/src/log.c index 3fd37d4..4502e26 100644 --- a/contrib/cvs/src/log.c +++ b/contrib/cvs/src/log.c @@ -3,7 +3,7 @@ * Copyright (c) 1989-1992, Brian Berliner * * You may distribute under the terms of the GNU General Public License as - * specified in the README file that comes with the CVS 1.4 kit. + * specified in the README file that comes with the CVS source distribution. * * Print Log Information * @@ -148,6 +148,7 @@ static const char *const log_usage[] = "\t-d dates\tSpecify dates (D1<D2 for range, D for latest before).\n", "\t-s states\tOnly list revisions with specified states.\n", "\t-w[logins]\tOnly list revisions checked in by specified logins.\n", + "(Specify the --help global option for a list of other help options)\n", NULL }; @@ -469,6 +470,20 @@ log_parse_list (plist, argstring) } } +static int printlock_proc PROTO ((Node *, void *)); + +static int +printlock_proc (lock, foo) + Node *lock; + void *foo; +{ + cvs_output ("\n\t", 2); + cvs_output (lock->data, 0); + cvs_output (": ", 2); + cvs_output (lock->key, 0); + return 0; +} + /* * Do an rlog on a file */ @@ -493,7 +508,7 @@ log_fileproc (callerdat, finfo) Entnode *e; e = (Entnode *) p->data; - if (e->version[0] == '0' || e->version[1] == '\0') + if (e->version[0] == '0' && e->version[1] == '\0') { if (!really_quiet) error (0, 0, "%s has been added, but not committed", @@ -560,98 +575,18 @@ log_fileproc (callerdat, finfo) } cvs_output ("\nlocks:", 0); - if (rcsfile->other != NULL) - { - p = findnode (rcsfile->other, "strict"); - if (p != NULL) - cvs_output (" strict", 0); - p = findnode (rcsfile->other, "locks"); - if (p != NULL && p->data != NULL) - { - char *f, *cp; - - f = xstrdup (p->data); - cp = f; - while (*cp != '\0') - { - char *cp2, *locker, *version; - RCSVers *vnode; - - locker = cp; - - cp2 = strchr (cp, ':'); - if (cp2 == NULL) - { - error (0, 0, "warning: bad locks field in RCS file `%s'", - finfo->fullname); - break; - } - - *cp2 = '\0'; - - cvs_output ("\n\t", 2); - cvs_output (cp, cp2 - cp); - cvs_output (": ", 2); - - cp = cp2 + 1; - while (isspace (*cp) && *cp != '\0') - ++cp; - - version = cp; - - cp2 = cp; - while (! isspace (*cp2) && *cp2 != '\0') - ++cp2; - - cvs_output (cp, cp2 - cp); - - if (*cp2 == '\0') - cp = cp2; - else - { - *cp2 = '\0'; - cp = cp2 + 1; - while (isspace (*cp) && *cp != '\0') - ++cp; - } - - p = findnode (rcsfile->versions, version); - if (p == NULL) - error (0, 0, - "warning: lock for missing version `%s' in `%s'", - version, finfo->fullname); - else - { - vnode = (RCSVers *) p->data; - p = getnode (); - p->type = RCSFIELD; - p->key = xstrdup (";locker"); - p->data = xstrdup (locker); - if (addnode (vnode->other, p) != 0) - { - error (0, 0, - "warning: duplicate lock for `%s' in `%s'", - version, finfo->fullname); - freenode (p); - } - } - } - - free (f); - } - } + if (rcsfile->strict_locks) + cvs_output (" strict", 0); + walklist (RCS_getlocks (rcsfile), printlock_proc, NULL); cvs_output ("\naccess list:", 0); - if (rcsfile->other != NULL) + if (rcsfile->access != NULL) { - p = findnode (rcsfile->other, "access"); - if (p != NULL && p->data != NULL) - { - const char *cp; + const char *cp; - cp = p->data; - while (*cp != '\0') - { + cp = rcsfile->access; + while (*cp != '\0') + { const char *cp2; cvs_output ("\n\t", 2); @@ -662,7 +597,6 @@ log_fileproc (callerdat, finfo) cp = cp2; while (isspace (*cp) && *cp != '\0') ++cp; - } } } @@ -712,12 +646,8 @@ log_fileproc (callerdat, finfo) if (! log_data->header || log_data->long_header) { cvs_output ("description:\n", 0); - if (rcsfile->other != NULL) - { - p = findnode (rcsfile->other, "desc"); - if (p != NULL && p->data != NULL) - cvs_output (p->data, 0); - } + if (rcsfile->desc != NULL) + cvs_output (rcsfile->desc, 0); } if (! log_data->header && ! log_data->long_header && rcsfile->head != NULL) @@ -1276,7 +1206,7 @@ log_version (log_data, revlist, rcs, ver, trunk) cvs_output ("----------------------------\nrevision ", 0); cvs_output (ver->version, 0); - p = findnode (ver->other, ";locker"); + p = findnode (RCS_getlocks (rcs), ver->version); if (p != NULL) { cvs_output ("\tlocked by: ", 0); @@ -1341,7 +1271,14 @@ log_version (log_data, revlist, rcs, ver, trunk) cvs_output ("\n", 1); p = findnode (ver->other, "log"); - if (p == NULL || p->data[0] == '\0') + /* The p->date == NULL case is the normal one for an empty log + message (rcs-14 in sanity.sh). I don't think the case where + p->data is "" can happen (getrcskey in rcs.c checks for an + empty string and set the value to NULL in that case). My guess + would be the p == NULL case would mean an RCS file which was + missing the "log" keyword (which is illegal according to + rcsfile.5). */ + if (p == NULL || p->data == NULL || p->data[0] == '\0') cvs_output ("*** empty log message ***\n", 0); else { diff --git a/contrib/cvs/src/login.c b/contrib/cvs/src/login.c index cc277a6..4ffce36 100644 --- a/contrib/cvs/src/login.c +++ b/contrib/cvs/src/login.c @@ -75,6 +75,7 @@ construct_cvspass_filename () static const char *const login_usage[] = { "Usage: %s %s\n", + "(Specify the --help global option for a list of other help options)\n", NULL }; @@ -112,6 +113,7 @@ login (argc, argv) char *linebuf = (char *) NULL; size_t linebuf_len; int root_len, already_entered = 0; + int line_length; if (argc < 0) usage (login_usage); @@ -121,7 +123,7 @@ login (argc, argv) error (0, 0, "can only use pserver method with `login' command"); error (1, 0, "CVSROOT: %s", CVSroot_original); } - + if (! CVSroot_username) { error (0, 0, "CVSROOT \"%s\" is not fully-qualified.", @@ -143,11 +145,7 @@ login (argc, argv) cvs_password = xstrdup (typed_password); - if (connect_to_pserver (NULL, NULL, 1) == 0) - { - /* The password is wrong, according to the server. */ - error (1, 0, "incorrect password"); - } + connect_to_pserver (NULL, NULL, 1, 0); /* IF we have a password for this "[user@]host:/path" already * THEN @@ -171,7 +169,7 @@ login (argc, argv) if (fp != NULL) { /* Check each line to see if we have this entry already. */ - while (getline (&linebuf, &linebuf_len, fp) >= 0) + while ((line_length = getline (&linebuf, &linebuf_len, fp)) >= 0) { if (strncmp (CVSroot_original, linebuf, root_len) == 0) { @@ -179,8 +177,11 @@ login (argc, argv) break; } } - fclose (fp); + if (fclose (fp) < 0) + error (0, errno, "cannot close %s", passfile); } + else if (!existence_error (errno)) + error (0, errno, "cannot open %s", passfile); if (already_entered) { @@ -219,22 +220,35 @@ login (argc, argv) /* I'm not paranoid, they really ARE out to get me: */ chmod (passfile, 0600); - while (getline (&linebuf, &linebuf_len, fp) >= 0) + while ((line_length = getline (&linebuf, &linebuf_len, fp)) >= 0) { if (strncmp (CVSroot_original, linebuf, root_len)) - fprintf (tmp_fp, "%s", linebuf); + { + if (fprintf (tmp_fp, "%s", linebuf) == EOF) + error (0, errno, "cannot write %s", tmp_name); + } else - fprintf (tmp_fp, "%s %s\n", CVSroot_original, - typed_password); - + { + if (fprintf (tmp_fp, "%s %s\n", CVSroot_original, + typed_password) == EOF) + error (0, errno, "cannot write %s", tmp_name); + } } + if (line_length < 0 && !feof (fp)) + error (0, errno, "cannot read %s", passfile); if (linebuf) free (linebuf); - fclose (tmp_fp); - fclose (fp); + if (fclose (tmp_fp) < 0) + error (0, errno, "cannot close %s", tmp_name); + if (fclose (fp) < 0) + error (0, errno, "cannot close %s", passfile); + + /* FIXME: rename_file would make more sense (e.g. almost + always faster). */ copy_file (tmp_name, passfile); unlink_file (tmp_name); chmod (passfile, 0600); + free (tmp_name); } } @@ -249,8 +263,10 @@ login (argc, argv) return 1; } - fprintf (fp, "%s %s\n", CVSroot_original, typed_password); - fclose (fp); + if (fprintf (fp, "%s %s\n", CVSroot_original, typed_password) == EOF) + error (0, errno, "cannot write %s", passfile); + if (fclose (fp) < 0) + error (0, errno, "cannot close %s", passfile); } /* Utter, total, raving paranoia, I know. */ @@ -276,6 +292,7 @@ get_cvs_password () size_t linebuf_len; FILE *fp; char *passfile; + int line_length; /* If someone (i.e., login()) is calling connect_to_pserver() out of context, then assume they have supplied the correct, scrambled @@ -324,7 +341,7 @@ get_cvs_password () root_len = strlen (CVSroot_original); /* Check each line to see if we have this entry already. */ - while (getline (&linebuf, &linebuf_len, fp) >= 0) + while ((line_length = getline (&linebuf, &linebuf_len, fp)) >= 0) { if (strncmp (CVSroot_original, linebuf, root_len) == 0) { @@ -333,6 +350,10 @@ get_cvs_password () break; } } + if (line_length < 0 && !feof (fp)) + error (0, errno, "cannot read %s", passfile); + if (fclose (fp) < 0) + error (0, errno, "cannot close %s", passfile); if (found_it) { @@ -362,6 +383,7 @@ get_cvs_password () static const char *const logout_usage[] = { "Usage: %s %s\n", + "(Specify the --help global option for a list of other help options)\n", NULL }; @@ -378,6 +400,7 @@ logout (argc, argv) char *linebuf = (char *) NULL; size_t linebuf_len; int root_len, found = 0; + int line_length; if (argc < 0) usage (logout_usage); @@ -430,17 +453,25 @@ logout (argc, argv) /* Check each line to see if we have this entry. */ /* Copy only those lines that do not match this entry */ - while (getline (&linebuf, &linebuf_len, fp) >= 0) + while ((line_length = getline (&linebuf, &linebuf_len, fp)) >= 0) { - if (strncmp (CVSroot_original, linebuf, root_len)) - fprintf (tmp_fp, "%s", linebuf); + if (strncmp (CVSroot_original, linebuf, root_len)) + { + if (fprintf (tmp_fp, "%s", linebuf) == EOF) + error (0, errno, "cannot write %s", tmp_name); + } else - found = TRUE; + found = 1; } + if (line_length < 0 && !feof (fp)) + error (0, errno, "cannot read %s", passfile); + if (linebuf) free (linebuf); - fclose (fp); - fclose (tmp_fp); + if (fclose (fp) < 0) + error (0, errno, "cannot close %s", passfile); + if (fclose (tmp_fp) < 0) + error (0, errno, "cannot close %s", tmp_name); if (! found) { @@ -449,6 +480,8 @@ logout (argc, argv) } else { + /* FIXME: rename_file would make more sense (e.g. almost + always faster). */ copy_file (tmp_name, passfile); unlink_file (tmp_name); chmod (passfile, 0600); diff --git a/contrib/cvs/src/logmsg.c b/contrib/cvs/src/logmsg.c index 2655fd9..67194be 100644 --- a/contrib/cvs/src/logmsg.c +++ b/contrib/cvs/src/logmsg.c @@ -3,7 +3,7 @@ * Copyright (c) 1989-1992, Brian Berliner * * You may distribute under the terms of the GNU General Public License as - * specified in the README file that comes with the CVS 1.4 kit. + * specified in the README file that comes with the CVS source distribution. */ #include "cvs.h" @@ -282,7 +282,7 @@ do_editor (dir, messagep, repository, changes) (void) Parse_Info (CVSROOTADM_EDITINFO, repository, editinfo_proc, 0); /* run the editor */ - run_setup ("%s", editinfo_editor ? editinfo_editor : Editor); + run_setup (editinfo_editor ? editinfo_editor : Editor); run_arg (fname); if ((retcode = run_exec (RUN_TTY, RUN_TTY, RUN_TTY, RUN_NORMAL | RUN_SIGIGNORE)) != 0) @@ -345,8 +345,16 @@ do_editor (dir, messagep, repository, changes) (void) printf ("Action: (continue) "); (void) fflush (stdout); line_length = getline (&line, &line_chars_allocated, stdin); - if (line_length <= 0 - || *line == '\n' || *line == 'c' || *line == 'C') + if (line_length < 0) + { + error (0, errno, "cannot read from stdin"); + if (unlink_file (fname) < 0) + error (0, errno, + "warning: cannot remove temp file %s", fname); + error (1, 0, "aborting"); + } + else if (line_length == 0 + || *line == '\n' || *line == 'c' || *line == 'C') break; if (*line == 'a' || *line == 'A') { @@ -411,10 +419,7 @@ do_verify (message, repository) fp = fopen (fname, "w"); if (fp == NULL) - { error (1, errno, "cannot create temporary file %s", fname); - return; - } else { fprintf (fp, "%s", message); @@ -434,15 +439,21 @@ do_verify (message, repository) if (verifymsg_script) { - run_setup ("%s", verifymsg_script); + run_setup (verifymsg_script); run_arg (fname); if ((retcode = run_exec (RUN_TTY, RUN_TTY, RUN_TTY, RUN_NORMAL | RUN_SIGIGNORE)) != 0) + { + /* Since following error() exits, delete the temp file + now. */ + unlink_file (fname); + error (1, retcode == -1 ? errno : 0, "Message verification failed"); + } } - /* Close and delete the temp file */ + /* Delete the temp file */ unlink_file (fname); free (fname); diff --git a/contrib/cvs/src/main.c b/contrib/cvs/src/main.c index 3352f60..2397d7e 100644 --- a/contrib/cvs/src/main.c +++ b/contrib/cvs/src/main.c @@ -3,7 +3,7 @@ * Copyright (c) 1989-1992, Brian Berliner * * You may distribute under the terms of the GNU General Public License - * as specified in the README file that comes with the CVS 1.4 kit. + * as specified in the README file that comes with the CVS source distribution. * * This is the main C driver for the CVS system. * @@ -33,14 +33,14 @@ char *command_name; char hostname[MAXHOSTNAMELEN]; -int use_editor = TRUE; -int use_cvsrc = TRUE; +int use_editor = 1; +int use_cvsrc = 1; int cvswrite = !CVSREAD_DFLT; -int really_quiet = FALSE; -int quiet = FALSE; -int trace = FALSE; -int noexec = FALSE; -int logoff = FALSE; +int really_quiet = 0; +int quiet = 0; +int trace = 0; +int noexec = 0; +int logoff = 0; mode_t cvsumask = UMASK_DFLT; char *CurDir; @@ -48,7 +48,6 @@ char *CurDir; /* * Defaults, for the environment variables that are not set */ -char *Rcsbin = RCSBIN_DFLT; char *Tmpdir = TMPDIR_DFLT; char *Editor = EDITOR_DFLT; @@ -124,32 +123,47 @@ static const struct cmd static const char *const usg[] = { - "Usage: %s [cvs-options] command [command-options] [files...]\n", - " Where 'cvs-options' are:\n", - " -H Displays Usage information for command\n", - " -Q Cause CVS to be really quiet.\n", - " -q Cause CVS to be somewhat quiet.\n", - " -r Make checked-out files read-only\n", - " -w Make checked-out files read-write (default)\n", - " -l Turn History logging off\n", - " -n Do not execute anything that will change the disk\n", - " -t Show trace of program execution -- Try with -n\n", - " -v CVS version and copyright\n", - " -b bindir Find RCS programs in 'bindir'\n", - " -T tmpdir Use 'tmpdir' for temporary files\n", - " -e editor Use 'editor' for editing log information\n", - " -d CVS_root Overrides $CVSROOT as the root of the CVS tree\n", - " -f Do not use the ~/.cvsrc file\n", -#ifdef CLIENT_SUPPORT - " -z # Use compression level '#' for net traffic.\n", -#ifdef ENCRYPTION - " -x Encrypt all net traffic.\n", -#endif -#endif - " -s VAR=VAL Set CVS user variable.\n", + /* CVS usage messages never have followed the GNU convention of + putting metavariables in uppercase. I don't know whether that + is a good convention or not, but if it changes it would have to + change in all the usage messages. For now, they consistently + use lowercase, as far as I know. Puncutation is pretty funky, + though. Sometimes they use none, as here. Sometimes they use + single quotes (not the TeX-ish `' stuff), as in --help-options. + Sometimes they use double quotes, as in cvs -H add. + + Most (not all) of the usage messages seem to have periods at + the end of each line. I haven't tried to duplicate this style + in --help as it is a rather different format from the rest. */ + + "Usage: %s [cvs-options] command [command-options-and-arguments]\n", + " where cvs-options are -q, -n, etc.\n", + " (specify --help-options for a list of options)\n", + " where command is add, admin, etc.\n", + " (specify --help-commands for a list of commands\n", + " or --help-synonyms for a list of command synonyms)\n", + " where command-options-and-arguments depend on the specific command\n", + " (specify -H followed by a command name for command-specific help)\n", + " Specify --help to receive this message\n", "\n", - " and where 'command' is: add, admin, etc. (use the --help-commands\n", - " option for a list of commands)\n", + + /* Some people think that a bug-reporting address should go here. IMHO, + the web sites are better because anything else is very likely to go + obsolete in the years between a release and when someone might be + reading this help. Besides, we could never adequately discuss + bug reporting in a concise enough way to put in a help message. */ + + /* I was going to put this at the top, but usage() wants the %s to + be in the first line. */ + "The Concurrent Versions System (CVS) is a tool for version control.\n", + /* I really don't think I want to try to define "version control" + in one line. I'm not sure one can get more concise than the + paragraph in ../cvs.spec without assuming the reader knows what + version control means. */ + + "For CVS updates and additional information, see\n", + " Cyclic Software at http://www.cyclic.com/ or\n", + " Pascal Molli's CVS site at http://www.loria.fr/~molli/cvs-index.html\n", NULL, }; @@ -183,17 +197,47 @@ static const char *const cmd_usage[] = " update Bring work tree in sync with repository\n", " watch Set watches\n", " watchers See who is watching a file\n", - "(Use the --help-synonyms option for a list of alternate command names)\n", + "(Specify the --help option for a list of other help options)\n", NULL, }; +static const char *const opt_usage[] = +{ + "CVS global options (specified before the command name) are:\n", + " -H Displays usage information for command.\n", + " -Q Cause CVS to be really quiet.\n", + " -q Cause CVS to be somewhat quiet.\n", + " -r Make checked-out files read-only.\n", + " -w Make checked-out files read-write (default).\n", + " -l Turn history logging off.\n", + " -n Do not execute anything that will change the disk.\n", + " -t Show trace of program execution -- try with -n.\n", + " -v CVS version and copyright.\n", + " -b bindir Find RCS programs in 'bindir'.\n", + " -T tmpdir Use 'tmpdir' for temporary files.\n", + " -e editor Use 'editor' for editing log information.\n", + " -d CVS_root Overrides $CVSROOT as the root of the CVS tree.\n", + " -f Do not use the ~/.cvsrc file.\n", +#ifdef CLIENT_SUPPORT + " -z # Use compression level '#' for net traffic.\n", +#ifdef ENCRYPTION + " -x Encrypt all net traffic.\n", +#endif + " -a Authenticate all net traffic.\n", +#endif + " -s VAR=VAL Set CVS user variable.\n", + "(Specify the --help option for a list of other help options)\n", + NULL +}; + static const char * const* cmd_synonyms () { char ** synonyms; char ** line; const struct cmd *c = &cmds[0]; - int numcmds = 2; /* two more for title and end */ + /* Three more for title, "specify --help" line, and NULL. */ + int numcmds = 3; while (c->fullname != NULL) { @@ -218,6 +262,7 @@ cmd_synonyms () line++; } } + *line++ = "(Specify the --help option for a list of other help options)\n"; *line = NULL; return (const char * const*) synonyms; /* will never be freed */ @@ -328,11 +373,10 @@ main (argc, argv) char *cp, *end; const struct cmd *cm; int c, err = 0; - int rcsbin_update_env, tmpdir_update_env, cvs_update_env; + int tmpdir_update_env, cvs_update_env; int free_CVSroot = 0; int free_Editor = 0; int free_Tmpdir = 0; - int free_Rcsbin = 0; int help = 0; /* Has the user asked for help? This lets us support the `cvs -H cmd' @@ -343,6 +387,7 @@ main (argc, argv) {"version", 0, NULL, 'v'}, {"help-commands", 0, NULL, 1}, {"help-synonyms", 0, NULL, 2}, + {"help-options", 0, NULL, 4}, {"allow-root", required_argument, NULL, 3}, {0, 0, 0, 0} }; @@ -380,12 +425,6 @@ main (argc, argv) * they can be overridden by command line arguments */ cvs_update_env = 0; - rcsbin_update_env = *Rcsbin; /* RCSBIN_DFLT must be set */ - if ((cp = getenv (RCSBIN_ENV)) != NULL) - { - Rcsbin = cp; - rcsbin_update_env = 0; /* it's already there */ - } tmpdir_update_env = *Tmpdir; /* TMPDIR_DFLT must be set */ if ((cp = getenv (TMPDIR_ENV)) != NULL) { @@ -404,7 +443,7 @@ main (argc, argv) cvs_update_env = 0; /* it's already there */ } if (getenv (CVSREAD_ENV) != NULL) - cvswrite = FALSE; + cvswrite = 0; /* Set this to 0 to force getopt initialization. getopt() sets this to 1 internally. */ @@ -421,7 +460,7 @@ main (argc, argv) != EOF) { if (c == 'f') - use_cvsrc = FALSE; + use_cvsrc = 0; } /* @@ -434,7 +473,7 @@ main (argc, argv) opterr = 1; while ((c = getopt_long - (argc, argv, "+Qqrwtnlvb:T:e:d:Hfz:s:x", long_options, &option_index)) + (argc, argv, "+Qqrwtnlvb:T:e:d:Hfz:s:xa", long_options, &option_index)) != EOF) { switch (c) @@ -447,47 +486,59 @@ main (argc, argv) /* --help-synonyms */ usage (cmd_synonyms()); break; + case 4: + /* --help-options */ + usage (opt_usage); + break; case 3: /* --allow-root */ root_allow_add (optarg); break; case 'Q': - really_quiet = TRUE; + really_quiet = 1; /* FALL THROUGH */ case 'q': - quiet = TRUE; + quiet = 1; break; case 'r': - cvswrite = FALSE; + cvswrite = 0; break; case 'w': - cvswrite = TRUE; + cvswrite = 1; break; case 't': - trace = TRUE; + trace = 1; break; case 'n': - noexec = TRUE; + noexec = 1; case 'l': /* Fall through */ - logoff = TRUE; + logoff = 1; break; case 'v': + /* Having the year here is a good idea, so people have + some idea of how long ago their version of CVS was + released. */ (void) fputs (version_string, stdout); (void) fputs (config_string, stdout); (void) fputs ("\n", stdout); - (void) fputs ("Copyright (c) 1993-1994 Brian Berliner\n", stdout); - (void) fputs ("Copyright (c) 1993-1994 david d `zoo' zuhn\n", stdout); - (void) fputs ("Copyright (c) 1992, Brian Berliner and Jeff Polk\n", stdout); - (void) fputs ("Copyright (c) 1989-1992, Brian Berliner\n", stdout); + (void) fputs ("\ +Copyright (c) 1989-1997 Brian Berliner, david d `zoo' zuhn, \n\ + Jeff Polk, and other authors\n", stdout); (void) fputs ("\n", stdout); (void) fputs ("CVS may be copied only under the terms of the GNU General Public License,\n", stdout); (void) fputs ("a copy of which can be found with the CVS distribution kit.\n", stdout); + (void) fputs ("\n", stdout); + + (void) fputs ("Specify the --help option for further information about CVS\n", stdout); + exit (0); break; case 'b': - Rcsbin = xstrdup (optarg); - free_Rcsbin = 1; - rcsbin_update_env = 1; /* need to update environment */ + /* This option used to specify the directory for RCS + executables. But since we don't run them any more, + this is a noop. Silently ignore it so that .cvsrc + and scripts and inetd.conf and such can work with + either new or old CVS. */ break; case 'T': Tmpdir = xstrdup (optarg); @@ -507,7 +558,7 @@ main (argc, argv) help = 1; break; case 'f': - use_cvsrc = FALSE; /* unnecessary, since we've done it above */ + use_cvsrc = 0; /* unnecessary, since we've done it above */ break; case 'z': #ifdef CLIENT_SUPPORT @@ -532,6 +583,15 @@ main (argc, argv) If no ENCRYPTION, we still accept -x, but issue an error if we are being run as a client. */ break; + case 'a': +#ifdef CLIENT_SUPPORT + cvsauthenticate = 1; +#endif + /* If no CLIENT_SUPPORT, ignore -a, so that users can + have it in their .cvsrc and not cause any trouble. + We will issue an error later if stream + authentication is not supported. */ + break; case '?': default: usage (usg); @@ -562,6 +622,9 @@ main (argc, argv) else command_name = cm->fullname; /* Global pointer for later use */ + /* This should probably remain a warning, rather than an error, + for quite a while. For one thing the version of VC distributed + with GNU emacs 19.34 invokes 'cvs rlog' instead of 'cvs log'. */ if (strcmp (argv[0], "rlog") == 0) { error (0, 0, "warning: the rlog command is deprecated"); @@ -605,7 +668,7 @@ main (argc, argv) #endif /* HAVE_KERBEROS */ -#if defined(AUTH_SERVER_SUPPORT) && defined(SERVER_SUPPORT) +#if (defined(AUTH_SERVER_SUPPORT) || defined (HAVE_GSSAPI)) && defined(SERVER_SUPPORT) if (strcmp (command_name, "pserver") == 0) { /* The reason that --allow-root is not a command option @@ -622,15 +685,16 @@ main (argc, argv) /* Pretend we were invoked as a plain server. */ command_name = "server"; } -#endif /* AUTH_SERVER_SUPPORT && SERVER_SUPPORT */ +#endif /* (AUTH_SERVER_SUPPORT || HAVE_GSSAPI) && SERVER_SUPPORT */ +#ifdef SERVER_SUPPORT + server_active = strcmp (command_name, "server") == 0; /* Fiddling with CVSROOT doesn't make sense if we're running in server mode, since the client will send the repository directory after the connection is made. */ -#ifdef SERVER_SUPPORT - if (strcmp (command_name, "server") != 0) + if (!server_active) #endif { char *CVSADM_Root; @@ -777,7 +841,7 @@ main (argc, argv) it is worth the trouble. */ #ifdef SERVER_SUPPORT - if (strcmp (command_name, "server") == 0) + if (server_active) CurDir = xstrdup ("<remote>"); else #endif @@ -791,16 +855,6 @@ main (argc, argv) Tmpdir = "/tmp"; #ifdef HAVE_PUTENV - /* Now, see if we should update the environment with the - Rcsbin value */ - if (rcsbin_update_env) - { - char *env; - env = xmalloc (strlen (RCSBIN_ENV) + strlen (Rcsbin) + 1 + 1); - (void) sprintf (env, "%s=%s", RCSBIN_ENV, Rcsbin); - (void) putenv (env); - /* do not free env, as putenv has control of it */ - } if (tmpdir_update_env) { char *env; @@ -811,24 +865,6 @@ main (argc, argv) } #endif - /* - * If Rcsbin is set to something, make sure it is terminated with - * a slash character. If not, add one. - */ - if (*Rcsbin) - { - int len = strlen (Rcsbin); - char *rcsbin; - - if (Rcsbin[len - 1] != '/') - { - rcsbin = Rcsbin; - Rcsbin = xmalloc (len + 2); /* one for '/', one for NULL */ - (void) strcpy (Rcsbin, rcsbin); - (void) strcat (Rcsbin, "/"); - } - } - #ifndef DONT_USE_SIGNALS /* make sure we clean up on error */ #ifdef SIGHUP @@ -866,6 +902,28 @@ main (argc, argv) if (use_cvsrc) read_cvsrc (&argc, &argv, command_name); + /* Parse the CVSROOT/config file, but only for local. For the + server, we parse it after we know $CVSROOT. For the + client, it doesn't get parsed at all, obviously. The + presence of the parse_config call here is not mean to + predetermine whether CVSROOT/config overrides things from + read_cvsrc and other such places or vice versa. That sort + of thing probably needs more thought. */ + if (1 +#ifdef SERVER_SUPPORT + && !server_active +#endif +#ifdef CLIENT_SUPPORT + && !client_active +#endif + ) + { + /* If there was an error parsing the config file, parse_config + already printed an error. We keep going. Why? Because + if we didn't, then there would be no way to check in a new + CVSROOT/config file to fix the broken one! */ + parse_config (CVSroot_directory); + } } /* end of stuff that gets done if the user DOESN'T ask for help */ err = (*(cm->func)) (argc, argv); @@ -874,7 +932,10 @@ main (argc, argv) { /* Update the CVS/Root file. We might want to do this in all directories that we recurse into, but currently we - don't. */ + don't. Note that if there is an error writing the file, + we give an error/warning. This is so if users try to rewrite + CVS/Root with the -d option (a documented feature), they will + either succeed, or be told why it didn't work. */ Create_Root (NULL, CVSroot); } @@ -887,8 +948,6 @@ main (argc, argv) free (Editor); if (free_Tmpdir) free (Tmpdir); - if (free_Rcsbin) - free (Rcsbin); root_allow_free (); #ifdef SYSTEM_CLEANUP @@ -900,6 +959,8 @@ main (argc, argv) /* This is exit rather than return because apparently that keeps some tools which check for memory leaks happier. */ exit (err ? EXIT_FAILURE : 0); + /* Keep picky/stupid compilers (e.g. Visual C++ 5.0) happy. */ + return 0; } char * @@ -914,11 +975,14 @@ Make_Date (rawdate) unixtime = get_date (rawdate, (struct timeb *) NULL); if (unixtime == (time_t) - 1) error (1, 0, "Can't parse date/time: %s", rawdate); -#ifdef HAVE_RCS5 + ftm = gmtime (&unixtime); -#else - ftm = localtime (&unixtime); -#endif + if (ftm == NULL) + /* This is a system, like VMS, where the system clock is in local + time. Hopefully using localtime here matches the "zero timezone" + hack I added to get_date. */ + ftm = localtime (&unixtime); + (void) sprintf (date, DATEFORM, ftm->tm_year + (ftm->tm_year < 100 ? 0 : 1900), ftm->tm_mon + 1, ftm->tm_mday, ftm->tm_hour, diff --git a/contrib/cvs/src/mkmodules.c b/contrib/cvs/src/mkmodules.c index ec5d770..3c63433 100644 --- a/contrib/cvs/src/mkmodules.c +++ b/contrib/cvs/src/mkmodules.c @@ -275,6 +275,12 @@ static const char *const modules_contents[] = { NULL }; +static const char *const config_contents[] = { + "# Set this to \"no\" if pserver shouldn't check system users/passwords\n", + "#SystemAuth=no\n", + NULL +}; + static const struct admin_file filelist[] = { {CVSROOTADM_LOGINFO, "no logging of 'cvs commit' messages is done without a %s file", @@ -316,14 +322,27 @@ static const struct admin_file filelist[] = { {CVSROOTADM_WRITERS, "a %s file specifies read/write users", NULL}, - /* Some have suggested listing CVSROOTADM_PASSWD here too. The - security implications of transmitting hashed passwords over the - net are no worse than transmitting cleartext passwords which pserver - does, so this isn't a problem. But I'm worried about the implications - of storing old passwords--if someone used a password in the past - they might be using it elsewhere, using a similar password, etc, - and so it doesn't seem to me like we should be saving old passwords, - even hashed. */ + + /* Some have suggested listing CVSROOTADM_PASSWD here too. This + would mean that CVS commands which operate on the + CVSROOTADM_PASSWD file would transmit hashed passwords over the + net. This might seem to be no big deal, as pserver normally + transmits cleartext passwords, but the difference is that + CVSROOTADM_PASSWD contains *all* passwords, not just the ones + currently being used. For example, it could be too easy to + accidentally give someone readonly access to CVSROOTADM_PASSWD + (e.g. via anonymous CVS or cvsweb), and then if there are any + guessable passwords for read/write access (usually there will be) + they get read/write access. + + Another worry is the implications of storing old passwords--if + someone used a password in the past they might be using it + elsewhere, using a similar password, etc, and so saving old + passwords, even hashed, is probably not a good idea. */ + + {CVSROOTADM_CONFIG, + "a %s file configures various behaviors", + config_contents}, {NULL, NULL} }; @@ -694,6 +713,7 @@ rename_rcsfile (temp, real) const char *const init_usage[] = { "Usage: %s %s\n", + "(Specify the --help global option for a list of other help options)\n", NULL }; @@ -785,8 +805,12 @@ init (argc, argv) "initial checkin" but I fail to see the point as we know what file it is from the name. */ retcode = add_rcs_file ("initial checkin", info_v, - fileptr->filename, "1.1", NULL, NULL, - 0, NULL, NULL); + fileptr->filename, "1.1", NULL, + + /* No vendor branch. */ + NULL, NULL, 0, NULL, + + NULL, 0, NULL); if (retcode != 0) /* add_rcs_file already printed an error message. */ err = 1; diff --git a/contrib/cvs/src/modules.c b/contrib/cvs/src/modules.c index e01f733..de95f7e 100644 --- a/contrib/cvs/src/modules.c +++ b/contrib/cvs/src/modules.c @@ -3,7 +3,7 @@ * Copyright (c) 1989-1992, Brian Berliner * * You may distribute under the terms of the GNU General Public License - * as specified in the README file that comes with the CVS 1.4 kit. + * as specified in the README file that comes with the CVS source distribution. * * Modules * @@ -36,8 +36,15 @@ struct sortrec { + /* Name of the module, malloc'd. */ char *modname; + /* If Status variable is set, this is either def_status or the malloc'd + name of the status. If Status is not set, the field is left + uninitialized. */ char *status; + /* Pointer to a malloc'd array which contains (1) the raw contents + of the options and arguments, excluding comments, (2) a '\0', + and (3) the storage for the "comment" field. */ char *rest; char *comment; }; @@ -127,7 +134,7 @@ do_module (db, mname, m_type, msg, callback_proc, where, #ifdef SERVER_SUPPORT int restore_server_dir = 0; - char *server_dir_to_restore; + char *server_dir_to_restore = NULL; if (trace) { char *buf; @@ -268,6 +275,11 @@ do_module (db, mname, m_type, msg, callback_proc, where, } is_found = 1; } + else + { + /* This initialization suppresses a warning from gcc -Wall. */ + value = NULL; + } } free (attic_file); free (file); @@ -384,24 +396,10 @@ do_module (db, mname, m_type, msg, callback_proc, where, { char *nullrepos; - nullrepos = xmalloc (strlen (CVSroot_directory) - + sizeof (CVSROOTADM) - + sizeof (CVSNULLREPOS) - + 10); - (void) sprintf (nullrepos, "%s/%s/%s", CVSroot_directory, - CVSROOTADM, CVSNULLREPOS); - if (!isfile (nullrepos)) - { - mode_t omask; - omask = umask (cvsumask); - (void) CVS_MKDIR (nullrepos, 0777); - (void) umask (omask); - } - if (!isdir (nullrepos)) - error (1, 0, "there is no repository %s", nullrepos); + nullrepos = emptydir_name (); Create_Admin (".", dir, - nullrepos, (char *) NULL, (char *) NULL, 0); + nullrepos, (char *) NULL, (char *) NULL, 0, 0); if (!noexec) { FILE *fp; @@ -439,7 +437,7 @@ do_module (db, mname, m_type, msg, callback_proc, where, (void) sprintf (line, "%s %s", "XXX", value); /* turn the line into an argv[] array */ - line2argv (&xmodargc, &xmodargv, line); + line2argv (&xmodargc, &xmodargv, line, " \t"); free (line); modargc = xmodargc; modargv = xmodargv; @@ -541,6 +539,15 @@ do_module (db, mname, m_type, msg, callback_proc, where, goto do_module_return; } + if (mfile != NULL && modargc > 1) + { + error (0, 0, "\ +module `%s' is a request for a file in a module which is not a directory", + mname); + ++err; + goto do_module_return; + } + /* otherwise, process this module */ err += callback_proc (&modargc, modargv, where, mwhere, mfile, shorten, local_specified, mname, msg); @@ -698,7 +705,8 @@ do_module (db, mname, m_type, msg, callback_proc, where, expanded_path = expand_path (prog, "modules", 0); if (expanded_path != NULL) { - run_setup ("%s %s", expanded_path, real_where); + run_setup (expanded_path); + run_arg (real_where); if (extra_arg) run_arg (extra_arg); @@ -849,15 +857,19 @@ save_d (k, ks, d, ds) { s_rec->status = def_status; - /* Minor kluge, but general enough to maintain */ for (cp = s_rec->rest; (cp2 = strchr (cp, '-')) != NULL; cp = ++cp2) { if (*(cp2 + 1) == 's' && *(cp2 + 2) == ' ') { - s_rec->status = (cp2 += 3); - while (*cp2 != ' ') + char *status_start; + + cp2 += 3; + status_start = cp2; + while (*cp2 != ' ' && *cp2 != '\0') cp2++; - *cp2++ = '\0'; + s_rec->status = xmalloc (cp2 - status_start + 1); + strncpy (s_rec->status, status_start, cp2 - status_start); + s_rec->status[cp2 - status_start] = '\0'; cp = cp2; break; } @@ -934,15 +946,13 @@ cat_module (status) line = xmalloc (strlen (s_h->status) + 15); sprintf (line, " %-11s", s_h->status); cvs_output (line, 0); - if (s_h->status != def_status) - *(s_h->status + strlen (s_h->status)) = ' '; free (line); } line = xmalloc (strlen (s_h->modname) + strlen (s_h->rest) + 15); /* Parse module file entry as command line and print options */ (void) sprintf (line, "%s %s", s_h->modname, s_h->rest); - line2argv (&moduleargc, &moduleargv, line); + line2argv (&moduleargc, &moduleargv, line, " \t"); free (line); argc = moduleargc; argv = moduleargv; @@ -1032,5 +1042,11 @@ cat_module (status) } free_names(&moduleargc, moduleargv); + /* FIXME-leak: here is where we would free s_h->modname, s_h->rest, + and if applicable, s_h->status. Not exactly a memory leak, + in the sense that we are about to exit(), but may be worth + noting if we ever do a multithreaded server or something of + the sort. */ } + /* FIXME-leak: as above, here is where we would free s_head. */ } diff --git a/contrib/cvs/src/myndbm.c b/contrib/cvs/src/myndbm.c index 1a3fcae..949ac78 100644 --- a/contrib/cvs/src/myndbm.c +++ b/contrib/cvs/src/myndbm.c @@ -2,7 +2,7 @@ * Copyright (c) 1992, Brian Berliner * * You may distribute under the terms of the GNU General Public License as - * specified in the README file that comes with the CVS 1.4 kit. + * specified in the README file that comes with the CVS source distribution. * * A simple ndbm-emulator for CVS. It parses a text file of the format: * @@ -21,6 +21,8 @@ static void mydbm_load_file PROTO ((FILE *, List *)); +/* Returns NULL on error in which case errno has been set to indicate + the error. Can also call error() itself. */ /* ARGSUSED */ DBM * mydbm_open (file, flags, mode) @@ -203,11 +205,12 @@ mydbm_load_file (fp, list) size_t value_allocated; char *cp, *vp; int len, cont; + int line_length; value_allocated = 1; value = xmalloc (value_allocated); - for (cont = 0; getline (&line, &line_len, fp) >= 0;) + for (cont = 0; (line_length = getline (&line, &line_len, fp)) >= 0;) { if ((cp = strrchr (line, '\012')) != NULL) *cp = '\0'; /* strip the newline */ @@ -288,6 +291,10 @@ mydbm_load_file (fp, list) } } } + if (line_length < 0 && !feof (fp)) + /* FIXME: should give the name of the file. */ + error (0, errno, "cannot read file in mydbm_load_file"); + free (line); free (value); } diff --git a/contrib/cvs/src/no_diff.c b/contrib/cvs/src/no_diff.c index 384800f..6d6a6fb 100644 --- a/contrib/cvs/src/no_diff.c +++ b/contrib/cvs/src/no_diff.c @@ -3,7 +3,7 @@ * Copyright (c) 1989-1992, Brian Berliner * * You may distribute under the terms of the GNU General Public License as - * specified in the README file that comes with the CVS 1.4 kit. + * specified in the README file that comes with the CVS source distribution. * * No Difference * diff --git a/contrib/cvs/src/options.h.in b/contrib/cvs/src/options.h.in index 476d747..144980e 100644 --- a/contrib/cvs/src/options.h.in +++ b/contrib/cvs/src/options.h.in @@ -3,7 +3,7 @@ * Copyright (c) 1989-1992, Brian Berliner * * You may distribute under the terms of the GNU General Public License as - * specified in the README file that comes with the CVS 1.4 kit. + * specified in the README file that comes with the CVS source distribution. * * This file holds (most of) the configuration tweaks that can be made to * customize CVS for your site. CVS comes configured for a typical SunOS 4.x @@ -16,19 +16,6 @@ */ /* - * CVS provides the most features when used in conjunction with the - * Version-5 release of RCS. Thus, it is the default. This also - * assumes that GNU diff Version-1.15 is being used as well -- you - * will have to configure your RCS V5 release separately to make this - * the case. If you do not have RCS V5 and GNU diff V1.15, comment out - * this define. You should not try mixing and matching other - * combinations of these tools. - */ -#ifndef HAVE_RCS5 -#define HAVE_RCS5 -#endif - -/* * For portability and heterogeneity reasons, CVS is shipped by * default using my own text-file version of the ndbm database library * in the src/myndbm.c file. If you want better performance and are @@ -40,23 +27,6 @@ #endif /* - * The "diff" program to execute when creating patch output. This - * "diff" must support the "-c" option for context diffing. Specify a - * full pathname if your site wants to use a particular diff. Note - * that unlike the diff used with RCS, you *must not* supply -a here - * (doing so will cause the server to generate patches which patch - * cannot handle in some cases). - * - * NOTE: this program is only used for the ``patch'' sub-command (and - * for ``update'' if you are using the server). The other commands - * use rcsdiff which will use whatever version of diff was specified - * when rcsdiff was built on your system. - */ -#ifndef DIFF -#define DIFF "diff" -#endif - -/* * The "patch" program to run when using the CVS server and accepting * patches across the network. Specify a full pathname if your site * wants to use a particular patch. @@ -65,41 +35,6 @@ #define PATCH_PROGRAM "patch" #endif -/* - * By default, RCS programs are executed with the shell or through - * execlp(), so the user's PATH environment variable is searched. If - * you'd like to bind all RCS programs to a certain directory (perhaps - * one not in most people's PATH) then set the default in RCSBIN_DFLT. - * Note that setting this here will cause all RCS programs to be - * executed from this directory, unless the user overrides the default - * with the RCSBIN environment variable or the "-b" option to CVS. - * - * If you use the password-authenticating server, then you need to - * make sure that the server can find the RCS programs to invoke them. - * The authenticating server starts out running as root, and then - * switches to run as the appropriate user once authentication is - * complete. But no actual shell is ever started by that user, so the - * PATH environment variable may not contain the directory with the - * RCS binaries, even though if that user logged in normally, PATH - * would include the directory. - * - * One way to solve this problem is to set RCSBIN_DFLT here. An - * alternative is to make sure that root has the right directory in - * its path already. Another, probably better alternative is to - * specify -b in /etc/inetd.conf. - * - * You may also have to set RCSBIN_DFLT here if there's no global - * start-up script run for users by rshd and your RCS programs are not - * in a directory in the default PATH assigned by rshd. - * - * This define should be either the empty string ("") or a full - * pathname to the directory containing all the installed programs - * from the RCS distribution. - */ -#ifndef RCSBIN_DFLT -#define RCSBIN_DFLT "" -#endif - /* Directory used for storing temporary files, if not overridden by environment variables or the -T global option. There should be little need to change this (-T is a better mechanism if you need to use a @@ -149,10 +84,14 @@ * working directory. This path is either a full-path or a path * relative to CVSROOT. * - * The only advantage that I can see to having a relative path is that + * The big advantage that I can see to having a relative path is that * one can change the physical location of the master source - * repository, change one's CVSROOT environment variable, and CVS will - * work without problems. I recommend using full-paths. + * repository, change the contents of CVS/Root files in your + * checked-out code, and CVS will work without problems. + * + * This is likely to be the default in the future, but we want to give + * people who may be relying on absolute pathnames time to update + * their scripts/software. */ #ifndef RELATIVE_REPOS /* #define RELATIVE_REPOS */ @@ -261,8 +200,3 @@ #ifndef STDC_HEADERS extern void exit (); #endif - -#ifndef getwd -extern char *getwd (); -#endif - diff --git a/contrib/cvs/src/parseinfo.c b/contrib/cvs/src/parseinfo.c index 833463a..c492be0 100644 --- a/contrib/cvs/src/parseinfo.c +++ b/contrib/cvs/src/parseinfo.c @@ -3,11 +3,12 @@ * Copyright (c) 1989-1992, Brian Berliner * * You may distribute under the terms of the GNU General Public License as - * specified in the README file that comes with the CVS 1.4 kit. + * specified in the README file that comes with the CVS source distribution. */ #include "cvs.h" #include "getline.h" +#include <assert.h> /* * Parse the INFOFILE file for the specified REPOSITORY. Invoke CALLPROC for @@ -62,7 +63,7 @@ Parse_Info (infofile, repository, callproc, all) srepos = Short_Repository (repository); if (trace) - (void) fprintf (stderr, "-> ParseInfo(%s, %s, %s)\n", + (void) fprintf (stderr, " -> ParseInfo(%s, %s, %s)\n", infopath, srepos, all ? "ALL" : "not ALL"); /* search the info file for lines that match */ @@ -185,3 +186,183 @@ Parse_Info (infofile, repository, callproc, all) return (err); } + + +/* Parse the CVS config file. The syntax right now is a bit ad hoc + but tries to draw on the best or more common features of the other + *info files and various unix (or non-unix) config file syntaxes. + Lines starting with # are comments. Settings are lines of the form + KEYWORD=VALUE. There is currently no way to have a multi-line + VALUE (would be nice if there was, probably). + + CVSROOT is the $CVSROOT directory (CVSroot_directory might not be + set yet). + + Returns 0 for success, negative value for failure. Call + error(0, ...) on errors in addition to the return value. */ +int +parse_config (cvsroot) + char *cvsroot; +{ + char *infopath; + FILE *fp_info; + char *line = NULL; + size_t line_allocated = 0; + size_t len; + char *p; + /* FIXME-reentrancy: If we do a multi-threaded server, this would need + to go to the per-connection data structures. */ + static int parsed = 0; + + /* Authentication code and serve_root might both want to call us. + Let this happen smoothly. */ + if (parsed) + return 0; + parsed = 1; + + infopath = malloc (strlen (cvsroot) + + sizeof (CVSROOTADM_CONFIG) + + sizeof (CVSROOTADM) + + 10); + if (infopath == NULL) + { + error (0, 0, "out of memory; cannot allocate infopath"); + goto error_return; + } + + strcpy (infopath, cvsroot); + strcat (infopath, "/"); + strcat (infopath, CVSROOTADM); + strcat (infopath, "/"); + strcat (infopath, CVSROOTADM_CONFIG); + + fp_info = CVS_FOPEN (infopath, "r"); + if (fp_info == NULL) + { + /* If no file, don't do anything special. */ + if (!existence_error (errno)) + { + /* Just a warning message; doesn't affect return + value, currently at least. */ + error (0, errno, "cannot open %s", infopath); + } + free (infopath); + return 0; + } + + while (getline (&line, &line_allocated, fp_info) >= 0) + { + /* Skip comments. */ + if (line[0] == '#') + continue; + + /* At least for the moment we don't skip whitespace at the start + of the line. Too picky? Maybe. But being insufficiently + picky leads to all sorts of confusion, and it is a lot easier + to start out picky and relax it than the other way around. + + Is there any kind of written standard for the syntax of this + sort of config file? Anywhere in POSIX for example (I guess + makefiles are sort of close)? Red Hat Linux has a bunch of + these too (with some GUI tools which edit them)... + + Along the same lines, we might want a table of keywords, + with various types (boolean, string, &c), as a mechanism + for making sure the syntax is consistent. Any good examples + to follow there (Apache?)? */ + + /* Strip the training newline. There will be one unless we + read a partial line without a newline, and then got end of + file (or error?). */ + + len = strlen (line) - 1; + if (line[len] == '\n') + line[len] = '\0'; + + /* Skip blank lines. */ + if (line[0] == '\0') + continue; + + /* The first '=' separates keyword from value. */ + p = strchr (line, '='); + if (p == NULL) + { + /* Probably should be printing line number. */ + error (0, 0, "syntax error in %s: line '%s' is missing '='", + infopath, line); + goto error_return; + } + + *p++ = '\0'; + + if (strcmp (line, "RCSBIN") == 0) + { + /* This option used to specify the directory for RCS + executables. But since we don't run them any more, + this is a noop. Silently ignore it so that a + repository can work with either new or old CVS. */ + ; + } + else if (strcmp (line, "SystemAuth") == 0) + { + if (strcmp (p, "no") == 0) +#ifdef AUTH_SERVER_SUPPORT + system_auth = 0; +#else + /* Still parse the syntax but ignore the + option. That way the same config file can + be used for local and server. */ + ; +#endif + else if (strcmp (p, "yes") == 0) +#ifdef AUTH_SERVER_SUPPORT + system_auth = 1; +#else + ; +#endif + else + { + error (0, 0, "unrecognized value '%s' for SystemAuth", p); + goto error_return; + } + } + else + { + /* We may be dealing with a keyword which was added in a + subsequent version of CVS. In that case it is a good idea + to complain, as (1) the keyword might enable a behavior like + alternate locking behavior, in which it is dangerous and hard + to detect if some CVS's have it one way and others have it + the other way, (2) in general, having us not do what the user + had in mind when they put in the keyword violates the + principle of least surprise. Note that one corollary is + adding new keywords to your CVSROOT/config file is not + particularly recommended unless you are planning on using + the new features. */ + error (0, 0, "%s: unrecognized keyword '%s'", + infopath, line); + goto error_return; + } + } + if (ferror (fp_info)) + { + error (0, errno, "cannot read %s", infopath); + goto error_return; + } + if (fclose (fp_info) < 0) + { + error (0, errno, "cannot close %s", infopath); + goto error_return; + } + free (infopath); + if (line != NULL) + free (line); + return 0; + + error_return: + if (infopath != NULL) + free (infopath); + if (line != NULL) + free (line); + return -1; +} diff --git a/contrib/cvs/src/patch.c b/contrib/cvs/src/patch.c index 194999b..9d091c3 100644 --- a/contrib/cvs/src/patch.c +++ b/contrib/cvs/src/patch.c @@ -3,7 +3,7 @@ * Copyright (c) 1989-1992, Brian Berliner * * You may distribute under the terms of the GNU General Public License as - * specified in the README file that comes with the CVS 1.4 kit. + * specified in the README file that comes with the CVS source distribution. * * Patch * @@ -54,6 +54,7 @@ static const char *const patch_usage[] = "\t-D date\tDate.\n", "\t-r rev\tRevision - symbolic or numeric.\n", "\t-V vers\tUse RCS Version \"vers\" for keyword expansion.\n", + "(Specify the --help global option for a list of other help options)\n", NULL }; @@ -385,6 +386,7 @@ patch_fileproc (callerdat, finfo) size_t line2_chars_allocated; char *cp1, *cp2; FILE *fp; + int line_length; line1 = NULL; line1_chars_allocated = 0; @@ -461,23 +463,39 @@ patch_fileproc (callerdat, finfo) if (patch_short) { - (void) printf ("File %s ", finfo->fullname); + cvs_output ("File ", 0); + cvs_output (finfo->fullname, 0); if (vers_tag == NULL) - (void) printf ("is new; current revision %s\n", vers_head); + { + cvs_output (" is new; current revision ", 0); + cvs_output (vers_head, 0); + cvs_output ("\n", 1); + } else if (vers_head == NULL) { - (void) printf ("is removed; not included in "); + cvs_output (" is removed; not included in ", 0); if (rev2 != NULL) - (void) printf ("release tag %s", rev2); + { + cvs_output ("release tag ", 0); + cvs_output (rev2, 0); + } else if (date2 != NULL) - (void) printf ("release date %s", date2); + { + cvs_output ("release date ", 0); + cvs_output (date2, 0); + } else - (void) printf ("current release"); - (void) printf ("\n"); + cvs_output ("current release", 0); + cvs_output ("\n", 1); } else - (void) printf ("changed from revision %s to %s\n", - vers_tag, vers_head); + { + cvs_output (" changed from revision ", 0); + cvs_output (vers_tag, 0); + cvs_output (" to ", 0); + cvs_output (vers_head, 0); + cvs_output ("\n", 1); + } ret = 0; goto out2; } @@ -542,11 +560,8 @@ patch_fileproc (callerdat, finfo) and therefore should be on the server, not the client. */ (void) utime (tmpfile2, &t); } - run_setup ("%s -%c", DIFF, unidiff ? 'u' : 'c'); - run_arg (tmpfile1); - run_arg (tmpfile2); - switch (run_exec (RUN_TTY, tmpfile3, RUN_TTY, RUN_REALLY)) + switch (diff_exec (tmpfile1, tmpfile2, unidiff ? "-u" : "-c", tmpfile3)) { case -1: /* fork/wait failure */ error (1, errno, "fork for diff failed on %s", rcs); @@ -561,9 +576,9 @@ patch_fileproc (callerdat, finfo) */ /* Output an "Index:" line for patch to use */ - (void) fflush (stdout); - (void) printf ("Index: %s\n", finfo->fullname); - (void) fflush (stdout); + cvs_output ("Index: ", 0); + cvs_output (finfo->fullname, 0); + cvs_output ("\n", 1); fp = open_file (tmpfile3, "r"); if (getline (&line1, &line1_chars_allocated, fp) < 0 || @@ -628,25 +643,49 @@ patch_fileproc (callerdat, finfo) (void) sprintf (file2, "%s:%s", finfo->fullname, vers_head ? vers_head : "removed"); - /* Note that this prints "diff" not DIFF. The format of a diff - does not depend on the name of the program which happens to - have produced it. */ + /* Note that the string "diff" is specified by POSIX (for -c) + and is part of the diff output format, not the name of a + program. */ if (unidiff) { - (void) printf ("diff -u %s %s\n", file1, file2); - (void) printf ("--- %s%s+++ ", file1, cp1); + cvs_output ("diff -u ", 0); + cvs_output (file1, 0); + cvs_output (" ", 1); + cvs_output (file2, 0); + cvs_output ("\n", 1); + + cvs_output ("--- ", 0); + cvs_output (file1, 0); + cvs_output (cp1, 0); + cvs_output ("+++ ", 0); } else { - (void) printf ("diff -c %s %s\n", file1, file2); - (void) printf ("*** %s%s--- ", file1, cp1); + cvs_output ("diff -c ", 0); + cvs_output (file1, 0); + cvs_output (" ", 1); + cvs_output (file2, 0); + cvs_output ("\n", 1); + + cvs_output ("*** ", 0); + cvs_output (file1, 0); + cvs_output (cp1, 0); + cvs_output ("--- ", 0); } - (void) printf ("%s%s", finfo->fullname, cp2); + cvs_output (finfo->fullname, 0); + cvs_output (cp2, 0); + /* spew the rest of the diff out */ - while (getline (&line1, &line1_chars_allocated, fp) >= 0) - (void) fputs (line1, stdout); - (void) fclose (fp); + while ((line_length + = getline (&line1, &line1_chars_allocated, fp)) + >= 0) + cvs_output (line1, 0); + if (line_length < 0 && !feof (fp)) + error (0, errno, "cannot read %s", tmpfile3); + + if (fclose (fp) < 0) + error (0, errno, "cannot close %s", tmpfile3); free (file1); free (file2); break; @@ -658,10 +697,12 @@ patch_fileproc (callerdat, finfo) free (line1); if (line2) free (line2); - /* FIXME: should be checking for errors. */ - (void) CVS_UNLINK (tmpfile1); - (void) CVS_UNLINK (tmpfile2); - (void) CVS_UNLINK (tmpfile3); + if (CVS_UNLINK (tmpfile1) < 0) + error (0, errno, "cannot unlink %s", tmpfile1); + if (CVS_UNLINK (tmpfile2) < 0) + error (0, errno, "cannot unlink %s", tmpfile2); + if (CVS_UNLINK (tmpfile3) < 0) + error (0, errno, "cannot unlink %s", tmpfile3); free (tmpfile1); free (tmpfile2); free (tmpfile3); diff --git a/contrib/cvs/src/rcs.c b/contrib/cvs/src/rcs.c index a49c449..c134d67 100644 --- a/contrib/cvs/src/rcs.c +++ b/contrib/cvs/src/rcs.c @@ -2,7 +2,7 @@ * Copyright (c) 1992, Brian Berliner and Jeff Polk * * You may distribute under the terms of the GNU General Public License as - * specified in the README file that comes with the CVS 1.4 kit. + * specified in the README file that comes with the CVS source distribution. * * The routines contained in this file do all the rcs file parsing and * manipulation @@ -10,6 +10,7 @@ #include <assert.h> #include "cvs.h" +#include "edit.h" /* The RCS -k options, and a set of enums that must match the array. These come first so that we can use enum kflag in function @@ -19,7 +20,6 @@ static const char *const kflags[] = enum kflag { KFLAG_KV = 0, KFLAG_KVL, KFLAG_K, KFLAG_V, KFLAG_O, KFLAG_B }; static RCSNode *RCS_parsercsfile_i PROTO((FILE * fp, const char *rcsfile)); -static void RCS_reparsercsfile PROTO((RCSNode *, int, FILE **)); static char *RCS_getdatebranch PROTO((RCSNode * rcs, char *date, char *branch)); static int getrcskey PROTO((FILE * fp, char **keyp, char **valp, size_t *lenp)); @@ -27,7 +27,9 @@ static void getrcsrev PROTO ((FILE *fp, char **revp)); static int checkmagic_proc PROTO((Node *p, void *closure)); static void do_branches PROTO((List * list, char *val)); static void do_symbols PROTO((List * list, char *val)); +static void do_locks PROTO((List * list, char *val)); static void free_rcsnode_contents PROTO((RCSNode *)); +static void free_rcsvers_contents PROTO((RCSVers *)); static void rcsvers_delproc PROTO((Node * p)); static char *translate_symtag PROTO((RCSNode *, const char *)); static char *printable_date PROTO((const char *)); @@ -41,6 +43,24 @@ enum rcs_delta_op {RCS_ANNOTATE, RCS_FETCH}; static void RCS_deltas PROTO ((RCSNode *, FILE *, char *, enum rcs_delta_op, char **, size_t *, char **, size_t *)); +/* Routines for reading, parsing and writing RCS files. */ +static RCSVers *getdelta PROTO ((FILE *, char *)); +static Deltatext *RCS_getdeltatext PROTO ((RCSNode *, FILE *)); +static void freedeltatext PROTO ((Deltatext *)); + +static void RCS_putadmin PROTO ((RCSNode *, FILE *)); +static void RCS_putdtree PROTO ((RCSNode *, char *, FILE *)); +static void RCS_putdesc PROTO ((RCSNode *, FILE *)); +static void putdelta PROTO ((RCSVers *, FILE *)); +static int putrcsfield_proc PROTO ((Node *, void *)); +static int putsymbol_proc PROTO ((Node *, void *)); +static void RCS_copydeltas PROTO ((RCSNode *, FILE *, FILE *, Deltatext *, char *)); +static void putdeltatext PROTO ((FILE *, Deltatext *)); + +static FILE *rcs_internal_lockfile PROTO ((char *)); +static void rcs_internal_unlockfile PROTO ((FILE *, char *)); +static char *rcs_lockfilename PROTO ((char *)); + /* * We don't want to use isspace() from the C library because: * @@ -232,10 +252,20 @@ RCS_parsercsfile_i (fp, rcsfile) rdata->path = xstrdup (rcsfile); /* Process HEAD and BRANCH keywords from the RCS header. - * - * Most cvs operatations on the main branch don't need any more - * information. Those that do call XXX to completely parse the - * RCS file. */ + + Most cvs operations on the main branch don't need any more + information. Those that do call RCS_reparsercsfile to parse + the rest of the header and the deltas. + + People often wonder whether this is inefficient, to open the + file once here and once in RCS_reparsercsfile. Well, it might + help a little bit if we kept the file open (I haven't tried + timing this myself), but basically the common case, which we + want to optimize, is the one in which we call + RCS_parsercsfile_i and not RCS_reparsercsfile (for example, + "cvs update" on a lot of files most of which are unmodified). + So making the case in which we call RCS_reparsercsfile fast is + not as important. */ if (getrcskey (fp, &key, &value, NULL) == -1 || key == NULL) goto l_error; @@ -288,23 +318,19 @@ l_error: On error, die with a fatal error; if it returns at all it was successful. - If ALL is nonzero, remember all keywords and values. Otherwise - only keep the ones we will need. - If PFP is NULL, close the file when done. Otherwise, leave it open and store the FILE * in *PFP. */ -static void -RCS_reparsercsfile (rdata, all, pfp) +void +RCS_reparsercsfile (rdata, pfp) RCSNode *rdata; - int all; FILE **pfp; { FILE *fp; char *rcsfile; - Node *q; + Node *q, *kv; RCSVers *vnode; - int n; + long fpos; char *cp; char *key, *value; @@ -316,6 +342,9 @@ RCS_reparsercsfile (rdata, all, pfp) error (1, 0, "unable to reopen `%s'", rcsfile); /* make a node */ + /* This probably shouldn't be done until later: if a file has an + empty revision tree (which is permissible), rdata->versions + should be NULL. -twp */ rdata->versions = getlist (); /* @@ -324,12 +353,13 @@ RCS_reparsercsfile (rdata, all, pfp) */ for (;;) { + fpos = ftell (fp); + /* get the next key/value pair */ /* if key is NULL here, then the file is missing some headers or we had trouble reading the file. */ - if (getrcskey (fp, &key, &value, NULL) == -1 || key == NULL - || strcmp (key, RCSDESC) == 0) + if (getrcskey (fp, &key, &value, NULL) == -1 || key == NULL) { if (ferror(fp)) { @@ -342,6 +372,35 @@ RCS_reparsercsfile (rdata, all, pfp) } } + /* Skip head and branch tags; we already have them. */ + if (strcmp (key, RCSHEAD) == 0 || strcmp (key, RCSBRANCH) == 0) + continue; + + if (strcmp (key, "access") == 0) + { + if (value != NULL) + rdata->access = xstrdup (value); + continue; + } + + /* We always save lock information, so that we can handle + -kkvl correctly when checking out a file. */ + if (strcmp (key, "locks") == 0) + { + if (value != NULL) + rdata->locks_data = xstrdup (value); + fpos = ftell (fp); + if (getrcskey (fp, &key, &value, NULL) >= 0 && + strcmp (key, "strict") == 0 && + value == NULL) + { + rdata->strict_locks = 1; + } + else + (void) fseek (fp, fpos, SEEK_SET); + continue; + } + if (strcmp (RCSSYMBOLS, key) == 0) { if (value != NULL) @@ -357,7 +416,7 @@ RCS_reparsercsfile (rdata, all, pfp) /* * check key for '.''s and digits (probably a rev) if it is a - * revision, we are done with the headers and are down to the + * revision or `desc', we are done with the headers and are down to the * revision deltas, so we break out of the loop */ for (cp = key; (isdigit (*cp) || *cp == '.') && *cp != '\0'; cp++) @@ -365,26 +424,25 @@ RCS_reparsercsfile (rdata, all, pfp) if (*cp == '\0' && strncmp (RCSDATE, value, strlen (RCSDATE)) == 0) break; - /* We always save lock information, so that we can handle - -kkvl correctly when checking out a file. We don't use a - special field for this information, since it will normally - not be set for a CVS file. */ - if (all || strcmp (key, "locks") == 0) - { - Node *kv; - - if (rdata->other == NULL) - rdata->other = getlist (); - kv = getnode (); - kv->type = RCSFIELD; - kv->key = xstrdup (key); - kv->data = xstrdup (value); - if (addnode (rdata->other, kv) != 0) - { - error (0, 0, "warning: duplicate key `%s' in RCS file `%s'", - key, rcsfile); - freenode (kv); - } + if (strcmp (key, RCSDESC) == 0) + break; + + if (strcmp (key, "comment") == 0) + { + rdata->comment = xstrdup (value); + continue; + } + if (rdata->other == NULL) + rdata->other = getlist (); + kv = getnode (); + kv->type = RCSFIELD; + kv->key = xstrdup (key); + kv->data = xstrdup (value); + if (addnode (rdata->other, kv) != 0) + { + error (0, 0, "warning: duplicate key `%s' in RCS file `%s'", + key, rcsfile); + freenode (kv); } /* if we haven't grabbed it yet, we didn't want it */ @@ -395,116 +453,11 @@ RCS_reparsercsfile (rdata, all, pfp) * revision delta in our hand key=the revision and value=the date key and * its value */ - for (;;) - { - char *valp; - - vnode = (RCSVers *) xmalloc (sizeof (RCSVers)); - memset (vnode, 0, sizeof (RCSVers)); - - /* fill in the version before we forget it */ - vnode->version = xstrdup (key); - - /* grab the value of the date from value */ - valp = value + strlen (RCSDATE);/* skip the "date" keyword */ - while (whitespace (*valp)) /* take space off front of value */ - valp++; - - vnode->date = xstrdup (valp); - - /* Get author field. */ - (void) getrcskey (fp, &key, &value, NULL); - /* FIXME: should be using errno in case of ferror. */ - if (key == NULL || strcmp (key, "author") != 0) - error (1, 0, "\ -unable to parse rcs file; `author' not in the expected place"); - vnode->author = xstrdup (value); - - /* Get state field. */ - (void) getrcskey (fp, &key, &value, NULL); - /* FIXME: should be using errno in case of ferror. */ - if (key == NULL || strcmp (key, "state") != 0) - error (1, 0, "\ -unable to parse rcs file; `state' not in the expected place"); - vnode->state = xstrdup (value); - if (strcmp (value, "dead") == 0) - { - vnode->dead = 1; - } - - /* fill in the branch list (if any branches exist) */ - (void) getrcskey (fp, &key, &value, NULL); - /* FIXME: should be handling various error conditions better. */ - if (key != NULL && strcmp (key, RCSDESC) == 0) - value = NULL; - if (value != (char *) NULL) - { - vnode->branches = getlist (); - do_branches (vnode->branches, value); - } - - /* fill in the next field if there is a next revision */ - (void) getrcskey (fp, &key, &value, NULL); - /* FIXME: should be handling various error conditions better. */ - if (key != NULL && strcmp (key, RCSDESC) == 0) - value = NULL; - if (value != (char *) NULL) - vnode->next = xstrdup (value); - - /* - * at this point, we skip any user defined fields XXX - this is where - * we put the symbolic link stuff??? - */ - /* FIXME: Does not correctly handle errors, e.g. from stdio. */ - while ((n = getrcskey (fp, &key, &value, NULL)) >= 0) - { - assert (key != NULL); - - if (strcmp (key, RCSDESC) == 0) - { - n = -1; - break; - } - - /* Enable use of repositories created by certain obsolete - versions of CVS. This code should remain indefinately; - there is no procedure for converting old repositories, and - checking for it is harmless. */ - if (strcmp(key, RCSDEAD) == 0) - { - vnode->dead = 1; - if (vnode->state != NULL) - free (vnode->state); - vnode->state = xstrdup ("dead"); - continue; - } - /* if we have a revision, break and do it */ - for (cp = key; (isdigit (*cp) || *cp == '.') && *cp != '\0'; cp++) - /* do nothing */ ; - if (*cp == '\0' && strncmp (RCSDATE, value, strlen (RCSDATE)) == 0) - break; - - if (all) - { - Node *kv; - - if (vnode->other == NULL) - vnode->other = getlist (); - kv = getnode (); - kv->type = RCSFIELD; - kv->key = xstrdup (key); - kv->data = xstrdup (value); - if (addnode (vnode->other, kv) != 0) - { - error (0, 0, - "\ -warning: duplicate key `%s' in version `%s' of RCS file `%s'", - key, vnode->version, rcsfile); - freenode (kv); - } - } - } + /* First, seek back to the start of the delta block. */ + (void) fseek (fp, fpos, SEEK_SET); + while ((vnode = getdelta (fp, rcsfile)) != NULL) + { /* get the node */ q = getnode (); q->type = RCSVERS; @@ -521,36 +474,22 @@ warning: duplicate key `%s' in version `%s' of RCS file `%s'", freenode (q); #endif } - - /* - * if we left the loop because there were no more keys, we break out - * of the revision processing loop - */ - if (n < 0) - break; } - if (all && key != NULL && strcmp (key, RCSDESC) == 0) + (void) getrcskey (fp, &key, &value, NULL); + if (key != NULL && strcmp (key, RCSDESC) == 0) { - Node *kv; - - if (rdata->other == NULL) - rdata->other = getlist (); - kv = getnode (); - kv->type = RCSFIELD; - kv->key = xstrdup (key); - kv->data = xstrdup (value); - if (addnode (rdata->other, kv) != 0) + if (rdata->desc != NULL) { error (0, 0, "warning: duplicate key `%s' in RCS file `%s'", key, rcsfile); - freenode (kv); + free (rdata->desc); } + rdata->desc = xstrdup (value); } rdata->delta_pos = ftell (fp); - rdata->flags &= ~NODELTA; if (pfp == NULL) { @@ -582,7 +521,7 @@ RCS_fully_parse (rcs) { FILE *fp; - RCS_reparsercsfile (rcs, 1, &fp); + RCS_reparsercsfile (rcs, &fp); while (1) { @@ -780,19 +719,25 @@ free_rcsnode_contents (rnode) free (rnode->expand); if (rnode->other != (List *) NULL) dellist (&rnode->other); + if (rnode->access != NULL) + free (rnode->access); + if (rnode->locks_data != NULL) + free (rnode->locks_data); + if (rnode->locks != (List *) NULL) + dellist (&rnode->locks); + if (rnode->comment != NULL) + free (rnode->comment); + if (rnode->desc != NULL) + free (rnode->desc); } -/* - * rcsvers_delproc - free up an RCSVers type node - */ +/* free_rcsvers_contents -- free up the contents of an RCSVers node, + but also free the pointer to the node itself. */ + static void -rcsvers_delproc (p) - Node *p; -{ +free_rcsvers_contents (rnode) RCSVers *rnode; - - rnode = (RCSVers *) p->data; - +{ if (rnode->branches != (List *) NULL) dellist (&rnode->branches); if (rnode->date != (char *) NULL) @@ -805,14 +750,29 @@ rcsvers_delproc (p) free (rnode->state); if (rnode->other != (List *) NULL) dellist (&rnode->other); + if (rnode->other_delta != NULL) + dellist (&rnode->other_delta); + if (rnode->text != NULL) + freedeltatext (rnode->text); free ((char *) rnode); } /* + * rcsvers_delproc - free up an RCSVers type node + */ +static void +rcsvers_delproc (p) + Node *p; +{ + free_rcsvers_contents ((RCSVers *) p->data); +} + +/* * getrcskey - fill in the key and value from the rcs file the algorithm is * as follows * - * o skip whitespace o fill in key with everything up to next white + * o skip whitespace + * o fill in key with everything up to next white * space or semicolon * o if key == "desc" then key and data are NULL and return -1 * o if key wasn't terminated by a semicolon, skip white space and fill @@ -978,14 +938,18 @@ getrcskey (fp, keyp, valp, lenp) } } while (whitespace (c)); - if (cur >= max) + /* Do not include any trailing whitespace in the value. */ + if (c != ';') { - size_t curoff = cur - value; - expand_string (&value, &valsize, valsize + 1); - cur = value + curoff; - max = value + valsize; + if (cur >= max) + { + size_t curoff = cur - value; + expand_string (&value, &valsize, valsize + 1); + cur = value + curoff; + max = value + valsize; + } + *cur++ = ' '; } - *cur++ = ' '; } /* if we got a semi-colon we are done with the entire value */ @@ -1096,6 +1060,59 @@ getrcsrev (fp, revp) *revp = key; } +/* Like getrcsrev, but don't die on error. Return the last character + read (last call to getc, which may be EOF). TODO: implement getrcsrev + in terms of this function. */ +static int +getrevnum (fp, revp) + FILE *fp; + char **revp; +{ + char *cur; + char *max; + int c; + + *revp = NULL; + do { + c = getc (fp); + if (c == EOF) + return c; + } while (whitespace (c)); + + if (!(isdigit (c) || c == '.')) + return c; + + cur = key; + max = key + keysize; + while (isdigit (c) || c == '.') + { + if (cur >= max) + { + size_t curoff = cur - key; + expand_string (&key, &keysize, keysize + 1); + cur = key + curoff; + max = key + keysize; + } + *cur = c; + + c = getc (fp); + if (c == EOF) + break; + cur++; + } + + if (cur >= max) + { + size_t curoff = cur - key; + expand_string (&key, &keysize, keysize + 1); + cur = key + curoff; + max = key + keysize; + } + *cur = '\0'; + *revp = key; + return c; +} + /* * process the symbols list of the rcs file */ @@ -1137,6 +1154,48 @@ do_symbols (list, val) } /* + * process the locks list of the rcs file + * Like do_symbols, but hash entries are keyed backwards: i.e. + * an entry like `user:rev' is keyed on REV rather than on USER. + */ +static void +do_locks (list, val) + List *list; + char *val; +{ + Node *p; + char *cp = val; + char *user, *rev; + + for (;;) + { + /* skip leading whitespace */ + while (whitespace (*cp)) + cp++; + + /* if we got to the end, we are done */ + if (*cp == '\0') + break; + + /* split it up into user and rev */ + user = cp; + cp = strchr (cp, ':'); + *cp++ = '\0'; + rev = cp; + while (!whitespace (*cp) && *cp != '\0') + cp++; + if (*cp != '\0') + *cp++ = '\0'; + + /* make a new node and add it to the list */ + p = getnode (); + p->key = xstrdup (rev); + p->data = xstrdup (user); + (void) addnode (list, p); + } +} + +/* * process the branches list of a revision delta */ static void @@ -1198,7 +1257,7 @@ RCS_getversion (rcs, tag, date, force_tag_match, simple_tag) { char *branch, *rev; - if (! RCS_isbranch (rcs, tag)) + if (! RCS_nodeisbranch (rcs, tag)) { /* We can't get a particular date if the tag is not a branch. */ @@ -1232,6 +1291,8 @@ RCS_getversion (rcs, tag, date, force_tag_match, simple_tag) * and handle "magic" revisions specially. * * If the matched tag is a branch tag, find the head of the branch. + * + * Returns pointer to newly malloc'd string, or NULL. */ char * RCS_gettag (rcs, symtag, force_tag_match, simple_tag) @@ -1251,7 +1312,7 @@ RCS_gettag (rcs, symtag, force_tag_match, simple_tag) /* XXX this is probably not necessary, --jtc */ if (rcs->flags & PARTIAL) - RCS_reparsercsfile (rcs, 0, NULL); + RCS_reparsercsfile (rcs, NULL); /* If tag is "HEAD", special case to get head RCS revision */ if (tag && (strcmp (tag, TAG_HEAD) == 0 || *tag == '\0')) @@ -1483,6 +1544,8 @@ RCS_nodeisbranch (rcs, rev) int dots; char *version; + assert (rcs != NULL); + /* numeric revisions are easy -- even number of dots is a branch */ if (isdigit (*rev)) return ((numdots (rev) & 1) == 0); @@ -1573,7 +1636,8 @@ RCS_whatbranch (rcs, rev) /* * Get the head of the specified branch. If the branch does not exist, - * return NULL or RCS_head depending on force_tag_match + * return NULL or RCS_head depending on force_tag_match. + * Returns NULL or a newly malloc'd string. */ char * RCS_getbranch (rcs, tag, force_tag_match) @@ -1591,7 +1655,7 @@ RCS_getbranch (rcs, tag, force_tag_match) assert (rcs != NULL); if (rcs->flags & PARTIAL) - RCS_reparsercsfile (rcs, 0, NULL); + RCS_reparsercsfile (rcs, NULL); /* find out if the tag contains a dot, or is on the trunk */ cp = strrchr (tag, '.'); @@ -1690,9 +1754,88 @@ RCS_getbranch (rcs, tag, force_tag_match) return (xstrdup (vn->version)); } +/* Get the branch point for a particular branch, that is the first + revision on that branch. For example, RCS_getbranchpoint (rcs, + "1.3.2") will normally return "1.3.2.1". TARGET may be either a + branch number or a revision number; if a revnum, find the + branchpoint of the branch to which TARGET belongs. + + Return RCS_head if TARGET is on the trunk or if the root node could + not be found (this is sort of backwards from our behavior on a branch; + the rationale is that the return value is a revision from which you + can start walking the next fields and end up at TARGET). + Return NULL on error. */ + +static char * +RCS_getbranchpoint (rcs, target) + RCSNode *rcs; + char *target; +{ + char *branch, *bp; + Node *vp; + RCSVers *rev; + int dots, isrevnum, brlen; + + dots = numdots (target); + isrevnum = dots & 1; + + if (dots == 1) + /* TARGET is a trunk revision; return rcs->head. */ + return (RCS_head (rcs)); + + /* Get the revision number of the node at which TARGET's branch is + rooted. If TARGET is a branch number, lop off the last field; + if it's a revision number, lop off the last *two* fields. */ + branch = xstrdup (target); + bp = strrchr (branch, '.'); + if (bp == NULL) + error (1, 0, "%s: confused revision number %s", + rcs->path, target); + if (isrevnum) + while (*--bp != '.') + ; + *bp = '\0'; + + vp = findnode (rcs->versions, branch); + if (vp == NULL) + { + error (0, 0, "%s: can't find branch point %s", rcs->path, target); + return NULL; + } + rev = (RCSVers *) vp->data; + + *bp++ = '.'; + while (*bp && *bp != '.') + ++bp; + brlen = bp - branch; + + vp = rev->branches->list->next; + while (vp != rev->branches->list) + { + /* BRANCH may be a genuine branch number, e.g. `1.1.3', or + maybe a full revision number, e.g. `1.1.3.6'. We have + found our branch point if the first BRANCHLEN characters + of the revision number match, *and* if the following + character is a dot. */ + if (strncmp (vp->key, branch, brlen) == 0 && vp->key[brlen] == '.') + break; + vp = vp->next; + } + + free (branch); + if (vp == rev->branches->list) + { + error (0, 0, "%s: can't find branch point %s", rcs->path, target); + return NULL; + } + else + return (xstrdup (vp->key)); +} + /* * Get the head of the RCS file. If branch is set, this is the head of the - * branch, otherwise the real head + * branch, otherwise the real head. + * Returns NULL or a newly malloc'd string. */ char * RCS_head (rcs) @@ -1730,7 +1873,7 @@ RCS_getdate (rcs, date, force_tag_match) assert (rcs != NULL); if (rcs->flags & PARTIAL) - RCS_reparsercsfile (rcs, 0, NULL); + RCS_reparsercsfile (rcs, NULL); /* if the head is on a branch, try the branch first */ if (rcs->branch != NULL) @@ -1817,7 +1960,7 @@ RCS_getdatebranch (rcs, date, branch) assert (rcs != NULL); if (rcs->flags & PARTIAL) - RCS_reparsercsfile (rcs, 0, NULL); + RCS_reparsercsfile (rcs, NULL); p = findnode (rcs->versions, xrev); free (xrev); @@ -1829,7 +1972,8 @@ RCS_getdatebranch (rcs, date, branch) if (RCS_datecmp (vers->date, date) <= 0) cur_rev = vers->version; - /* if no branches list, return now */ + /* If no branches list, return now. This is what happens if the branch + is a (magic) branch with no revisions yet. */ if (vers->branches == NULL) return xstrdup (cur_rev); @@ -1843,9 +1987,11 @@ RCS_getdatebranch (rcs, date, branch) free (xbranch); if (p == vers->branches->list) { - /* FIXME: This case would seem to imply that the RCS file is - somehow invalid. Should we give an error message? */ - return (NULL); + /* This is what happens if the branch is a (magic) branch with + no revisions yet. Similar to the case where vers->branches == + NULL, except here there was a another branch off the same + branchpoint. */ + return xstrdup (cur_rev); } p = findnode (rcs->versions, p->key); @@ -1911,7 +2057,7 @@ RCS_getrevtime (rcs, rev, date, fudge) assert (rcs != NULL); if (rcs->flags & PARTIAL) - RCS_reparsercsfile (rcs, 0, NULL); + RCS_reparsercsfile (rcs, NULL); /* look up the revision */ p = findnode (rcs->versions, rev); @@ -1934,15 +2080,9 @@ RCS_getrevtime (rcs, rev, date, fudge) ftm->tm_year -= 1900; /* put the date in a form getdate can grok */ -#ifdef HAVE_RCS5 (void) sprintf (tdate, "%d/%d/%d GMT %d:%d:%d", ftm->tm_mon, ftm->tm_mday, ftm->tm_year + 1900, ftm->tm_hour, ftm->tm_min, ftm->tm_sec); -#else - (void) sprintf (tdate, "%d/%d/%d %d:%d:%d", ftm->tm_mon, - ftm->tm_mday, ftm->tm_year + 1900, ftm->tm_hour, - ftm->tm_min, ftm->tm_sec); -#endif /* turn it into seconds since the epoch */ revdate = get_date (tdate, (struct timeb *) NULL); @@ -1952,11 +2092,7 @@ RCS_getrevtime (rcs, rev, date, fudge) if (date) { /* put an appropriate string into ``date'' if we were given one */ -#ifdef HAVE_RCS5 ftm = gmtime (&revdate); -#else - ftm = localtime (&revdate); -#endif (void) sprintf (date, DATEFORM, ftm->tm_year + (ftm->tm_year < 100 ? 0 : 1900), ftm->tm_mon + 1, ftm->tm_mday, ftm->tm_hour, @@ -1967,13 +2103,32 @@ RCS_getrevtime (rcs, rev, date, fudge) } List * +RCS_getlocks (rcs) + RCSNode *rcs; +{ + assert(rcs != NULL); + + if (rcs->flags & PARTIAL) + RCS_reparsercsfile (rcs, NULL); + + if (rcs->locks_data) { + rcs->locks = getlist (); + do_locks (rcs->locks, rcs->locks_data); + free(rcs->locks_data); + rcs->locks_data = NULL; + } + + return rcs->locks; +} + +List * RCS_symbols(rcs) RCSNode *rcs; { assert(rcs != NULL); if (rcs->flags & PARTIAL) - RCS_reparsercsfile (rcs, 0, NULL); + RCS_reparsercsfile (rcs, NULL); if (rcs->symbols_data) { rcs->symbols = getlist (); @@ -1987,6 +2142,7 @@ RCS_symbols(rcs) /* * Return the version associated with a particular symbolic tag. + * Returns NULL or a newly malloc'd string. */ static char * translate_symtag (rcs, tag) @@ -1994,7 +2150,7 @@ translate_symtag (rcs, tag) const char *tag; { if (rcs->flags & PARTIAL) - RCS_reparsercsfile (rcs, 0, NULL); + RCS_reparsercsfile (rcs, NULL); if (rcs->symbols != NULL) { @@ -2067,17 +2223,13 @@ RCS_check_kflag (arg) " -kv\tGenerate only keyword values in keyword strings.\n", " -ko\tGenerate the old keyword string (no changes from checked in file).\n", " -kb\tGenerate binary file unmodified (merges not allowed) (RCS 5.7).\n", + "(Specify the --help global option for a list of other help options)\n", NULL, }; /* Big enough to hold any of the strings from kflags. */ char karg[10]; char const *const *cpp = NULL; -#ifndef HAVE_RCS5 - error (1, 0, "%s %s: your version of RCS does not support the -k option", - program_name, command_name); -#endif - if (arg) { for (cpp = kflags; *cpp != NULL; cpp++) @@ -2140,7 +2292,7 @@ RCS_isdead (rcs, tag) RCSVers *version; if (rcs->flags & PARTIAL) - RCS_reparsercsfile (rcs, 0, NULL); + RCS_reparsercsfile (rcs, NULL); p = findnode (rcs->versions, tag); if (p == NULL) @@ -2161,7 +2313,7 @@ RCS_getexpand (rcs) { assert (rcs != NULL); if (rcs->flags & PARTIAL) - RCS_reparsercsfile (rcs, 0, NULL); + RCS_reparsercsfile (rcs, NULL); return rcs->expand; } @@ -2338,45 +2490,12 @@ expand_keywords (rcs, ver, name, log, loglen, expand, buf, len, retbuf, retlen) /* If we are using -kkvl, dig out the locker information if any. */ locker = NULL; - if (expand == KFLAG_KVL && rcs->other != NULL) + if (expand == KFLAG_KVL) { - Node *p; - - p = findnode (rcs->other, "locks"); - if (p != NULL) - { - char *cp; - size_t verlen; - - /* The format of the locking information is - USER:VERSION USER:VERSION ... - If we find our version on the list, we set LOCKER to - the corresponding user name. */ - - verlen = strlen (ver->version); - cp = p->data; - while ((cp = strstr (cp, ver->version)) != NULL) - { - if (cp > p->data - && cp[-1] == ':' - && (cp[verlen] == '\0' - || whitespace (cp[verlen]))) - { - char *cpend; - - --cp; - cpend = cp; - while (cp > p->data && ! whitespace (*cp)) - --cp; - locker = xmalloc (cpend - cp + 1); - memcpy (locker, cp, cpend - cp); - locker[cpend - cp] = '\0'; - break; - } - - ++cp; - } - } + Node *lock; + lock = findnode (RCS_getlocks(rcs), ver->version); + if (lock != NULL) + locker = xstrdup (lock->data); } /* RCS keywords look like $STRING$ or $STRING: VALUE$. */ @@ -2849,14 +2968,8 @@ RCS_checkout (rcs, workfile, rev, nametag, options, sout, pfn, callerdat) /* We want the head revision. Try to read it directly. */ - if (rcs->flags & NODELTA) - { - free_rcsnode_contents (rcs); - rcs->flags |= PARTIAL; - } - if (rcs->flags & PARTIAL) - RCS_reparsercsfile (rcs, 0, &fp); + RCS_reparsercsfile (rcs, &fp); else { fp = CVS_FOPEN (rcs->path, FOPEN_BINARY_READ); @@ -2904,7 +3017,7 @@ RCS_checkout (rcs, workfile, rev, nametag, options, sout, pfn, callerdat) fp = NULL; if (rcs->flags & PARTIAL) - RCS_reparsercsfile (rcs, 0, &fp); + RCS_reparsercsfile (rcs, &fp); if (fp == NULL) { @@ -3013,16 +3126,42 @@ RCS_checkout (rcs, workfile, rev, nametag, options, sout, pfn, callerdat) if (workfile == NULL && sout == RUN_TTY) { - if (len > 0) - cvs_output (value, len); + if (expand == KFLAG_B) + cvs_output_binary (value, len); + else + { + /* cvs_output requires the caller to check for zero + length. */ + if (len > 0) + cvs_output (value, len); + } } else { - if (fwrite (value, 1, len, ofp) != len) - error (1, errno, "cannot write %s", - (workfile != NULL - ? workfile - : (sout != RUN_TTY ? sout : "stdout"))); + /* NT 4.0 is said to have trouble writing 2099999 bytes + (for example) in a single fwrite. So break it down + (there is no need to be writing that much at once + anyway; it is possible that LARGEST_FWRITE should be + somewhat larger for good performance, but for testing I + want to start with a small value until/unless a bigger + one proves useful). */ +#define LARGEST_FWRITE 8192 + size_t nleft = len; + size_t nstep = (len < LARGEST_FWRITE ? len : LARGEST_FWRITE); + char *p = value; + + while (nleft > 0) + { + if (fwrite (p, 1, nstep, ofp) != nstep) + error (1, errno, "cannot write %s", + (workfile != NULL + ? workfile + : (sout != RUN_TTY ? sout : "stdout"))); + p += nstep; + nleft -= nstep; + if (nleft < nstep) + nstep = nleft; + } } if (workfile != NULL) @@ -3049,6 +3188,794 @@ RCS_checkout (rcs, workfile, rev, nametag, options, sout, pfn, callerdat) return 0; } +static RCSVers *RCS_findlock_or_tip PROTO ((RCSNode *rcs)); + +/* Find the delta currently locked by the user. From the `ci' man page: + + "If rev is omitted, ci tries to derive the new revision + number from the caller's last lock. If the caller has + locked the tip revision of a branch, the new revision is + appended to that branch. The new revision number is + obtained by incrementing the tip revision number. If the + caller locked a non-tip revision, a new branch is started + at that revision by incrementing the highest branch number + at that revision. The default initial branch and level + numbers are 1. + + If rev is omitted and the caller has no lock, but owns the + file and locking is not set to strict, then the revision + is appended to the default branch (normally the trunk; see + the -b option of rcs(1))." + + RCS_findlock_or_tip finds the unique revision locked by the caller + and returns its delta node. If the caller has not locked any + revisions (and is permitted to commit to an unlocked delta, as + described above), return the tip of the default branch. */ + +static RCSVers * +RCS_findlock_or_tip (rcs) + RCSNode *rcs; +{ + char *user = getcaller(); + Node *lock, *p; + List *locklist; + + /* Find unique delta locked by caller. This code is very similar + to the code in RCS_unlock -- perhaps it could be abstracted + into a RCS_findlock function. */ + locklist = RCS_getlocks (rcs); + lock = NULL; + for (p = locklist->list->next; p != locklist->list; p = p->next) + { + if (strcmp (p->data, user) == 0) + { + if (lock != NULL) + { + error (0, 0, "\ +%s: multiple revisions locked by %s; please specify one", rcs->path, user); + return NULL; + } + lock = p; + } + } + + if (lock != NULL) + { + /* Found an old lock, but check that the revision still exists. */ + p = findnode (rcs->versions, lock->key); + if (p == NULL) + { + error (0, 0, "%s: can't unlock nonexistent revision %s", + rcs->path, + lock->key); + return NULL; + } + return (RCSVers *) p->data; + } + + /* No existing lock. The RCS rule is that this is an error unless + locking is nonstrict AND the file is owned by the current + user. Trying to determine the latter is a portability nightmare + in the face of NT, VMS, AFS, and other systems with non-unix-like + ideas of users and owners. In the case of CVS, we should never get + here (as long as the traditional behavior of making sure to call + RCS_lock persists). Anyway, we skip the RCS error checks + and just return the default branch or head. The reasoning is that + those error checks are to make users lock before a checkin, and we do + that in other ways if at all anyway (e.g. rcslock.pl). */ + + p = findnode (rcs->versions, RCS_getbranch (rcs, rcs->branch, 0)); + return (RCSVers *) p->data; +} + +/* Revision number string, R, must contain a `.'. + Return a newly-malloc'd copy of the prefix of R up + to but not including the final `.'. */ + +static char * +truncate_revnum (r) + const char *r; +{ + size_t len; + char *new_r; + char *dot = strrchr (r, '.'); + + assert (dot); + len = dot - r; + new_r = xmalloc (len + 1); + memcpy (new_r, r, len); + *(new_r + len) = '\0'; + return new_r; +} + +/* Revision number string, R, must contain a `.'. + R must be writable. Replace the rightmost `.' in R with + the NUL byte and return a pointer to that NUL byte. */ + +static char * +truncate_revnum_in_place (r) + char *r; +{ + char *dot = strrchr (r, '.'); + assert (dot); + *dot = '\0'; + return dot; +} + +/* Revision number strings, R and S, must each contain a `.'. + R and S must be writable and must have the same number of dots. + Truncate R and S for the comparison, then restored them to their + original state. + Return the result (see compare_revnums) of comparing R and S + ignoring differences in any component after the rightmost `.'. */ + +static int +compare_truncated_revnums (r, s) + char *r; + char *s; +{ + char *r_dot = truncate_revnum_in_place (r); + char *s_dot = truncate_revnum_in_place (s); + int cmp; + + assert (numdots (r) == numdots (s)); + + cmp = compare_revnums (r, s); + + *r_dot = '.'; + *s_dot = '.'; + + return cmp; +} + +/* Return a malloc'd copy of the string representing the highest branch + number on BRANCHNODE. If there are no branches on BRANCHNODE, return NULL. + FIXME: isn't the max rev always the last one? + If so, we don't even need a loop. */ + +static char * +max_rev (const RCSVers *branchnode) +{ + Node *head; + Node *bp; + char *max; + + if (branchnode->branches == NULL) + { + return NULL; + } + + max = NULL; + head = branchnode->branches->list; + for (bp = head->next; bp != head; bp = bp->next) + { + if (max == NULL || compare_truncated_revnums (max, bp->key) < 0) + { + max = bp->key; + } + } + assert (max); + + return truncate_revnum (max); +} + +/* Create BRANCH in RCS's delta tree. BRANCH may be either a branch + number or a revision number. In the former case, create the branch + with the specified number; in the latter case, create a new branch + rooted at node BRANCH with a higher branch number than any others. + Return the number of the tip node on the new branch. */ + +static char * +RCS_addbranch (rcs, branch) + RCSNode *rcs; + const char *branch; +{ + char *branchpoint, *newrevnum; + Node *nodep, *bp; + Node *marker; + RCSVers *branchnode; + + /* Append to end by default. */ + marker = NULL; + + branchpoint = xstrdup (branch); + if ((numdots (branchpoint) & 1) == 0) + { + truncate_revnum_in_place (branchpoint); + } + + /* Find the branch rooted at BRANCHPOINT. */ + nodep = findnode (rcs->versions, branchpoint); + if (nodep == NULL) + { + error (0, 0, "%s: can't find branch point %s", rcs->path, branchpoint); + return NULL; + } + branchnode = (RCSVers *) nodep->data; + + /* If BRANCH was a full branch number, make sure it is higher than MAX. */ + if ((numdots (branch) & 1) == 1) + { + if (branchnode->branches == NULL) + { + /* We have to create the first branch on this node, which means + appending ".2" to the revision number. */ + newrevnum = (char *) xmalloc (strlen (branch) + 3); + strcpy (newrevnum, branch); + strcat (newrevnum, ".2"); + } + else + { + char *max = max_rev (branchnode); + assert (max); + newrevnum = increment_revnum (max); + free (max); + } + } + else + { + newrevnum = xstrdup (branch); + + if (branchnode->branches != NULL) + { + Node *head; + Node *bp; + + /* Find the position of this new branch in the sorted list + of branches. */ + head = branchnode->branches->list; + for (bp = head->next; bp != head; bp = bp->next) + { + char *dot; + int found_pos; + + /* The existing list must be sorted on increasing revnum. */ + assert (bp->next == head + || compare_truncated_revnums (bp->key, + bp->next->key) < 0); + dot = truncate_revnum_in_place (bp->key); + found_pos = (compare_revnums (branch, bp->key) < 0); + *dot = '.'; + + if (found_pos) + { + break; + } + } + marker = bp; + } + } + + newrevnum = (char *) xrealloc (newrevnum, strlen (newrevnum) + 3); + strcat (newrevnum, ".1"); + + /* Add this new revision number to BRANCHPOINT's branches list. */ + if (branchnode->branches == NULL) + branchnode->branches = getlist(); + bp = getnode(); + bp->key = xstrdup (newrevnum); + + /* Append to the end of the list by default, that is, just before + the header node, `list'. */ + if (marker == NULL) + marker = branchnode->branches->list; + + { + int fail; + fail = insert_before (branchnode->branches, marker, bp); + assert (!fail); + } + + return newrevnum; +} + +/* Check in to RCSFILE with revision REV (which must be greater than the + largest revision) and message MESSAGE (which is checked for legality). + If FLAGS & RCS_FLAGS_DEAD, check in a dead revision. If FLAGS & + RCS_FLAGS_QUIET, tell ci to be quiet. If FLAGS & RCS_FLAGS_MODTIME, + use the working file's modification time for the checkin time. + WORKFILE is the working file to check in from, or NULL to use the usual + RCS rules for deriving it from the RCSFILE. + + Return value is -1 for error (and errno is set to indicate the + error), positive for error (and an error message has been printed), + or zero for success. */ + +/* TODO: RCS_checkin always unlinks the working file after checkin -- + then RCS_checkout checks it out again. The logic should probably + be reversed here. */ + +int +RCS_checkin (rcs, workfile, message, rev, flags) + RCSNode *rcs; + char *workfile; + char *message; + char *rev; + int flags; +{ + RCSVers *delta, *commitpt; + Deltatext *dtext; + Node *nodep; + char *tmpfile, *changefile, *chtext; + char *diffopts; + size_t bufsize; + int buflen, chtextlen; + int status, checkin_quiet, allocated_workfile; + struct tm *ftm; + time_t modtime; + + commitpt = NULL; + + if (rcs->flags & PARTIAL) + RCS_reparsercsfile (rcs, NULL); + + /* Get basename of working file. Is there a library function to + do this? I couldn't find one. -twp */ + allocated_workfile = 0; + if (workfile == NULL) + { + char *p; + int extlen = strlen (RCSEXT); + workfile = xstrdup (last_component (rcs->path)); + p = workfile + (strlen (workfile) - extlen); + assert (strncmp (p, RCSEXT, extlen) == 0); + *p = '\0'; + allocated_workfile = 1; + } + + checkin_quiet = flags & RCS_FLAGS_QUIET; + if (!checkin_quiet) + { + cvs_output (rcs->path, 0); + cvs_output (" <-- ", 7); + cvs_output (workfile, 0); + cvs_output ("\n", 1); + } + + /* Create new delta node. */ + delta = (RCSVers *) xmalloc (sizeof (RCSVers)); + memset (delta, 0, sizeof (RCSVers)); + delta->author = xstrdup (getcaller ()); + if (flags & RCS_FLAGS_MODTIME) + { + struct stat ws; + if (stat (workfile, &ws) < 0) + { + error (1, errno, "cannot stat %s", workfile); + } + modtime = ws.st_mtime; + } + else + (void) time (&modtime); + ftm = gmtime (&modtime); + delta->date = (char *) xmalloc (MAXDATELEN); + (void) sprintf (delta->date, DATEFORM, + ftm->tm_year + (ftm->tm_year < 100 ? 0 : 1900), + ftm->tm_mon + 1, ftm->tm_mday, ftm->tm_hour, + ftm->tm_min, ftm->tm_sec); + if (flags & RCS_FLAGS_DEAD) + { + delta->state = xstrdup (RCSDEAD); + delta->dead = 1; + } + else + delta->state = xstrdup ("Exp"); + + /* Create a new deltatext node. */ + dtext = (Deltatext *) xmalloc (sizeof (Deltatext)); + memset (dtext, 0, sizeof (Deltatext)); + + dtext->log = make_message_rcslegal (message); + + /* If the delta tree is empty, then there's nothing to link the + new delta into. So make a new delta tree, snarf the working + file contents, and just write the new RCS file. */ + if (rcs->head == NULL) + { + char *newrev; + FILE *fout; + + /* Figure out what the first revision number should be. */ + if (rev == NULL || *rev == '\0') + newrev = xstrdup ("1.1"); + else if (numdots (rev) == 0) + { + newrev = (char *) xmalloc (strlen (rev) + 3); + strcpy (newrev, rev); + strcat (newrev, ".1"); + } + else + newrev = xstrdup (rev); + + /* Don't need to xstrdup NEWREV because it's already dynamic, and + not used for anything else. (Don't need to free it, either.) */ + rcs->head = newrev; + delta->version = xstrdup (newrev); + nodep = getnode(); + nodep->type = RCSVERS; + nodep->key = xstrdup (newrev); + nodep->data = (char *) delta; + (void) addnode (rcs->versions, nodep); + + dtext->version = xstrdup (newrev); + bufsize = 0; + get_file(workfile, workfile, "r", &dtext->text, &bufsize, &dtext->len); + + if (!checkin_quiet) + { + cvs_output ("initial revision: ", 0); + cvs_output (rcs->head, 0); + cvs_output ("\n", 1); + } + + fout = rcs_internal_lockfile (rcs->path); + RCS_putadmin (rcs, fout); + RCS_putdtree (rcs, rcs->head, fout); + RCS_putdesc (rcs, fout); + rcs->delta_pos = ftell (fout); + if (rcs->delta_pos == -1) + error (1, errno, "cannot ftell for %s", rcs->path); + putdeltatext (fout, dtext); + rcs_internal_unlockfile (fout, rcs->path); + freedeltatext (dtext); + + /* Removing the file here is an RCS user-visible behavior which + we almost surely do not need in the CVS case. In fact, getting + rid of it should clean up link_file and friends in import.c. */ + if (unlink_file (workfile) < 0) + /* FIXME-update-dir: message does not include update_dir. */ + error (0, errno, "cannot remove %s", workfile); + + if (!checkin_quiet) + cvs_output ("done\n", 5); + + return 0; + } + + /* Derive a new revision number. From the `ci' man page: + + "If rev is a revision number, it must be higher than the + latest one on the branch to which rev belongs, or must + start a new branch. + + If rev is a branch rather than a revision number, the new + revision is appended to that branch. The level number is + obtained by incrementing the tip revision number of that + branch. If rev indicates a non-existing branch, that + branch is created with the initial revision numbered + rev.1." + + RCS_findlock_or_tip handles the case where REV is omitted. + RCS 5.7 also permits REV to be "$" or to begin with a dot, but + we do not address those cases -- every routine that calls + RCS_checkin passes it a numeric revision. */ + + if (rev == NULL || *rev == '\0') + { + /* Figure out where the commit point is by looking for locks. + If the commit point is at the tip of a branch (or is the + head of the delta tree), then increment its revision number + to obtain the new revnum. Otherwise, start a new + branch. */ + commitpt = RCS_findlock_or_tip (rcs); + if (commitpt == NULL) + { + status = 1; + goto checkin_done; + } + else if (commitpt->next == NULL + || strcmp (commitpt->version, rcs->head) == 0) + delta->version = increment_revnum (commitpt->version); + else + delta->version = RCS_addbranch (rcs, commitpt->version); + } + else + { + /* REV is either a revision number or a branch number. Find the + tip of the target branch. */ + char *branch, *tip, *newrev, *p; + int dots, isrevnum; + + assert (isdigit(*rev)); + + newrev = xstrdup (rev); + dots = numdots (newrev); + isrevnum = dots & 1; + + branch = xstrdup (rev); + if (isrevnum) + { + p = strrchr (branch, '.'); + *p = '\0'; + } + + /* Find the tip of the target branch. If we got a one- or two-digit + revision number, this will be the head of the tree. Exception: + if rev is a single-field revision equal to the branch number of + the trunk (usually "1") then we want to treat it like an ordinary + branch revision. */ + if (dots == 0) + { + tip = xstrdup (rcs->head); + if (atoi (tip) != atoi (branch)) + { + newrev = (char *) xrealloc (newrev, strlen (newrev) + 3); + strcat (newrev, ".1"); + dots = isrevnum = 1; + } + } + else if (dots == 1) + tip = xstrdup (rcs->head); + else + tip = RCS_getbranch (rcs, branch, 1); + + /* If the branch does not exist, and we were supplied an exact + revision number, signal an error. Otherwise, if we were + given only a branch number, create it and set COMMITPT to + the branch point. */ + if (tip == NULL) + { + if (isrevnum) + { + error (0, 0, "%s: can't find branch point %s", + rcs->path, branch); + free (branch); + free (newrev); + status = 1; + goto checkin_done; + } + delta->version = RCS_addbranch (rcs, branch); + p = strrchr (branch, '.'); + *p = '\0'; + tip = xstrdup (branch); + } + else + { + if (isrevnum) + { + /* NEWREV must be higher than TIP. */ + if (compare_revnums (tip, newrev) >= 0) + { + error (0, 0, + "%s: revision %s too low; must be higher than %s", + rcs->path, + newrev, tip); + free (branch); + free (newrev); + free (tip); + status = 1; + goto checkin_done; + } + delta->version = xstrdup (newrev); + } + else + /* Just increment the tip number to get the new revision. */ + delta->version = increment_revnum (tip); + } + + nodep = findnode (rcs->versions, tip); + commitpt = (RCSVers *) nodep->data; + + free (branch); + free (newrev); + free (tip); + } + + assert (delta->version != NULL); + + /* If COMMITPT is locked by us, break the lock. If it's locked + by someone else, signal an error. */ + nodep = findnode (RCS_getlocks (rcs), commitpt->version); + if (nodep != NULL) + { + if (strcmp (nodep->data, delta->author) != 0) + { + error (0, 0, "%s: revision %s locked by %s", + rcs->path, + nodep->key, nodep->data); + status = 1; + goto checkin_done; + } + delnode (nodep); + } + + dtext->version = xstrdup (delta->version); + + /* Obtain the change text for the new delta. If DELTA is to be the + new head of the tree, then its change text should be the contents + of the working file, and LEAFNODE's change text should be a diff. + Else, DELTA's change text should be a diff between LEAFNODE and + the working file. */ + + tmpfile = cvs_temp_name(); + status = RCS_checkout (rcs, NULL, commitpt->version, NULL, + ((rcs->expand != NULL + && strcmp (rcs->expand, "b") == 0) + ? "-kb" + : "-ko"), + tmpfile, + (RCSCHECKOUTPROC)0, NULL); + if (status != 0) + error (1, status < 0 ? errno : 0, + "could not check out revision %s of `%s'", + commitpt->version, rcs->path); + + bufsize = buflen = 0; + chtext = NULL; + chtextlen = 0; + changefile = cvs_temp_name(); + + /* Diff options should include --binary if the RCS file has -kb set + in its `expand' field. */ + diffopts = (rcs->expand != NULL && strcmp (rcs->expand, "b") == 0 + ? "-a -n --binary" + : "-a -n"); + + if (strcmp (commitpt->version, rcs->head) == 0 && + numdots (delta->version) == 1) + { + /* If this revision is being inserted on the trunk, the change text + for the new delta should be the contents of the working file ... */ + bufsize = 0; + get_file (workfile, workfile, + rcs->expand != NULL && strcmp (rcs->expand, "b") == 0 ? "rb" : "r", + &dtext->text, &bufsize, &dtext->len); + + /* ... and the change text for the old delta should be a diff. */ + commitpt->text = (Deltatext *) xmalloc (sizeof (Deltatext)); + memset (commitpt->text, 0, sizeof (Deltatext)); + + bufsize = 0; + switch (diff_exec (workfile, tmpfile, diffopts, changefile)) + { + case 0: + case 1: + break; + case -1: + /* FIXME-update-dir: message does not include update_dir. */ + error (1, errno, "error diffing %s", workfile); + break; + default: + /* FIXME-update-dir: message does not include update_dir. */ + error (1, 0, "error diffing %s", workfile); + break; + } + + /* OK, the text file case here is really dumb. Logically + speaking we want diff to read the files in text mode, + convert them to the canonical form found in RCS files + (which, we hope at least, is independent of OS--always + bare linefeeds), and then work with change texts in that + format. However, diff_exec both generates change + texts and produces output for user purposes (e.g. patch.c), + and there is no way to distinguish between the two cases. + So we actually implement the text file case by writing the + change text as a text file, then reading it as a text file. + This should cause no harm, but doesn't strike me as + immensely clean. */ + get_file (changefile, changefile, + rcs->expand != NULL && strcmp (rcs->expand, "b") == 0 ? "rb" : "r", + &commitpt->text->text, &bufsize, &commitpt->text->len); + + /* If COMMITPT->TEXT->TEXT is NULL, it means that CHANGEFILE + was empty and that there are no differences between revisions. + In that event, we want to force RCS_rewrite to write an empty + string for COMMITPT's change text. Leaving the change text + field set NULL won't work, since that means "preserve the original + change text for this delta." */ + if (commitpt->text->text == NULL) + { + commitpt->text->text = xstrdup (""); + commitpt->text->len = 0; + } + } + else + { + /* This file is not being inserted at the head, but on a side + branch somewhere. Make a diff from the previous revision + to the working file. */ + switch (diff_exec (tmpfile, workfile, diffopts, changefile)) + { + case 0: + case 1: + break; + case -1: + /* FIXME-update-dir: message does not include update_dir. */ + error (1, errno, "error diffing %s", workfile); + break; + default: + /* FIXME-update-dir: message does not include update_dir. */ + error (1, 0, "error diffing %s", workfile); + break; + } + /* See the comment above, at the other get_file invocation, + regarding binary vs. text. */ + get_file (changefile, changefile, + rcs->expand != NULL && strcmp (rcs->expand, "b") == 0 ? "rb" : "r", + &dtext->text, &bufsize, + &dtext->len); + if (dtext->text == NULL) + { + dtext->text = xstrdup (""); + dtext->len = 0; + } + } + + /* Update DELTA linkage. It is important not to do this before + the very end of RCS_checkin; if an error arises that forces + us to abort checking in, we must not have malformed deltas + partially linked into the tree. + + If DELTA and COMMITPT are on different branches, do nothing -- + DELTA is linked to the tree through COMMITPT->BRANCHES, and we + don't want to change `next' pointers. + + Otherwise, if the nodes are both on the trunk, link DELTA to + COMMITPT; otherwise, link COMMITPT to DELTA. */ + + if (numdots (commitpt->version) == numdots (delta->version)) + { + if (strcmp (commitpt->version, rcs->head) == 0) + { + delta->next = rcs->head; + rcs->head = xstrdup (delta->version); + } + else + commitpt->next = xstrdup (delta->version); + } + + /* Add DELTA to RCS->VERSIONS. */ + if (rcs->versions == NULL) + rcs->versions = getlist(); + nodep = getnode(); + nodep->type = RCSVERS; + nodep->key = xstrdup (delta->version); + nodep->data = (char *) delta; + (void) addnode (rcs->versions, nodep); + + /* Write the new RCS file, inserting the new delta at COMMITPT. */ + if (!checkin_quiet) + { + cvs_output ("new revision: ", 14); + cvs_output (delta->version, 0); + cvs_output ("; previous revision: ", 21); + cvs_output (commitpt->version, 0); + cvs_output ("\n", 1); + } + + RCS_rewrite (rcs, dtext, commitpt->version); + + /* Removing the file here is an RCS user-visible behavior which + we almost surely do not need in the CVS case. In fact, getting + rid of it should clean up link_file and friends in import.c. */ + if (unlink_file (workfile) < 0) + /* FIXME-update-dir: message does not include update_dir. */ + error (1, errno, "cannot remove %s", workfile); + if (unlink_file (tmpfile) < 0) + error (0, errno, "cannot remove %s", tmpfile); + if (unlink_file (changefile) < 0) + error (0, errno, "cannot remove %s", changefile); + + if (!checkin_quiet) + cvs_output ("done\n", 5); + + checkin_done: + if (allocated_workfile) + free (workfile); + + if (commitpt != NULL && commitpt->text != NULL) + { + freedeltatext (commitpt->text); + commitpt->text = NULL; + } + + freedeltatext (dtext); + if (status != 0) + free_rcsvers_contents (delta); + + return status; +} + /* This structure is passed between RCS_cmp_file and cmp_file_buffer. */ struct cmp_file_data @@ -3175,7 +4102,11 @@ RCS_settag (rcs, tag, rev) const char *tag; const char *rev; { - int ret; + List *symbols; + Node *node; + + if (rcs->flags & PARTIAL) + RCS_reparsercsfile (rcs, NULL); /* FIXME: This check should be moved to RCS_check_tag. There is no reason for it to be here. */ @@ -3190,89 +4121,61 @@ RCS_settag (rcs, tag, rev) return 1; } - ret = RCS_exec_settag (rcs->path, tag, rev); - if (ret != 0) - return ret; - - /* If we have already parsed the RCS file, update the tag - information. If we have not yet parsed it (i.e., the PARTIAL - flag is set), the new tag information will be read when and if - we do parse it. */ - if ((rcs->flags & PARTIAL) == 0) + /* A revision number of NULL means use the head or default branch. + If rev is not NULL, it may be a symbolic tag or branch number; + expand it to the correct numeric revision or branch head. */ + if (rev == NULL) + rev = rcs->branch ? rcs->branch : rcs->head; + + /* At this point rcs->symbol_data may not have been parsed. + Calling RCS_symbols will force it to be parsed into a list + which we can easily manipulate. */ + symbols = RCS_symbols (rcs); + if (symbols == NULL) { - List *symbols; - Node *node; - - /* At this point rcs->symbol_data may not have been parsed. - Calling RCS_symbols will force it to be parsed into a list - which we can easily manipulate. */ - symbols = RCS_symbols (rcs); - if (symbols == NULL) - { - symbols = getlist (); - rcs->symbols = symbols; - } - node = findnode (symbols, tag); - if (node != NULL) - { - free (node->data); - node->data = xstrdup (rev); - } - else - { - node = getnode (); - node->key = xstrdup (tag); - node->data = xstrdup (rev); - (void) addnode (symbols, node); - } + symbols = getlist (); + rcs->symbols = symbols; + } + node = findnode (symbols, tag); + if (node != NULL) + { + free (node->data); + node->data = xstrdup (rev); + } + else + { + node = getnode (); + node->key = xstrdup (tag); + node->data = xstrdup (rev); + (void) addnode_at_front (symbols, node); } - - /* Setting the tag will most likely have invalidated delta_pos. */ - rcs->flags |= NODELTA; return 0; } -/* Delete the symbolic tag TAG from the RCS file RCS. NOERR is 1 to - suppress errors--FIXME it would be better to avoid the errors or - some cleaner solution. */ +/* Delete the symbolic tag TAG from the RCS file RCS. Return 0 if + the tag was found (and removed), or 1 if it was not present. (In + either case, the tag will no longer be in RCS->SYMBOLS.) */ int -RCS_deltag (rcs, tag, noerr) +RCS_deltag (rcs, tag) RCSNode *rcs; const char *tag; - int noerr; { - int ret; - - ret = RCS_exec_deltag (rcs->path, tag, noerr); - if (ret != 0) - return ret; - - /* If we have already parsed the RCS file, update the tag - information. If we have not yet parsed it (i.e., the PARTIAL - flag is set), the new tag information will be read when and if - we do parse it. */ - if ((rcs->flags & PARTIAL) == 0) - { - List *symbols; + List *symbols; + Node *node; + if (rcs->flags & PARTIAL) + RCS_reparsercsfile (rcs, NULL); - /* At this point rcs->symbol_data may not have been parsed. - Calling RCS_symbols will force it to be parsed into a list - which we can easily manipulate. */ - symbols = RCS_symbols (rcs); - if (symbols != NULL) - { - Node *node; + symbols = RCS_symbols (rcs); + if (symbols == NULL) + return 1; - node = findnode (symbols, tag); - if (node != NULL) - delnode (node); - } - } + node = findnode (symbols, tag); + if (node == NULL) + return 1; - /* Deleting the tag will most likely have invalidated delta_pos. */ - rcs->flags |= NODELTA; + delnode (node); return 0; } @@ -3284,124 +4187,836 @@ RCS_setbranch (rcs, rev) RCSNode *rcs; const char *rev; { - int ret; + if (rcs->flags & PARTIAL) + RCS_reparsercsfile (rcs, NULL); if (rev == NULL && rcs->branch == NULL) return 0; if (rev != NULL && rcs->branch != NULL && strcmp (rev, rcs->branch) == 0) return 0; - ret = RCS_exec_setbranch (rcs->path, rev); - if (ret != 0) - return ret; - if (rcs->branch != NULL) free (rcs->branch); rcs->branch = xstrdup (rev); - /* Changing the branch will have changed the data in the file, so - delta_pos will no longer be correct. */ - rcs->flags |= NODELTA; - return 0; } -/* Lock revision REV. NOERR is 1 to suppress errors--FIXME it would - be better to avoid the errors or some cleaner solution. FIXME: +/* Lock revision REV. LOCK_QUIET is 1 to suppress output. FIXME: This is only required because the RCS ci program requires a lock. If we eventually do the checkin ourselves, this can become a no-op. */ +/* FIXME-twp: if a lock owned by someone else is broken, should this + send mail to the lock owner? Prompt user? It seems like such an + obscure situation for CVS as almost not worth worrying much + about. */ int -RCS_lock (rcs, rev, noerr) +RCS_lock (rcs, rev, lock_quiet) RCSNode *rcs; const char *rev; - int noerr; + int lock_quiet; { - int ret; + List *locks; + Node *p; + char *user; + char *xrev = NULL; + + if (rcs->flags & PARTIAL) + RCS_reparsercsfile (rcs, NULL); + + locks = RCS_getlocks (rcs); + if (locks == NULL) + locks = rcs->locks = getlist(); + user = getcaller(); + + /* A revision number of NULL means lock the head or default branch. */ + if (rev == NULL) + xrev = RCS_head (rcs); + + /* If rev is a branch number, lock the latest revision on that + branch. I think that if the branch doesn't exist, it's + okay to return 0 -- that just means that the branch is new, + so we don't need to lock it anyway. -twp */ + else if (RCS_nodeisbranch (rcs, rev)) + { + xrev = RCS_getbranch (rcs, (char *) rev, 1); + if (xrev == NULL) + { + if (!lock_quiet) + error (0, 0, "%s: branch %s absent", rcs->path, rev); + return 1; + } + } + + if (xrev == NULL) + xrev = xstrdup (rev); + + /* Make sure that the desired revision exists. Technically, + we can update the locks list without even checking this, + but RCS 5.7 did this. And it can't hurt. */ + if (findnode (rcs->versions, xrev) == NULL) + { + if (!lock_quiet) + error (0, 0, "%s: revision %s absent", rcs->path, xrev); + free (xrev); + return 1; + } - ret = RCS_exec_lock (rcs->path, rev, noerr); - if (ret != 0) - return ret; + /* Is this rev already locked? */ + p = findnode (locks, xrev); + if (p != NULL) + { + if (strcmp (p->data, user) == 0) + { + /* We already own the lock on this revision, so do nothing. */ + free (xrev); + return 0; + } - /* Setting a lock will have changed the data in the file, so - delta_pos will no longer be correct. */ - rcs->flags |= NODELTA; + /* Break the lock. */ + if (!lock_quiet) + { + cvs_output (rev, 0); + cvs_output (" unlocked\n", 0); + } + delnode (p); + } + + /* Create a new lock. */ + p = getnode(); + p->key = xrev; /* already xstrdupped */ + p->data = xstrdup (getcaller()); + (void) addnode_at_front (locks, p); + + if (!lock_quiet) + { + cvs_output (xrev, 0); + cvs_output (" locked\n", 0); + } return 0; } -/* Unlock revision REV. NOERR is 1 to suppress errors--FIXME it would - be better to avoid the errors or some cleaner solution. FIXME: +/* Unlock revision REV. UNLOCK_QUIET is 1 to suppress output. FIXME: Like RCS_lock, this can become a no-op if we do the checkin - ourselves. */ + ourselves. + + If REV is not null and is locked by someone else, break their + lock and notify them. It is an open issue whether RCS_unlock + queries the user about whether or not to break the lock. */ int -RCS_unlock (rcs, rev, noerr) +RCS_unlock (rcs, rev, unlock_quiet) RCSNode *rcs; const char *rev; - int noerr; + int unlock_quiet; { - int ret; + Node *lock; + List *locks; + char *user; + char *xrev = NULL; + + user = getcaller(); + if (rcs->flags & PARTIAL) + RCS_reparsercsfile (rcs, NULL); + + /* If rev is NULL, unlock the latest revision (first in + rcs->locks) held by the caller. */ + if (rev == NULL) + { + Node *p; + + /* No-ops: attempts to unlock an empty tree or an unlocked file. */ + if (rcs->head == NULL) + { + if (!unlock_quiet) + cvs_outerr ("can't unlock an empty tree\n", 0); + return 0; + } + + locks = RCS_getlocks (rcs); + if (locks == NULL) + { + if (!unlock_quiet) + cvs_outerr ("No locks are set.\n", 0); + return 0; + } + + lock = NULL; + for (p = locks->list->next; p != locks->list; p = p->next) + { + if (strcmp (p->data, user) == 0) + { + if (lock != NULL) + { + if (!unlock_quiet) + error (0, 0, "\ +%s: multiple revisions locked by %s; please specify one", rcs->path, user); + return 1; + } + lock = p; + } + } + if (lock == NULL) + return 0; /* no lock found, ergo nothing to do */ + xrev = xstrdup (lock->key); + } + else if (RCS_nodeisbranch (rcs, rev)) + { + /* If rev is a branch number, unlock the latest revision on that + branch. */ + xrev = RCS_getbranch (rcs, (char *) rev, 1); + if (xrev == NULL) + { + error (0, 0, "%s: branch %s absent", rcs->path, rev); + return 1; + } + } + else + /* REV is an exact revision number. */ + xrev = xstrdup (rev); - ret = RCS_exec_unlock (rcs->path, rev, noerr); - if (ret != 0) - return ret; + lock = findnode (RCS_getlocks (rcs), xrev); + if (lock == NULL) + { + /* This revision isn't locked. */ + free (xrev); + return 0; + } - /* Setting a lock will have changed the data in the file, so - delta_pos will no longer be correct. */ - rcs->flags |= NODELTA; + if (strcmp (lock->data, user) != 0) + { + /* If the revision is locked by someone else, notify + them. Note that this shouldn't ever happen if RCS_unlock + is called with a NULL revision, since that means "whatever + revision is currently locked by the caller." */ + char *repos, *workfile; + repos = xstrdup (rcs->path); + workfile = strrchr (repos, '/'); + *workfile++ = '\0'; + notify_do ('C', workfile, user, NULL, NULL, repos); + free (repos); + } + + delnode (lock); + if (!unlock_quiet) + { + cvs_output (xrev, 0); + cvs_output (" unlocked\n", 0); + } + free (xrev); return 0; } - -/* RCS_deltas and friends. Processing of the deltas in RCS files. */ -/* Linked list of allocated blocks. Seems kind of silly to - reinvent the obstack wheel, and this isn't as nice as obstacks - in some ways, but obstacks are pretty baroque. */ -struct allocblock +/* Add USER to the access list of RCS. Do nothing if already present. + FIXME-twp: check syntax of USER to make sure it's a valid id. */ + +void +RCS_addaccess (rcs, user) + RCSNode *rcs; + char *user; { - char *text; - struct allocblock *next; -}; -struct allocblock *blocks; + char *access, *a; -static void *block_alloc PROTO ((size_t)); + if (rcs->flags & PARTIAL) + RCS_reparsercsfile (rcs, NULL); -static void * -block_alloc (n) - size_t n; -{ - struct allocblock *blk; - blk = (struct allocblock *) xmalloc (sizeof (struct allocblock)); - blk->text = xmalloc (n); - blk->next = blocks; - blocks = blk; - return blk->text; + if (rcs->access == NULL) + rcs->access = xstrdup (user); + else + { + access = xstrdup (rcs->access); + for (a = strtok (access, " "); a != NULL; a = strtok (NULL, " ")) + { + if (strcmp (a, user) == 0) + { + free (access); + return; + } + } + rcs->access = (char *) xrealloc + (rcs->access, strlen (rcs->access) + strlen (user) + 2); + strcat (rcs->access, " "); + strcat (rcs->access, user); + } } -static void block_free PROTO ((void)); +/* Remove USER from the access list of RCS. */ -static void -block_free () +void +RCS_delaccess (rcs, user) + RCSNode *rcs; + char *user; { - struct allocblock *p; - struct allocblock *q; + char *p, *s; + int ulen; + + if (rcs->flags & PARTIAL) + RCS_reparsercsfile (rcs, NULL); + + if (rcs->access == NULL) + return; - p = blocks; + p = rcs->access; + ulen = strlen (user); while (p != NULL) { - free (p->text); - q = p->next; - free (p); - p = q; + if (p[ulen] == '\0' || p[ulen] == ' ') + if (strncmp (p, user, ulen) == 0) + break; + p = strchr (p, ' '); + if (p != NULL) + ++p; } - blocks = NULL; + + if (p == NULL) + return; + + s = p + ulen; + while (*s != '\0') + *p++ = *s++; + *p = '\0'; +} + +char * +RCS_getaccess (rcs) + RCSNode *rcs; +{ + if (rcs->flags & PARTIAL) + RCS_reparsercsfile (rcs, NULL); + + return rcs->access; } +static int findtag PROTO ((Node *, void *)); + +/* Return a nonzero value if the revision specified by ARG is found. */ + +static int +findtag (node, arg) + Node *node; + void *arg; +{ + char *rev = (char *)arg; + + if (strcmp (node->data, rev) == 0) + return 1; + else + return 0; +} + +/* Delete revisions between REV1 and REV2. The changes between the two + revisions must be collapsed, and the result stored in the revision + immediately preceding the lower one. Return 0 for successful completion, + 1 otherwise. + + Solution: check out the revision preceding REV1 and the revision + following REV2. Use call_diff to find aggregate diffs between + these two revisions, and replace the delta text for the latter one + with the new aggregate diff. Alternatively, we could write a + function that takes two change texts and combines them to produce a + new change text, without checking out any revs or calling diff. It + would be hairy, but so, so cool. + + If INCLUSIVE is set, then TAG1 and TAG2, if non-NULL, tell us to + delete that revision as well (cvs admin -o tag1:tag2). If clear, + delete up to but not including that revision (cvs admin -o tag1::tag2). + This does not affect TAG1 or TAG2 being NULL; the meaning of the start + point in ::tag2 and :tag2 is the same and likewise for end points. */ + +int +RCS_delete_revs (rcs, tag1, tag2, inclusive) + RCSNode *rcs; + char *tag1; + char *tag2; + int inclusive; +{ + char *next; + Node *nodep; + RCSVers *revp = NULL; + RCSVers *beforep; + int status, found; + int save_noexec; + + char *branchpoint = NULL; + char *rev1 = NULL; + char *rev2 = NULL; + int rev1_inclusive = inclusive; + int rev2_inclusive = inclusive; + char *before = NULL; + char *after = NULL; + char *beforefile = NULL; + char *afterfile = NULL; + char *outfile = NULL; + + if (tag1 == NULL && tag2 == NULL) + return 0; + + /* Assume error status until everything is finished. */ + status = 1; + + /* Make sure both revisions exist. */ + if (tag1 != NULL) + { + rev1 = RCS_gettag (rcs, tag1, 1, NULL); + if (rev1 == NULL || (nodep = findnode (rcs->versions, rev1)) == NULL) + { + error (0, 0, "%s: Revision %s doesn't exist.", rcs->path, tag1); + goto delrev_done; + } + } + if (tag2 != NULL) + { + rev2 = RCS_gettag (rcs, tag2, 1, NULL); + if (rev2 == NULL || (nodep = findnode (rcs->versions, rev2)) == NULL) + { + error (0, 0, "%s: Revision %s doesn't exist.", rcs->path, tag2); + goto delrev_done; + } + } + + /* If rev1 is on the trunk and rev2 is NULL, rev2 should be + RCS->HEAD. (*Not* RCS_head(rcs), which may return rcs->branch + instead.) We need to check this special case early, in order + to make sure that rev1 and rev2 get ordered correctly. */ + if (rev2 == NULL && numdots (rev1) == 1) + { + rev2 = xstrdup (rcs->head); + rev2_inclusive = 1; + } + + if (rev2 == NULL) + rev2_inclusive = 1; + + if (rev1 != NULL && rev2 != NULL) + { + /* A range consisting of a branch number means the latest revision + on that branch. */ + if (RCS_isbranch (rcs, rev1) && strcmp (rev1, rev2) == 0) + rev1 = rev2 = RCS_getbranch (rcs, rev1, 0); + else + { + /* Make sure REV1 and REV2 are ordered correctly (in the + same order as the next field). For revisions on the + trunk, REV1 should be higher than REV2; for branches, + REV1 should be lower. */ + /* Shouldn't we just be giving an error in the case where + the user specifies the revisions in the wrong order + (that is, always swap on the trunk, never swap on a + branch, in the non-error cases)? It is not at all + clear to me that users who specify -o 1.4:1.2 really + meant to type -o 1.2:1.4, and the out of order usage + has never been documented, either by cvs.texinfo or + rcs(1). */ + char *temp; + int temp_inclusive; + if (numdots (rev1) == 1) + { + if (compare_revnums (rev1, rev2) <= 0) + { + temp = rev2; + rev2 = rev1; + rev1 = temp; + + temp_inclusive = rev2_inclusive; + rev2_inclusive = rev1_inclusive; + rev1_inclusive = temp_inclusive; + } + } + else if (compare_revnums (rev1, rev2) > 0) + { + temp = rev2; + rev2 = rev1; + rev1 = temp; + + temp_inclusive = rev2_inclusive; + rev2_inclusive = rev1_inclusive; + rev1_inclusive = temp_inclusive; + } + } + } + + /* Basically the same thing; make sure that the ordering is what we + need. */ + if (rev1 == NULL) + { + assert (rev2 != NULL); + if (numdots (rev2) == 1) + { + /* Swap rev1 and rev2. */ + int temp_inclusive; + + rev1 = rev2; + rev2 = NULL; + + temp_inclusive = rev2_inclusive; + rev2_inclusive = rev1_inclusive; + rev1_inclusive = temp_inclusive; + } + } + + /* Put the revision number preceding the first one to delete into + BEFORE (where "preceding" means according to the next field). + If the first revision to delete is the first revision on its + branch (e.g. 1.3.2.1), BEFORE should be the node on the trunk + at which the branch is rooted. If the first revision to delete + is the head revision of the trunk, set BEFORE to NULL. + + Note that because BEFORE may not be on the same branch as REV1, + it is not very handy for navigating the revision tree. It's + most useful just for checking out the revision preceding REV1. */ + before = NULL; + branchpoint = RCS_getbranchpoint (rcs, rev1 != NULL ? rev1 : rev2); + if (rev1 == NULL) + { + rev1 = xstrdup (branchpoint); + if (numdots (branchpoint) > 1) + { + char *bp; + bp = strrchr (branchpoint, '.'); + while (*--bp != '.') + ; + *bp = '\0'; + /* Note that this is exclusive, always, because the inclusive + flag doesn't affect the meaning when rev1 == NULL. */ + before = xstrdup (branchpoint); + *bp = '.'; + } + } + else if (strcmp (rev1, branchpoint) != 0) + { + /* Walk deltas from BRANCHPOINT on, looking for REV1. */ + nodep = findnode (rcs->versions, branchpoint); + revp = (RCSVers *) nodep->data; + while (revp->next != NULL && strcmp (revp->next, rev1) != 0) + { + revp = (RCSVers *) nodep->data; + nodep = findnode (rcs->versions, revp->next); + } + if (revp->next == NULL) + { + error (0, 0, "%s: Revision %s doesn't exist.", rcs->path, rev1); + goto delrev_done; + } + if (rev1_inclusive) + before = xstrdup (revp->version); + else + { + before = rev1; + nodep = findnode (rcs->versions, before); + rev1 = xstrdup (((RCSVers *)nodep->data)->next); + } + } + else if (!rev1_inclusive) + { + before = rev1; + nodep = findnode (rcs->versions, before); + rev1 = xstrdup (((RCSVers *)nodep->data)->next); + } + else if (numdots (branchpoint) > 1) + { + /* Example: rev1 is "1.3.2.1", branchpoint is "1.3.2.1". + Set before to "1.3". */ + char *bp; + bp = strrchr (branchpoint, '.'); + while (*--bp != '.') + ; + *bp = '\0'; + before = xstrdup (branchpoint); + *bp = '.'; + } + + /* If any revision between REV1 and REV2 is locked or is a branch point, + we can't delete that revision and must abort. */ + after = NULL; + next = rev1; + found = 0; + while (!found && next != NULL) + { + nodep = findnode (rcs->versions, next); + revp = (RCSVers *) nodep->data; + + if (rev2 != NULL) + found = (strcmp (revp->version, rev2) == 0); + next = revp->next; + + if ((!found && next != NULL) || rev2_inclusive || rev2 == NULL) + { + if (findnode (RCS_getlocks (rcs), revp->version)) + { + error (0, 0, "%s: can't remove locked revision %s", + rcs->path, + revp->version); + goto delrev_done; + } + if (revp->branches != NULL) + { + error (0, 0, "%s: can't remove branch point %s", + rcs->path, + revp->version); + goto delrev_done; + } + + /* Doing this only for the :: syntax is for compatibility. + See cvs.texinfo for somewhat more discussion. */ + if (!inclusive + && walklist (RCS_symbols (rcs), findtag, revp->version)) + { + /* We don't print which file this happens to on the theory + that the caller will print the name of the file in a + more useful fashion (fullname not rcs->path). */ + error (0, 0, "cannot remove revision %s because it has tags", + revp->version); + goto delrev_done; + } + + /* It's misleading to print the `deleting revision' output + here, since we may not actually delete these revisions. + But that's how RCS does it. Bleah. Someday this should be + moved to the point where the revs are actually marked for + deletion. -twp */ + cvs_output ("deleting revision ", 0); + cvs_output (revp->version, 0); + cvs_output ("\n", 1); + } + } + + if (rev2 == NULL) + ; + else if (found) + { + if (rev2_inclusive) + after = xstrdup (next); + else + after = xstrdup (revp->version); + } + else if (!inclusive) + { + /* In the case of an empty range, for example 1.2::1.2 or + 1.2::1.3, we want to just do nothing. */ + status = 0; + goto delrev_done; + } + else + { + /* This looks fishy in the cases where tag1 == NULL or tag2 == NULL. + Are those cases really impossible? */ + assert (tag1 != NULL); + assert (tag2 != NULL); + + error (0, 0, "%s: invalid revision range %s:%s", rcs->path, + tag1, tag2); + goto delrev_done; + } + + /* The conditionals at this point get really hairy. Here is the + general idea: + + IF before != NULL and after == NULL + THEN don't check out any revisions, just delete them + IF before == NULL and after != NULL + THEN only check out after's revision, and use it for the new deltatext + ELSE + check out both revisions and diff -n them. This could use + RCS_exec_rcsdiff with some changes, like being able + to suppress diagnostic messages and to direct output. */ + + assert (before != NULL || after != NULL); + + if (after != NULL) + { + char *diffbuf; + size_t bufsize, len; + + afterfile = cvs_temp_name(); + status = RCS_checkout (rcs, NULL, after, NULL, NULL, afterfile, + (RCSCHECKOUTPROC)0, NULL); + if (status > 0) + goto delrev_done; + + else if (status < 0) + { + error (0, errno, + "cannot check out revision %s of %s", after, rcs->path); + goto delrev_done; + } + + if (before == NULL) + { + /* We are deleting revisions from the head of the tree, + so must create a new head. */ + diffbuf = NULL; + bufsize = 0; + get_file (afterfile, afterfile, "r", &diffbuf, &bufsize, &len); + + save_noexec = noexec; + noexec = 0; + if (unlink_file (afterfile) < 0) + error (0, errno, "cannot remove %s", afterfile); + noexec = save_noexec; + + free (afterfile); + afterfile = NULL; + + free (rcs->head); + rcs->head = xstrdup (after); + } + else + { + beforefile = cvs_temp_name(); + status = RCS_checkout (rcs, NULL, before, NULL, NULL, beforefile, + (RCSCHECKOUTPROC)0, NULL); + if (status > 0) + goto delrev_done; + else if (status < 0) + { + error (0, errno, "cannot check out revision %s of %s", + before, rcs->path); + goto delrev_done; + } + + outfile = cvs_temp_name(); + status = diff_exec (beforefile, afterfile, "-n", outfile); + + if (status == 2) + { + /* Not sure we need this message; will diff_exec already + have printed an error? */ + error (0, 0, "%s: could not diff", rcs->path); + status = 1; + goto delrev_done; + } + + diffbuf = NULL; + bufsize = 0; + get_file (outfile, outfile, "r", &diffbuf, &bufsize, &len); + } + + /* Save the new change text in after's delta node. */ + nodep = findnode (rcs->versions, after); + revp = (RCSVers *) nodep->data; + + assert (revp->text == NULL); + + revp->text = (Deltatext *) xmalloc (sizeof (Deltatext)); + memset ((Deltatext *) revp->text, 0, sizeof (Deltatext)); + revp->text->version = xstrdup (revp->version); + revp->text->text = diffbuf; + revp->text->len = len; + + /* If DIFFBUF is NULL, it means that OUTFILE is empty and that + there are no differences between the two revisions. In that + case, we want to force RCS_copydeltas to write an empty string + for the new change text (leaving the text field set NULL + means "preserve the original change text for this delta," so + we don't want that). */ + if (revp->text->text == NULL) + revp->text->text = xstrdup (""); + } + + /* Walk through the revisions (again) to mark each one as + outdated. (FIXME: would it be safe to use the `dead' field for + this? Doubtful.) */ + for (next = rev1; + next != NULL && (after == NULL || strcmp (next, after) != 0); + next = revp->next) + { + nodep = findnode (rcs->versions, next); + revp = (RCSVers *) nodep->data; + revp->outdated = 1; + } + + /* Update delta links. If BEFORE == NULL, we're changing the + head of the tree and don't need to update any `next' links. */ + if (before != NULL) + { + /* If REV1 is the first node on its branch, then BEFORE is its + root node (on the trunk) and we have to update its branches + list. Otherwise, BEFORE is on the same branch as AFTER, and + we can just change BEFORE's `next' field to point to AFTER. + (This should be safe: since findnode manages its lists via + the `hashnext' and `hashprev' fields, rather than `next' and + `prev', mucking with `next' and `prev' should not corrupt the + delta tree's internal structure. Much. -twp) */ + + if (rev1 == NULL) + /* beforep's ->next field already should be equal to after, + which I think is always NULL in this case. */ + ; + else if (strcmp (rev1, branchpoint) == 0) + { + nodep = findnode (rcs->versions, before); + revp = (RCSVers *) nodep->data; + nodep = revp->branches->list->next; + while (nodep != revp->branches->list && + strcmp (nodep->key, rev1) != 0) + nodep = nodep->next; + assert (nodep != revp->branches->list); + if (after == NULL) + delnode (nodep); + else + { + free (nodep->key); + nodep->key = xstrdup (after); + } + } + else + { + nodep = findnode (rcs->versions, before); + beforep = (RCSVers *) nodep->data; + free (beforep->next); + beforep->next = xstrdup (after); + } + } + + status = 0; + + delrev_done: + if (rev1 != NULL) + free (rev1); + if (rev2 != NULL) + free (rev2); + if (branchpoint != NULL) + free (branchpoint); + if (before != NULL) + free (before); + if (after != NULL) + free (after); + + save_noexec = noexec; + noexec = 0; + if (beforefile != NULL) + { + if (unlink_file (beforefile) < 0) + error (0, errno, "cannot remove %s", beforefile); + free (beforefile); + } + if (afterfile != NULL) + { + if (unlink_file (afterfile) < 0) + error (0, errno, "cannot remove %s", afterfile); + free (afterfile); + } + if (outfile != NULL) + { + if (unlink_file (outfile) < 0) + error (0, errno, "cannot remove %s", outfile); + free (outfile); + } + noexec = save_noexec; + + return status; +} + +/* RCS_deltas and friends. Processing of the deltas in RCS files. */ + struct line { - /* Text of this line. */ + /* Text of this line. Part of the same malloc'd block as the struct + line itself (we probably should use the "struct hack" (char text[1]) + and save ourselves sizeof (char *) bytes). Does not include \n; + instead has_newline indicates the presence or absence of \n. */ char *text; /* Length of this line, not counting \n if has_newline is true. */ size_t len; @@ -3410,6 +5025,8 @@ struct line /* Nonzero if this line ends with \n. This will always be true except possibly for the last line. */ int has_newline; + /* Number of pointers to this struct line. */ + int refcount; }; struct linevector @@ -3434,30 +5051,36 @@ linevector_init (vec) vec->vector = NULL; } -static int linevector_add PROTO ((struct linevector *vec, char *text, +static int linevector_add PROTO ((struct linevector *vec, const char *text, size_t len, RCSVers *vers, unsigned int pos)); /* Given some text TEXT, add each of its lines to VEC before line POS (where line 0 is the first line). The last line in TEXT may or may - not be \n terminated. All \n in TEXT are changed to \0 (FIXME: I - don't think this is needed, or used, now that we have the ->len - field). Set the version for each of the new lines to VERS. This + not be \n terminated. + Set the version for each of the new lines to VERS. This function returns non-zero for success. It returns zero if the line - number is out of range. */ + number is out of range. + + Each of the lines in TEXT are copied to space which is managed with + the linevector (and freed by linevector_free). So the caller doesn't + need to keep TEXT around after the call to this function. */ static int linevector_add (vec, text, len, vers, pos) struct linevector *vec; - char *text; + const char *text; size_t len; RCSVers *vers; unsigned int pos; { - char *textend; + const char *textend; unsigned int i; unsigned int nnew; - char *p; - struct line *lines; + const char *p; + const char *nextline_text; + size_t nextline_len; + int nextline_newline; + struct line *q; if (len == 0) return 1; @@ -3469,8 +5092,6 @@ linevector_add (vec, text, len, vers, pos) for (p = text; p < textend; ++p) if (*p == '\n' && p + 1 < textend) ++nnew; - /* Allocate the struct line's. */ - lines = block_alloc (nnew * sizeof (struct line)); /* Expand VEC->VECTOR if needed. */ if (vec->nlines + nnew >= vec->lines_alloced) @@ -3490,29 +5111,41 @@ linevector_add (vec, text, len, vers, pos) if (pos > vec->nlines) return 0; - /* Actually add the lines, to LINES and VEC->VECTOR. */ + /* Actually add the lines, to VEC->VECTOR. */ i = pos; - lines[0].text = text; - lines[0].vers = vers; - lines[0].has_newline = 0; - vec->vector[i++] = &lines[0]; + nextline_text = text; + nextline_newline = 0; for (p = text; p < textend; ++p) if (*p == '\n') { - *p = '\0'; - lines[i - pos - 1].has_newline = 1; + nextline_newline = 1; if (p + 1 == textend) /* If there are no characters beyond the last newline, we don't consider it another line. */ break; - lines[i - pos - 1].len = p - lines[i - pos - 1].text; - lines[i - pos].text = p + 1; - lines[i - pos].vers = vers; - lines[i - pos].has_newline = 0; - vec->vector[i] = &lines[i - pos]; - ++i; - } - lines[i - pos - 1].len = p - lines[i - pos - 1].text; + nextline_len = p - nextline_text; + q = (struct line *) xmalloc (sizeof (struct line) + nextline_len); + q->vers = vers; + q->text = (char *)q + sizeof (struct line); + q->len = nextline_len; + q->has_newline = nextline_newline; + q->refcount = 1; + memcpy (q->text, nextline_text, nextline_len); + vec->vector[i++] = q; + + nextline_text = (char *)p + 1; + nextline_newline = 0; + } + nextline_len = p - nextline_text; + q = (struct line *) xmalloc (sizeof (struct line) + nextline_len); + q->vers = vers; + q->text = (char *)q + sizeof (struct line); + q->len = nextline_len; + q->has_newline = nextline_newline; + q->refcount = 1; + memcpy (q->text, nextline_text, nextline_len); + vec->vector[i] = q; + vec->nlines += nnew; return 1; @@ -3533,6 +5166,11 @@ linevector_delete (vec, pos, nlines) unsigned int last; last = vec->nlines - nlines; + for (i = pos; i < pos + nlines; ++i) + { + if (--vec->vector[i]->refcount == 0) + free (vec->vector[i]); + } for (i = pos; i < last; ++i) vec->vector[i] = vec->vector[i + nlines]; vec->nlines -= nlines; @@ -3546,6 +5184,13 @@ linevector_copy (to, from) struct linevector *to; struct linevector *from; { + unsigned int ln; + + for (ln = 0; ln < to->nlines; ++ln) + { + if (--to->vector[ln]->refcount == 0) + free (to->vector[ln]); + } if (from->nlines > to->lines_alloced) { if (to->lines_alloced == 0) @@ -3558,18 +5203,27 @@ linevector_copy (to, from) memcpy (to->vector, from->vector, from->nlines * sizeof (*to->vector)); to->nlines = from->nlines; + for (ln = 0; ln < to->nlines; ++ln) + ++to->vector[ln]->refcount; } static void linevector_free PROTO ((struct linevector *)); -/* Free storage associated with linevector (that is, the vector but - not the lines pointed to). */ +/* Free storage associated with linevector. */ static void linevector_free (vec) struct linevector *vec; { + unsigned int ln; + if (vec->vector != NULL) + { + for (ln = 0; ln < vec->nlines; ++ln) + if (--vec->vector[ln]->refcount == 0) + free (vec->vector[ln]); + free (vec->vector); + } } static char *month_printname PROTO ((char *)); @@ -3630,7 +5284,7 @@ apply_rcs_changes (lines, diffbuf, difflen, name, addvers, delvers) enum {ADD, DELETE} type; unsigned long pos; unsigned long nlines; - char *new_lines; + const char *new_lines; size_t len; struct deltafrag *next; }; @@ -3683,9 +5337,8 @@ apply_rcs_changes (lines, diffbuf, difflen, name, addvers, delvers) break; } - /* Copy the text we are adding into allocated space. */ - df->new_lines = block_alloc (q - p); - memcpy (df->new_lines, p, q - p); + /* Stash away a pointer to the text we are adding. */ + df->new_lines = p; df->len = q - p; p = q; @@ -3735,9 +5388,9 @@ apply_rcs_changes (lines, diffbuf, difflen, name, addvers, delvers) argument. NAME is used in error messages. TEXTBUF is the text buffer to change, and TEXTLEN is the size. DIFFBUF and DIFFLEN are the change buffer and size. The new buffer is returned in *RETBUF - and *RETLEN. The new buffer is allocated by xmalloc. The function - changes the contents of TEXTBUF. This function returns 1 for - success. On failure, it calls error and returns 0. */ + and *RETLEN. The new buffer is allocated by xmalloc. + + Return 1 for success. On failure, call error and return 0. */ int rcs_change_text (name, textbuf, textlen, diffbuf, difflen, retbuf, retlen) @@ -3795,11 +5448,6 @@ rcs_change_text (name, textbuf, textlen, diffbuf, difflen, retbuf, retlen) linevector_free (&lines); - /* Note that this assumes that we have not called from anything - else which uses the block vectors. FIXME: We could fix this by - saving and restoring the state of the block allocation code. */ - block_free (); - return ret; } @@ -3851,19 +5499,11 @@ RCS_deltas (rcs, fp, version, op, text, len, log, loglen) if (fp == NULL) { - if (rcs->flags & NODELTA) - { - free_rcsnode_contents (rcs); - RCS_reparsercsfile (rcs, 0, &fp); - } - else - { - fp = CVS_FOPEN (rcs->path, FOPEN_BINARY_READ); - if (fp == NULL) - error (1, 0, "unable to reopen `%s'", rcs->path); - if (fseek (fp, rcs->delta_pos, SEEK_SET) != 0) - error (1, 0, "cannot fseek RCS file"); - } + fp = CVS_FOPEN (rcs->path, FOPEN_BINARY_READ); + if (fp == NULL) + error (1, 0, "unable to reopen `%s'", rcs->path); + if (fseek (fp, rcs->delta_pos, SEEK_SET) != 0) + error (1, 0, "cannot fseek RCS file"); } ishead = 1; @@ -3940,12 +5580,7 @@ RCS_deltas (rcs, fp, version, op, text, len, log, loglen) { if (ishead) { - char *p; - - p = block_alloc (vallen); - memcpy (p, value, vallen); - - if (! linevector_add (&curlines, p, vallen, NULL, 0)) + if (! linevector_add (&curlines, value, vallen, NULL, 0)) error (1, 0, "invalid rcs file %s", rcs->path); ishead = 0; @@ -4084,7 +5719,18 @@ RCS_deltas (rcs, fp, version, op, text, len, log, loglen) /* Now output the date. */ ym = strchr (prvers->date, '.'); if (ym == NULL) - cvs_output ("?\?-??\?-??", 0); + { + /* ??- is an ANSI trigraph. The ANSI way to + avoid it is \? but some pre ANSI compilers + complain about the unrecognized escape + sequence. Of course string concatenation + ("??" "-???") is also an ANSI-ism. Testing + __STDC__ seems to be a can of worms, since + compilers do all kinds of things with it. */ + cvs_output ("??", 0); + cvs_output ("-???", 0); + cvs_output ("-??", 0); + } else { md = strchr (ym + 1, '.'); @@ -4102,8 +5748,9 @@ RCS_deltas (rcs, fp, version, op, text, len, log, loglen) cvs_output (ym - 2, 2); } cvs_output ("): ", 0); - cvs_output (headlines.vector[ln]->text, - headlines.vector[ln]->len); + if (headlines.vector[ln]->len != 0) + cvs_output (headlines.vector[ln]->text, + headlines.vector[ln]->len); cvs_output ("\n", 1); } } @@ -4141,7 +5788,6 @@ RCS_deltas (rcs, fp, version, op, text, len, log, loglen) linevector_free (&headlines); linevector_free (&trunklines); - block_free (); return; l_error: @@ -4151,6 +5797,720 @@ RCS_deltas (rcs, fp, version, op, text, len, log, loglen) error (1, 0, "%s does not appear to be a valid rcs file", rcs->path); } + +static RCSVers * +getdelta (fp, rcsfile) + FILE *fp; + char *rcsfile; +{ + RCSVers *vnode; + char *key, *value, *cp; + long fpos; + Node *kv; + + vnode = (RCSVers *) xmalloc (sizeof (RCSVers)); + memset (vnode, 0, sizeof (RCSVers)); + + /* Get revision number. This uses getrcskey because it doesn't + croak when encountering unexpected input. As a result, we have + to play unholy games with `key' and `value'. */ + fpos = ftell (fp); + getrcskey (fp, &key, &value, NULL); + + /* Make sure that it is a revision number and not a cabbage + or something. */ + for (cp = key; (isdigit (*cp) || *cp == '.') && *cp != '\0'; cp++) + /* do nothing */ ; + if (*cp != '\0' || strncmp (RCSDATE, value, strlen (RCSDATE)) != 0) + { + (void) fseek (fp, fpos, SEEK_SET); + free (vnode); + return NULL; + } + vnode->version = xstrdup (key); + + /* grab the value of the date from value */ + cp = value + strlen (RCSDATE);/* skip the "date" keyword */ + while (whitespace (*cp)) /* take space off front of value */ + cp++; + + vnode->date = xstrdup (cp); + + /* Get author field. */ + (void) getrcskey (fp, &key, &value, NULL); + /* FIXME: should be using errno in case of ferror. */ + if (key == NULL || strcmp (key, "author") != 0) + error (1, 0, "\ +unable to parse rcs file; `author' not in the expected place"); + vnode->author = xstrdup (value); + + /* Get state field. */ + (void) getrcskey (fp, &key, &value, NULL); + /* FIXME: should be using errno in case of ferror. */ + if (key == NULL || strcmp (key, "state") != 0) + error (1, 0, "\ +unable to parse rcs file; `state' not in the expected place"); + vnode->state = xstrdup (value); + if (strcmp (value, "dead") == 0) + { + vnode->dead = 1; + } + + /* Note that "branches" and "next" are in fact mandatory, according + to doc/RCSFILES. We perhaps should be giving an error if they + are not there. */ + + /* fill in the branch list (if any branches exist) */ + fpos = ftell (fp); + (void) getrcskey (fp, &key, &value, NULL); + /* FIXME: should be handling various error conditions better. */ + if (key != NULL && strcmp (key, RCSDESC) == 0) + { + (void) fseek (fp, fpos, SEEK_SET); + return vnode; + } + if (value != (char *) NULL) + { + vnode->branches = getlist (); + do_branches (vnode->branches, value); + } + + /* fill in the next field if there is a next revision */ + fpos = ftell (fp); + (void) getrcskey (fp, &key, &value, NULL); + /* FIXME: should be handling various error conditions better. */ + if (key != NULL && strcmp (key, RCSDESC) == 0) + { + (void) fseek (fp, fpos, SEEK_SET); + return vnode; + } + if (value != (char *) NULL) + vnode->next = xstrdup (value); + + /* + * XXX - this is where we put the symbolic link stuff??? + * (into newphrases in the deltas). + */ + /* FIXME: Does not correctly handle errors, e.g. from stdio. */ + while (1) + { + fpos = ftell (fp); + if (getrcskey (fp, &key, &value, NULL) < 0) + break; + + assert (key != NULL); + + if (strcmp (key, RCSDESC) == 0) + break; + + /* Enable use of repositories created by certain obsolete + versions of CVS. This code should remain indefinately; + there is no procedure for converting old repositories, and + checking for it is harmless. */ + if (strcmp(key, RCSDEAD) == 0) + { + vnode->dead = 1; + if (vnode->state != NULL) + free (vnode->state); + vnode->state = xstrdup ("dead"); + continue; + } + /* if we have a new revision number, we're done with this delta */ + for (cp = key; (isdigit (*cp) || *cp == '.') && *cp != '\0'; cp++) + /* do nothing */ ; + if (*cp == '\0' && strncmp (RCSDATE, value, strlen (RCSDATE)) == 0) + break; + + /* At this point, key and value represent a user-defined field + in the delta node. */ + if (vnode->other_delta == NULL) + vnode->other_delta = getlist (); + kv = getnode (); + kv->type = RCSFIELD; + kv->key = xstrdup (key); + kv->data = xstrdup (value); + if (addnode (vnode->other_delta, kv) != 0) + { + /* Complaining about duplicate keys in newphrases seems + questionable, in that we don't know what they mean and + doc/RCSFILES has no prohibition on several newphrases + with the same key. But we can't store more than one as + long as we store them in a List *. */ + error (0, 0, "warning: duplicate key `%s' in RCS file `%s'", + key, rcsfile); + freenode (kv); + } + } + + /* We got here because we read beyond the end of a delta. Seek back + to the beginning of the erroneous read. */ + (void) fseek (fp, fpos, SEEK_SET); + + return vnode; +} + +static void +freedeltatext (d) + Deltatext *d; +{ + if (d->version != NULL) + free (d->version); + if (d->log != NULL) + free (d->log); + if (d->text != NULL) + free (d->text); + if (d->other != (List *) NULL) + dellist (&d->other); + free (d); +} + +static Deltatext * +RCS_getdeltatext (rcs, fp) + RCSNode *rcs; + FILE *fp; +{ + char *num; + char *key, *value; + int n; + Node *p; + Deltatext *d; + size_t textlen; + + /* Get the revision number. */ + n = getrevnum (fp, &num); + if (ferror (fp)) + error (1, errno, "%s: cannot read", rcs->path); + if (n == EOF) + { + /* If n == EOF and num == NULL, it means we reached EOF + naturally. That's fine. */ + if (num == NULL) + return NULL; + else + error (1, 0, "%s: unexpected EOF", rcs->path); + } + + p = findnode (rcs->versions, num); + if (p == NULL) + error (1, 0, "mismatch in rcs file %s between deltas and deltatexts", + rcs->path); + + d = (Deltatext *) xmalloc (sizeof (Deltatext)); + d->version = xstrdup (num); + + /* Get the log message. */ + if (getrcskey (fp, &key, &value, NULL) < 0) + error (1, 0, "%s, delta %s: unexpected EOF", rcs->path, num); + if (strcmp (key, "log") != 0) + error (1, 0, "%s, delta %s: expected `log', got `%s'", + rcs->path, num, key); + d->log = xstrdup (value); + + /* Get random newphrases. */ + d->other = getlist(); + for (n = getrcskey (fp, &key, &value, &textlen); + n >= 0 && strcmp (key, "text") != 0; + n = getrcskey (fp, &key, &value, &textlen)) + { + p = getnode(); + p->type = RCSFIELD; + p->key = xstrdup (key); + p->data = xstrdup (value); + if (addnode (d->other, p) < 0) + { + error (0, 0, "warning: %s, delta %s: duplicate field `%s'", + rcs->path, num, key); + } + } + if (n < 0) + error (1, 0, "%s, delta %s: unexpected EOF", rcs->path, num); + + /* Get the change text. We already know that this key is `text'. */ + d->text = (char *) malloc (textlen + 1); + d->len = textlen; + memcpy (d->text, value, textlen); + + return d; +} + +/* RCS output functions, for writing RCS format files from RCSNode + structures. + + For most of this work, RCS 5.7 uses an `aprintf' function which aborts + program upon error. Instead, these functions check the output status + of the stream right before closing it, and aborts if an error condition + is found. The RCS solution is probably the better one: it produces + more overhead, but will produce a clearer diagnostic in the case of + catastrophic error. In either case, however, the repository will probably + not get corrupted. */ + +static int +putsymbol_proc (symnode, fp) + Node *symnode; + void *fp; +{ + return fprintf ((FILE *) fp, "\n\t%s:%s", symnode->key, symnode->data); +} + +static int putlock_proc PROTO ((Node *, void *)); + +/* putlock_proc is like putsymbol_proc, but key and data are reversed. */ + +static int +putlock_proc (symnode, fp) + Node *symnode; + void *fp; +{ + return fprintf ((FILE *) fp, "\n\t%s:%s", symnode->data, symnode->key); +} + +static int +putrcsfield_proc (node, vfp) + Node *node; + void *vfp; +{ + FILE *fp = (FILE *) vfp; + + /* Some magic keys used internally by CVS start with `;'. Skip them. */ + if (node->key[0] == ';') + return 0; + + fprintf (fp, "\n%s\t", node->key); + if (node->data != NULL) + { + /* If the field's value contains evil characters, + it must be stringified. */ + /* FIXME: This does not quite get it right. "7jk8f" is not a legal + value for a value in a newpharse, according to doc/RCSFILES, + because digits are not valid in an "id". We might do OK by + always writing strings (enclosed in @@). Would be nice to + explicitly mention this one way or another in doc/RCSFILES. + A case where we are wrong in a much more clear-cut way is that + we let through non-graphic characters such as whitespace and + control characters. */ + int n = strcspn (node->data, "$,.:;@"); + if (node->data[n] == 0) + fputs (node->data, fp); + else + { + putc ('@', fp); + expand_at_signs (node->data, (off_t) strlen (node->data), fp); + putc ('@', fp); + } + } + + /* desc, log and text fields should not be terminated with semicolon; + all other fields should be. */ + if (strcmp (node->key, "desc") != 0 && + strcmp (node->key, "log") != 0 && + strcmp (node->key, "text") != 0) + { + putc (';', fp); + } + return 0; +} + +/* Output the admin node for RCS into stream FP. */ + +static void +RCS_putadmin (rcs, fp) + RCSNode *rcs; + FILE *fp; +{ + fprintf (fp, "%s\t%s;\n", RCSHEAD, rcs->head ? rcs->head : ""); + if (rcs->branch) + fprintf (fp, "%s\t%s;\n", RCSBRANCH, rcs->branch); + + fputs ("access", fp); + if (rcs->access) + { + char *p, *s; + s = xstrdup (rcs->access); + for (p = strtok (s, " \n\t"); p != NULL; p = strtok (NULL, " \n\t")) + fprintf (fp, "\n\t%s", p); + free (s); + } + fputs (";\n", fp); + + fputs (RCSSYMBOLS, fp); + walklist (RCS_symbols(rcs), putsymbol_proc, (void *) fp); + fputs (";\n", fp); + + fputs ("locks", fp); + if (rcs->locks_data) + fprintf (fp, "\t%s", rcs->locks_data); + else if (rcs->locks) + walklist (rcs->locks, putlock_proc, (void *) fp); + if (rcs->strict_locks) + fprintf (fp, "; strict"); + fputs (";\n", fp); + + if (rcs->comment) + { + fprintf (fp, "comment\t@"); + expand_at_signs (rcs->comment, (off_t) strlen (rcs->comment), fp); + fputs ("@;\n", fp); + } + if (rcs->expand && strcmp (rcs->expand, "kv") != 0) + fprintf (fp, "%s\t@%s@;\n", RCSEXPAND, rcs->expand); + + walklist (rcs->other, putrcsfield_proc, (void *) fp); + + putc ('\n', fp); +} + +static void +putdelta (vers, fp) + RCSVers *vers; + FILE *fp; +{ + Node *bp, *start; + + /* Skip if no revision was supplied, or if it is outdated (cvs admin -o) */ + if (vers == NULL || vers->outdated) + return; + + fprintf (fp, "\n%s\n%s\t%s;\t%s %s;\t%s %s;\nbranches", + vers->version, + RCSDATE, vers->date, + "author", vers->author, + "state", vers->state ? vers->state : ""); + + if (vers->branches != NULL) + { + start = vers->branches->list; + for (bp = start->next; bp != start; bp = bp->next) + fprintf (fp, "\n\t%s", bp->key); + } + + fprintf (fp, ";\nnext\t%s;", vers->next ? vers->next : ""); + + walklist (vers->other_delta, putrcsfield_proc, fp); + + putc ('\n', fp); +} + +static void +RCS_putdtree (rcs, rev, fp) + RCSNode *rcs; + char *rev; + FILE *fp; +{ + RCSVers *versp; + Node *p, *branch; + + if (rev == NULL) + return; + + /* Find the delta node for this revision. */ + p = findnode (rcs->versions, rev); + assert (p != NULL); + versp = (RCSVers *) p->data; + + /* Print the delta node and recurse on its `next' node. This prints + the trunk. If there are any branches printed on this revision, + print those trunks as well. */ + putdelta (versp, fp); + RCS_putdtree (rcs, versp->next, fp); + if (versp->branches != NULL) + { + branch = versp->branches->list; + for (p = branch->next; p != branch; p = p->next) + RCS_putdtree (rcs, p->key, fp); + } +} + +static void +RCS_putdesc (rcs, fp) + RCSNode *rcs; + FILE *fp; +{ + fprintf (fp, "\n\n%s\n@", RCSDESC); + if (rcs->desc != NULL) + { + off_t len = (off_t) strlen (rcs->desc); + if (len > 0) + { + expand_at_signs (rcs->desc, len, fp); + if (rcs->desc[len-1] != '\n') + putc ('\n', fp); + } + } + fputs ("@\n", fp); +} + +static void +putdeltatext (fp, d) + FILE *fp; + Deltatext *d; +{ + fprintf (fp, "\n\n%s\nlog\n@", d->version); + if (d->log != NULL) + { + int loglen = strlen (d->log); + expand_at_signs (d->log, (off_t) loglen, fp); + if (d->log[loglen-1] != '\n') + putc ('\n', fp); + } + putc ('@', fp); + + walklist (d->other, putrcsfield_proc, fp); + + fputs ("\ntext\n@", fp); + if (d->text != NULL) + expand_at_signs (d->text, (off_t) d->len, fp); + fputs ("@\n", fp); +} + +/* TODO: the whole mechanism for updating deltas is kludgey... more + sensible would be to supply all the necessary info in a `newdeltatext' + field for RCSVers nodes. -twp */ + +/* Copy delta text nodes from FIN to FOUT. If NEWDTEXT is non-NULL, it + is a new delta text node, and should be added to the tree at the + node whose revision number is INSERTPT. (Note that trunk nodes are + written in decreasing order, and branch nodes are written in + increasing order.) */ + +static void +RCS_copydeltas (rcs, fin, fout, newdtext, insertpt) + RCSNode *rcs; + FILE *fin; + FILE *fout; + Deltatext *newdtext; + char *insertpt; +{ + Deltatext *dtext; + RCSVers *dadmin; + Node *np; + int insertbefore, found; + + /* Make a note of whether NEWDTEXT should be inserted + before or after its INSERTPT. */ + insertbefore = (newdtext != NULL && numdots (newdtext->version) == 1); + + found = 0; + while ((dtext = RCS_getdeltatext (rcs, fin)) != NULL) + { + found = (insertpt != NULL && strcmp (dtext->version, insertpt) == 0); + if (found && insertbefore) + putdeltatext (fout, newdtext); + + np = findnode (rcs->versions, dtext->version); + dadmin = (RCSVers *) np->data; + + /* If this revision has been outdated, just skip it. */ + if (dadmin->outdated) + continue; + + /* Update the change text for this delta. New change text + data may come from cvs admin -m, cvs admin -o, or cvs ci. */ + if (dadmin->text != NULL) + { + if (dadmin->text->log != NULL) + { + free (dtext->log); + dtext->log = dadmin->text->log; + dadmin->text->log = NULL; + } + if (dadmin->text->text != NULL) + { + free (dtext->text); + dtext->text = dadmin->text->text; + dtext->len = dadmin->text->len; + dadmin->text->text = NULL; + } + } + putdeltatext (fout, dtext); + freedeltatext (dtext); + + if (found && !insertbefore) + putdeltatext (fout, newdtext); + } + putc ('\n', fout); +} + +/* RCS_internal_lockfile and RCS_internal_unlockfile perform RCS-style + locking on the specified RCSFILE: for a file called `foo,v', open + for writing a file called `,foo,'. + + Note that we what do here is quite different from what RCS does. + RCS creates the ,foo, file before it reads the RCS file (if it + knows that it will be writing later), so that it actually serves as + a lock. We don't; instead we rely on CVS writelocks. This means + that if someone is running RCS on the file at the same time they + are running CVS on it, they might lose (we read the file, + then RCS writes it, then we write it, clobbering the + changes made by RCS). I believe the current sentiment about this + is "well, don't do that". + + A concern has been expressed about whether adopting the RCS + strategy would slow us down. I don't think so, since we need to + write the ,foo, file anyway (unless perhaps if O_EXCL is slower or + something). + + These do not perform quite the same function as the RCS -l option + for locking files: they are intended to prevent competing RCS + processes from stomping all over each other's laundry. Hence, + they are `internal' locking functions. + + Note that we don't clean up the ,foo, file on ^C. We probably should. + I'm not completely sure whether RCS does or not (I looked at the code + a little, and didn't find it). + + If there is an error, give a fatal error; if we return we always + return a non-NULL value. */ + +static FILE * +rcs_internal_lockfile (rcsfile) + char *rcsfile; +{ + char *lockfile; + int fd; + struct stat rstat; + FILE *fp; + + /* Get the lock file name: `,file,' for RCS file `file,v'. */ + lockfile = rcs_lockfilename (rcsfile); + + /* Use the existing RCS file mode, or read-only if this is a new + file. (Really, this is a lie -- if this is a new file, + RCS_checkin uses the permissions from the working copy. For + actually creating the file, we use 0444 as a safe default mode.) */ + if (stat (rcsfile, &rstat) < 0) + { + if (existence_error (errno)) + rstat.st_mode = S_IRUSR | S_IRGRP | S_IROTH; + else + error (1, errno, "cannot stat %s", rcsfile); + } + + /* Try to open exclusively. POSIX.1 guarantees that O_EXCL|O_CREAT + guarantees an exclusive open. According to the RCS source, with + NFS v2 we must also throw in O_TRUNC and use an open mask that makes + the file unwriteable. For extensive justification, see the comments for + rcswriteopen() in rcsedit.c, in RCS 5.7. This is kind of pointless + in the CVS case; see comment at the start of this file concerning + general ,foo, file strategy. + + There is some sentiment that with NFSv3 and such, that one can + rely on O_EXCL these days. This might be true for unix (I + don't really know), but I am still pretty skeptical in the case + of the non-unix systems. */ + fd = open (lockfile, OPEN_BINARY | O_WRONLY | O_CREAT | O_EXCL | O_TRUNC, + S_IRUSR | S_IRGRP | S_IROTH); + + if (fd < 0) + { + error (1, errno, "could not open lock file `%s'", lockfile); + } + + free (lockfile); + + /* Force the file permissions, and return a stream object. */ + /* Because we change the modes later, we don't worry about + this in the non-HAVE_FCHMOD case. */ +#ifdef HAVE_FCHMOD + if (fchmod (fd, rstat.st_mode) < 0) + error (1, errno, "cannot change mode for %s", lockfile); +#endif + fp = fdopen (fd, FOPEN_BINARY_WRITE); + if (fp == NULL) + error (1, errno, "cannot fdopen %s", lockfile); + return fp; +} + +static void +rcs_internal_unlockfile (fp, rcsfile) + FILE *fp; + char *rcsfile; +{ + char *lockfile; + + /* Get the lock file name: `,file,' for RCS file `file,v'. */ + lockfile = rcs_lockfilename (rcsfile); + + /* Abort if we could not write everything successfully to LOCKFILE. + This is not a great error-handling mechanism, but should prevent + corrupting the repository. */ + + if (ferror (fp)) + error (1, 0, "error writing to lock file %s", lockfile); + if (fclose (fp) == EOF) + error (1, errno, "error closing lock file %s", lockfile); + + rename_file (lockfile, rcsfile); + free (lockfile); +} + +static char * +rcs_lockfilename (rcsfile) + char *rcsfile; +{ + char *lockfile, *lockp; + char *rcsbase, *rcsp, *rcsend; + int rcslen; + + /* Create the lockfile name. */ + rcslen = strlen (rcsfile); + lockfile = (char *) xmalloc (rcslen + 10); + rcsbase = last_component (rcsfile); + rcsend = rcsfile + rcslen - sizeof(RCSEXT); + for (lockp = lockfile, rcsp = rcsfile; rcsp < rcsbase; ++rcsp) + *lockp++ = *rcsp; + *lockp++ = ','; + while (rcsp <= rcsend) + *lockp++ = *rcsp++; + *lockp++ = ','; + *lockp = '\0'; + + return lockfile; +} + +/* Rewrite an RCS file. The basic idea here is that the caller should + first call RCS_reparsercsfile, then munge the data structures as + desired (via RCS_delete_revs, RCS_settag, &c), then call RCS_rewrite. */ + +void +RCS_rewrite (rcs, newdtext, insertpt) + RCSNode *rcs; + Deltatext *newdtext; + char *insertpt; +{ + FILE *fin, *fout; + + if (noexec) + return; + + fout = rcs_internal_lockfile (rcs->path); + + RCS_putadmin (rcs, fout); + RCS_putdtree (rcs, rcs->head, fout); + RCS_putdesc (rcs, fout); + + /* Open the original RCS file and seek to the first delta text. */ + if ((fin = CVS_FOPEN (rcs->path, FOPEN_BINARY_READ)) == NULL) + error (1, errno, "cannot open RCS file `%s' for reading", rcs->path); + if (fseek (fin, rcs->delta_pos, SEEK_SET) < 0) + error (1, errno, "cannot fseek in RCS file %s", rcs->path); + + /* Update delta_pos to the current position in the output file. + Do NOT move these statements: they must be done after fin has + been positioned at the old delta_pos, but before any delta + texts have been written to fout. */ + rcs->delta_pos = ftell (fout); + if (rcs->delta_pos == -1) + error (1, errno, "cannot ftell in RCS file %s", rcs->path); + + RCS_copydeltas (rcs, fin, fout, newdtext, insertpt); + + if (ferror (fin)) + error (0, errno, "warning: when closing RCS file `%s'", rcs->path); + if (fclose (fin) < 0) + error (0, errno, "warning: closing RCS file `%s'", rcs->path); + + rcs_internal_unlockfile (fout, rcs->path); +} /* Annotate command. In rcs.c for historical reasons (from back when @@ -4176,7 +6536,7 @@ annotate_fileproc (callerdat, finfo) return (1); if (finfo->rcs->flags & PARTIAL) - RCS_reparsercsfile (finfo->rcs, 0, &fp); + RCS_reparsercsfile (finfo->rcs, &fp); version = RCS_getversion (finfo->rcs, tag, date, force_tag_match, (int *) NULL); @@ -4203,6 +6563,7 @@ static const char *const annotate_usage[] = "\t-f\tUse head revision if tag/date not found.\n", "\t-r rev\tAnnotate file as of specified revision/tag.\n", "\t-D date\tAnnotate file as of specified date.\n", + "(Specify the --help global option for a list of other help options)\n", NULL }; @@ -4274,3 +6635,57 @@ annotate (argc, argv) argc, argv, local, W_LOCAL, 0, 1, (char *)NULL, 1); } + +/* + * For a given file with full pathname PATH and revision number REV, + * produce a file label suitable for passing to diff. The default + * file label as used by RCS 5.7 looks like this: + * + * FILENAME <tab> YYYY/MM/DD <sp> HH:MM:SS <tab> REVNUM + * + * The date and time used are the revision's last checkin date and time. + * If REV is NULL, use the working copy's mtime instead. + */ +char * +make_file_label (path, rev, rcs) + char *path; + char *rev; + RCSNode *rcs; +{ + char datebuf[MAXDATELEN]; + char *label; + char *file; + + file = last_component (path); + label = (char *) xmalloc (strlen (file) + + (rev == NULL ? 0 : strlen (rev)) + + 50); + + if (rev) + { + char *date; + RCS_getrevtime (rcs, rev, datebuf, 0); + date = printable_date (datebuf); + (void) sprintf (label, "-L%s\t%s\t%s", file, date, rev); + free (date); + } + else + { + struct stat sb; + struct tm *wm; + + if (CVS_STAT (file, &sb) < 0) + error (0, 1, "could not get info for `%s'", path); + else + { + wm = gmtime (&sb.st_mtime); + (void) sprintf (datebuf, "%04d/%02d/%02d %02d:%02d:%02d", + wm->tm_year + 1900, wm->tm_mon + 1, + wm->tm_mday, wm->tm_hour, + wm->tm_min, wm->tm_sec); + (void) sprintf (label, "-L%s\t%s", file, datebuf); + } + } + return label; +} + diff --git a/contrib/cvs/src/rcs.h b/contrib/cvs/src/rcs.h index 1855fb9..d0f47bb 100644 --- a/contrib/cvs/src/rcs.h +++ b/contrib/cvs/src/rcs.h @@ -3,16 +3,11 @@ * Copyright (c) 1989-1992, Brian Berliner * * You may distribute under the terms of the GNU General Public License as - * specified in the README file that comes with the CVS 1.4 kit. + * specified in the README file that comes with the CVS source distribution. * * RCS source control definitions needed by rcs.c and friends */ -#define RCS "rcs" -#define RCS_CI "ci" -#define RCS_DIFF "rcsdiff" -#define RCS_RCSMERGE "rcsmerge" - /* String which indicates a conflict if it occurs at the start of a line. */ #define RCS_MERGE_PAT ">>>>>>> " @@ -40,11 +35,21 @@ #define VALID 0x1 /* flags field contains valid data */ #define INATTIC 0x2 /* RCS file is located in the Attic */ #define PARTIAL 0x4 /* RCS file not completly parsed */ -#define NODELTA 0x8 /* delta_pos no longer valid */ + +/* All the "char *" fields in RCSNode, Deltatext, and RCSVers are + '\0'-terminated (except "text" in Deltatext). This means that we + can't deal with fields containing '\0', which is a limitation that + RCS does not have. Would be nice to fix this some day. */ struct rcsnode { + /* Reference count for this structure. Used to deal with the + fact that there might be a pointer from the Vers_TS or might + not. Callers who increment this field are responsible for + calling freercsnode when they are done with their reference. */ int refcount; + + /* Flags (INATTIC, PARTIAL, &c), see above. */ int flags; /* File name of the RCS file. This is not necessarily the name @@ -53,28 +58,102 @@ struct rcsnode (the various names might differ in case). */ char *path; + /* Value for head keyword from RCS header, or NULL if empty. */ char *head; + + /* Value for branch keyword from RCS header, or NULL if omitted. */ char *branch; + + /* Raw data on symbolic revisions. The first time that RCS_symbols is + called, we parse these into ->symbols, and free ->symbols_data. */ char *symbols_data; + + /* Value for expand keyword from RCS header, or NULL if omitted. */ char *expand; + + /* List of nodes, the key of which is the symbolic name and the data + of which is the numeric revision that it corresponds to (malloc'd). */ List *symbols; + + /* List of nodes (type RCSVERS), the key of which the numeric revision + number, and the data of which is an RCSVers * for the revision. */ List *versions; + + /* Value for access keyword from RCS header, or NULL if empty. + FIXME: RCS_delaccess would also seem to use "" for empty. We + should pick one or the other. */ + char *access; + + /* Raw data on locked revisions. The first time that RCS_getlocks is + called, we parse these into ->locks, and free ->locks_data. */ + char *locks_data; + + /* List of nodes, the key of which is the numeric revision and the + data of which is the user that it corresponds to (malloc'd). */ + List *locks; + + /* Set for the strict keyword from the RCS header. */ + int strict_locks; + + /* Value for the comment keyword from RCS header (comment leader), or + NULL if omitted. */ + char *comment; + + /* Value for the desc field in the RCS file, or NULL if empty. */ + char *desc; + + /* File offset of the first deltatext node, so we can seek there. */ long delta_pos; + + /* Newphrases from the RCS header. List of nodes, the key of which + is the "id" which introduces the newphrase, and the value of which + is the value from the newphrase. */ List *other; }; typedef struct rcsnode RCSNode; +struct deltatext { + char *version; + + /* Log message, or NULL if we do not intend to change the log message + (that is, RCS_copydeltas should just use the log message from the + file). */ + char *log; + + /* Change text, or NULL if we do not intend to change the change text + (that is, RCS_copydeltas should just use the change text from the + file). Note that it is perfectly legal to have log be NULL and + text non-NULL, or vice-versa. */ + char *text; + size_t len; + + /* Newphrase fields from deltatext nodes. FIXME: duplicates the + other field in the rcsversnode, I think. */ + List *other; +}; +typedef struct deltatext Deltatext; + struct rcsversnode { + /* Duplicate of the key by which this structure is indexed. */ char *version; + char *date; char *author; char *state; char *next; int dead; + int outdated; + Deltatext *text; List *branches; + /* Newphrase fields from deltatext nodes. Also contains ";add" and + ";delete" magic fields (see rcs.c, log.c). I think this is + only used by log.c (where it looks up "log"). Duplicates the + other field in struct deltatext, I think. */ List *other; + /* Newphrase fields from delta nodes. */ + List *other_delta; }; typedef struct rcsversnode RCSVers; @@ -96,6 +175,8 @@ typedef void (*RCSCHECKOUTPROC) PROTO ((void *, const char *, size_t)); RCSNode *RCS_parse PROTO((const char *file, const char *repos)); RCSNode *RCS_parsercsfile PROTO((char *rcsfile)); void RCS_fully_parse PROTO((RCSNode *)); +void RCS_reparsercsfile PROTO((RCSNode *, FILE **)); + char *RCS_check_kflag PROTO((const char *arg)); char *RCS_getdate PROTO((RCSNode * rcs, char *date, int force_tag_match)); char *RCS_gettag PROTO((RCSNode * rcs, char *symtag, int force_tag_match, @@ -111,6 +192,7 @@ int RCS_datecmp PROTO((char *date1, char *date2)); time_t RCS_getrevtime PROTO((RCSNode * rcs, char *rev, char *date, int fudge)); List *RCS_symbols PROTO((RCSNode *rcs)); void RCS_check_tag PROTO((const char *tag)); +List *RCS_getlocks PROTO((RCSNode *rcs)); void freercsnode PROTO((RCSNode ** rnodep)); char *RCS_getbranch PROTO((RCSNode * rcs, char *tag, int force_tag_match)); @@ -118,15 +200,24 @@ int RCS_isdead PROTO((RCSNode *, const char *)); char *RCS_getexpand PROTO ((RCSNode *)); int RCS_checkout PROTO ((RCSNode *, char *, char *, char *, char *, char *, RCSCHECKOUTPROC, void *)); +int RCS_checkin PROTO ((RCSNode *rcs, char *workfile, char *message, + char *rev, int flags)); int RCS_cmp_file PROTO ((RCSNode *, char *, char *, const char *)); int RCS_settag PROTO ((RCSNode *, const char *, const char *)); -int RCS_deltag PROTO ((RCSNode *, const char *, int)); +int RCS_deltag PROTO ((RCSNode *, const char *)); int RCS_setbranch PROTO((RCSNode *, const char *)); int RCS_lock PROTO ((RCSNode *, const char *, int)); int RCS_unlock PROTO ((RCSNode *, const char *, int)); +int RCS_delete_revs PROTO ((RCSNode *, char *, char *, int)); +void RCS_addaccess PROTO ((RCSNode *, char *)); +void RCS_delaccess PROTO ((RCSNode *, char *)); +char *RCS_getaccess PROTO ((RCSNode *)); +void RCS_rewrite PROTO ((RCSNode *, Deltatext *, char *)); int rcs_change_text PROTO ((const char *, char *, size_t, const char *, size_t, char **, size_t *)); +char *make_file_label PROTO ((char *, char *, RCSNode *)); /* From import.c. */ -extern int add_rcs_file PROTO ((char *, char *, char *, char *, - char *, char *, int, char **, FILE *)); +extern int add_rcs_file PROTO ((char *, char *, char *, char *, char *, + char *, char *, int, char **, + char *, size_t, FILE *)); diff --git a/contrib/cvs/src/rcscmds.c b/contrib/cvs/src/rcscmds.c index 1f356cf..9a237a9 100644 --- a/contrib/cvs/src/rcscmds.c +++ b/contrib/cvs/src/rcscmds.c @@ -3,7 +3,7 @@ * Copyright (c) 1989-1992, Brian Berliner * * You may distribute under the terms of the GNU General Public License as - * specified in the README file that comes with the CVS 1.4 kit. + * specified in the README file that comes with the CVS source distribution. * * The functions in this file provide an interface for performing * operations directly on RCS files. @@ -12,16 +12,8 @@ #include "cvs.h" #include <assert.h> -/* This file, rcs.h, and rcs.c, are intended to define our interface - to RCS files. As of July, 1996, there are still a few places that - still exec RCS commands directly. The intended long-term direction - is to have CVS access RCS files via an RCS library (rcs.c can be - considered a start at one), for performance, cleanliness (CVS has - some awful hacks to work around RCS behaviors which don't make - sense for CVS), installation hassles, ease of implementing the CVS - server (I don't think that the output-out-of-order bug can be - completely fixed as long as CVS calls RCS), and perhaps other - reasons. +/* This file, rcs.h, and rcs.c, together sometimes known as the "RCS + library", are intended to define our interface to RCS files. Whether there will also be a version of RCS which uses this library, or whether the library will be packaged for uses beyond @@ -32,7 +24,7 @@ existing CVS code which accesses RCS files. In particular, simple approaches will often be slow. - 2. An RCS library should not use the code from the current RCS + 2. An RCS library should not use code from the current RCS (5.7 and its ancestors). The code has many problems. Too few comments, too many layers of abstraction, too many global variables (the correct number for a library is zero), too much intricately @@ -54,169 +46,514 @@ See doc/RCSFILES in the CVS distribution for documentation of this file format. - On somewhat related notes: + On a related note, see the comments at diff_exec, later in this file, + for more on the diff library. */ - 1. A library for diff is an obvious idea. The one thing which I'm - not so sure about is that I think CVS probably wants the ability to - allow arbitrarily-bizarre (and possibly customized for particular - file formats) external diff programs. +static void RCS_output_diff_options PROTO ((char *, char *, char *, char *)); - 2. A library for patch is another such idea. CVS's needs are - smaller than the functionality of the standalone patch program (it - only calls patch in the client, and only needs to be able to patch - unmodified versions, which is something that RCS_deltas already - does in a different context). But it is silly for CVS to be making - people install patch as well as CVS for such a simple purpose. */ -/* For RCS file PATH, make symbolic tag TAG point to revision REV. - This validates that TAG is OK for a user to use. Return value is - -1 for error (and errno is set to indicate the error), positive for - error (and an error message has been printed), or zero for success. */ +/* Stuff to deal with passing arguments the way libdiff.a wants to deal + with them. This is a crufty interface; there is no good reason for it + to resemble a command line rather than something closer to "struct + log_data" in log.c. */ -int -RCS_exec_settag(path, tag, rev) - const char *path; - const char *tag; - const char *rev; +/* First call call_diff_setup to setup any initial arguments. The + argument will be parsed into whitespace separated words and added + to the global call_diff_argv list. + + Then, optionally, call call_diff_arg for each additional argument + that you'd like to pass to the diff library. + + Finally, call call_diff or call_diff3 to produce the diffs. */ + +static char **call_diff_argv; +static int call_diff_argc; +static int call_diff_argc_allocated; + +static void call_diff_add_arg PROTO ((const char *)); +static void call_diff_setup PROTO ((const char *prog)); +static int call_diff PROTO ((char *out)); +static int call_diff3 PROTO ((char *out)); + +/* VARARGS */ +static void +call_diff_setup (prog) + const char *prog; { - run_setup ("%s%s -x,v/ -q -N%s:%s", Rcsbin, RCS, tag, rev); - run_arg (path); - return run_exec (RUN_TTY, RUN_TTY, RUN_TTY, RUN_NORMAL); + char *cp; + int i; + char *call_diff_prog; + + /* clean out any malloc'ed values from call_diff_argv */ + for (i = 0; i < call_diff_argc; i++) + { + if (call_diff_argv[i]) + { + free (call_diff_argv[i]); + call_diff_argv[i] = (char *) 0; + } + } + call_diff_argc = 0; + + call_diff_prog = xstrdup (prog); + + /* put each word into call_diff_argv, allocating it as we go */ + for (cp = strtok (call_diff_prog, " \t"); + cp != NULL; + cp = strtok ((char *) NULL, " \t")) + call_diff_add_arg (cp); + free (call_diff_prog); } -/* NOERR is 1 to suppress errors--FIXME it would - be better to avoid the errors or some cleaner solution. */ -int -RCS_exec_deltag(path, tag, noerr) - const char *path; - const char *tag; - int noerr; +static void +call_diff_arg (s) + const char *s; { - run_setup ("%s%s -x,v/ -q -N%s", Rcsbin, RCS, tag); - run_arg (path); - return run_exec (RUN_TTY, RUN_TTY, noerr ? DEVNULL : RUN_TTY, RUN_NORMAL); + call_diff_add_arg (s); } -/* set RCS branch to REV */ -int -RCS_exec_setbranch(path, rev) - const char *path; - const char *rev; +static void +call_diff_add_arg (s) + const char *s; { - run_setup ("%s%s -x,v/ -q -b%s", Rcsbin, RCS, rev ? rev : ""); - run_arg (path); - return run_exec (RUN_TTY, RUN_TTY, RUN_TTY, RUN_NORMAL); + /* allocate more argv entries if we've run out */ + if (call_diff_argc >= call_diff_argc_allocated) + { + call_diff_argc_allocated += 50; + call_diff_argv = (char **) + xrealloc ((char *) call_diff_argv, + call_diff_argc_allocated * sizeof (char **)); + } + + if (s) + call_diff_argv[call_diff_argc++] = xstrdup (s); + else + /* Not post-incremented on purpose! */ + call_diff_argv[call_diff_argc] = (char *) 0; } -/* Lock revision REV. NOERR is 1 to suppress errors--FIXME it would - be better to avoid the errors or some cleaner solution. */ -int -RCS_exec_lock(path, rev, noerr) - const char *path; - const char *rev; - int noerr; +/* diff_run is imported from libdiff.a. */ +extern int diff_run PROTO ((int argc, char **argv, char *out)); + +static int +call_diff (out) + char *out; { - run_setup ("%s%s -x,v/ -q -l%s", Rcsbin, RCS, rev ? rev : ""); - run_arg (path); - return run_exec (RUN_TTY, RUN_TTY, noerr ? DEVNULL : RUN_TTY, RUN_NORMAL); + /* Try to keep the out-of-order bugs at bay (protocol_pipe for cvs_output + with has "Index: foo" and such; stdout and/or stderr for diff's + output). I think the only reason that this used to not be such + a problem is that the time spent on the fork() and exec() of diff + slowed us down enough to let the "Index:" make it through first. + + The real fix, of course, will be to have the diff library do all + its output through callbacks (which CVS will supply as cvs_output + and cvs_outerr). */ + sleep (1); + + if (out == RUN_TTY) + return diff_run (call_diff_argc, call_diff_argv, NULL); + else + return diff_run (call_diff_argc, call_diff_argv, out); } -/* Unlock revision REV. NOERR is 1 to suppress errors--FIXME it would - be better to avoid the errors or some cleaner solution. */ -int -RCS_exec_unlock(path, rev, noerr) - const char *path; - const char *rev; - int noerr; +extern int diff3_run PROTO ((int argc, char **argv, char *out)); + +static int +call_diff3 (out) + char *out; { - run_setup ("%s%s -x,v/ -q -u%s", Rcsbin, RCS, rev ? rev : ""); - run_arg (path); - return run_exec (RUN_TTY, RUN_TTY, noerr ? DEVNULL : RUN_TTY, RUN_NORMAL); + /* Try to keep the out-of-order bugs at bay (protocol_pipe for cvs_output + with has "Index: foo" and such; stdout and/or stderr for diff's + output). I think the only reason that this used to not be such + a problem is that the time spent on the fork() and exec() of diff + slowed us down enough to let the "Index:" make it through first. + + The real fix, of course, will be to have the diff library do all + its output through callbacks (which CVS will supply as cvs_output + and cvs_outerr). */ + sleep (1); + + if (out == RUN_TTY) + return diff3_run (call_diff_argc, call_diff_argv, NULL); + else + return diff3_run (call_diff_argc, call_diff_argv, out); } + + /* Merge revisions REV1 and REV2. */ + int -RCS_merge(path, options, rev1, rev2) - const char *path; - const char *options; - const char *rev1; - const char *rev2; +RCS_merge(rcs, path, workfile, options, rev1, rev2) + RCSNode *rcs; + char *path; + char *workfile; + char *options; + char *rev1; + char *rev2; { - int status; + char *xrev1, *xrev2; + char *tmp1, *tmp2; + char *diffout = NULL; + int retval; + + if (options != NULL && options[0] != '\0') + assert (options[0] == '-' && options[1] == 'k'); + + cvs_output ("RCS file: ", 0); + cvs_output (rcs->path, 0); + cvs_output ("\n", 1); + + /* Calculate numeric revision numbers from rev1 and rev2 (may be + symbolic). */ + xrev1 = RCS_gettag (rcs, rev1, 0, NULL); + xrev2 = RCS_gettag (rcs, rev2, 0, NULL); - /* XXX - Do merge by hand instead of using rcsmerge, due to -k handling */ + /* Check out chosen revisions. The error message when RCS_checkout + fails is not very informative -- it is taken verbatim from RCS 5.7, + and relies on RCS_checkout saying something intelligent upon failure. */ + cvs_output ("retrieving revision ", 0); + cvs_output (xrev1, 0); + cvs_output ("\n", 1); - run_setup ("%s%s -x,v/ %s -r%s -r%s %s", Rcsbin, RCS_RCSMERGE, - options, rev1, rev2, path); - status = run_exec (RUN_TTY, RUN_TTY, RUN_TTY, RUN_NORMAL); -#ifndef HAVE_RCS5 - if (status == 0) + tmp1 = cvs_temp_name(); + if (RCS_checkout (rcs, NULL, xrev1, rev1, options, tmp1, + (RCSCHECKOUTPROC)0, NULL)) { - error (1, 0, "CVS no longer supports RCS versions older than RCS5"); - /* This case needs to call file_has_markers to see if the file - contains conflict indicators. But is anyone using the !HAVE_RCS5 - code any more? */ + cvs_outerr ("rcsmerge: co failed\n", 0); + error_exit(); } -#endif - return status; + + cvs_output ("retrieving revision ", 0); + cvs_output (xrev2, 0); + cvs_output ("\n", 1); + + tmp2 = cvs_temp_name(); + if (RCS_checkout (rcs, NULL, xrev2, rev2, options, tmp2, + (RCSCHECKOUTPROC)0, NULL)) + { + cvs_outerr ("rcsmerge: co failed\n", 0); + error_exit(); + } + + /* Merge changes. */ + cvs_output ("Merging differences between ", 0); + cvs_output (xrev1, 0); + cvs_output (" and ", 0); + cvs_output (xrev2, 0); + cvs_output (" into ", 0); + cvs_output (workfile, 0); + cvs_output ("\n", 1); + + /* Remember that the first word in the `call_diff_setup' string is used now + only for diagnostic messages -- CVS no longer forks to run diff3. */ + diffout = cvs_temp_name(); + call_diff_setup ("diff3"); + call_diff_arg ("-E"); + call_diff_arg ("-am"); + + call_diff_arg ("-L"); + call_diff_arg (workfile); + call_diff_arg ("-L"); + call_diff_arg (xrev1); + call_diff_arg ("-L"); + call_diff_arg (xrev2); + + call_diff_arg (workfile); + call_diff_arg (tmp1); + call_diff_arg (tmp2); + + retval = call_diff3 (diffout); + + if (retval == 1) + cvs_outerr ("rcsmerge: warning: conflicts during merge\n", 0); + else if (retval == 2) + error_exit(); + + if (diffout) + copy_file (diffout, workfile); + + /* Clean up. */ + { + int save_noexec = noexec; + noexec = 0; + if (unlink_file (tmp1) < 0) + { + if (!existence_error (errno)) + error (0, errno, "cannot remove temp file %s", tmp1); + } + free (tmp1); + if (unlink_file (tmp2) < 0) + { + if (!existence_error (errno)) + error (0, errno, "cannot remove temp file %s", tmp2); + } + free (tmp2); + if (diffout) + { + if (unlink_file (diffout) < 0) + { + if (!existence_error (errno)) + error (0, errno, "cannot remove temp file %s", diffout); + } + free (diffout); + } + free (xrev1); + free (xrev2); + noexec = save_noexec; + } + + return retval; } -/* Check in to RCSFILE with revision REV (which must be greater than the - largest revision) and message MESSAGE (which is checked for legality). - If FLAGS & RCS_FLAGS_DEAD, check in a dead revision. If FLAGS & - RCS_FLAGS_QUIET, tell ci to be quiet. If FLAGS & RCS_FLAGS_MODTIME, - use the working file's modification time for the checkin time. - WORKFILE is the working file to check in from, or NULL to use the usual - RCS rules for deriving it from the RCSFILE. - - Return value is -1 for error (and errno is set to indicate the - error), positive for error (and an error message has been printed), - or zero for success. */ +/* Diff revisions and/or files. OPTS controls the format of the diff + (it contains options such as "-w -c", &c), or "" for the default. + OPTIONS controls keyword expansion, as a string starting with "-k", + or "" to use the default. REV1 is the first revision to compare + against; it must be non-NULL. If REV2 is non-NULL, compare REV1 + and REV2; if REV2 is NULL compare REV1 with the file in the working + directory, whose name is WORKFILE. LABEL1 and LABEL2 are default + file labels, and (if non-NULL) should be added as -L options + to diff. Output goes to stdout. + + Return value is 0 for success, -1 for a failure which set errno, + or positive for a failure which printed a message on stderr. + + This used to exec rcsdiff, but now calls RCS_checkout and diff_exec. + + An issue is what timezone is used for the dates which appear in the + diff output. rcsdiff uses the -z flag, which is not presently + processed by CVS diff, but I'm not sure exactly how hard to worry + about this--any such features are undocumented in the context of + CVS, and I'm not sure how important to users. */ int -RCS_checkin (rcsfile, workfile, message, rev, flags) - char *rcsfile; +RCS_exec_rcsdiff (rcsfile, opts, options, rev1, rev2, label1, label2, workfile) + RCSNode *rcsfile; + char *opts; + char *options; + char *rev1; + char *rev2; + char *label1; + char *label2; char *workfile; - char *message; - char *rev; - int flags; { - /* The desired behavior regarding permissions is to preserve the - permissions on RCSFILE if it already exists. Based on looking - at the RCS 5.7 source, it would appear that RCS_CI does this - except when it is creating RCSFILE (reasonable), or when - RCSFILE was created with rcs -i (this is strange, and quite - possibly unintentional). In those two cases it copies the - permissions from the workfile. - - Anyway, the fix is simple enough: we preserve the mode ourself. */ - struct stat sb; - int fix_mode = 1; - int retval; + char *tmpfile1; + char *tmpfile2; + char *use_file2; + int status, retval; + + tmpfile1 = cvs_temp_name (); + tmpfile2 = NULL; + + cvs_output ("\ +===================================================================\n\ +RCS file: ", 0); + cvs_output (rcsfile->path, 0); + cvs_output ("\n", 1); - if (CVS_STAT (rcsfile, &sb) < 0) + /* Historically, `cvs diff' has expanded the $Name keyword to the + empty string when checking out revisions. This is an accident, + but no one has considered the issue thoroughly enough to determine + what the best behavior is. Passing NULL for the `nametag' argument + preserves the existing behavior. */ + + cvs_output ("retrieving revision ", 0); + cvs_output (rev1, 0); + cvs_output ("\n", 1); + status = RCS_checkout (rcsfile, NULL, rev1, NULL, options, tmpfile1, + (RCSCHECKOUTPROC)0, NULL); + if (status > 0) + { + retval = status; + goto error_return; + } + else if (status < 0) { - fix_mode = 0; - if (!existence_error (errno)) - error (0, errno, "warning: cannot stat %s", rcsfile); + error (0, errno, + "cannot check out revision %s of %s", rev1, rcsfile->path); + retval = 1; + goto error_return; } - run_setup ("%s%s -x,v/ -w%s -f %s%s", Rcsbin, RCS_CI, getcaller (), - rev ? "-r" : "", rev ? rev : ""); - if (flags & RCS_FLAGS_DEAD) - run_arg ("-sdead"); - if (flags & RCS_FLAGS_QUIET) - run_arg ("-q"); - if (flags & RCS_FLAGS_MODTIME) - run_arg ("-d"); - run_args ("-m%s", make_message_rcslegal (message)); - if (workfile != NULL) - run_arg (workfile); - run_arg (rcsfile); - retval = run_exec (RUN_TTY, RUN_TTY, RUN_TTY, RUN_NORMAL); - if (retval == 0 && fix_mode) + + if (rev2 == NULL) + { + assert (workfile != NULL); + use_file2 = workfile; + } + else + { + tmpfile2 = cvs_temp_name (); + cvs_output ("retrieving revision ", 0); + cvs_output (rev2, 0); + cvs_output ("\n", 1); + status = RCS_checkout (rcsfile, NULL, rev2, NULL, options, + tmpfile2, (RCSCHECKOUTPROC)0, NULL); + if (status > 0) + { + retval = status; + goto error_return; + } + else if (status < 0) + { + error (0, errno, + "cannot check out revision %s of %s", rev2, rcsfile->path); + return 1; + } + use_file2 = tmpfile2; + } + + RCS_output_diff_options (opts, rev1, rev2, workfile); + status = diff_execv (tmpfile1, use_file2, label1, label2, opts, RUN_TTY); + if (status >= 0) { - if (chmod (rcsfile, sb.st_mode) < 0) - error (0, errno, "warning: cannot change permissions on %s", - rcsfile); + retval = status; + goto error_return; } + else if (status < 0) + { + error (0, errno, + "cannot diff %s and %s", tmpfile1, use_file2); + retval = 1; + goto error_return; + } + + error_return: + { + int save_noexec = noexec; + noexec = 0; + if (unlink_file (tmpfile1) < 0) + { + if (!existence_error (errno)) + error (0, errno, "cannot remove temp file %s", tmpfile1); + } + noexec = save_noexec; + } + free (tmpfile1); + if (tmpfile2 != NULL) + { + int save_noexec = noexec; + noexec = 0; + if (unlink_file (tmpfile2) < 0) + { + if (!existence_error (errno)) + error (0, errno, "cannot remove temp file %s", tmpfile2); + } + noexec = save_noexec; + free (tmpfile2); + } + return retval; } + + +/* Show differences between two files. This is the start of a diff library. + + Some issues: + + * Should option parsing be part of the library or the caller? The + former allows the library to add options without changing the callers, + but it causes various problems. One is that something like --brief really + wants special handling in CVS, and probably the caller should retain + some flexibility in this area. Another is online help (the library could + have some feature for providing help, but how does that interact with + the help provided by the caller directly?). Another is that as things + stand currently, there is no separate namespace for diff options versus + "cvs diff" options like -l (that is, if the library adds an option which + conflicts with a CVS option, it is trouble). + + * This isn't required for a first-cut diff library, but if there + would be a way for the caller to specify the timestamps that appear + in the diffs (rather than the library getting them from the files), + that would clean up the kludgy utime() calls in patch.c. + + Show differences between FILE1 and FILE2. Either one can be + DEVNULL to indicate a nonexistent file (same as an empty file + currently, I suspect, but that may be an issue in and of itself). + OPTIONS is a list of diff options, or "" if none. At a minimum, + CVS expects that -c (update.c, patch.c) and -n (update.c) will be + supported. Other options, like -u, --speed-large-files, &c, will + be specified if the user specified them. + + OUT is a filename to send the diffs to, or RUN_TTY to send them to + stdout. Error messages go to stderr. Return value is 0 for + success, -1 for a failure which set errno, 1 for success (and some + differences were found), or >1 for a failure which printed a + message on stderr. */ + +int +diff_exec (file1, file2, options, out) + char *file1; + char *file2; + char *options; + char *out; +{ + char *args = xmalloc (strlen (options) + 10); + /* The first word in this string is used only for error reporting. */ + sprintf (args, "diff %s", options); + call_diff_setup (args); + call_diff_arg (file1); + call_diff_arg (file2); + free (args); + + return call_diff (out); +} + +int +diff_execv (file1, file2, label1, label2, options, out) + char *file1; + char *file2; + char *label1; + char *label2; + char *options; + char *out; +{ + char *args = xmalloc (strlen (options) + 10); + /* The first word in this string is used only for error reporting. */ + /* I guess we are pretty confident that options starts with a space. */ + sprintf (args, "diff%s", options); + call_diff_setup (args); + if (label1) + call_diff_arg (label1); + if (label2) + call_diff_arg (label2); + call_diff_arg (file1); + call_diff_arg (file2); + free (args); + + return call_diff (out); +} + +/* Print the options passed to DIFF, in the format used by rcsdiff. + The rcsdiff code that produces this output is extremely hairy, and + it is not clear how rcsdiff decides which options to print and + which not to print. The code below reproduces every rcsdiff run + that I have seen. */ + +static void +RCS_output_diff_options (opts, rev1, rev2, workfile) + char *opts; + char *rev1; + char *rev2; + char *workfile; +{ + char *tmp; + + tmp = (char *) xmalloc (strlen (opts) + strlen (rev1) + 10); + + sprintf (tmp, "diff%s -r%s", opts, rev1); + cvs_output (tmp, 0); + free (tmp); + + if (rev2) + { + cvs_output (" -r", 3); + cvs_output (rev2, 0); + } + else + { + assert (workfile != NULL); + cvs_output (" ", 1); + cvs_output (workfile, 0); + } + cvs_output ("\n", 1); +} diff --git a/contrib/cvs/src/recurse.c b/contrib/cvs/src/recurse.c index b4b55a8..d2fae6f 100644 --- a/contrib/cvs/src/recurse.c +++ b/contrib/cvs/src/recurse.c @@ -2,7 +2,7 @@ * Copyright (c) 1992, Brian Berliner and Jeff Polk * * You may distribute under the terms of the GNU General Public License as - * specified in the README file that comes with the CVS 1.4 kit. + * specified in the README file that comes with the CVS source distribution. * * General recursion handler * @@ -157,7 +157,25 @@ start_recursion (fileproc, filesdoneproc, direntproc, dirleaveproc, callerdat, * called with the list of sub-dirs of the current dir as args */ if ((which & W_LOCAL) && !isdir (CVSADM)) + { dirlist = Find_Directories ((char *) NULL, W_LOCAL, (List *) NULL); + /* If there are no sub-directories, there is a certain logic in + favor of doing nothing, but in fact probably the user is just + confused about what directory they are in, or whether they + cvs add'd a new directory. In the case of at least one + sub-directory, at least when we recurse into them we + notice (hopefully) whether they are under CVS control. */ + if (list_isempty (dirlist)) + { + if (update_dir[0] == '\0') + error (0, 0, "in directory .:"); + else + error (0, 0, "in directory %s:", update_dir); + error (1, 0, + "there is no version here; run '%s checkout' first", + program_name); + } + } else addlist (&dirlist, "."); @@ -637,7 +655,7 @@ but CVS uses %s for its own purposes; skipping %s directory", else { newrepos = xmalloc (strlen (repository) + strlen (dir) + 5); - (void) sprintf (newrepos, "%s/%s", repository, dir); + sprintf (newrepos, "%s/%s", repository, dir); } } else @@ -651,10 +669,78 @@ but CVS uses %s for its own purposes; skipping %s directory", newrepos = xstrdup (repository); } + /* Check to see that the CVSADM directory, if it exists, seems to be + well-formed. It can be missing files if the user hit ^C in the + middle of a previous run. We want to (a) make this a nonfatal + error, and (b) make sure we print which directory has the + problem. + + Do this before the direntproc, so that (1) the direntproc + doesn't have to guess/deduce whether we will skip the directory + (e.g. send_dirent_proc and whether to send the directory), and + (2) so that the warm fuzzy doesn't get printed if we skip the + directory. */ + if (frame->which & W_LOCAL) + { + char *cvsadmdir; + + cvsadmdir = xmalloc (strlen (dir) + + sizeof (CVSADM_REP) + + sizeof (CVSADM_ENT) + + 80); + + strcpy (cvsadmdir, dir); + strcat (cvsadmdir, "/"); + strcat (cvsadmdir, CVSADM); + if (isdir (cvsadmdir)) + { + strcpy (cvsadmdir, dir); + strcat (cvsadmdir, "/"); + strcat (cvsadmdir, CVSADM_REP); + if (!isfile (cvsadmdir)) + { + /* Some commands like update may have printed "? foo" but + if we were planning to recurse, and don't on account of + CVS/Repository, we want to say why. */ + error (0, 0, "ignoring %s (%s missing)", update_dir, + CVSADM_REP); + dir_return = R_SKIP_ALL; + } + + /* Likewise for CVS/Entries. */ + if (dir_return != R_SKIP_ALL) + { + strcpy (cvsadmdir, dir); + strcat (cvsadmdir, "/"); + strcat (cvsadmdir, CVSADM_ENT); + if (!isfile (cvsadmdir)) + { + /* Some commands like update may have printed "? foo" but + if we were planning to recurse, and don't on account of + CVS/Repository, we want to say why. */ + error (0, 0, "ignoring %s (%s missing)", update_dir, + CVSADM_ENT); + dir_return = R_SKIP_ALL; + } + } + } + free (cvsadmdir); + } + /* call-back dir entry proc (if any) */ - if (frame->direntproc != NULL) + if (dir_return == R_SKIP_ALL) + ; + else if (frame->direntproc != NULL) dir_return = frame->direntproc (frame->callerdat, dir, newrepos, update_dir, frent->entries); + else + { + /* Generic behavior. I don't see a reason to make the caller specify + a direntproc just to get this. */ + if ((frame->which & W_LOCAL) && !isdir (dir)) + dir_return = R_SKIP_ALL; + } + free (newrepos); /* only process the dir if the return code was 0 */ diff --git a/contrib/cvs/src/release.c b/contrib/cvs/src/release.c index 702e903..82429e0 100644 --- a/contrib/cvs/src/release.c +++ b/contrib/cvs/src/release.c @@ -14,6 +14,7 @@ static const char *const release_usage[] = { "Usage: %s %s [-d] directories...\n", "\t-d\tDelete the given directory.\n", + "(Specify the --help global option for a list of other help options)\n", NULL }; @@ -46,7 +47,10 @@ release_server (argc, argv) 2. The fact that "cvs update" contacts the server slows things down; it undermines the case for using "cvs release" rather than "rm -rf". However, for correctly printing "? foo" and correctly handling - CVSROOTADM_IGNORE, we currently need to contact the server. + CVSROOTADM_IGNORE, we currently need to contact the server. (One + idea for how to fix this is to stash a copy of CVSROOTADM_IGNORE in + the working directories; see comment at base_* in entries.c for a + few thoughts on that). 3. Would be nice to take processing things on the client side one step further, and making it like edit/unedit in terms of working well if @@ -156,6 +160,8 @@ release (argc, argv) if (!really_quiet) { + int line_length; + /* The "release" command piggybacks on "update", which does the real work of finding out if anything is not up-to-date with the repository. Then "release" prompts @@ -163,14 +169,19 @@ release (argc, argv) modified, and asking if she still wants to do the release. */ fp = run_popen (update_cmd, "r"); + if (fp == NULL) + error (1, 0, "cannot run command %s", update_cmd); + c = 0; - while (getline (&line, &line_allocated, fp) >= 0) + while ((line_length = getline (&line, &line_allocated, fp)) >= 0) { if (strchr ("MARCZ", *line)) c++; (void) printf (line); } + if (line_length < 0 && !feof (fp)) + error (0, errno, "cannot read from subprocess"); /* If the update exited with an error, then we just want to complain and go on to the next arg. Especially, we do @@ -270,9 +281,15 @@ release_delete (dir) (void) CVS_STAT (dir, &st); if (ino != st.st_ino) { + /* This test does not work on cygwin32, because under cygwin32 + the st_ino field is not the same when you refer to a file + by a different name. This is a cygwin32 bug, but then I + don't see what the point of this test is anyhow. */ +#ifndef __CYGWIN32__ error (0, 0, "Parent dir on a different disk, delete of %s aborted", dir); return; +#endif } /* * XXX - shouldn't this just delete the CVS-controlled files and, perhaps, diff --git a/contrib/cvs/src/remove.c b/contrib/cvs/src/remove.c index 46c4169..9ed32d7 100644 --- a/contrib/cvs/src/remove.c +++ b/contrib/cvs/src/remove.c @@ -3,7 +3,7 @@ * Copyright (c) 1989-1992, Brian Berliner * * You may distribute under the terms of the GNU General Public License as - * specified in the README file that comes with the CVS 1.4 kit. + * specified in the README file that comes with the CVS source distribution. * * Remove a File * @@ -37,6 +37,7 @@ static const char *const remove_usage[] = "\t-f\tDelete the file before removing it.\n", "\t-l\tProcess this directory only (not recursive).\n", "\t-R\tProcess directories recursively.\n", + "(Specify the --help global option for a list of other help options)\n", NULL }; @@ -215,6 +216,22 @@ remove_fileproc (callerdat, finfo) error (0, 0, "file `%s' already scheduled for removal", finfo->fullname); } + else if (vers->tag != NULL && isdigit (*vers->tag)) + { + /* Commit will just give an error, and so there seems to be + little reason to allow the remove. I mean, conflicts that + arise out of parallel development are one thing, but conflicts + that arise from sticky tags are quite another. + + I would have thought that non-branch sticky tags should be the + same but at least now, removing a file with a non-branch sticky + tag means to delete the tag from the file. I'm not sure that + is a good behavior, but until it is changed, we need to allow + it. */ + error (0, 0, "\ +cannot remove file `%s' which has a numeric sticky tag of `%s'", + finfo->fullname, vers->tag); + } else { char *fname; diff --git a/contrib/cvs/src/repos.c b/contrib/cvs/src/repos.c index 2590df5..2738665 100644 --- a/contrib/cvs/src/repos.c +++ b/contrib/cvs/src/repos.c @@ -3,9 +3,10 @@ * Copyright (c) 1989-1992, Brian Berliner * * You may distribute under the terms of the GNU General Public License as - * specified in the README file that comes with the CVS 1.4 kit. + * specified in the README file that comes with the CVS source distribution. */ +#include <assert.h> #include "cvs.h" #include "getline.h" @@ -86,7 +87,6 @@ Name_Repository (dir, update_dir) error (1, save_errno, "cannot open %s", tmp); } - free (tmp); if (getline (&repos, &repos_allocated, fpin) < 0) { @@ -94,7 +94,10 @@ Name_Repository (dir, update_dir) error (0, 0, "in directory %s:", xupdate_dir); error (1, errno, "cannot read %s", CVSADM_REP); } - (void) fclose (fpin); + if (fclose (fpin) < 0) + error (0, errno, "cannot close %s", tmp); + free (tmp); + if ((cp = strrchr (repos, '\n')) != NULL) *cp = '\0'; /* strip the newline */ @@ -126,7 +129,8 @@ Name_Repository (dir, update_dir) repos = newrepos; } - strip_trailing_slashes (repos); + Sanitize_Repository_Name (repos); + return repos; } @@ -152,3 +156,51 @@ Short_Repository (repository) else return (repository); } + +/* Sanitize the repository name (in place) by removing trailing + * slashes and a trailing "." if present. It should be safe for + * callers to use strcat and friends to create repository names. + * Without this check, names like "/path/to/repos/./foo" and + * "/path/to/repos//foo" would be created. For example, one + * significant case is the CVSROOT-detection code in commit.c. It + * decides whether or not it needs to rebuild the administrative file + * database by doing a string compare. If we've done a `cvs co .' to + * get the CVSROOT files, "/path/to/repos/./CVSROOT" and + * "/path/to/repos/CVSROOT" are the arguments that are compared! + * + * This function ends up being called from the same places as + * strip_path, though what it does is much more conservative. Many + * comments about this operation (which was scattered around in + * several places in the source code) ran thus: + * + * ``repository ends with "/."; omit it. This sort of thing used + * to be taken care of by strip_path. Now we try to be more + * selective. I suspect that it would be even better to push it + * back further someday, so that the trailing "/." doesn't get into + * repository in the first place, but we haven't taken things that + * far yet.'' --Jim Kingdon (recurse.c, 07-Sep-97) + * + * Ahh, all too true. The major consideration is RELATIVE_REPOS. If + * the "/." doesn't end up in the repository while RELATIVE_REPOS is + * defined, there will be nothing in the CVS/Repository file. I + * haven't verified that the remote protocol will handle that + * correctly yet, so I've not made that change. */ + +void +Sanitize_Repository_Name (repository) + char *repository; +{ + size_t len; + + assert (repository != NULL); + + strip_trailing_slashes (repository); + + len = strlen (repository); + if (len >= 2 + && repository[len - 1] == '.' + && ISDIRSEP (repository[len - 2])) + { + repository[len - 2] = '\0'; + } +} diff --git a/contrib/cvs/src/root.c b/contrib/cvs/src/root.c index bf5c89e..050e168 100644 --- a/contrib/cvs/src/root.c +++ b/contrib/cvs/src/root.c @@ -2,7 +2,7 @@ * Copyright (c) 1992, Mark D. Baushke * * You may distribute under the terms of the GNU General Public License as - * specified in the README file that comes with the CVS 1.4 kit. + * specified in the README file that comes with the CVS source distribution. * * Name of Root * @@ -18,15 +18,15 @@ Watch out if the enum is changed in cvs.h! */ char *method_names[] = { - "local", "server (rsh)", "pserver", "kserver", "ext" + "local", "server (rsh)", "pserver", "kserver", "gserver", "ext" }; #ifndef DEBUG char * -Name_Root(dir, update_dir) - char *dir; - char *update_dir; +Name_Root (dir, update_dir) + char *dir; + char *update_dir; { FILE *fpin; char *ret, *xupdate_dir; @@ -133,41 +133,14 @@ Name_Root(dir, update_dir) } /* - * Returns non-zero if the two directories have the same stat values - * which indicates that they are really the same directories. - */ -int -same_directories (dir1, dir2) - char *dir1; - char *dir2; -{ - struct stat sb1; - struct stat sb2; - int ret; - - if ( CVS_STAT (dir1, &sb1) < 0) - return (0); - if ( CVS_STAT (dir2, &sb2) < 0) - return (0); - - ret = 0; - if ( (memcmp( &sb1.st_dev, &sb2.st_dev, sizeof(dev_t) ) == 0) && - (memcmp( &sb1.st_ino, &sb2.st_ino, sizeof(ino_t) ) == 0)) - ret = 1; - - return (ret); -} - - -/* * Write the CVS/Root file so that the environment variable CVSROOT * and/or the -d option to cvs will be validated or not necessary for * future work. */ void Create_Root (dir, rootdir) - char *dir; - char *rootdir; + char *dir; + char *rootdir; { FILE *fout; char *tmp; @@ -272,6 +245,23 @@ root_allow_ok (arg) char *arg; { unsigned int i; + + if (root_allow_count == 0) + { + /* Probably someone upgraded from CVS before 1.9.10 to 1.9.10 + or later without reading the documentation about + --allow-root. Printing an error here doesn't disclose any + particularly useful information to an attacker because a + CVS server configured in this way won't let *anyone* in. */ + + /* Note that we are called from a context where we can spit + back "error" rather than waiting for the next request which + expects responses. */ + printf ("\ +error 0 Server configuration missing --allow-root in inetd.conf\n"); + error_exit (); + } + for (i = 0; i < root_allow_count; ++i) if (strcmp (root_allow_vector[i], arg) == 0) return 1; @@ -327,6 +317,7 @@ parse_cvsroot (CVSroot) { static int cvsroot_parsed = 0; char *cvsroot_copy, *p; + int check_hostname; /* Don't go through the trouble twice. */ if (cvsroot_parsed) @@ -366,6 +357,8 @@ parse_cvsroot (CVSroot) CVSroot_method = pserver_method; else if (strcmp (method, "kserver") == 0) CVSroot_method = kserver_method; + else if (strcmp (method, "gserver") == 0) + CVSroot_method = gserver_method; else if (strcmp (method, "server") == 0) CVSroot_method = server_method; else if (strcmp (method, "ext") == 0) @@ -445,6 +438,7 @@ parse_cvsroot (CVSroot) return 1; } + check_hostname = 0; switch (CVSroot_method) { case local_method: @@ -471,15 +465,31 @@ parse_cvsroot (CVSroot) error (0, 0, "(%s)", CVSroot); return 1; #endif + check_hostname = 1; + break; + case gserver_method: +#ifndef HAVE_GSSAPI + error (0, 0, "Your CVSROOT is set for a GSSAPI access method"); + error (0, 0, "but your CVS executable doesn't support it"); + error (0, 0, "(%s)", CVSroot); + return 1; +#endif + check_hostname = 1; + break; case server_method: case ext_method: case pserver_method: + check_hostname = 1; + break; + } + + if (check_hostname) + { if (! CVSroot_hostname) { error (0, 0, "didn't specify hostname in CVSROOT: %s", CVSroot); return 1; } - break; } if (*CVSroot_directory == '\0') diff --git a/contrib/cvs/src/rtag.c b/contrib/cvs/src/rtag.c index 934cd40..5a21786 100644 --- a/contrib/cvs/src/rtag.c +++ b/contrib/cvs/src/rtag.c @@ -3,7 +3,7 @@ * Copyright (c) 1989-1992, Brian Berliner * * You may distribute under the terms of the GNU General Public License as - * specified in the README file that comes with the CVS 1.4 kit. + * specified in the README file that comes with the CVS source distribution. * * Rtag * @@ -72,8 +72,10 @@ static const char *const rtag_usage[] = "\t-n\tNo execution of 'tag program'\n", "\t-d\tDelete the given Tag.\n", "\t-b\tMake the tag a \"branch\" tag, allowing concurrent development.\n", - "\t-[rD]\tExisting tag or Date.\n", + "\t-r rev\tExisting revision/tag.\n", + "\t-D\tExisting date.\n", "\t-F\tMove tag if it already exists\n", + "(Specify the --help global option for a list of other help options)\n", NULL }; @@ -206,7 +208,8 @@ rtag (argc, argv) /* XXX last arg should be repository, but doesn't make sense here */ history_write ('T', (delete_flag ? "D" : (numtag ? numtag : (date ? date : "A"))), symtag, argv[i], ""); - err += do_module (db, argv[i], TAG, delete_flag ? "Untagging" : "Tagging", + err += do_module (db, argv[i], TAG, + delete_flag ? "Untagging" : "Tagging", rtag_proc, (char *) NULL, 0, 0, run_module_prog, symtag); } @@ -469,11 +472,10 @@ pretag_proc(repository, filter) } free(s); } - run_setup("%s %s %s %s", - filter, - symtag, - delete_flag ? "del" : force_tag_move ? "mov" : "add", - repository); + run_setup (filter); + run_arg (symtag); + run_arg (delete_flag ? "del" : force_tag_move ? "mov" : "add"); + run_arg (repository); walklist(tlist, pretag_list_proc, NULL); return (run_exec(RUN_TTY, RUN_TTY, RUN_TTY, RUN_NORMAL|RUN_REALLY)); } @@ -594,6 +596,8 @@ rtag_fileproc (callerdat, finfo) */ rev = branch_mode ? RCS_magicrev (rcsfile, version) : numtag; retcode = RCS_settag(rcsfile, symtag, numtag); + if (retcode == 0) + RCS_rewrite (rcsfile, NULL, NULL); } else { @@ -613,7 +617,7 @@ rtag_fileproc (callerdat, finfo) (int *) NULL); if (oversion != NULL) { - int isbranch = RCS_isbranch (finfo->rcs, symtag); + int isbranch = RCS_nodeisbranch (finfo->rcs, symtag); /* * if versions the same and neither old or new are branches don't @@ -643,6 +647,8 @@ rtag_fileproc (callerdat, finfo) free (oversion); } retcode = RCS_settag(rcsfile, symtag, rev); + if (retcode == 0) + RCS_rewrite (rcsfile, NULL, NULL); } if (retcode != 0) @@ -694,7 +700,7 @@ rtag_delete (rcsfile) return (0); free (version); - if ((retcode = RCS_deltag(rcsfile, symtag, 1)) != 0) + if ((retcode = RCS_deltag(rcsfile, symtag)) != 0) { if (!quiet) error (0, retcode == -1 ? errno : 0, @@ -702,6 +708,7 @@ rtag_delete (rcsfile) rcsfile->path); return (1); } + RCS_rewrite (rcsfile, NULL, NULL); return (0); } @@ -733,7 +740,8 @@ rtag_dirproc (callerdat, dir, repos, update_dir, entries) List *entries; { if (!quiet) - error (0, 0, "%s %s", delete_flag ? "Untagging" : "Tagging", update_dir); + error (0, 0, "%s %s", delete_flag ? "Untagging" : "Tagging", + update_dir); return (R_PROCESS); } diff --git a/contrib/cvs/src/run.c b/contrib/cvs/src/run.c index 5b59bca..dc35a78 100644 --- a/contrib/cvs/src/run.c +++ b/contrib/cvs/src/run.c @@ -14,30 +14,18 @@ #include "cvs.h" -#ifdef HAVE_VPRINTF -#if defined (USE_PROTOTYPES) ? USE_PROTOTYPES : defined (__STDC__) -#include <stdarg.h> -#define VA_START(args, lastarg) va_start(args, lastarg) -#else -#include <varargs.h> -#define VA_START(args, lastarg) va_start(args) -#endif -#else -#define va_alist a1, a2, a3, a4, a5, a6, a7, a8 -#define va_dcl char *a1, *a2, *a3, *a4, *a5, *a6, *a7, *a8; +#ifndef HAVE_UNISTD_H +extern int execvp PROTO((char *file, char **argv)); #endif static void run_add_arg PROTO((const char *s)); extern char *strtok (); -extern int vasprintf (); - /* - * To exec a program under CVS, first call run_setup() to setup any initial - * arguments. The options to run_setup are essentially like printf(). The - * arguments will be parsed into whitespace separated words and added to the - * global run_argv list. + * To exec a program under CVS, first call run_setup() to setup initial + * arguments. The argument to run_setup will be parsed into whitespace + * separated words and added to the global run_argv list. * * Then, optionally call run_arg() for each additional argument that you'd like * to pass to the executed program. @@ -51,19 +39,10 @@ static int run_argc; static int run_argc_allocated; /* VARARGS */ -#if defined (HAVE_VPRINTF) && (defined (USE_PROTOTYPES) ? USE_PROTOTYPES : defined (__STDC__)) void -run_setup (const char *fmt,...) -#else -void -run_setup (fmt, va_alist) - char *fmt; - va_dcl -#endif +run_setup (prog) + const char *prog; { -#ifdef HAVE_VPRINTF - va_list args; -#endif char *cp; int i; char *run_prog; @@ -79,16 +58,7 @@ run_setup (fmt, va_alist) } run_argc = 0; - /* process the varargs into run_prog */ -#ifdef HAVE_VPRINTF - VA_START (args, fmt); - (void) vasprintf (&run_prog, fmt, args); - va_end (args); -#else - you lose -#endif - if (run_prog == NULL) - error (1, 0, "out of memory"); + run_prog = xstrdup (prog); /* put each word into run_argv, allocating it as we go */ for (cp = strtok (run_prog, " \t"); cp; cp = strtok ((char *) NULL, " \t")) @@ -103,38 +73,6 @@ run_arg (s) run_add_arg (s); } -/* VARARGS */ -#if defined (HAVE_VPRINTF) && (defined (USE_PROTOTYPES) ? USE_PROTOTYPES : defined (__STDC__)) -void -run_args (const char *fmt,...) -#else -void -run_args (fmt, va_alist) - char *fmt; - va_dcl -#endif -{ -#ifdef HAVE_VPRINTF - va_list args; -#endif - char *run_prog; - - /* process the varargs into run_prog */ -#ifdef HAVE_VPRINTF - VA_START (args, fmt); - (void) vasprintf (&run_prog, fmt, args); - va_end (args); -#else - you lose -#endif - if (run_prog == NULL) - error (1, 0, "out of memory"); - - /* and add the (single) argument to the run_argv list */ - run_add_arg (run_prog); - free (run_prog); -} - static void run_add_arg (s) const char *s; @@ -155,9 +93,9 @@ run_add_arg (s) int run_exec (stin, stout, sterr, flags) - char *stin; - char *stout; - char *sterr; + const char *stin; + const char *stout; + const char *sterr; int flags; { int shin, shout, sherr; @@ -398,7 +336,13 @@ run_print (fp) else if (fp == stdout) outfn = cvs_output; else + { error (1, 0, "internal error: bad argument to run_print"); + /* Solely to placate gcc -Wall. + FIXME: it'd be better to use a function named `fatal' that + is known never to return. Then kludges wouldn't be necessary. */ + outfn = NULL; + } for (i = 0; i < run_argc; i++) { @@ -410,6 +354,11 @@ run_print (fp) } } +/* Return value is NULL for error, or if noexec was set. If there was an + error, return NULL and I'm not sure whether errno was set (the Red Hat + Linux 4.1 popen manpage was kind of vague but discouraging; and the noexec + case complicates this even aside from popen behavior). */ + FILE * run_popen (cmd, mode) const char *cmd; @@ -428,8 +377,6 @@ run_popen (cmd, mode) return (popen (cmd, mode)); } -extern int evecvp PROTO((char *file, char **argv)); - int piped_child (command, tofdp, fromfdp) char **command; diff --git a/contrib/cvs/src/sanity.sh b/contrib/cvs/src/sanity.sh index a815fc0..4084b5f 100755 --- a/contrib/cvs/src/sanity.sh +++ b/contrib/cvs/src/sanity.sh @@ -2,7 +2,19 @@ : # sanity.sh -- a growing testsuite for cvs. # -# Copyright (C) 1992, 1993 Cygnus Support +# The copyright notice said: "Copyright (C) 1992, 1993 Cygnus Support" +# I'm not adding new copyright notices for new years as our recent +# practice has been to include copying terms without copyright notices. +# +# 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. # # Original Author: K. Richard Pixley @@ -15,16 +27,38 @@ # You can't run CVS as root; print a nice error message here instead # of somewhere later, after making a mess. -case "`whoami`" in - "root" ) - echo "sanity.sh: test suite does not work correctly when run as root" >&2 - exit 1 - ;; -esac +# Commented out because: +# (1) whoami is not portable. If memory serves the POSIX way is "id -un". +# ("logname" or "who am i" are similar but different--they have more to +# do with who logged in on your tty than your uid). +# (2) This definition of "root" doesn't quite match CVS's (which is based +# on uid 0, not username "root"). +#case "`whoami`" in +# "root" ) +# echo "sanity.sh: test suite does not work correctly when run as root" >&2 +# exit 1 +# ;; +#esac # required to make this script work properly. unset CVSREAD +# The default value of /tmp/cvs-sanity for TESTDIR is dubious, +# because it loses if two people/scripts try to run the tests +# at the same time. Some possible solutions: +# 1. Use /tmp/cvs-test$$. One disadvantage is that the old +# cvs-test* directories would pile up, because they wouldn't +# necessarily get removed. +# 2. Have everyone/everything running the testsuite set +# TESTDIR to some appropriate directory. +# 3. Have the default value of TESTDIR be some variation of +# `pwd`/cvs-sanity. The biggest problem here is that we have +# been fairly careful to test that CVS prints in messages the +# actual pathnames that we pass to it, rather than a different +# pathname for the same directory, as may come out of `pwd`. +# So this would be lost if everything was `pwd`-based. I suppose +# if we wanted to get baroque we could start making symlinks +# to ensure the two are different. TESTDIR=${TESTDIR:-/tmp/cvs-sanity} # "debugger" @@ -79,12 +113,22 @@ PROG=`basename ${testcvs}` # Regexp to match an author name. I'm not really sure what characters # should be here. a-zA-Z obviously. People complained when 0-9 were # not allowed in usernames. Other than that I'm not sure. -username="[a-zA-Z0-9][a-zA-Z0-9]*" +username="[-a-zA-Z0-9][-a-zA-Z0-9]*" # Regexp to match the name of a temporary file (from cvs_temp_name). # This appears in certain diff output. tempname="[-a-zA-Z0-9/.%_]*" +# On cygwin32, we may not have /bin/sh. +if [ -r /bin/sh ]; then + TESTSHELL="/bin/sh" +else + TESTSHELL=`type -p sh 2>/dev/null` + if [ ! -r "$TESTSHELL" ]; then + TESTSHELL="/bin/sh" + fi +fi + # FIXME: try things (what things? checkins?) without -m. # # Some of these tests are written to expect -Q. But testing with @@ -452,6 +496,22 @@ dotest_status () dotest_internal "$1" "$3" "$4" "$5" } +# Like dotest except output is sorted. +dotest_sort () +{ + rm -f ${TESTDIR}/dotest.ex? 2>&1 + if $2 >${TESTDIR}/dotest.tmp1 2>&1; then + : so far so good + else + status=$? + cat ${TESTDIR}/dotest.tmp1 >>${LOGFILE} + echo "exit status was $status" >>${LOGFILE} + fail "$1" + fi + sort < ${TESTDIR}/dotest.tmp1 > ${TESTDIR}/dotest.tmp + dotest_internal "$@" +} + # clean any old remnants rm -rf ${TESTDIR} mkdir ${TESTDIR} @@ -459,7 +519,17 @@ cd ${TESTDIR} # This will show up in cvs history output where it prints the working # directory. It should *not* appear in any cvs output referring to the # repository; cvs should use the name of the repository as specified. -TMPPWD=`/bin/pwd` +# +# Note that using pwd here rather than /bin/pwd will make it even less +# likely that we test whether CVS is distinguishing between TMPPWD +# and TESTDIR. However, there is no guarantee that will test it anyway. +# If we really care, we should do something along the lines of: +# cd /tmp/cvs-sanity # In reality, overridable with environment variable? +# mkdir realdir +# ln -s realdir testdir +# TESTDIR=/tmp/cvs-sanity/testdir +# TMPPWD=/tmp/cvs-sanity/realdir +TMPPWD=`pwd` # Avoid picking up any stray .cvsrc, etc., from the user running the tests mkdir home @@ -478,12 +548,19 @@ RCSINIT=; export RCSINIT # tests. if test x"$*" = x; then - tests="basica basicb basic1 deep basic2 rdiff death death2 branches" - tests="${tests} multibranch import join new newb conflicts conflicts2" - tests="${tests} modules modules2 modules3 mflag errmsg1 devcom devcom2" - tests="${tests} devcom3 ignore binfiles binfiles2 binwrap mwrap info" - tests="${tests} serverpatch log log2 crerepos rcs big modes stamps" - tests="${tests} sticky keyword toplevel" + tests="basica basicb basicc basic1 deep basic2" + tests="${tests} rdiff death death2 branches" + tests="${tests} rcslib multibranch import importb join join2 join3" + tests="${tests} new newb conflicts conflicts2 conflicts3" + tests="${tests} modules modules2 modules3 mflag editor errmsg1 errmsg2" + tests="${tests} devcom devcom2 devcom3 watch4" + tests="${tests} ignore binfiles binfiles2 mcopy binwrap binwrap2" + tests="${tests} binwrap3 mwrap info config" + tests="${tests} serverpatch log log2 ann crerepos rcs big modes stamps" + tests="${tests} sticky keyword keywordlog" + tests="${tests} toplevel head tagdate multibranch2" + tests="${tests} admin reserved" + tests="${tests} cvsadm diffmerge1 diffmerge2" else tests="$*" fi @@ -594,14 +671,14 @@ Directory ${TESTDIR}/cvsroot/first-dir/sdir added to the repository" # that I consider to be more correct, but local cvs prints the # "nothing known" message and noone has gotten around to fixing it. dotest_fail basica-notadded "${testcvs} -q ci ssfile" \ -"${PROG} [a-z]*: use "'`cvs add'\'' to create an entry for ssfile -'"${PROG}"' \[[a-z]* aborted\]: correct above errors first!' \ +"${PROG} [a-z]*: use .${PROG} add. to create an entry for ssfile +${PROG}"' \[[a-z]* aborted\]: correct above errors first!' \ "${PROG}"' [a-z]*: nothing known about `ssfile'\'' '"${PROG}"' \[[a-z]* aborted\]: correct above errors first!' dotest basica-4 "${testcvs} add ssfile" \ "${PROG}"' [a-z]*: scheduling file `ssfile'\'' for addition -'"${PROG}"' [a-z]*: use '\''cvs commit'\'' to add this file permanently' +'"${PROG}"' [a-z]*: use .'"${PROG}"' commit. to add this file permanently' dotest_fail basica-4a "${testcvs} tag tag0 ssfile" \ "${PROG} [a-z]*: nothing known about ssfile ${PROG} "'\[[a-z]* aborted\]: correct the above errors first!' @@ -701,6 +778,68 @@ diff -r1\.2 -r1\.3" \*\*\*\*\*\*\*\*\*\*\*\*\*\*\* 1\.1 .'"${username}"' *[0-9a-zA-Z-]*.: ssfile 1\.2 .'"${username}"' *[0-9a-zA-Z-]*.: ssfile line 2' + + # As long as we have a file with a few revisions, test + # a few "cvs admin -o" invocations. + cd sdir/ssdir + dotest_fail basica-o1 "${testcvs} admin -o 1.2::1.2" \ +"${PROG} [a-z]*: while processing more than one file: +${PROG} \[[a-z]* aborted\]: attempt to specify a numeric revision" + dotest basica-o2 "${testcvs} admin -o 1.2::1.2 ssfile" \ +"RCS file: ${TESTDIR}/cvsroot/first-dir/sdir/ssdir/ssfile,v +done" + dotest basica-o2a "${testcvs} admin -o 1.1::NOT_RESERVED ssfile" \ +"RCS file: ${TESTDIR}/cvsroot/first-dir/sdir/ssdir/ssfile,v +done" + dotest_fail basica-o2b "${testcvs} admin -o 1.1::NOT_EXIST ssfile" \ +"RCS file: ${TESTDIR}/cvsroot/first-dir/sdir/ssdir/ssfile,v +${PROG} [a-z]*: ${TESTDIR}/cvsroot/first-dir/sdir/ssdir/ssfile,v: Revision NOT_EXIST doesn't exist. +${PROG} [a-z]*: cannot modify RCS file for .ssfile." + dotest basica-o3 "${testcvs} admin -o 1.2::1.3 ssfile" \ +"RCS file: ${TESTDIR}/cvsroot/first-dir/sdir/ssdir/ssfile,v +done" + dotest basica-o4 "${testcvs} admin -o 3.1:: ssfile" \ +"RCS file: ${TESTDIR}/cvsroot/first-dir/sdir/ssdir/ssfile,v +done" + dotest basica-o5 "${testcvs} admin -o ::1.1 ssfile" \ +"RCS file: ${TESTDIR}/cvsroot/first-dir/sdir/ssdir/ssfile,v +done" + dotest basica-o5a "${testcvs} -n admin -o 1.2::3.1 ssfile" \ +"RCS file: ${TESTDIR}/cvsroot/first-dir/sdir/ssdir/ssfile,v +deleting revision 2\.0 +deleting revision 1\.3 +done" + dotest basica-o6 "${testcvs} admin -o 1.2::3.1 ssfile" \ +"RCS file: ${TESTDIR}/cvsroot/first-dir/sdir/ssdir/ssfile,v +deleting revision 2\.0 +deleting revision 1\.3 +done" + dotest basica-o7 "${testcvs} log -N ssfile" " +RCS file: ${TESTDIR}/cvsroot/first-dir/sdir/ssdir/ssfile,v +Working file: ssfile +head: 3\.1 +branch: +locks: strict +access list: +keyword substitution: kv +total revisions: 3; selected revisions: 3 +description: +---------------------------- +revision 3\.1 +date: [0-9/]* [0-9:]*; author: ${username}; state: Exp; lines: ${PLUS}0 -0 +bump-it +---------------------------- +revision 1\.2 +date: [0-9/]* [0-9:]*; author: ${username}; state: Exp; lines: ${PLUS}1 -0 +modify-it +---------------------------- +revision 1\.1 +date: [0-9/]* [0-9:]*; author: ${username}; state: Exp; +add-it +=============================================================================" + dotest basica-o8 "${testcvs} -q update -p -r 1.1 ssfile" "ssfile" + cd ../.. + cd .. rm -rf ${CVSROOT_DIRNAME}/first-dir @@ -714,18 +853,25 @@ diff -r1\.2 -r1\.3" touch topfile dotest basicb-0b "${testcvs} add topfile" \ "${PROG} [a-z]*: scheduling file .topfile. for addition -${PROG} [a-z]*: use .cvs commit. to add this file permanently" +${PROG} [a-z]*: use .${PROG} commit. to add this file permanently" dotest basicb-0c "${testcvs} -q ci -m add-it topfile" \ -"RCS file: ${TESTDIR}/cvsroot/\./topfile,v +"RCS file: ${TESTDIR}/cvsroot/topfile,v done Checking in topfile; -${TESTDIR}/cvsroot/\./topfile,v <-- topfile +${TESTDIR}/cvsroot/topfile,v <-- topfile initial revision: 1\.1 done" cd .. rm -r 1 mkdir 2; cd 2 dotest basicb-0d "${testcvs} -q co -l ." "U topfile" + # Now test the ability to run checkout on an existing working + # directory without having it lose its mind. I don't know + # whether this is tested elsewhere in sanity.sh. A more elaborate + # test might also have modified files, make sure it works if + # the modules file was modified to add new directories to the + # module, and such. + dotest basicb-0d0 "${testcvs} -q co -l ." "" mkdir first-dir dotest basicb-0e "${testcvs} add first-dir" \ "Directory ${TESTDIR}/cvsroot/first-dir added to the repository" @@ -735,24 +881,33 @@ done" : mkdir ${CVSROOT_DIRNAME}/first-dir dotest basicb-1 "${testcvs} -q co first-dir" '' dotest basicb-1a "test -d CVS" '' - # See comment at modules3-7f for more on this behavior. + + # In 1b and 1c, the first string matches if we're using absolute + # paths, while the second matches if RELATIVE_REPOS is defined + # (we're using relative paths). + dotest basicb-1b "cat CVS/Repository" \ -"${TESTDIR}/cvsroot/first-dir" "${TESTDIR}/cvsroot/\." +"${TESTDIR}/cvsroot/\." \ +"\." dotest basicb-1c "cat first-dir/CVS/Repository" \ -"${TESTDIR}/cvsroot/first-dir" +"${TESTDIR}/cvsroot/first-dir" \ +"first-dir" cd first-dir - mkdir sdir1 sdir2 - dotest basicb-2 "${testcvs} add sdir1 sdir2" \ -"Directory ${TESTDIR}/cvsroot/first-dir/sdir1 added to the repository + # Note that the name Emptydir is chosen to test that CVS just + # treats it like any other directory name. It should be + # special only when it is directly in $CVSROOT/CVSROOT. + mkdir Emptydir sdir2 + dotest basicb-2 "${testcvs} add Emptydir sdir2" \ +"Directory ${TESTDIR}/cvsroot/first-dir/Emptydir added to the repository Directory ${TESTDIR}/cvsroot/first-dir/sdir2 added to the repository" - cd sdir1 + cd Emptydir echo sfile1 starts >sfile1 dotest basicb-2a10 "${testcvs} -n add sfile1" \ "${PROG} [a-z]*: scheduling file .sfile1. for addition -${PROG} [a-z]*: use .cvs commit. to add this file permanently" +${PROG} [a-z]*: use .${PROG} commit. to add this file permanently" dotest basicb-2a11 "${testcvs} status sfile1" \ -"${PROG} [a-z]*: use .cvs add' to create an entry for sfile1 +"${PROG} [a-z]*: use .${PROG} add. to create an entry for sfile1 =================================================================== File: sfile1 Status: Unknown @@ -760,7 +915,7 @@ File: sfile1 Status: Unknown Repository revision: No revision control file" dotest basicb-3 "${testcvs} add sfile1" \ "${PROG} [a-z]*: scheduling file .sfile1. for addition -${PROG} [a-z]*: use .cvs commit. to add this file permanently" +${PROG} [a-z]*: use .${PROG} commit. to add this file permanently" dotest basicb-3a1 "${testcvs} status sfile1" \ "=================================================================== File: sfile1 Status: Locally Added @@ -775,16 +930,16 @@ File: sfile1 Status: Locally Added echo sfile2 starts >sfile2 dotest basicb-4 "${testcvs} add sfile2" \ "${PROG} [a-z]*: scheduling file .sfile2. for addition -${PROG} [a-z]*: use .cvs commit. to add this file permanently" +${PROG} [a-z]*: use .${PROG} commit. to add this file permanently" dotest basicb-4a "${testcvs} -q ci CVS" \ "${PROG} [a-z]*: warning: directory CVS specified in argument ${PROG} [a-z]*: but CVS uses CVS for its own purposes; skipping CVS directory" cd .. dotest basicb-5 "${testcvs} -q ci -m add" \ -"RCS file: ${TESTDIR}/cvsroot/first-dir/sdir1/sfile1,v +"RCS file: ${TESTDIR}/cvsroot/first-dir/Emptydir/sfile1,v done -Checking in sdir1/sfile1; -${TESTDIR}/cvsroot/first-dir/sdir1/sfile1,v <-- sfile1 +Checking in Emptydir/sfile1; +${TESTDIR}/cvsroot/first-dir/Emptydir/sfile1,v <-- sfile1 initial revision: 1\.1 done RCS file: ${TESTDIR}/cvsroot/first-dir/sdir2/sfile2,v @@ -793,13 +948,13 @@ Checking in sdir2/sfile2; ${TESTDIR}/cvsroot/first-dir/sdir2/sfile2,v <-- sfile2 initial revision: 1\.1 done" - echo sfile1 develops >sdir1/sfile1 + echo sfile1 develops >Emptydir/sfile1 dotest basicb-6 "${testcvs} -q ci -m modify" \ -"Checking in sdir1/sfile1; -${TESTDIR}/cvsroot/first-dir/sdir1/sfile1,v <-- sfile1 +"Checking in Emptydir/sfile1; +${TESTDIR}/cvsroot/first-dir/Emptydir/sfile1,v <-- sfile1 new revision: 1\.2; previous revision: 1\.1 done" - dotest basicb-7 "${testcvs} -q tag release-1" 'T sdir1/sfile1 + dotest basicb-7 "${testcvs} -q tag release-1" 'T Emptydir/sfile1 T sdir2/sfile2' echo not in time for release-1 >sdir2/sfile2 dotest basicb-8 "${testcvs} -q ci -m modify-2" \ @@ -817,22 +972,48 @@ done" # for existing files, even if co -d is in use. touch first-dir/extra dotest basicb-cod-1 "${testcvs} -q co -d first-dir1 first-dir" \ -'U first-dir1/sdir1/sfile1 +'U first-dir1/Emptydir/sfile1 U first-dir1/sdir2/sfile2' rm -r first-dir1 rm -r first-dir + + # FIXME? basicb-9 used to check things out like this: + # U newdir/Emptydir/sfile1 + # U newdir/sdir2/sfile2 + # but that's difficult to do. The whole "shorten" thing + # is pretty bogus, because it will break on things + # like "cvs co foo/bar baz/quux". Unless there's some + # pretty detailed expansion and analysis of the command-line + # arguments, we shouldn't do "shorten" stuff at all. + dotest basicb-9 \ -"${testcvs} -q co -d newdir -r release-1 first-dir/sdir1 first-dir/sdir2" \ -'U newdir/sdir1/sfile1 -U newdir/sdir2/sfile2' +"${testcvs} -q co -d newdir -r release-1 first-dir/Emptydir first-dir/sdir2" \ +'U newdir/first-dir/Emptydir/sfile1 +U newdir/first-dir/sdir2/sfile2' dotest basicb-9a "test -d CVS" '' - # See comment at modules3-7f for more on this behavior. + + # In 9b through 9f, the first string matches if we're using + # absolute paths, while the second matches if RELATIVE_REPOS + # is defined (we're using relative paths). + dotest basicb-9b "cat CVS/Repository" \ -"${TESTDIR}/cvsroot/first-dir" "${TESTDIR}/cvsroot/\." +"${TESTDIR}/cvsroot/\." \ +"\." dotest basicb-9c "cat newdir/CVS/Repository" \ -"${TESTDIR}/cvsroot/CVSROOT/Emptydir" - dotest basicb-10 "cat newdir/sdir1/sfile1 newdir/sdir2/sfile2" \ +"${TESTDIR}/cvsroot/\." \ +"\." + dotest basicb-9d "cat newdir/first-dir/CVS/Repository" \ +"${TESTDIR}/cvsroot/first-dir" \ +"first-dir" + dotest basicb-9e "cat newdir/first-dir/Emptydir/CVS/Repository" \ +"${TESTDIR}/cvsroot/first-dir/Emptydir" \ +"first-dir/Emptydir" + dotest basicb-9f "cat newdir/first-dir/sdir2/CVS/Repository" \ +"${TESTDIR}/cvsroot/first-dir/sdir2" \ +"first-dir/sdir2" + + dotest basicb-10 "cat newdir/first-dir/Emptydir/sfile1 newdir/first-dir/sdir2/sfile2" \ "sfile1 develops sfile2 starts" @@ -842,7 +1023,7 @@ sfile2 starts" # seem to deal with it... if false; then dotest basicb-11 "${testcvs} -q co -d sub1/sub2 first-dir" \ -"U sub1/sub2/sdir1/sfile1 +"U sub1/sub2/Emptydir/sfile1 U sub1/sub2/sdir2/sfile2" cd sub1 dotest basicb-12 "${testcvs} -q update" '' @@ -864,7 +1045,7 @@ U sub1/sub2/sdir2/sfile2" touch aa dotest basicb-16 "${testcvs} add aa" \ "${PROG} [a-z]*: scheduling file .aa. for addition -${PROG} [a-z]*: use .cvs commit. to add this file permanently" +${PROG} [a-z]*: use .${PROG} commit. to add this file permanently" dotest basicb-17 "${testcvs} -q ci -m add" \ "RCS file: ${TESTDIR}/cvsroot/second-dir/aa,v done @@ -874,16 +1055,13 @@ initial revision: 1\.1 done" cd ../.. rm -r 1 - # Now here is the kicker: note that the semantics of -d - # are fundamentally different if we specify two or more directories - # rather than one! I consider this to be seriously bogus, - # but for the moment I am just trying to figure out what - # CVS's current behaviors are. - dotest basicb-18 "${testcvs} -q co -d test2 first-dir second-dir" \ -"U test2/first-dir/sdir1/sfile1 -U test2/first-dir/sdir2/sfile2 -U test2/second-dir/aa" - cd test2 + + # Let's see if we can add something to Emptydir. + dotest basicb-18 "${testcvs} -q co -d t2/t3 first-dir second-dir" \ +"U t2/t3/first-dir/Emptydir/sfile1 +U t2/t3/first-dir/sdir2/sfile2 +U t2/t3/second-dir/aa" + cd t2 touch emptyfile # The fact that CVS lets us add a file here is a CVS bug, right? # I can just make this an error message (on the add and/or the @@ -892,7 +1070,7 @@ U test2/second-dir/aa" # Right? dotest basicb-19 "${testcvs} add emptyfile" \ "${PROG} [a-z]*: scheduling file .emptyfile. for addition -${PROG} [a-z]*: use .cvs commit. to add this file permanently" +${PROG} [a-z]*: use .${PROG} commit. to add this file permanently" dotest basicb-20 "${testcvs} -q ci -m add" \ "RCS file: ${TESTDIR}/cvsroot/CVSROOT/Emptydir/emptyfile,v done @@ -901,32 +1079,75 @@ ${TESTDIR}/cvsroot/CVSROOT/Emptydir/emptyfile,v <-- emptyfile initial revision: 1\.1 done" cd .. + rm -r t2 mkdir 1; cd 1 - # "cvs admin" tests are scattered around a bit. Here we test - # ability to reject an unrecognized option. The "keyword" - # test has a test of "cvs admin -l" and the "binfiles" test - # has a test of "cvs admin -k". Note that -H is an illegal - # option. It probably should be an error message. But - # currently it is one error message for each file operated on, - # which in this case is zero files. - dotest basicb-21 "${testcvs} -q admin -H" "" + # Note that -H is an illegal option. + # I suspect that the choice between "illegal" and "invalid" + # depends on the user's environment variables, the phase + # of the moon (weirdness with optind), and who knows what else. + # I've been seeing "illegal"... + dotest_fail basicb-21 "${testcvs} -q admin -H" \ +"admin: illegal option -- H +${PROG} \[admin aborted\]: specify ${PROG} -H admin for usage information" \ +"admin: invalid option -- H +${PROG} \[admin aborted\]: specify ${PROG} -H admin for usage information" cd .. rmdir 1 + # OK, while we have an Emptydir around, test a few obscure + # things about it. + mkdir edir; cd edir + dotest basicb-edir-1 "${testcvs} -q co -l CVSROOT" \ +"U CVSROOT${DOTSTAR}" + cd CVSROOT + dotest_fail basicb-edir-2 "test -d Emptydir" '' + # This tests the code in find_dirs which skips Emptydir. + dotest basicb-edir-3 "${testcvs} -q -n update -d -P" '' + cd ../.. + rm -r edir + if test "$keep" = yes; then echo Keeping ${TESTDIR} and exiting due to --keep exit 0 fi - rm -r test2 - rm -rf ${CVSROOT_DIRNAME}/first-dir rm -rf ${CVSROOT_DIRNAME}/second-dir rm -rf ${CVSROOT_DIRNAME}/CVSROOT/Emptydir rm -f ${CVSROOT_DIRNAME}/topfile,v ;; + basicc) + # More tests of basic/miscellaneous functionality. + mkdir 1; cd 1 + dotest_fail basicc-1 "${testcvs} diff" \ +"${PROG} [a-z]*: in directory \.: +${PROG} \[[a-z]* aborted\]: there is no version here; run .${PROG} checkout. first" + dotest basicc-2 "${testcvs} -q co -l ." '' + mkdir first-dir second-dir + dotest basicc-3 "${testcvs} add first-dir second-dir" \ +"Directory ${TESTDIR}/cvsroot/first-dir added to the repository +Directory ${TESTDIR}/cvsroot/second-dir added to the repository" + # Old versions of CVS often didn't create this top-level CVS + # directory in the first place. I think that maybe the only + # way to get avoid it currently is to let CVS create it, and + # then blow it away. But that is perfectly legal; people who + # are used to the old behavior especially may be interested. + rm -r CVS + dotest basicc-4 "echo *" "first-dir second-dir" + dotest basicc-5 "${testcvs} update" \ +"${PROG} [a-z]*: Updating first-dir +${PROG} [a-z]*: Updating second-dir" \ +"${PROG} [a-z]*: Updating \. +${PROG} [a-z]*: Updating first-dir +${PROG} [a-z]*: Updating second-dir" + + cd .. + rm -r 1 + rm -rf ${CVSROOT_DIRNAME}/first-dir + ;; + basic1) # first dive - add a files, first singly, then in a group. mkdir ${CVSROOT_DIRNAME}/first-dir @@ -945,7 +1166,7 @@ done" ${PROG} [a-z]*: scheduling file \`file3' for addition ${PROG} [a-z]*: scheduling file \`file4' for addition ${PROG} [a-z]*: scheduling file \`file5' for addition -${PROG} [a-z]*: use 'cvs commit' to add these files permanently" +${PROG} [a-z]*: use .${PROG} commit. to add these files permanently" dotest basic1-15-add-add \ "${testcvs} -q update file2 file3 file4 file5" \ "A file2 @@ -1315,7 +1536,7 @@ done" echo file1 >file1 dotest deep-3-$i "${testcvs} add file1" \ "${PROG}"' [a-z]*: scheduling file `file1'\'' for addition -'"${PROG}"' [a-z]*: use '\''cvs commit'\'' to add this file permanently' +'"${PROG}"' [a-z]*: use .'"${PROG}"' commit. to add this file permanently' done cd ../../../../../../../../.. dotest_lit deep-4 "${testcvs} -q ci -m add-them first-dir" <<HERE @@ -1391,6 +1612,8 @@ done" # that "cvs release -d" is the way to delete the directory # and have it stay gone -kingdon, Oct1996). rm -r dir6 + dotest deep-4b0a "${testcvs} -q diff" '' + dotest deep-4b0b "${testcvs} -q ci" '' dotest deep-4b1 "${testcvs} -q update" '' dotest deep-4b2 "${testcvs} -q update -d -P" \ 'U dir6/file1 @@ -1462,9 +1685,9 @@ done" if test ! -d $i ; then mkdir $i if ${CVS} add $i >> ${LOGFILE}; then - echo "PASS: test 29-$i" >>${LOGFILE} + pass 29-$i else - echo "FAIL: test 29-$i" | tee -a ${LOGFILE} ; exit 1 + fail 29-$i fi fi @@ -1475,48 +1698,48 @@ done" done if ${CVS} add file6 file7 2>> ${LOGFILE}; then - echo "PASS: test 30-$i-$j" >>${LOGFILE} + pass 30-$i-$j else - echo "FAIL: test 30-$i-$j" | tee -a ${LOGFILE} ; exit 1 + fail 30-$i-$j fi done cd ../../.. if ${CVS} update first-dir ; then - echo "PASS: test 31" >>${LOGFILE} + pass 31 else - echo "FAIL: test 31" | tee -a ${LOGFILE} ; exit 1 + fail 31 fi # fixme: doesn't work right for added files. if ${CVS} log first-dir >> ${LOGFILE}; then - echo "PASS: test 32" >>${LOGFILE} + pass 32 else - echo "FAIL: test 32" | tee -a ${LOGFILE} # ; exit 1 + fail 32 fi if ${CVS} status first-dir >> ${LOGFILE}; then - echo "PASS: test 33" >>${LOGFILE} + pass 33 else - echo "FAIL: test 33" | tee -a ${LOGFILE} ; exit 1 + fail 33 fi # XXX why is this commented out??? # if ${CVS} diff -u first-dir >> ${LOGFILE} || test $? = 1 ; then -# echo "PASS: test 34" >>${LOGFILE} +# pass 34 # else -# echo "FAIL: test 34" | tee -a ${LOGFILE} # ; exit 1 +# fail 34 # fi if ${CVS} ci -m "second dive" first-dir >> ${LOGFILE} 2>&1; then - echo "PASS: test 35" >>${LOGFILE} + pass 35 else - echo "FAIL: test 35" | tee -a ${LOGFILE} ; exit 1 + fail 35 fi if ${CVS} tag second-dive first-dir ; then - echo "PASS: test 36" >>${LOGFILE} + pass 36 else - echo "FAIL: test 36" | tee -a ${LOGFILE} ; exit 1 + fail 36 fi # third dive - in bunch o' directories, add bunch o' files, @@ -1532,137 +1755,137 @@ done" rm file7 if ${CVS} rm file7 2>> ${LOGFILE}; then - echo "PASS: test 37-$i" >>${LOGFILE} + pass 37-$i else - echo "FAIL: test 37-$i" | tee -a ${LOGFILE} ; exit 1 + fail 37-$i fi # and add a new file echo file14 >file14 if ${CVS} add file14 2>> ${LOGFILE}; then - echo "PASS: test 38-$i" >>${LOGFILE} + pass 38-$i else - echo "FAIL: test 38-$i" | tee -a ${LOGFILE} ; exit 1 + fail 38-$i fi done cd ../../.. if ${CVS} update first-dir ; then - echo "PASS: test 39" >>${LOGFILE} + pass 39 else - echo "FAIL: test 39" | tee -a ${LOGFILE} ; exit 1 + fail 39 fi # FIXME: doesn't work right for added files if ${CVS} log first-dir >> ${LOGFILE}; then - echo "PASS: test 40" >>${LOGFILE} + pass 40 else - echo "FAIL: test 40" | tee -a ${LOGFILE} # ; exit 1 + fail 40 fi if ${CVS} status first-dir >> ${LOGFILE}; then - echo "PASS: test 41" >>${LOGFILE} + pass 41 else - echo "FAIL: test 41" | tee -a ${LOGFILE} ; exit 1 + fail 41 fi # XXX why is this commented out? # if ${CVS} diff -u first-dir >> ${LOGFILE} || test $? = 1 ; then -# echo "PASS: test 42" >>${LOGFILE} +# pass 42 # else -# echo "FAIL: test 42" | tee -a ${LOGFILE} # ; exit 1 +# fail 42 # fi if ${CVS} ci -m "third dive" first-dir >>${LOGFILE} 2>&1; then - echo "PASS: test 43" >>${LOGFILE} + pass 43 else - echo "FAIL: test 43" | tee -a ${LOGFILE} ; exit 1 + fail 43 fi dotest 43.5 "${testcvs} -q update first-dir" '' if ${CVS} tag third-dive first-dir ; then - echo "PASS: test 44" >>${LOGFILE} + pass 44 else - echo "FAIL: test 44" | tee -a ${LOGFILE} ; exit 1 + fail 44 fi if echo "yes" | ${CVS} release -d first-dir ; then - echo "PASS: test 45" >>${LOGFILE} + pass 45 else - echo "FAIL: test 45" | tee -a ${LOGFILE} ; exit 1 + fail 45 fi # end of third dive if test -d first-dir ; then - echo "FAIL: test 45.5" | tee -a ${LOGFILE} ; exit 1 + fail 45.5 else - echo "PASS: test 45.5" >>${LOGFILE} + pass 45.5 fi # now try some rtags # rtag HEADS if ${CVS} rtag rtagged-by-head first-dir ; then - echo "PASS: test 46" >>${LOGFILE} + pass 46 else - echo "FAIL: test 46" | tee -a ${LOGFILE} ; exit 1 + fail 46 fi # tag by tag if ${CVS} rtag -r rtagged-by-head rtagged-by-tag first-dir ; then - echo "PASS: test 47" >>${LOGFILE} + pass 47 else - echo "FAIL: test 47" | tee -a ${LOGFILE} ; exit 1 + fail 47 fi # tag by revision if ${CVS} rtag -r1.1 rtagged-by-revision first-dir ; then - echo "PASS: test 48" >>${LOGFILE} + pass 48 else - echo "FAIL: test 48" | tee -a ${LOGFILE} ; exit 1 + fail 48 fi # rdiff by revision if ${CVS} rdiff -r1.1 -rrtagged-by-head first-dir >> ${LOGFILE} || test $? = 1 ; then - echo "PASS: test 49" >>${LOGFILE} + pass 49 else - echo "FAIL: test 49" | tee -a ${LOGFILE} ; exit 1 + fail 49 fi # now export by rtagged-by-head and rtagged-by-tag and compare. if ${CVS} export -r rtagged-by-head first-dir ; then - echo "PASS: test 50" >>${LOGFILE} + pass 50 else - echo "FAIL: test 50" | tee -a ${LOGFILE} ; exit 1 + fail 50 fi mv first-dir 1dir if ${CVS} export -r rtagged-by-tag first-dir ; then - echo "PASS: test 51" >>${LOGFILE} + pass 51 else - echo "FAIL: test 51" | tee -a ${LOGFILE} ; exit 1 + fail 51 fi directory_cmp 1dir first-dir if $ISDIFF ; then - echo "FAIL: test 52" | tee -a ${LOGFILE} ; exit 1 + fail 52 else - echo "PASS: test 52" >>${LOGFILE} + pass 52 fi rm -r 1dir first-dir # checkout by revision vs export by rtagged-by-revision and compare. if ${CVS} export -rrtagged-by-revision -d export-dir first-dir ; then - echo "PASS: test 53" >>${LOGFILE} + pass 53 else - echo "FAIL: test 53" | tee -a ${LOGFILE} ; exit 1 + fail 53 fi if ${CVS} co -r1.1 first-dir ; then - echo "PASS: test 54" >>${LOGFILE} + pass 54 else - echo "FAIL: test 54" | tee -a ${LOGFILE} ; exit 1 + fail 54 fi # directory copies are done in an oblique way in order to avoid a bug in sun's tmp filesystem. @@ -1671,9 +1894,9 @@ done" directory_cmp first-dir export-dir if $ISDIFF ; then - echo "FAIL: test 55" | tee -a ${LOGFILE} ; exit 1 + fail 55 else - echo "PASS: test 55" >>${LOGFILE} + pass 55 fi # interrupt, while we've got a clean 1.1 here, let's import it @@ -1696,17 +1919,17 @@ No conflicts created by this import" cd .. if ${CVS} export -r HEAD second-dir ; then - echo "PASS: test 57" >>${LOGFILE} + pass 57 else - echo "FAIL: test 57" | tee -a ${LOGFILE} ; exit 1 + fail 57 fi directory_cmp first-dir second-dir if $ISDIFF ; then - echo "FAIL: test 58" | tee -a ${LOGFILE} ; exit 1 + fail 58 else - echo "PASS: test 58" >>${LOGFILE} + pass 58 fi rm -r second-dir @@ -1718,22 +1941,22 @@ No conflicts created by this import" # update the top, cancelling sticky tags, retag, update other copy, compare. cd first-dir if ${CVS} update -A -l *file* 2>> ${LOGFILE}; then - echo "PASS: test 59" >>${LOGFILE} + pass 59 else - echo "FAIL: test 59" | tee -a ${LOGFILE} ; exit 1 + fail 59 fi # If we don't delete the tag first, cvs won't retag it. # This would appear to be a feature. if ${CVS} tag -l -d rtagged-by-revision ; then - echo "PASS: test 60a" >>${LOGFILE} + pass 60a else - echo "FAIL: test 60a" | tee -a ${LOGFILE} ; exit 1 + fail 60a fi if ${CVS} tag -l rtagged-by-revision ; then - echo "PASS: test 60b" >>${LOGFILE} + pass 60b else - echo "FAIL: test 60b" | tee -a ${LOGFILE} ; exit 1 + fail 60b fi cd .. @@ -1744,9 +1967,9 @@ No conflicts created by this import" dotest 61 "${testcvs} -q diff -u" '' if ${CVS} update ; then - echo "PASS: test 62" >>${LOGFILE} + pass 62 else - echo "FAIL: test 62" | tee -a ${LOGFILE} ; exit 1 + fail 62 fi cd .. @@ -1756,9 +1979,9 @@ No conflicts created by this import" # directory_cmp 1dir first-dir # # if $ISDIFF ; then -# echo "FAIL: test 63" | tee -a ${LOGFILE} # ; exit 1 +# fail 63 # else -# echo "PASS: test 63" >>${LOGFILE} +# pass 63 # fi rm -r 1dir first-dir @@ -1774,44 +1997,44 @@ No conflicts created by this import" # which don't exist in the remote output? would seem to be # a CVS bug. dotest basic2-64 "${testcvs} his -x TOFWUCGMAR -a" \ -"O [0-9/]* [0-9:]* ${PLUS}0000 [a-z0-9@][a-z0-9@]* first-dir =first-dir= ${TMPPWD}/\* -A [0-9/]* [0-9:]* ${PLUS}0000 [a-z0-9@][a-z0-9@]* 1\.1 file6 first-dir == ${TMPPWD} -A [0-9/]* [0-9:]* ${PLUS}0000 [a-z0-9@][a-z0-9@]* 1\.1 file7 first-dir == ${TMPPWD} -A [0-9/]* [0-9:]* ${PLUS}0000 [a-z0-9@][a-z0-9@]* 1\.1 file6 first-dir/dir1 == ${TMPPWD} -A [0-9/]* [0-9:]* ${PLUS}0000 [a-z0-9@][a-z0-9@]* 1\.1 file7 first-dir/dir1 == ${TMPPWD} -A [0-9/]* [0-9:]* ${PLUS}0000 [a-z0-9@][a-z0-9@]* 1\.1 file6 first-dir/dir1/dir2 == ${TMPPWD} -A [0-9/]* [0-9:]* ${PLUS}0000 [a-z0-9@][a-z0-9@]* 1\.1 file7 first-dir/dir1/dir2 == ${TMPPWD} -A [0-9/]* [0-9:]* ${PLUS}0000 [a-z0-9@][a-z0-9@]* 1\.1 file14 first-dir == ${TMPPWD} -M [0-9/]* [0-9:]* ${PLUS}0000 [a-z0-9@][a-z0-9@]* 1\.2 file6 first-dir == ${TMPPWD} -A [0-9/]* [0-9:]* ${PLUS}0000 [a-z0-9@][a-z0-9@]* 1\.1 file14 first-dir/dir1 == ${TMPPWD} -M [0-9/]* [0-9:]* ${PLUS}0000 [a-z0-9@][a-z0-9@]* 1\.2 file6 first-dir/dir1 == ${TMPPWD} -A [0-9/]* [0-9:]* ${PLUS}0000 [a-z0-9@][a-z0-9@]* 1\.1 file14 first-dir/dir1/dir2 == ${TMPPWD} -M [0-9/]* [0-9:]* ${PLUS}0000 [a-z0-9@][a-z0-9@]* 1\.2 file6 first-dir/dir1/dir2 == ${TMPPWD} -F [0-9/]* [0-9:]* ${PLUS}0000 [a-z0-9@][a-z0-9@]* =first-dir= ${TMPPWD}/\* -T [0-9/]* [0-9:]* ${PLUS}0000 [a-z0-9@][a-z0-9@]* first-dir \[rtagged-by-head:A\] -T [0-9/]* [0-9:]* ${PLUS}0000 [a-z0-9@][a-z0-9@]* first-dir \[rtagged-by-tag:rtagged-by-head\] -T [0-9/]* [0-9:]* ${PLUS}0000 [a-z0-9@][a-z0-9@]* first-dir \[rtagged-by-revision:1\.1\] -O [0-9/]* [0-9:]* ${PLUS}0000 [a-z0-9@][a-z0-9@]* \[1\.1\] first-dir =first-dir= ${TMPPWD}/\* -U [0-9/]* [0-9:]* ${PLUS}0000 [a-z0-9@][a-z0-9@]* 1\.2 file6 first-dir == ${TMPPWD}/first-dir -U [0-9/]* [0-9:]* ${PLUS}0000 [a-z0-9@][a-z0-9@]* 1\.2 file7 first-dir == ${TMPPWD}/first-dir" \ -"O [0-9/]* [0-9:]* ${PLUS}0000 [a-z0-9@][a-z0-9@]* first-dir =first-dir= <remote>/\* -A [0-9/]* [0-9:]* ${PLUS}0000 [a-z0-9@][a-z0-9@]* 1\.1 file6 first-dir == <remote> -A [0-9/]* [0-9:]* ${PLUS}0000 [a-z0-9@][a-z0-9@]* 1\.1 file7 first-dir == <remote> -A [0-9/]* [0-9:]* ${PLUS}0000 [a-z0-9@][a-z0-9@]* 1\.1 file6 first-dir/dir1 == <remote> -A [0-9/]* [0-9:]* ${PLUS}0000 [a-z0-9@][a-z0-9@]* 1\.1 file7 first-dir/dir1 == <remote> -A [0-9/]* [0-9:]* ${PLUS}0000 [a-z0-9@][a-z0-9@]* 1\.1 file6 first-dir/dir1/dir2 == <remote> -A [0-9/]* [0-9:]* ${PLUS}0000 [a-z0-9@][a-z0-9@]* 1\.1 file7 first-dir/dir1/dir2 == <remote> -A [0-9/]* [0-9:]* ${PLUS}0000 [a-z0-9@][a-z0-9@]* 1\.1 file14 first-dir == <remote> -M [0-9/]* [0-9:]* ${PLUS}0000 [a-z0-9@][a-z0-9@]* 1\.2 file6 first-dir == <remote> -A [0-9/]* [0-9:]* ${PLUS}0000 [a-z0-9@][a-z0-9@]* 1\.1 file14 first-dir/dir1 == <remote> -M [0-9/]* [0-9:]* ${PLUS}0000 [a-z0-9@][a-z0-9@]* 1\.2 file6 first-dir/dir1 == <remote> -A [0-9/]* [0-9:]* ${PLUS}0000 [a-z0-9@][a-z0-9@]* 1\.1 file14 first-dir/dir1/dir2 == <remote> -M [0-9/]* [0-9:]* ${PLUS}0000 [a-z0-9@][a-z0-9@]* 1\.2 file6 first-dir/dir1/dir2 == <remote> -F [0-9/]* [0-9:]* ${PLUS}0000 [a-z0-9@][a-z0-9@]* =first-dir= <remote>/\* -T [0-9/]* [0-9:]* ${PLUS}0000 [a-z0-9@][a-z0-9@]* first-dir \[rtagged-by-head:A\] -T [0-9/]* [0-9:]* ${PLUS}0000 [a-z0-9@][a-z0-9@]* first-dir \[rtagged-by-tag:rtagged-by-head\] -T [0-9/]* [0-9:]* ${PLUS}0000 [a-z0-9@][a-z0-9@]* first-dir \[rtagged-by-revision:1\.1\] -O [0-9/]* [0-9:]* ${PLUS}0000 [a-z0-9@][a-z0-9@]* \[1\.1\] first-dir =first-dir= <remote>/\*" +"O [0-9/]* [0-9:]* ${PLUS}0000 ${username} first-dir =first-dir= ${TMPPWD}/\* +A [0-9/]* [0-9:]* ${PLUS}0000 ${username} 1\.1 file6 first-dir == ${TMPPWD} +A [0-9/]* [0-9:]* ${PLUS}0000 ${username} 1\.1 file7 first-dir == ${TMPPWD} +A [0-9/]* [0-9:]* ${PLUS}0000 ${username} 1\.1 file6 first-dir/dir1 == ${TMPPWD} +A [0-9/]* [0-9:]* ${PLUS}0000 ${username} 1\.1 file7 first-dir/dir1 == ${TMPPWD} +A [0-9/]* [0-9:]* ${PLUS}0000 ${username} 1\.1 file6 first-dir/dir1/dir2 == ${TMPPWD} +A [0-9/]* [0-9:]* ${PLUS}0000 ${username} 1\.1 file7 first-dir/dir1/dir2 == ${TMPPWD} +A [0-9/]* [0-9:]* ${PLUS}0000 ${username} 1\.1 file14 first-dir == ${TMPPWD} +M [0-9/]* [0-9:]* ${PLUS}0000 ${username} 1\.2 file6 first-dir == ${TMPPWD} +A [0-9/]* [0-9:]* ${PLUS}0000 ${username} 1\.1 file14 first-dir/dir1 == ${TMPPWD} +M [0-9/]* [0-9:]* ${PLUS}0000 ${username} 1\.2 file6 first-dir/dir1 == ${TMPPWD} +A [0-9/]* [0-9:]* ${PLUS}0000 ${username} 1\.1 file14 first-dir/dir1/dir2 == ${TMPPWD} +M [0-9/]* [0-9:]* ${PLUS}0000 ${username} 1\.2 file6 first-dir/dir1/dir2 == ${TMPPWD} +F [0-9/]* [0-9:]* ${PLUS}0000 ${username} =first-dir= ${TMPPWD}/\* +T [0-9/]* [0-9:]* ${PLUS}0000 ${username} first-dir \[rtagged-by-head:A\] +T [0-9/]* [0-9:]* ${PLUS}0000 ${username} first-dir \[rtagged-by-tag:rtagged-by-head\] +T [0-9/]* [0-9:]* ${PLUS}0000 ${username} first-dir \[rtagged-by-revision:1\.1\] +O [0-9/]* [0-9:]* ${PLUS}0000 ${username} \[1\.1\] first-dir =first-dir= ${TMPPWD}/\* +U [0-9/]* [0-9:]* ${PLUS}0000 ${username} 1\.2 file6 first-dir == ${TMPPWD}/first-dir +U [0-9/]* [0-9:]* ${PLUS}0000 ${username} 1\.2 file7 first-dir == ${TMPPWD}/first-dir" \ +"O [0-9/]* [0-9:]* ${PLUS}0000 ${username} first-dir =first-dir= <remote>/\* +A [0-9/]* [0-9:]* ${PLUS}0000 ${username} 1\.1 file6 first-dir == <remote> +A [0-9/]* [0-9:]* ${PLUS}0000 ${username} 1\.1 file7 first-dir == <remote> +A [0-9/]* [0-9:]* ${PLUS}0000 ${username} 1\.1 file6 first-dir/dir1 == <remote> +A [0-9/]* [0-9:]* ${PLUS}0000 ${username} 1\.1 file7 first-dir/dir1 == <remote> +A [0-9/]* [0-9:]* ${PLUS}0000 ${username} 1\.1 file6 first-dir/dir1/dir2 == <remote> +A [0-9/]* [0-9:]* ${PLUS}0000 ${username} 1\.1 file7 first-dir/dir1/dir2 == <remote> +A [0-9/]* [0-9:]* ${PLUS}0000 ${username} 1\.1 file14 first-dir == <remote> +M [0-9/]* [0-9:]* ${PLUS}0000 ${username} 1\.2 file6 first-dir == <remote> +A [0-9/]* [0-9:]* ${PLUS}0000 ${username} 1\.1 file14 first-dir/dir1 == <remote> +M [0-9/]* [0-9:]* ${PLUS}0000 ${username} 1\.2 file6 first-dir/dir1 == <remote> +A [0-9/]* [0-9:]* ${PLUS}0000 ${username} 1\.1 file14 first-dir/dir1/dir2 == <remote> +M [0-9/]* [0-9:]* ${PLUS}0000 ${username} 1\.2 file6 first-dir/dir1/dir2 == <remote> +F [0-9/]* [0-9:]* ${PLUS}0000 ${username} =first-dir= <remote>/\* +T [0-9/]* [0-9:]* ${PLUS}0000 ${username} first-dir \[rtagged-by-head:A\] +T [0-9/]* [0-9:]* ${PLUS}0000 ${username} first-dir \[rtagged-by-tag:rtagged-by-head\] +T [0-9/]* [0-9:]* ${PLUS}0000 ${username} first-dir \[rtagged-by-revision:1\.1\] +O [0-9/]* [0-9:]* ${PLUS}0000 ${username} \[1\.1\] first-dir =first-dir= <remote>/\*" rm -rf ${CVSROOT_DIRNAME}/first-dir rm -rf ${CVSROOT_DIRNAME}/second-dir @@ -1828,11 +2051,12 @@ O [0-9/]* [0-9:]* ${PLUS}0000 [a-z0-9@][a-z0-9@]* \[1\.1\] first-dir = echo '$''Name$' >> foo echo '$''Id$' > bar echo '$''Name$' >> bar - dotest rdiff-1 \ + dotest_sort rdiff-1 \ "${testcvs} import -I ! -m test-import-with-keyword trdiff TRDIFF T1" \ -'N trdiff/foo -N trdiff/bar +' +N trdiff/bar +N trdiff/foo No conflicts created by this import' dotest rdiff-2 \ "${testcvs} co -ko trdiff" \ @@ -1852,7 +2076,7 @@ done" dotest rdiff-4 \ "${testcvs} add -m new-file-description new" \ "${PROG} [a-z]*: scheduling file \`new' for addition -${PROG} [a-z]*: use 'cvs commit' to add this file permanently" +${PROG} [a-z]*: use .${PROG} commit. to add this file permanently" dotest rdiff-5 \ "${testcvs} commit -m added-new-file new" \ "RCS file: ${TESTDIR}/cvsroot/trdiff/new,v @@ -1932,9 +2156,9 @@ diff -c /dev/null trdiff/new:1\.1 mkdir ${CVSROOT_DIRNAME}/first-dir if ${CVS} co first-dir ; then - echo "PASS: test 65" >>${LOGFILE} + pass 65 else - echo "FAIL: test 65" | tee -a ${LOGFILE} ; exit 1 + fail 65 fi cd first-dir @@ -1948,7 +2172,7 @@ diff -c /dev/null trdiff/new:1\.1 echo file in subdir >sfile dotest 65a1 "${testcvs} add sfile" \ "${PROG}"' [a-z]*: scheduling file `sfile'\'' for addition -'"${PROG}"' [a-z]*: use '\''cvs commit'\'' to add this file permanently' +'"${PROG}"' [a-z]*: use .'"${PROG}"' commit. to add this file permanently' dotest 65a2 "${testcvs} -q ci -m add-it" \ "RCS file: ${TESTDIR}/cvsroot/first-dir/subdir/sfile,v done @@ -1959,7 +2183,7 @@ done" rm sfile dotest 65a3 "${testcvs} rm sfile" \ "${PROG}"' [a-z]*: scheduling `sfile'\'' for removal -'"${PROG}"' [a-z]*: use '\'"${PROG}"' commit'\'' to remove this file permanently' +'"${PROG}"' [a-z]*: use .'"${PROG}"' commit. to remove this file permanently' dotest 65a4 "${testcvs} -q ci -m remove-it" \ "Removing sfile; ${TESTDIR}/cvsroot/first-dir/subdir/sfile,v <-- sfile @@ -1972,31 +2196,31 @@ done" # add a file. touch file1 if ${CVS} add file1 2>> ${LOGFILE}; then - echo "PASS: test 66" >>${LOGFILE} + pass 66 else - echo "FAIL: test 66" | tee -a ${LOGFILE} ; exit 1 + fail 66 fi # commit if ${CVS} ci -m test >> ${LOGFILE} 2>&1; then - echo "PASS: test 67" >>${LOGFILE} + pass 67 else - echo "FAIL: test 67" | tee -a ${LOGFILE} ; exit 1 + fail 67 fi # remove rm file1 if ${CVS} rm file1 2>> ${LOGFILE}; then - echo "PASS: test 68" >>${LOGFILE} + pass 68 else - echo "FAIL: test 68" | tee -a ${LOGFILE} ; exit 1 + fail 68 fi # commit if ${CVS} ci -m test >>${LOGFILE} ; then - echo "PASS: test 69" >>${LOGFILE} + pass 69 else - echo "FAIL: test 69" | tee -a ${LOGFILE} ; exit 1 + fail 69 fi dotest_fail 69a0 "test -f file1" '' @@ -2011,30 +2235,30 @@ done" # create second file touch file2 if ${CVS} add file1 file2 2>> ${LOGFILE}; then - echo "PASS: test 70" >>${LOGFILE} + pass 70 else - echo "FAIL: test 70" | tee -a ${LOGFILE} ; exit 1 + fail 70 fi # commit if ${CVS} ci -m test >> ${LOGFILE} 2>&1; then - echo "PASS: test 71" >>${LOGFILE} + pass 71 else - echo "FAIL: test 71" | tee -a ${LOGFILE} ; exit 1 + fail 71 fi # log if ${CVS} log file1 >> ${LOGFILE}; then - echo "PASS: test 72" >>${LOGFILE} + pass 72 else - echo "FAIL: test 72" | tee -a ${LOGFILE} ; exit 1 + fail 72 fi # file4 will be dead at the time of branching and stay dead. echo file4 > file4 dotest death-file4-add "${testcvs} add file4" \ "${PROG}"' [a-z]*: scheduling file `file4'\'' for addition -'"${PROG}"' [a-z]*: use '\''cvs commit'\'' to add this file permanently' +'"${PROG}"' [a-z]*: use .'"${PROG}"' commit. to add this file permanently' dotest death-file4-ciadd "${testcvs} -q ci -m add file4" \ "RCS file: ${TESTDIR}/cvsroot/first-dir/file4,v done @@ -2045,7 +2269,7 @@ done" rm file4 dotest death-file4-rm "${testcvs} remove file4" \ "${PROG}"' [a-z]*: scheduling `file4'\'' for removal -'"${PROG}"' [a-z]*: use '\'"${PROG}"' commit'\'' to remove this file permanently' +'"${PROG}"' [a-z]*: use .'"${PROG}"' commit. to remove this file permanently' dotest death-file4-cirm "${testcvs} -q ci -m remove file4" \ "Removing file4; ${TESTDIR}/cvsroot/first-dir/file4,v <-- file4 @@ -2058,16 +2282,16 @@ T file2' # branch1 if ${CVS} tag -b branch1 ; then - echo "PASS: test 73" >>${LOGFILE} + pass 73 else - echo "FAIL: test 73" | tee -a ${LOGFILE} ; exit 1 + fail 73 fi # and move to the branch. if ${CVS} update -r branch1 ; then - echo "PASS: test 74" >>${LOGFILE} + pass 74 else - echo "FAIL: test 74" | tee -a ${LOGFILE} ; exit 1 + fail 74 fi dotest_fail death-file4-3 "test -f file4" '' @@ -2075,16 +2299,16 @@ T file2' # add a file in the branch echo line1 from branch1 >> file3 if ${CVS} add file3 2>> ${LOGFILE}; then - echo "PASS: test 75" >>${LOGFILE} + pass 75 else - echo "FAIL: test 75" | tee -a ${LOGFILE} ; exit 1 + fail 75 fi # commit if ${CVS} ci -m test >> ${LOGFILE} 2>&1; then - echo "PASS: test 76" >>${LOGFILE} + pass 76 else - echo "FAIL: test 76" | tee -a ${LOGFILE} ; exit 1 + fail 76 fi dotest death-76a0 \ @@ -2111,31 +2335,31 @@ diff -c first-dir/file3:1\.1\.2\.1 first-dir/file3:removed # remove rm file3 if ${CVS} rm file3 2>> ${LOGFILE}; then - echo "PASS: test 77" >>${LOGFILE} + pass 77 else - echo "FAIL: test 77" | tee -a ${LOGFILE} ; exit 1 + fail 77 fi # commit if ${CVS} ci -m test >>${LOGFILE} ; then - echo "PASS: test 78" >>${LOGFILE} + pass 78 else - echo "FAIL: test 78" | tee -a ${LOGFILE} ; exit 1 + fail 78 fi # add again echo line1 from branch1 >> file3 if ${CVS} add file3 2>> ${LOGFILE}; then - echo "PASS: test 79" >>${LOGFILE} + pass 79 else - echo "FAIL: test 79" | tee -a ${LOGFILE} ; exit 1 + fail 79 fi # commit if ${CVS} ci -m test >> ${LOGFILE} 2>&1; then - echo "PASS: test 80" >>${LOGFILE} + pass 80 else - echo "FAIL: test 80" | tee -a ${LOGFILE} ; exit 1 + fail 80 fi # change the first file @@ -2143,39 +2367,39 @@ diff -c first-dir/file3:1\.1\.2\.1 first-dir/file3:removed # commit if ${CVS} ci -m test >> ${LOGFILE} 2>&1; then - echo "PASS: test 81" >>${LOGFILE} + pass 81 else - echo "FAIL: test 81" | tee -a ${LOGFILE} ; exit 1 + fail 81 fi # remove the second rm file2 if ${CVS} rm file2 2>> ${LOGFILE}; then - echo "PASS: test 82" >>${LOGFILE} + pass 82 else - echo "FAIL: test 82" | tee -a ${LOGFILE} ; exit 1 + fail 82 fi # commit if ${CVS} ci -m test >>${LOGFILE}; then - echo "PASS: test 83" >>${LOGFILE} + pass 83 else - echo "FAIL: test 83" | tee -a ${LOGFILE} ; exit 1 + fail 83 fi # back to the trunk. if ${CVS} update -A 2>> ${LOGFILE}; then - echo "PASS: test 84" >>${LOGFILE} + pass 84 else - echo "FAIL: test 84" | tee -a ${LOGFILE} ; exit 1 + fail 84 fi dotest_fail death-file4-4 "test -f file4" '' if test -f file3 ; then - echo "FAIL: test 85" | tee -a ${LOGFILE} ; exit 1 + fail 85 else - echo "PASS: test 85" >>${LOGFILE} + pass 85 fi # join @@ -2190,24 +2414,23 @@ U file3" dotest_fail death-file4-5 "test -f file4" '' if test -f file3 ; then - echo "PASS: test 87" >>${LOGFILE} + pass 87 else - echo "FAIL: test 87" | tee -a ${LOGFILE} ; exit 1 + fail 87 fi # Make sure that we joined the correct change to file1 if echo line2 from branch1 | cmp - file1 >/dev/null; then - echo 'PASS: test 87a' >>${LOGFILE} + pass 87a else - echo 'FAIL: test 87a' | tee -a ${LOGFILE} - exit 1 + fail 87a fi # update if ${CVS} update ; then - echo "PASS: test 88" >>${LOGFILE} + pass 88 else - echo "FAIL: test 88" | tee -a ${LOGFILE} ; exit 1 + fail 88 fi # commit @@ -2236,22 +2459,22 @@ U first-dir/file3' # remove first file. rm file1 if ${CVS} rm file1 2>> ${LOGFILE}; then - echo "PASS: test 90" >>${LOGFILE} + pass 90 else - echo "FAIL: test 90" | tee -a ${LOGFILE} ; exit 1 + fail 90 fi # commit if ${CVS} ci -m test >>${LOGFILE}; then - echo "PASS: test 91" >>${LOGFILE} + pass 91 else - echo "FAIL: test 91" | tee -a ${LOGFILE} ; exit 1 + fail 91 fi if test -f file1 ; then - echo "FAIL: test 92" | tee -a ${LOGFILE} ; exit 1 + fail 92 else - echo "PASS: test 92" >>${LOGFILE} + pass 92 fi # typo; try to get to the branch and fail @@ -2259,29 +2482,29 @@ U first-dir/file3' "${PROG}"' \[[a-z]* aborted\]: no such tag brnach1' # Make sure we are still on the trunk if test -f file1 ; then - echo "FAIL: 92.1b" | tee -a ${LOGFILE} ; exit 1 + fail 92.1b else - echo "PASS: 92.1b" >>${LOGFILE} + pass 92.1b fi if test -f file3 ; then - echo "PASS: 92.1c" >>${LOGFILE} + pass 92.1c else - echo "FAIL: 92.1c" | tee -a ${LOGFILE} ; exit 1 + fail 92.1c fi # back to branch1 if ${CVS} update -r branch1 2>> ${LOGFILE}; then - echo "PASS: test 93" >>${LOGFILE} + pass 93 else - echo "FAIL: test 93" | tee -a ${LOGFILE} ; exit 1 + fail 93 fi dotest_fail death-file4-6 "test -f file4" '' if test -f file1 ; then - echo "PASS: test 94" >>${LOGFILE} + pass 94 else - echo "FAIL: test 94" | tee -a ${LOGFILE} ; exit 1 + fail 94 fi # and join @@ -2312,7 +2535,7 @@ U first-dir/file3' echo "first revision" > file1 dotest death2-2 "${testcvs} add file1" \ "${PROG}"' [a-z]*: scheduling file `file1'\'' for addition -'"${PROG}"' [a-z]*: use '\''cvs commit'\'' to add this file permanently' +'"${PROG}"' [a-z]*: use .'"${PROG}"' commit. to add this file permanently' dotest death2-3 "${testcvs} -q commit -m add" \ "RCS file: ${TESTDIR}/cvsroot/first-dir/file1,v @@ -2339,6 +2562,9 @@ ${PROG} [a-z]*: use .${PROG} commit. to remove this file permanently" dotest_fail death2-diff-1 "${testcvs} -q diff file1" \ "${PROG} [a-z]*: file1 was removed, no comparison available" + # If the DIFF that CVS is using (options.h) is Sun diff, this + # test is said to fail (I think the /dev/null is the part + # that differs), along with a number of the other similar tests. dotest_fail death2-diff-2 "${testcvs} -q diff -N -c file1" \ "Index: file1 =================================================================== @@ -2408,7 +2634,7 @@ diff -c first-dir/file1:1\.1 first-dir/file1:removed echo "second revision" > file1 dotest death2-9 "${testcvs} add file1" \ "${PROG}"' [a-z]*: file `file1'\'' will be added on branch `branch'\'' from version 1\.1\.2\.1 -'"${PROG}"' [a-z]*: use '\''cvs commit'\'' to add this file permanently' +'"${PROG}"' [a-z]*: use .'"${PROG}"' commit. to add this file permanently' # Test diff of the added file before it is committed. dotest_fail death2-diff-7 "${testcvs} -q diff file1" \ @@ -2439,7 +2665,7 @@ done" echo "first revision" > file2 dotest death2-12 "${testcvs} add file2" \ "${PROG}"' [a-z]*: scheduling file `file2'\'' for addition -'"${PROG}"' [a-z]*: use '\''cvs commit'\'' to add this file permanently' +'"${PROG}"' [a-z]*: use .'"${PROG}"' commit. to add this file permanently' dotest death2-13 "${testcvs} -q commit -m add" \ "RCS file: ${TESTDIR}/cvsroot/first-dir/file2,v done @@ -2462,7 +2688,7 @@ ${PROG} [a-z]*: file2 is no longer in the repository" echo "branch revision" > file2 dotest death2-15 "${testcvs} add file2" \ "${PROG}"' [a-z]*: scheduling file `file2'\'' for addition on branch `branch'\'' -'"${PROG}"' [a-z]*: use '\''cvs commit'\'' to add this file permanently' +'"${PROG}"' [a-z]*: use .'"${PROG}"' commit. to add this file permanently' dotest death2-16 "${testcvs} -q commit -m add" \ "Checking in file2; ${TESTDIR}/cvsroot/first-dir/file2,v <-- file2 @@ -2473,7 +2699,7 @@ done" echo "first revision" > file3 dotest death2-17 "${testcvs} add file3" \ "${PROG}"' [a-z]*: scheduling file `file3'\'' for addition on branch `branch'\'' -'"${PROG}"' [a-z]*: use '\''cvs commit'\'' to add this file permanently' +'"${PROG}"' [a-z]*: use .'"${PROG}"' commit. to add this file permanently' dotest death2-18 "${testcvs} -q commit -m add" \ "RCS file: ${TESTDIR}/cvsroot/first-dir/Attic/file3,v done @@ -2594,7 +2820,8 @@ ${PLUS} first revision" '"${PROG}"' [a-z]*: scheduling file `file2'\'' for addition '"${PROG}"' [a-z]*: scheduling file `file3'\'' for addition '"${PROG}"' [a-z]*: scheduling file `file4'\'' for addition -'"${PROG}"' [a-z]*: use '\''cvs commit'\'' to add these files permanently' +'"${PROG}"' [a-z]*: use .'"${PROG}"' commit. to add these files permanently' + dotest branches-2a "${testcvs} -n -q ci -m dont-commit" "" dotest_lit branches-3 "${testcvs} -q ci -m add-it" <<HERE RCS file: ${TESTDIR}/cvsroot/first-dir/file1,v done @@ -2627,6 +2854,13 @@ HERE ${TESTDIR}/cvsroot/first-dir/file4,v <-- file4 new revision: 1\.2; previous revision: 1\.1 done" + # The "cvs log file4" in test branches-14.3 will test that we + # didn't really add the tag. + dotest branches-3.3 "${testcvs} -qn tag dont-tag" \ +"T file1 +T file2 +T file3 +T file4" dotest branches-4 "${testcvs} tag -b br1" "${PROG}"' [a-z]*: Tagging \. T file1 T file2 @@ -2713,29 +2947,29 @@ total revisions: 6; selected revisions: 6 description: ---------------------------- revision 1\.3 -date: [0-9/: ]*; author: [a-z0-9@][a-z0-9@]*; state: Exp; lines: ${PLUS}1 -1 +date: [0-9/: ]*; author: ${username}; state: Exp; lines: ${PLUS}1 -1 trunk-change-after-branch ---------------------------- revision 1\.2 -date: [0-9/: ]*; author: [a-z0-9@][a-z0-9@]*; state: Exp; lines: ${PLUS}1 -1 +date: [0-9/: ]*; author: ${username}; state: Exp; lines: ${PLUS}1 -1 branches: 1\.2\.2; trunk-before-branch ---------------------------- revision 1\.1 -date: [0-9/: ]*; author: [a-z0-9@][a-z0-9@]*; state: Exp; +date: [0-9/: ]*; author: ${username}; state: Exp; add-it ---------------------------- revision 1\.2\.2\.2 -date: [0-9/: ]*; author: [a-z0-9@][a-z0-9@]*; state: Exp; lines: ${PLUS}1 -1 +date: [0-9/: ]*; author: ${username}; state: Exp; lines: ${PLUS}1 -1 change-on-br1 ---------------------------- revision 1\.2\.2\.1 -date: [0-9/: ]*; author: [a-z0-9@][a-z0-9@]*; state: Exp; lines: ${PLUS}1 -1 +date: [0-9/: ]*; author: ${username}; state: Exp; lines: ${PLUS}1 -1 branches: 1\.2\.2\.1\.2; modify ---------------------------- revision 1\.2\.2\.1\.2\.1 -date: [0-9/: ]*; author: [a-z0-9@][a-z0-9@]*; state: Exp; lines: ${PLUS}1 -1 +date: [0-9/: ]*; author: ${username}; state: Exp; lines: ${PLUS}1 -1 modify =============================================================================" dotest_status branches-14.4 1 \ @@ -2780,6 +3014,232 @@ rcsmerge: warning: conflicts during merge" ======= 1:brbr [>]>>>>>> 1\.1\.2\.1\.2\.1' + + dotest branches-o1 "${testcvs} -q admin -o ::brbr" \ +"RCS file: ${TESTDIR}/cvsroot/first-dir/file1,v +done +RCS file: ${TESTDIR}/cvsroot/first-dir/file2,v +done +RCS file: ${TESTDIR}/cvsroot/first-dir/file3,v +done +RCS file: ${TESTDIR}/cvsroot/first-dir/file4,v +done" + cd .. + + if test "$keep" = yes; then + echo Keeping ${TESTDIR} and exiting due to --keep + exit 0 + fi + + rm -rf ${CVSROOT_DIRNAME}/first-dir + rm -r first-dir + ;; + + rcslib) + # Test librarification of RCS. + # First: test whether `cvs diff' handles $Name expansion + # correctly. We diff two revisions with their symbolic tags; + # neither tag should be expanded in the output. Also diff + # one revision with the working copy. + + mkdir ${CVSROOT_DIRNAME}/first-dir + dotest rcsdiff-1 "${testcvs} -q co first-dir" '' + cd first-dir + echo "I am the first foo, and my name is $""Name$." > foo.c + dotest rcsdiff-2 "${testcvs} add -m new-file foo.c" \ +"${PROG} [a-z]*: scheduling file .foo\.c. for addition +${PROG} [a-z]*: use .${PROG} commit. to add this file permanently" + dotest rcsdiff-3 "${testcvs} commit -m rev1 foo.c" \ +"RCS file: ${TESTDIR}/cvsroot/first-dir/foo\.c,v +done +Checking in foo\.c; +${TESTDIR}/cvsroot/first-dir/foo.c,v <-- foo\.c +initial revision: 1\.1 +done" + dotest rcsdiff-4 "${testcvs} tag first foo.c" "T foo\.c" + dotest rcsdiff-5 "${testcvs} update -p -r first foo.c" \ +"=================================================================== +Checking out foo\.c +RCS: ${TESTDIR}/cvsroot/first-dir/foo\.c,v +VERS: 1\.1 +\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* +I am the first foo, and my name is \$""Name: first \$\." + + echo "I am the second foo, and my name is $""Name$." > foo.c + dotest rcsdiff-6 "${testcvs} commit -m rev2 foo.c" \ +"Checking in foo\.c; +${TESTDIR}/cvsroot/first-dir/foo\.c,v <-- foo\.c +new revision: 1\.2; previous revision: 1\.1 +done" + dotest rcsdiff-7 "${testcvs} tag second foo.c" "T foo\.c" + dotest rcsdiff-8 "${testcvs} update -p -r second foo.c" \ +"=================================================================== +Checking out foo\.c +RCS: ${TESTDIR}/cvsroot/first-dir/foo\.c,v +VERS: 1\.2 +\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* +I am the second foo, and my name is \$""Name: second \$\." + + dotest_fail rcsdiff-9 "${testcvs} diff -r first -r second" \ +"${PROG} [a-z]*: Diffing \. +Index: foo\.c +=================================================================== +RCS file: ${TESTDIR}/cvsroot/first-dir/foo\.c,v +retrieving revision 1\.1 +retrieving revision 1\.2 +diff -r1\.1 -r1\.2 +1c1 +< I am the first foo, and my name is \$""Name: \$\. +--- +> I am the second foo, and my name is \$""Name: \$\." + + echo "I am the once and future foo, and my name is $""Name$." > foo.c + dotest_fail rcsdiff-10 "${testcvs} diff -r first" \ +"${PROG} [a-z]*: Diffing \. +Index: foo\.c +=================================================================== +RCS file: ${TESTDIR}/cvsroot/first-dir/foo\.c,v +retrieving revision 1\.1 +diff -r1\.1 foo\.c +1c1 +< I am the first foo, and my name is \$""Name: \$\. +--- +> I am the once and future foo, and my name is \$""Name\$\." + + # Test handling of libdiff options. diff gets quite enough + # of a workout elsewhere in sanity.sh, so we assume that it's + # mostly working properly if it passes all the other tests. + # The main one we want to try is regex handling, since we are + # using CVS's regex matcher and not diff's. + + cat >rgx.c <<EOF +test_regex (whiz, bang) +{ +foo; +bar; +baz; +grumble; +} +EOF + + dotest rcslib-diffrgx-1 "${testcvs} -q add -m '' rgx.c" \ +"${PROG} [a-z]*: use .${PROG} commit. to add this file permanently" + dotest rcslib-diffrgx-2 "${testcvs} -q ci -m '' rgx.c" \ +"RCS file: ${TESTDIR}/cvsroot/first-dir/rgx\.c,v +done +Checking in rgx\.c; +${TESTDIR}/cvsroot/first-dir/rgx\.c,v <-- rgx\.c +initial revision: 1\.1 +done" + cat >rgx.c <<EOF +test_regex (whiz, bang) +{ +foo; +bar; +baz; +mumble; +} +EOF + # Use dotest_fail because exit status from `cvs diff' must be 1. + dotest_fail rcslib-diffrgx-3 "${testcvs} diff -c -F.*( rgx.c" \ +"Index: rgx\.c +=================================================================== +RCS file: ${TESTDIR}/cvsroot/first-dir/rgx\.c,v +retrieving revision 1\.1 +diff -c -F\.\*( -r1\.1 rgx\.c +\*\*\* rgx\.c [0-9/]* [0-9:]* 1\.1 +--- rgx\.c [0-9/]* [0-9:]* +\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* test_regex (whiz, bang) +\*\*\* 3,7 \*\*\*\* + foo; + bar; + baz; +! grumble; + } +--- 3,7 ---- + foo; + bar; + baz; +! mumble; + }" + + # Tests of rcsmerge/diff3. Merge operations get a good general + # workout elsewhere; we want to make sure that options are still + # handled properly. Try merging two branches with -kv, to test + # both -j and -k switches. + + cd .. + + rm -rf ${CVSROOT_DIRNAME}/first-dir + rm -r first-dir + + mkdir 1; cd 1 + dotest rcslib-merge-1 "${testcvs} -q co -l ." "" + mkdir first-dir + dotest rcslib-merge-2 "${testcvs} -q add first-dir" \ +"Directory ${TESTDIR}/cvsroot.*/first-dir added to the repository" + cd ..; rm -r 1 + + dotest rcslib-merge-3 "${testcvs} -q co first-dir" "" + cd first-dir + + echo '$''Revision$' > file1 + echo '2' >> file1 + echo '3' >> file1 + dotest rcslib-merge-4 "${testcvs} -q add file1" \ +"${PROG} [a-z]*: use .${PROG} commit. to add this file permanently" + dotest rcslib-merge-5 "${testcvs} -q commit -m '' file1" \ +"RCS file: ${TESTDIR}/cvsroot/first-dir/file1,v +done +Checking in file1; +${TESTDIR}/cvsroot/first-dir/file1,v <-- file1 +initial revision: 1\.1 +done" + sed -e 's/2/two/' file1 > f; mv f file1 + dotest rcslib-merge-6 "${testcvs} -q commit -m '' file1" \ +"Checking in file1; +${TESTDIR}/cvsroot/first-dir/file1,v <-- file1 +new revision: 1\.2; previous revision: 1\.1 +done" + dotest rcslib-merge-7 "${testcvs} -q tag -b -r 1.1 patch1" "T file1" + dotest rcslib-merge-8 "${testcvs} -q update -r patch1" "[UP] file1" + dotest rcslib-merge-9 "${testcvs} -q status" \ +"=================================================================== +File: file1 Status: Up-to-date + + Working revision: 1\.1.* + Repository revision: 1\.1 ${TESTDIR}/cvsroot/first-dir/file1,v + Sticky Tag: patch1 (branch: 1\.1\.2) + Sticky Date: (none) + Sticky Options: (none)" + dotest rcslib-merge-10 "cat file1" \ +'$''Revision: 1\.1 $ +2 +3' + sed -e 's/3/three/' file1 > f; mv f file1 + dotest rcslib-merge-11 "${testcvs} -q commit -m '' file1" \ +"Checking in file1; +${TESTDIR}/cvsroot/first-dir/file1,v <-- file1 +new revision: 1\.1\.2\.1; previous revision: 1\.1 +done" + dotest rcslib-merge-12 "${testcvs} -q update -kv -j1.2" \ +"U file1 +RCS file: ${TESTDIR}/cvsroot/first-dir/file1,v +retrieving revision 1\.1 +retrieving revision 1\.2 +Merging differences between 1\.1 and 1\.2 into file1 +rcsmerge: warning: conflicts during merge" + dotest rcslib-merge-13 "cat file1" \ +"<<<<<<< file1 +1\.1\.2\.1 +2 +three +[=]====== +1\.2 +two +3 +[>]>>>>>> 1\.2" + cd .. if test "$keep" = yes; then @@ -2800,7 +3260,7 @@ rcsmerge: warning: conflicts during merge" echo 1:trunk-1 >file1 dotest multibranch-2 "${testcvs} add file1" \ "${PROG}"' [a-z]*: scheduling file `file1'\'' for addition -'"${PROG}"' [a-z]*: use '\''cvs commit'\'' to add this file permanently' +'"${PROG}"' [a-z]*: use .'"${PROG}"' commit. to add this file permanently' dotest_lit multibranch-3 "${testcvs} -q ci -m add-it" <<HERE RCS file: ${TESTDIR}/cvsroot/first-dir/file1,v done @@ -2875,6 +3335,19 @@ modify-on-br1 ;; import) # test death after import + # Tests of "cvs import": + # basic2 + # rdiff -- imports with keywords + # import -- more tests of imports with keywords + # importb -- -b option. + # modules3 + # mflag -- various -m messages + # ignore -- import and cvsignore + # binwrap -- import and -k wrappers + # info -- imports which are rejected by verifymsg + # head -- intended to test vendor branches and HEAD, + # although it doesn't really do it yet. + # import mkdir import-dir ; cd import-dir @@ -2891,9 +3364,9 @@ modify-on-br1 cp imported-f2 ../imported-f2-orig.tmp if ${CVS} import -m first-import first-dir vendor-branch junk-1_0 ; then - echo "PASS: test 96" >>${LOGFILE} + pass 96 else - echo "FAIL: test 96" | tee -a ${LOGFILE} ; exit 1 + fail 96 fi if cmp ../imported-f2-orig.tmp imported-f2; then @@ -2905,31 +3378,31 @@ modify-on-br1 # co if ${CVS} co first-dir ; then - echo "PASS: test 97" >>${LOGFILE} + pass 97 else - echo "FAIL: test 97" | tee -a ${LOGFILE} ; exit 1 + fail 97 fi cd first-dir for i in 1 2 3 4 ; do if test -f imported-f"$i" ; then - echo "PASS: test 98-$i" >>${LOGFILE} + pass 98-$i else - echo "FAIL: test 98-$i" | tee -a ${LOGFILE} ; exit 1 + fail 98-$i fi done if test -d RCS; then - echo "FAIL: test 98.5" | tee -a ${LOGFILE} ; exit 1 + fail 98.5 else - echo "PASS: test 98.5" >>${LOGFILE} + pass 98.5 fi # remove rm imported-f1 if ${CVS} rm imported-f1 2>> ${LOGFILE}; then - echo "PASS: test 99" >>${LOGFILE} + pass 99 else - echo "FAIL: test 99" | tee -a ${LOGFILE} ; exit 1 + fail 99 fi # change @@ -2937,46 +3410,46 @@ modify-on-br1 # commit if ${CVS} ci -m local-changes >> ${LOGFILE} 2>&1; then - echo "PASS: test 100" >>${LOGFILE} + pass 100 else - echo "FAIL: test 100" | tee -a ${LOGFILE} ; exit 1 + fail 100 fi # log if ${CVS} log imported-f1 | grep '1.1.1.2 (dead)' ; then - echo "FAIL: test 101" | tee -a ${LOGFILE} ; exit 1 + fail 101 else - echo "PASS: test 101" >>${LOGFILE} + pass 101 fi # update into the vendor branch. if ${CVS} update -rvendor-branch ; then - echo "PASS: test 102" >>${LOGFILE} + pass 102 else - echo "FAIL: test 102" | tee -a ${LOGFILE} ; exit 1 + fail 102 fi # remove file4 on the vendor branch rm imported-f4 if ${CVS} rm imported-f4 2>> ${LOGFILE}; then - echo "PASS: test 103" >>${LOGFILE} + pass 103 else - echo "FAIL: test 103" | tee -a ${LOGFILE} ; exit 1 + fail 103 fi # commit if ${CVS} ci -m vendor-removed imported-f4 >>${LOGFILE}; then - echo "PASS: test 104" >>${LOGFILE} + pass 104 else - echo "FAIL: test 104" | tee -a ${LOGFILE} ; exit 1 + fail 104 fi # update to main line if ${CVS} update -A 2>> ${LOGFILE}; then - echo "PASS: test 105" >>${LOGFILE} + pass 105 else - echo "FAIL: test 105" | tee -a ${LOGFILE} ; exit 1 + fail 105 fi # second import - file4 deliberately unchanged @@ -2987,9 +3460,9 @@ modify-on-br1 cp imported-f2 ../imported-f2-orig.tmp if ${CVS} import -m second-import first-dir vendor-branch junk-2_0 ; then - echo "PASS: test 106" >>${LOGFILE} + pass 106 else - echo "FAIL: test 106" | tee -a ${LOGFILE} ; exit 1 + fail 106 fi if cmp ../imported-f2-orig.tmp imported-f2; then pass 106.5 @@ -3000,45 +3473,45 @@ modify-on-br1 # co if ${CVS} co first-dir ; then - echo "PASS: test 107" >>${LOGFILE} + pass 107 else - echo "FAIL: test 107" | tee -a ${LOGFILE} ; exit 1 + fail 107 fi cd first-dir if test -f imported-f1 ; then - echo "FAIL: test 108" | tee -a ${LOGFILE} ; exit 1 + fail 108 else - echo "PASS: test 108" >>${LOGFILE} + pass 108 fi for i in 2 3 ; do if test -f imported-f"$i" ; then - echo "PASS: test 109-$i" >>${LOGFILE} + pass 109-$i else - echo "FAIL: test 109-$i" | tee -a ${LOGFILE} ; exit 1 + fail 109-$i fi done # check vendor branch for file4 if ${CVS} update -rvendor-branch ; then - echo "PASS: test 110" >>${LOGFILE} + pass 110 else - echo "FAIL: test 110" | tee -a ${LOGFILE} ; exit 1 + fail 110 fi if test -f imported-f4 ; then - echo "PASS: test 111" >>${LOGFILE} + pass 111 else - echo "FAIL: test 111" | tee -a ${LOGFILE} ; exit 1 + fail 111 fi # update to main line if ${CVS} update -A 2>> ${LOGFILE}; then - echo "PASS: test 112" >>${LOGFILE} + pass 112 else - echo "FAIL: test 112" | tee -a ${LOGFILE} ; exit 1 + fail 112 fi cd .. @@ -3055,26 +3528,26 @@ rcsmerge: warning: conflicts during merge" cd first-dir if test -f imported-f1 ; then - echo "FAIL: test 114" | tee -a ${LOGFILE} ; exit 1 + fail 114 else - echo "PASS: test 114" >>${LOGFILE} + pass 114 fi for i in 2 3 ; do if test -f imported-f"$i" ; then - echo "PASS: test 115-$i" >>${LOGFILE} + pass 115-$i else - echo "FAIL: test 115-$i" | tee -a ${LOGFILE} ; exit 1 + fail 115-$i fi done dotest import-116 'cat imported-f2' \ 'imported file2 [<]<<<<<< imported-f2 -import should not expand \$''Id: imported-f2,v 1\.2 [0-9/]* [0-9:]* [a-z0-9@][a-z0-9@]* Exp \$ +import should not expand \$''Id: imported-f2,v 1\.2 [0-9/]* [0-9:]* '"${username}"' Exp \$ local-change [=]====== -import should not expand \$''Id: imported-f2,v 1\.1\.1\.2 [0-9/]* [0-9:]* [a-z0-9@][a-z0-9@]* Exp \$ +import should not expand \$''Id: imported-f2,v 1\.1\.1\.2 [0-9/]* [0-9:]* '"${username}"' Exp \$ rev 2 of file 2 [>]>>>>>> 1\.1\.1\.2' @@ -3084,9 +3557,128 @@ rev 2 of file 2 rm -r import-dir ;; + importb) + # More cvs import tests, especially -b option. + + # OK, first we get some sources from the NetMunger project, and + # import them into the 1.1.1 vendor branch. + mkdir imp-dir + cd imp-dir + echo 'OpenMunger sources' >file1 + echo 'OpenMunger sources' >file2 + dotest importb-1 \ +"${testcvs} import -m add first-dir openmunger openmunger-1_0" \ +"N first-dir/file1 +N first-dir/file2 + +No conflicts created by this import" + cd .. + rm -r imp-dir + + # Now we put the sources we get from FreeMunger into 1.1.3 + mkdir imp-dir + cd imp-dir + echo 'FreeMunger sources' >file1 + echo 'FreeMunger sources' >file2 + # Not completely sure how the conflict detection is supposed to + # be working here (haven't really thought about it). + dotest importb-2 \ +"${testcvs} import -m add -b 1.1.3 first-dir freemunger freemunger-1_0" \ +"C first-dir/file1 +C first-dir/file2 + +2 conflicts created by this import. +Use the following command to help the merge: + + ${PROG} checkout -jfreemunger:yesterday -jfreemunger first-dir" + cd .. + rm -r imp-dir + + # Now a test of main branch import (into second-dir, not first-dir). + mkdir imp-dir + cd imp-dir + echo 'my own stuff' >mine1.c + echo 'my own stuff' >mine2.c + dotest_fail importb-3 \ +"${testcvs} import -m add -b 1 second-dir dummy really_dumb_y" \ +"${PROG} \[[a-z]* aborted\]: Only branches with two dots are supported: 1" + : when we implement main-branch import, should be \ +"N second-dir/mine1\.c +N second-dir/mine2\.c + +No conflicts created by this import" + cd .. + rm -r imp-dir + + mkdir 1 + cd 1 + # when we implement main branch import, will want to + # add "second-dir" here. + dotest importb-4 "${testcvs} -q co first-dir" \ +"U first-dir/file1 +U first-dir/file2" + cd first-dir + dotest importb-5 "${testcvs} -q log file1" " +RCS file: ${TESTDIR}/cvsroot/first-dir/file1,v +Working file: file1 +head: 1\.1 +branch: 1\.1\.1 +locks: strict +access list: +symbolic names: + freemunger-1_0: 1\.1\.3\.1 + freemunger: 1\.1\.3 + openmunger-1_0: 1\.1\.1\.1 + openmunger: 1\.1\.1 +keyword substitution: kv +total revisions: 3; selected revisions: 3 +description: +---------------------------- +revision 1\.1 +date: [0-9/]* [0-9:]*; author: ${username}; state: Exp; +branches: 1\.1\.1; 1\.1\.3; +Initial revision +---------------------------- +revision 1\.1\.3\.1 +date: [0-9/]* [0-9:]*; author: ${username}; state: Exp; lines: ${PLUS}1 -1 +add +---------------------------- +revision 1\.1\.1\.1 +date: [0-9/]* [0-9:]*; author: ${username}; state: Exp; lines: ${PLUS}0 -0 +add +=============================================================================" + + cd ../.. + rm -r 1 + rm -rf ${CVSROOT_DIRNAME}/first-dir ${CVSROOT_DIRNAME}/second-dir + ;; + join) # Test doing joins which involve adding and removing files. + # Variety of scenarios (see list below), in the context of: + # * merge changes from T1 to T2 into the main line + # * merge changes from branch 'branch' into the main line + # * merge changes from branch 'branch' into branch 'br2'. # See also binfile2, which does similar things with binary files. + # See also join2, which tests joining (and update -A) on only + # a single file, rather than a directory. + # See also join3, which tests some cases involving the greatest + # common ancestor. Here is a list of tests according to branch + # topology: + # + # --->bp---->trunk too many to mention + # \----->branch + # + # /----->branch1 + # --->bp---->trunk multibranch + # \----->branch2 + # + # --->bp1----->bp2---->trunk join3 + # \->br1 \->br2 + # + # --->bp1----->trunk + # \----bp2---->branch branches + # \------>branch-of-branch # We check merging changes from T1 to T2 into the main line. # Here are the interesting cases I can think of: @@ -3147,7 +3739,7 @@ rev 2 of file 2 '"${PROG}"' [a-z]*: scheduling file `file4'\'' for addition '"${PROG}"' [a-z]*: scheduling file `file6'\'' for addition '"${PROG}"' [a-z]*: scheduling file `file8'\'' for addition -'"${PROG}"' [a-z]*: use '\''cvs commit'\'' to add these files permanently' +'"${PROG}"' [a-z]*: use .'"${PROG}"' commit. to add these files permanently' dotest join-3 "${testcvs} -q commit -m add" \ "RCS file: ${TESTDIR}/cvsroot/first-dir/file3,v @@ -3190,11 +3782,11 @@ T file8' dotest join-5 "${testcvs} add file2 file7" \ "${PROG}"' [a-z]*: scheduling file `file2'\'' for addition '"${PROG}"' [a-z]*: scheduling file `file7'\'' for addition -'"${PROG}"' [a-z]*: use '\''cvs commit'\'' to add these files permanently' +'"${PROG}"' [a-z]*: use .'"${PROG}"' commit. to add these files permanently' dotest join-6 "${testcvs} rm file6 file8" \ "${PROG}"' [a-z]*: scheduling `file6'\'' for removal '"${PROG}"' [a-z]*: scheduling `file8'\'' for removal -'"${PROG}"' [a-z]*: use '\'"${PROG} commit"\'' to remove these files permanently' +'"${PROG}"' [a-z]*: use .'"${PROG}"' commit. to remove these files permanently' dotest join-7 "${testcvs} -q ci -mx ." \ "RCS file: ${TESTDIR}/cvsroot/first-dir/file2,v done @@ -3241,7 +3833,7 @@ U first-dir/file8' echo 'first branch revision of file5' > file5 dotest join-9 "${testcvs} add file5" \ "${PROG}"' [a-z]*: scheduling file `file5'\'' for addition on branch `branch'\'' -'"${PROG}"' [a-z]*: use '\''cvs commit'\'' to add this file permanently' +'"${PROG}"' [a-z]*: use .'"${PROG}"' commit. to add this file permanently' dotest join-10 "${testcvs} -q ci -mx ." \ "Checking in file3; ${TESTDIR}/cvsroot/first-dir/file3,v <-- file3 @@ -3277,13 +3869,13 @@ T file8' dotest join-12 "${testcvs} add file1 file2" \ "${PROG}"' [a-z]*: scheduling file `file1'\'' for addition on branch `branch'\'' '"${PROG}"' [a-z]*: scheduling file `file2'\'' for addition on branch `branch'\'' -'"${PROG}"' [a-z]*: use '\''cvs commit'\'' to add these files permanently' +'"${PROG}"' [a-z]*: use .'"${PROG}"' commit. to add these files permanently' dotest join-13 "${testcvs} rm file3 file4 file5 file6" \ "${PROG}"' [a-z]*: scheduling `file3'\'' for removal '"${PROG}"' [a-z]*: scheduling `file4'\'' for removal '"${PROG}"' [a-z]*: scheduling `file5'\'' for removal '"${PROG}"' [a-z]*: scheduling `file6'\'' for removal -'"${PROG}"' [a-z]*: use '\'"${PROG} commit"\'' to remove these files permanently' +'"${PROG}"' [a-z]*: use .'"${PROG}"' commit. to remove these files permanently' dotest join-14 "${testcvs} -q ci -mx ." \ "RCS file: ${TESTDIR}/cvsroot/first-dir/Attic/file1,v done @@ -3421,59 +4013,323 @@ M file2 R file3 M file4' + cd .. + + # Checkout the main line again and make a new branch which we + # merge to. + rm -r first-dir + dotest join-25 "${testcvs} -q co first-dir" \ +'U first-dir/file2 +U first-dir/file3 +U first-dir/file4 +U first-dir/file7' + cd first-dir + dotest join-26 "${testcvs} -q tag -b br2" \ +"T file2 +T file3 +T file4 +T file7" + dotest join-27 "${testcvs} -q update -r br2" "" + # The handling of file8 here looks fishy to me. I don't see + # why it should be different from the case where we merge to + # the trunk (e.g. join-23). + dotest join-28 "${testcvs} -q update -j branch" \ +"U file1 +RCS file: ${TESTDIR}/cvsroot/first-dir/file2,v +retrieving revision 1.1 +retrieving revision 1.1.2.1 +Merging differences between 1.1 and 1.1.2.1 into file2 +${PROG} [a-z]*: scheduling file3 for removal +${PROG} [a-z]*: file file4 has been modified, but has been removed in revision branch +U file8" + # Verify that the right changes have been scheduled. + dotest join-29 "${testcvs} -q update" \ +"A file1 +M file2 +R file3 +A file8" + cd ../.. + rm -r 1 2 3 rm -rf ${CVSROOT_DIRNAME}/first-dir ;; + join2) + # More joining tests. + + # First the usual setup; create a directory first-dir, a file + # first-dir/file1, and a branch br1. + mkdir 1; cd 1 + dotest join2-1 "${testcvs} -q co -l ." '' + mkdir first-dir + dotest join2-2 "${testcvs} add first-dir" \ +"Directory ${TESTDIR}/cvsroot/first-dir added to the repository" + cd first-dir + echo 'initial contents of file1' >file1 + dotest join2-3 "${testcvs} add file1" \ +"${PROG} [a-z]*: scheduling file .file1. for addition +${PROG} [a-z]*: use .${PROG} commit. to add this file permanently" + dotest join2-4 "${testcvs} -q ci -m add" \ +"RCS file: ${TESTDIR}/cvsroot/first-dir/file1,v +done +Checking in file1; +${TESTDIR}/cvsroot/first-dir/file1,v <-- file1 +initial revision: 1\.1 +done" + dotest join2-5 "${testcvs} -q tag -b br1" "T file1" + dotest join2-6 "${testcvs} -q update -r br1" "" + echo 'modify on branch' >>file1 + touch bradd + dotest join2-6a "${testcvs} add bradd" \ +"${PROG} [a-z]*: scheduling file .bradd. for addition on branch .br1. +${PROG} [a-z]*: use .${PROG} commit. to add this file permanently" + dotest join2-7 "${testcvs} -q ci -m modify" \ +"RCS file: ${TESTDIR}/cvsroot/first-dir/Attic/bradd,v +done +Checking in bradd; +${TESTDIR}/cvsroot/first-dir/Attic/bradd,v <-- bradd +new revision: 1\.1\.2\.1; previous revision: 1\.1 +done +Checking in file1; +${TESTDIR}/cvsroot/first-dir/file1,v <-- file1 +new revision: 1\.1\.2\.1; previous revision: 1\.1 +done" + + # Here is the unusual/pathological part. We switch back to + # the trunk *for file1 only*, not for the whole directory. + dotest join2-8 "${testcvs} -q update -A file1" '[UP] file1' + dotest join2-9 "${testcvs} -q status file1" \ +"=================================================================== +File: file1 Status: Up-to-date + + Working revision: 1\.1.* + Repository revision: 1\.1 ${TESTDIR}/cvsroot/first-dir/file1,v + Sticky Tag: (none) + Sticky Date: (none) + Sticky Options: (none)" + dotest join2-10 "cat CVS/Tag" "Tbr1" + + dotest join2-11 "${testcvs} -q update -j br1 file1" \ +"RCS file: ${TESTDIR}/cvsroot/first-dir/file1,v +retrieving revision 1\.1 +retrieving revision 1\.1\.2\.1 +Merging differences between 1\.1 and 1\.1\.2\.1 into file1" + dotest join2-12 "cat file1" "initial contents of file1 +modify on branch" + # We should have no sticky tag on file1 + dotest join2-13 "${testcvs} -q status file1" \ +"=================================================================== +File: file1 Status: Locally Modified + + Working revision: 1\.1.* + Repository revision: 1\.1 ${TESTDIR}/cvsroot/first-dir/file1,v + Sticky Tag: (none) + Sticky Date: (none) + Sticky Options: (none)" + dotest join2-14 "cat CVS/Tag" "Tbr1" + # And the checkin should go to the trunk + dotest join2-15 "${testcvs} -q ci -m modify file1" \ +"Checking in file1; +${TESTDIR}/cvsroot/first-dir/file1,v <-- file1 +new revision: 1\.2; previous revision: 1\.1 +done" + + # OK, the above is all well and good and has worked for some + # time. Now try the case where the file had been added on + # the branch. + dotest join2-16 "${testcvs} -q update -r br1" "[UP] file1" + # The workaround is to update the whole directory. + # The non-circumvented version won't work. The reason is that + # update removes the entry from CVS/Entries, so of course we get + # the tag from CVS/Tag and not Entries. I suppose maybe + # we could invent some new format in Entries which would handle + # this, but doing so, and handling it properly throughout + # CVS, would be a lot of work and I'm not sure this case justifies + # it. + dotest join2-17-circumvent "${testcvs} -q update -A" \ +"${PROG} [a-z]*: warning: bradd is not (any longer) pertinent +[UP] file1" +: dotest join2-17 "${testcvs} -q update -A bradd" \ +"${PROG} [a-z]*: warning: bradd is not (any longer) pertinent" + dotest join2-18 "${testcvs} -q update -j br1 bradd" "U bradd" + dotest join2-19 "${testcvs} -q status bradd" \ +"=================================================================== +File: bradd Status: Locally Added + + Working revision: New file! + Repository revision: 1\.1 ${TESTDIR}/cvsroot/first-dir/Attic/bradd,v + Sticky Tag: (none) + Sticky Date: (none) + Sticky Options: (none)" + dotest join2-20 "${testcvs} -q ci -m modify bradd" \ +"Checking in bradd; +${TESTDIR}/cvsroot/first-dir/bradd,v <-- bradd +new revision: 1\.2; previous revision: 1\.1 +done" + + cd ../.. + rm -r 1 + rm -rf ${CVSROOT_DIRNAME}/first-dir + ;; + + join3) + # See "join" for a list of other joining/branching tests. + # First the usual setup; create a directory first-dir, a file + # first-dir/file1, and a branch br1. + mkdir 1; cd 1 + dotest join3-1 "${testcvs} -q co -l ." '' + mkdir first-dir + dotest join3-2 "${testcvs} add first-dir" \ +"Directory ${TESTDIR}/cvsroot/first-dir added to the repository" + cd first-dir + echo 'initial contents of file1' >file1 + dotest join3-3 "${testcvs} add file1" \ +"${PROG} [a-z]*: scheduling file .file1. for addition +${PROG} [a-z]*: use .${PROG} commit. to add this file permanently" + dotest join3-4 "${testcvs} -q ci -m add" \ +"RCS file: ${TESTDIR}/cvsroot/first-dir/file1,v +done +Checking in file1; +${TESTDIR}/cvsroot/first-dir/file1,v <-- file1 +initial revision: 1\.1 +done" + dotest join3-5 "${testcvs} -q tag -b br1" "T file1" + dotest join3-6 "${testcvs} -q update -r br1" "" + echo 'br1:line1' >>file1 + dotest join3-7 "${testcvs} -q ci -m modify" \ +"Checking in file1; +${TESTDIR}/cvsroot/first-dir/file1,v <-- file1 +new revision: 1\.1\.2\.1; previous revision: 1\.1 +done" + + # Now back to the trunk for: + # another revision and another branch for file1. + # add file2, which will exist on trunk and br2 but not br1. + dotest join3-8 "${testcvs} -q update -A" "[UP] file1" + echo 'trunk:line1' > file2 + dotest join3-8a "${testcvs} add file2" \ +"${PROG} [a-z]*: scheduling file .file2. for addition +${PROG} [a-z]*: use .${PROG} commit. to add this file permanently" + echo 'trunk:line1' >>file1 + dotest join3-9 "${testcvs} -q ci -m modify" \ +"Checking in file1; +${TESTDIR}/cvsroot/first-dir/file1,v <-- file1 +new revision: 1\.2; previous revision: 1\.1 +done +RCS file: ${TESTDIR}/cvsroot/first-dir/file2,v +done +Checking in file2; +${TESTDIR}/cvsroot/first-dir/file2,v <-- file2 +initial revision: 1\.1 +done" + dotest join3-10 "${testcvs} -q tag -b br2" "T file1 +T file2" + + # Before we actually have any revision on br2, let's try a join + dotest join3-11 "${testcvs} -q update -r br1" "[UP] file1 +${PROG} [a-z]*: file2 is no longer in the repository" + dotest join3-12 "${testcvs} -q update -j br2" \ +"RCS file: ${TESTDIR}/cvsroot/first-dir/file1,v +retrieving revision 1\.1 +retrieving revision 1\.2 +Merging differences between 1\.1 and 1\.2 into file1 +rcsmerge: warning: conflicts during merge +U file2" + dotest join3-13 "cat file1" \ +"initial contents of file1 +[<]<<<<<< file1 +br1:line1 +[=]====== +trunk:line1 +[>]>>>>>> 1\.2" + rm file1 + + # OK, we'll try the same thing with a revision on br2. + dotest join3-14 "${testcvs} -q update -r br2 file1" \ +"${PROG} [a-z]*: warning: file1 was lost +U file1" "U file1" + echo 'br2:line1' >>file1 + dotest join3-15 "${testcvs} -q ci -m modify file1" \ +"Checking in file1; +${TESTDIR}/cvsroot/first-dir/file1,v <-- file1 +new revision: 1\.2\.2\.1; previous revision: 1\.2 +done" + + # OK, now we can join br2 to br1 + dotest join3-16 "${testcvs} -q update -r br1 file1" "[UP] file1" + # It may seem odd, to merge a higher branch into a lower + # branch, but in fact CVS defines the ancestor as 1.1 + # and so it merges both the 1.1->1.2 and 1.2->1.2.2.1 changes. + # This seems like a reasonably plausible behavior. + dotest join3-17 "${testcvs} -q update -j br2 file1" \ +"RCS file: ${TESTDIR}/cvsroot/first-dir/file1,v +retrieving revision 1\.1 +retrieving revision 1\.2\.2\.1 +Merging differences between 1\.1 and 1\.2\.2\.1 into file1 +rcsmerge: warning: conflicts during merge" + dotest join3-18 "cat file1" \ +"initial contents of file1 +[<]<<<<<< file1 +br1:line1 +[=]====== +trunk:line1 +br2:line1 +[>]>>>>>> 1\.2\.2\.1" + + cd ../.. + rm -r 1 + rm -rf ${CVSROOT_DIRNAME}/first-dir + ;; + new) # look for stray "no longer pertinent" messages. mkdir ${CVSROOT_DIRNAME}/first-dir if ${CVS} co first-dir ; then - echo "PASS: test 117" >>${LOGFILE} + pass 117 else - echo "FAIL: test 117" | tee -a ${LOGFILE} ; exit 1 + fail 117 fi cd first-dir touch a if ${CVS} add a 2>>${LOGFILE}; then - echo "PASS: test 118" >>${LOGFILE} + pass 118 else - echo "FAIL: test 118" | tee -a ${LOGFILE} ; exit 1 + fail 118 fi if ${CVS} ci -m added >>${LOGFILE} 2>&1; then - echo "PASS: test 119" >>${LOGFILE} + pass 119 else - echo "FAIL: test 119" | tee -a ${LOGFILE} ; exit 1 + fail 119 fi rm a if ${CVS} rm a 2>>${LOGFILE}; then - echo "PASS: test 120" >>${LOGFILE} + pass 120 else - echo "FAIL: test 120" | tee -a ${LOGFILE} ; exit 1 + fail 120 fi if ${CVS} ci -m removed >>${LOGFILE} ; then - echo "PASS: test 121" >>${LOGFILE} + pass 121 else - echo "FAIL: test 121" | tee -a ${LOGFILE} ; exit 1 + fail 121 fi if ${CVS} update -A 2>&1 | grep longer ; then - echo "FAIL: test 122" | tee -a ${LOGFILE} ; exit 1 + fail 122 else - echo "PASS: test 122" >>${LOGFILE} + pass 122 fi if ${CVS} update -rHEAD 2>&1 | grep longer ; then - echo "FAIL: test 123" | tee -a ${LOGFILE} ; exit 1 + fail 123 else - echo "PASS: test 123" >>${LOGFILE} + pass 123 fi cd .. @@ -3495,7 +4351,7 @@ M file4' touch a dotest newb-123b "${testcvs} add a" \ "${PROG} [a-z]*: scheduling file .a. for addition -${PROG} [a-z]*: use .cvs commit. to add this file permanently" +${PROG} [a-z]*: use .${PROG} commit. to add this file permanently" dotest newb-123c "${testcvs} -q ci -m added" \ "RCS file: ${TESTDIR}/cvsroot/first-dir/a,v done @@ -3548,7 +4404,15 @@ done" # --disable-server. dotest newb-123j0 "${testcvs} status a" \ "=================================================================== -File: a Status: Needs \(Patch\|Checkout\) +File: a Status: Needs Patch + + Working revision: 1\.1.* + Repository revision: 1\.1\.2\.1 ${TESTDIR}/cvsroot/first-dir/a,v + Sticky Tag: branch (branch: 1\.1\.2) + Sticky Date: (none) + Sticky Options: (none)" \ +"=================================================================== +File: a Status: Needs Checkout Working revision: 1\.1.* Repository revision: 1\.1\.2\.1 ${TESTDIR}/cvsroot/first-dir/a,v @@ -3582,7 +4446,7 @@ File: a Status: Needs \(Patch\|Checkout\) dotest conflicts-125 "${testcvs} add a" \ "${PROG} [a-z]*: scheduling file .a. for addition -${PROG} [a-z]*: use .cvs commit. to add this file permanently" +${PROG} [a-z]*: use .${PROG} commit. to add this file permanently" dotest conflicts-126 "${testcvs} -q ci -m added" \ "RCS file: ${TESTDIR}/cvsroot/first-dir/a,v done @@ -3605,15 +4469,15 @@ RCS: ${TMPPWD}/cvsroot/first-dir/a,v VERS: 1\.1 \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*" if ${CVS} co first-dir ; then - echo 'PASS: test 127' >>${LOGFILE} + pass 127 else - echo 'FAIL: test 127' | tee -a ${LOGFILE} + fail 127 fi cd first-dir if test -f a; then - echo 'PASS: test 127a' >>${LOGFILE} + pass 127a else - echo 'FAIL: test 127a' | tee -a ${LOGFILE} + fail 127a fi cd ../../1/first-dir @@ -3708,31 +4572,36 @@ File: a Status: File had conflicts on merge Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none)" - dotest_fail conflicts-132 "${testcvs} -q ci -m try" \ -"${PROG} [a-z]*: file .a. still contains conflict indicators -${PROG} \[[a-z]* aborted\]: correct above errors first!" + dotest conflicts-132 "${testcvs} -q ci -m try" \ +"${PROG} [a-z]*: warning: file .a. seems to still contain conflict indicators +Checking in a; +${TESTDIR}/cvsroot/first-dir/a,v <-- a +new revision: 1\.3; previous revision: 1\.2 +done" + # OK, the user saw the warning (good user), and now + # resolves it for real. echo resolve conflict >a dotest conflicts-status-3 "${testcvs} status a" \ "=================================================================== -File: a Status: File had conflicts on merge +File: a Status: Locally Modified - Working revision: 1\.2.* - Repository revision: 1\.2 ${TESTDIR}/cvsroot/first-dir/a,v + Working revision: 1\.3.* + Repository revision: 1\.3 ${TESTDIR}/cvsroot/first-dir/a,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none)" dotest conflicts-133 "${testcvs} -q ci -m resolved" \ "Checking in a; ${TESTDIR}/cvsroot/first-dir/a,v <-- a -new revision: 1\.3; previous revision: 1\.2 +new revision: 1\.4; previous revision: 1\.3 done" dotest conflicts-status-4 "${testcvs} status a" \ "=================================================================== File: a Status: Up-to-date - Working revision: 1\.3.* - Repository revision: 1\.3 ${TESTDIR}/cvsroot/first-dir/a,v + Working revision: 1\.4.* + Repository revision: 1\.4 ${TESTDIR}/cvsroot/first-dir/a,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none)" @@ -3742,14 +4611,14 @@ File: a Status: Up-to-date cd ../../1/first-dir echo abc >abc if ${testcvs} add abc >>${LOGFILE} 2>&1; then - echo 'PASS: test 134' >>${LOGFILE} + pass 134 else - echo 'FAIL: test 134' | tee -a ${LOGFILE} + fail 134 fi if ${testcvs} ci -m 'add abc' abc >>${LOGFILE} 2>&1; then - echo 'PASS: test 135' >>${LOGFILE} + pass 135 else - echo 'FAIL: test 135' | tee -a ${LOGFILE} + fail 135 fi cd ../../2 mkdir first-dir/dir1 first-dir/sdir @@ -3769,41 +4638,41 @@ File: a Status: Up-to-date cd ../1/first-dir mkdir subdir if ${testcvs} add subdir >>${LOGFILE}; then - echo 'PASS: test 138' >>${LOGFILE} + pass 138 else - echo 'FAIL: test 138' | tee -a ${LOGFILE} + fail 138 fi cd ../.. mkdir 3 cd 3 if ${testcvs} -q co first-dir/abc first-dir/subdir \ >>${LOGFILE}; then - echo 'PASS: test 139' >>${LOGFILE} + pass 139 else - echo 'FAIL: test 139' | tee -a ${LOGFILE} + fail 139 fi cd ../1/first-dir/subdir echo sss >sss if ${testcvs} add sss >>${LOGFILE} 2>&1; then - echo 'PASS: test 140' >>${LOGFILE} + pass 140 else - echo 'FAIL: test 140' | tee -a ${LOGFILE} + fail 140 fi if ${testcvs} ci -m adding sss >>${LOGFILE} 2>&1; then - echo 'PASS: test 140' >>${LOGFILE} + pass 140 else - echo 'FAIL: test 140' | tee -a ${LOGFILE} + fail 140 fi cd ../../../3/first-dir if ${testcvs} -q update >>${LOGFILE}; then - echo 'PASS: test 141' >>${LOGFILE} + pass 141 else - echo 'FAIL: test 141' | tee -a ${LOGFILE} + fail 141 fi if test -f subdir/sss; then - echo 'PASS: test 142' >>${LOGFILE} + pass 142 else - echo 'FAIL: test 142' | tee -a ${LOGFILE} + fail 142 fi cd ../.. rm -r 1 2 3 ; rm -rf ${CVSROOT_DIRNAME}/first-dir @@ -3825,7 +4694,7 @@ File: a Status: Up-to-date dotest conflicts2-142a2 "${testcvs} add a abc" \ "${PROG} [a-z]*: scheduling file .a. for addition ${PROG} [a-z]*: scheduling file .abc. for addition -${PROG} [a-z]*: use .cvs commit. to add these files permanently" +${PROG} [a-z]*: use .${PROG} commit. to add these files permanently" dotest conflicts2-142a3 "${testcvs} -q ci -m added" \ "RCS file: ${TESTDIR}/cvsroot/first-dir/a,v done @@ -3899,48 +4768,301 @@ ${PROG} [a-z]*: use .${PROG} commit. to remove this file permanently" # party has a file of the same name, cvs notices cd 1/first-dir touch aa.c - dotest conflicts2-142d0 "${testcvs} add aa.c" \ + echo 'contents unchanged' >same.c + dotest conflicts2-142d0 "${testcvs} add aa.c same.c" \ "${PROG} [a-z]*: scheduling file .aa\.c. for addition -${PROG} [a-z]*: use .cvs commit. to add this file permanently" +${PROG} [a-z]*: scheduling file .same\.c. for addition +${PROG} [a-z]*: use .${PROG} commit. to add these files permanently" dotest conflicts2-142d1 "${testcvs} -q ci -m added" \ -"RCS file: ${TESTDIR}/cvsroot/first-dir/aa.c,v +"RCS file: ${TESTDIR}/cvsroot/first-dir/aa\.c,v done -Checking in aa.c; -${TESTDIR}/cvsroot/first-dir/aa.c,v <-- aa.c +Checking in aa\.c; +${TESTDIR}/cvsroot/first-dir/aa\.c,v <-- aa\.c +initial revision: 1\.1 +done +RCS file: ${TESTDIR}/cvsroot/first-dir/same\.c,v +done +Checking in same\.c; +${TESTDIR}/cvsroot/first-dir/same\.c,v <-- same\.c initial revision: 1\.1 done" cd ../../2/first-dir echo "don't you dare obliterate this text" >aa.c - # Doing this test separately for remote and local is a fair - # bit of a kludge, but the exit status differs. I'm not sure - # which exit status is the more appropriate one. + echo 'contents unchanged' >same.c + # Note the discrepancy between local and remote in the handling + # of same.c. I kind + # of suspect that the local CVS behavior is the more useful one + # although I do sort of wonder whether we should make people run + # cvs add just to get them in that habit (also, trying to implement + # the local CVS behavior for remote without the cvs add seems + # pretty difficult). if test "$remote" = yes; then - dotest conflicts2-142d2 "${testcvs} -q update" \ + dotest_fail conflicts2-142d2 "${testcvs} -q update" \ "${QUESTION} aa\.c -U aa\.c -${PROG} update: move away \./aa\.c; it is in the way" +${QUESTION} same\.c +${PROG} update: move away \./aa\.c; it is in the way +C aa\.c +${PROG} update: move away \./same\.c; it is in the way +C same\.c" else dotest_fail conflicts2-142d2 "${testcvs} -q update" \ "${PROG} [a-z]*: move away aa\.c; it is in the way -C aa\.c" +C aa\.c +U same\.c" fi + dotest conflicts2-142d3 "${testcvs} -q status aa.c" \ +"${PROG} [a-z]*: move away aa\.c; it is in the way +=================================================================== +File: aa\.c Status: Unresolved Conflict + + Working revision: No entry for aa\.c + Repository revision: 1\.1 ${TESTDIR}/cvsroot/first-dir/aa\.c,v" + + # Could also be testing the case in which the cvs add happened + # before the commit by the other user. + # This message seems somewhat bogus. I mean, parallel development + # means that we get to work in parallel if we choose, right? And + # then at commit time it would be a conflict. + dotest_fail conflicts2-142d4 "${testcvs} -q add aa.c" \ +"${PROG} [a-z]*: aa.c added independently by second party" + + # The user might want to see just what the conflict is. + # Don't bother, diff seems to kind of lose its mind, with or + # without -N. This is a CVS bug(s). + #dotest conflicts2-142d5 "${testcvs} -q diff -r HEAD -N aa.c" fixme + + # Now: "how can the user resolve this conflict", I hear you cry. + # Well, one way is to forget about the file in the working + # directory. + # Since it didn't let us do the add in conflicts2-142d4, there + # is no need to run cvs rm here. + #dotest conflicts2-142d6 "${testcvs} -q rm -f aa.c" fixme + dotest conflicts2-142d6 "rm aa.c" '' + dotest conflicts2-142d7 "${testcvs} -q update aa.c" "U aa\.c" + dotest conflicts2-142d8 "cat aa.c" '' + + # The other way is to use the version from the working directory + # instead of the version from the repository. Unfortunately, + # there doesn't seem to be any particularly clear way to do + # this (?). + cd ../.. rm -r 1 2 ; rm -rf ${CVSROOT_DIRNAME}/first-dir ;; + conflicts3) + # More tests of conflicts and/or multiple working directories + # in general. + + mkdir 1; cd 1 + dotest conflicts3-1 "${testcvs} -q co -l ." '' + mkdir first-dir + dotest conflicts3-2 "${testcvs} add first-dir" \ +"Directory ${TESTDIR}/cvsroot/first-dir added to the repository" + cd .. + mkdir 2; cd 2 + dotest conflicts3-3 "${testcvs} -q co -l first-dir" '' + cd ../1/first-dir + touch file1 file2 + dotest conflicts3-4 "${testcvs} add file1 file2" \ +"${PROG} [a-z]*: scheduling file .file1. for addition +${PROG} [a-z]*: scheduling file .file2. for addition +${PROG} [a-z]*: use .${PROG} commit. to add these files permanently" + dotest conflicts3-5 "${testcvs} -q ci -m add-them" \ +"RCS file: ${TESTDIR}/cvsroot/first-dir/file1,v +done +Checking in file1; +${TESTDIR}/cvsroot/first-dir/file1,v <-- file1 +initial revision: 1\.1 +done +RCS file: ${TESTDIR}/cvsroot/first-dir/file2,v +done +Checking in file2; +${TESTDIR}/cvsroot/first-dir/file2,v <-- file2 +initial revision: 1\.1 +done" + cd ../../2/first-dir + # Check that -n doesn't make CVS lose its mind as it creates + # (or rather, doesn't) a new file. + dotest conflicts3-6 "${testcvs} -nq update" \ +"U file1 +U file2" + dotest_fail conflicts3-7 "test -f file1" '' + dotest conflicts3-8 "${testcvs} -q update" \ +"U file1 +U file2" + dotest conflicts3-9 "test -f file2" '' + + # OK, now remove two files at once + dotest conflicts3-10 "${testcvs} rm -f file1 file2" \ +"${PROG} [a-z]*: scheduling .file1. for removal +${PROG} [a-z]*: scheduling .file2. for removal +${PROG} [a-z]*: use .${PROG} commit. to remove these files permanently" + dotest conflicts3-11 "${testcvs} -q ci -m remove-them" \ +"Removing file1; +${TESTDIR}/cvsroot/first-dir/file1,v <-- file1 +new revision: delete; previous revision: 1\.1 +done +Removing file2; +${TESTDIR}/cvsroot/first-dir/file2,v <-- file2 +new revision: delete; previous revision: 1\.1 +done" + cd ../../1/first-dir + dotest conflicts3-12 "${testcvs} -n -q update" \ +"${PROG} [a-z]*: warning: file1 is not (any longer) pertinent +${PROG} [a-z]*: warning: file2 is not (any longer) pertinent" + dotest conflicts3-13 "${testcvs} -q update" \ +"${PROG} [a-z]*: warning: file1 is not (any longer) pertinent +${PROG} [a-z]*: warning: file2 is not (any longer) pertinent" + + # OK, now add a directory to both working directories + # and see that CVS doesn't lose its mind. + mkdir sdir + dotest conficts3-14 "${testcvs} add sdir" \ +"Directory ${TESTDIR}/cvsroot/first-dir/sdir added to the repository" + cd ../../2/first-dir + + # Create a CVS directory without the proper administrative + # files in it. This can happen for example if you hit ^C + # in the middle of a checkout. + mkdir sdir + mkdir sdir/CVS + # OK, in the local case CVS sees that the directory exists + # in the repository and recurses into it. In the remote case + # CVS can't see the repository and has no way of knowing + # that sdir is even a directory (stat'ing everything would be + # too slow). The remote behavior makes more sense to me (but + # would this affect other cases?). + if test "$remote" = yes; then + dotest conflicts3-15 "${testcvs} -q update" \ +"${QUESTION} sdir" + else + dotest conflicts3-15 "${testcvs} -q update" \ +"${QUESTION} sdir +${PROG} [a-z]*: ignoring sdir (CVS/Repository missing)" + touch sdir/CVS/Repository + dotest conflicts3-16 "${testcvs} -q update" \ +"${QUESTION} sdir +${PROG} [a-z]*: ignoring sdir (CVS/Entries missing)" + fi + rm -r sdir + + # OK, now the same thing, but the directory doesn't exist + # in the repository. + mkdir newdir + mkdir newdir/CVS + dotest conflicts3-17 "${testcvs} -q update" "${QUESTION} newdir" + echo "D/newdir////" >> CVS/Entries + dotest conflicts3-18 "${testcvs} -q update" \ +"${PROG} [a-z]*: ignoring newdir (CVS/Repository missing)" + touch newdir/CVS/Repository + dotest conflicts3-19 "${testcvs} -q update" \ +"${PROG} [a-z]*: ignoring newdir (CVS/Entries missing)" + rm -r newdir + + cd ../.. + + rm -r 1 2 + rm -rf ${CVSROOT_DIRNAME}/first-dir + ;; + modules) # Tests of various ways to define and use modules. + + ############################################################ + # These tests are to make sure that administrative files get + # rebuilt, regardless of how and where files are checked + # out. + ############################################################ + # Check out the whole repository + mkdir 1; cd 1 + dotest modules-1 "${testcvs} -q co ." 'U CVSROOT/checkoutlist +U CVSROOT/commitinfo +U CVSROOT/config +U CVSROOT/cvswrappers +U CVSROOT/editinfo +U CVSROOT/loginfo +U CVSROOT/modules +U CVSROOT/notify +U CVSROOT/rcsinfo +U CVSROOT/taginfo +U CVSROOT/verifymsg' + echo "# made a change" >>CVSROOT/modules + dotest modules-1d "${testcvs} -q ci -m add-modules" \ +"Checking in CVSROOT/modules; +${TESTDIR}/cvsroot/CVSROOT/modules,v <-- modules +new revision: 1\.[0-9]*; previous revision: 1\.[0-9]* +done +${PROG} [a-z]*: Rebuilding administrative file database" + cd .. + rm -rf 1 + + ############################################################ + # Check out CVSROOT + mkdir 1; cd 1 + dotest modules-2 "${testcvs} -q co CVSROOT" 'U CVSROOT/checkoutlist +U CVSROOT/commitinfo +U CVSROOT/config +U CVSROOT/cvswrappers +U CVSROOT/editinfo +U CVSROOT/loginfo +U CVSROOT/modules +U CVSROOT/notify +U CVSROOT/rcsinfo +U CVSROOT/taginfo +U CVSROOT/verifymsg' + echo "# made a change" >>CVSROOT/modules + dotest modules-2d "${testcvs} -q ci -m add-modules" \ +"Checking in CVSROOT/modules; +${TESTDIR}/cvsroot/CVSROOT/modules,v <-- modules +new revision: 1\.[0-9]*; previous revision: 1\.[0-9]* +done +${PROG} [a-z]*: Rebuilding administrative file database" + cd .. + rm -rf 1 + + ############################################################ + # Check out CVSROOT in some other directory + mkdir ${CVSROOT_DIRNAME}/somedir + mkdir 1; cd 1 + dotest modules-3 "${testcvs} -q co somedir" '' + cd somedir + dotest modules-3d "${testcvs} -q co CVSROOT" 'U CVSROOT/checkoutlist +U CVSROOT/commitinfo +U CVSROOT/config +U CVSROOT/cvswrappers +U CVSROOT/editinfo +U CVSROOT/loginfo +U CVSROOT/modules +U CVSROOT/notify +U CVSROOT/rcsinfo +U CVSROOT/taginfo +U CVSROOT/verifymsg' + echo "# made a change" >>CVSROOT/modules + dotest modules-3g "${testcvs} -q ci -m add-modules" \ +"Checking in CVSROOT/modules; +${TESTDIR}/cvsroot/CVSROOT/modules,v <-- modules +new revision: 1\.[0-9]*; previous revision: 1\.[0-9]* +done +${PROG} [a-z]*: Rebuilding administrative file database" + cd ../.. + rm -rf 1 + rm -rf ${CVSROOT_DIRNAME}/somedir + ############################################################ + # end rebuild tests + ############################################################ + + mkdir ${CVSROOT_DIRNAME}/first-dir mkdir 1 cd 1 if ${testcvs} -q co first-dir; then - echo 'PASS: test 143' >>${LOGFILE} + pass 143 else - echo 'FAIL: test 143' | tee -a ${LOGFILE} - exit 1 + fail 143 fi cd first-dir @@ -3954,25 +5076,22 @@ C aa\.c" touch a b if ${testcvs} add a b 2>>${LOGFILE} ; then - echo 'PASS: test 144' >>${LOGFILE} + pass 144 else - echo 'FAIL: test 144' | tee -a ${LOGFILE} - exit 1 + fail 144 fi if ${testcvs} ci -m added >>${LOGFILE} 2>&1; then - echo 'PASS: test 145' >>${LOGFILE} + pass 145 else - echo 'FAIL: test 145' | tee -a ${LOGFILE} - exit 1 + fail 145 fi cd .. if ${testcvs} -q co CVSROOT >>${LOGFILE}; then - echo 'PASS: test 146' >>${LOGFILE} + pass 146 else - echo 'FAIL: test 146' | tee -a ${LOGFILE} - exit 1 + fail 146 fi # Here we test that CVS can deal with CVSROOT (whose repository @@ -3980,10 +5099,9 @@ C aa\.c" # is a subdirectory of first-dir). TODO: Might want to check that # files can actually get updated in this state. if ${testcvs} -q update; then - echo 'PASS: test 147' >>${LOGFILE} + pass 147 else - echo 'FAIL: test 147' | tee -a ${LOGFILE} - exit 1 + fail 147 fi echo realmodule first-dir/subdir a >CVSROOT/modules @@ -3993,6 +5111,7 @@ C aa\.c" echo aliasnested -a first-dir/subdir/ssdir >>CVSROOT/modules echo topfiles -a first-dir/file1 first-dir/file2 >>CVSROOT/modules echo world -a . >>CVSROOT/modules + echo statusmod -s Mungeable >>CVSROOT/modules # Options must come before arguments. It is possible this should # be relaxed at some point (though the result would be bizarre for @@ -4000,85 +5119,86 @@ C aa\.c" echo bogusalias first-dir/subdir/a -a >>CVSROOT/modules if ${testcvs} ci -m 'add modules' CVSROOT/modules \ >>${LOGFILE} 2>&1; then - echo 'PASS: test 148' >>${LOGFILE} + pass 148 else - echo 'FAIL: test 148' | tee -a ${LOGFILE} - exit 1 + fail 148 fi cd .. + # The "statusmod" module contains an error; trying to use it + # will produce "modules file missing directory" I think. + # However, that shouldn't affect the ability of "cvs co -c" or + # "cvs co -s" to do something reasonable with it. dotest 148a0 "${testcvs} co -c" 'aliasmodule -a first-dir/subdir/a aliasnested -a first-dir/subdir/ssdir bogusalias first-dir/subdir/a -a dirmodule first-dir/subdir namedmodule -d nameddir first-dir/subdir realmodule first-dir/subdir a +statusmod -s Mungeable topfiles -a first-dir/file1 first-dir/file2 -world -a .' - # I don't know why aliasmodule isn't printed (I would have thought - # that it gets printed without the -a; although I'm not sure that - # printing expansions without options is useful). +world -a \.' + # There is code in modules.c:save_d which explicitly skips + # modules defined with -a, which is why aliasmodule is not + # listed. dotest 148a1 "${testcvs} co -s" \ -'bogusalias NONE first-dir/subdir/a -a +'statusmod Mungeable +bogusalias NONE first-dir/subdir/a -a dirmodule NONE first-dir/subdir namedmodule NONE first-dir/subdir realmodule NONE first-dir/subdir a' # Test that real modules check out to realmodule/a, not subdir/a. if ${testcvs} co realmodule >>${LOGFILE}; then - echo 'PASS: test 149a1' >>${LOGFILE} + pass 149a1 else - echo 'FAIL: test 149a1' | tee -a ${LOGFILE} - exit 1 + fail 149a1 fi if test -d realmodule && test -f realmodule/a; then - echo 'PASS: test 149a2' >>${LOGFILE} + pass 149a2 else - echo 'FAIL: test 149a2' | tee -a ${LOGFILE} - exit 1 + fail 149a2 fi if test -f realmodule/b; then - echo 'FAIL: test 149a3' | tee -a ${LOGFILE} - exit 1 + fail 149a3 else - echo 'PASS: test 149a3' >>${LOGFILE} + pass 149a3 fi if ${testcvs} -q co realmodule; then - echo 'PASS: test 149a4' >>${LOGFILE} + pass 149a4 else - echo 'FAIL: test 149a4' | tee -a ${LOGFILE} - exit 1 + fail 149a4 fi if echo "yes" | ${testcvs} release -d realmodule >>${LOGFILE} ; then - echo 'PASS: test 149a5' >>${LOGFILE} + pass 149a5 else - echo 'FAIL: test 149a5' | tee -a ${LOGFILE} - exit 1 + fail 149a5 fi + dotest_fail 149b1 "${testcvs} co realmodule/a" \ +"${PROG}"' [a-z]*: module `realmodule/a'\'' is a request for a file in a module which is not a directory' \ +"${PROG}"' [a-z]*: module `realmodule/a'\'' is a request for a file in a module which is not a directory +'"${PROG}"' \[[a-z]* aborted\]: cannot expand modules' + # Now test the ability to check out a single file from a directory if ${testcvs} co dirmodule/a >>${LOGFILE}; then - echo 'PASS: test 150c' >>${LOGFILE} + pass 150c else - echo 'FAIL: test 150c' | tee -a ${LOGFILE} - exit 1 + fail 150c fi if test -d dirmodule && test -f dirmodule/a; then - echo 'PASS: test 150d' >>${LOGFILE} + pass 150d else - echo 'FAIL: test 150d' | tee -a ${LOGFILE} - exit 1 + fail 150d fi if test -f dirmodule/b; then - echo 'FAIL: test 150e' | tee -a ${LOGFILE} - exit 1 + fail 150e else - echo 'PASS: test 150e' >>${LOGFILE} + pass 150e fi if echo "yes" | ${testcvs} release -d dirmodule >>${LOGFILE} ; then - echo 'PASS: test 150f' >>${LOGFILE} + pass 150f else - echo 'FAIL: test 150f' | tee -a ${LOGFILE} - exit 1 + fail 150f fi # Now test the ability to correctly reject a non-existent filename. # For maximum studliness we would check that an error message is @@ -4087,18 +5207,17 @@ realmodule NONE first-dir/subdir a' # We accept a zero exit status because it is what CVS does # (Dec 95). Probably the exit status should be nonzero, # however. - echo 'PASS: test 150g1' >>${LOGFILE} + pass 150g1 else - echo 'PASS: test 150g1' >>${LOGFILE} + pass 150g1 fi # We tolerate the creation of the dirmodule directory, since that # is what CVS does, not because we view that as preferable to not # creating it. if test -f dirmodule/a || test -f dirmodule/b; then - echo 'FAIL: test 150g2' | tee -a ${LOGFILE} - exit 1 + fail 150g2 else - echo 'PASS: test 150g2' >>${LOGFILE} + pass 150g2 fi rm -r dirmodule @@ -4124,31 +5243,27 @@ U nameddir/b' # Now test that alias modules check out to subdir/a, not # aliasmodule/a. if ${testcvs} co aliasmodule >>${LOGFILE}; then - echo 'PASS: test 151' >>${LOGFILE} + pass 151 else - echo 'FAIL: test 151' | tee -a ${LOGFILE} - exit 1 + fail 151 fi if test -d aliasmodule; then - echo 'FAIL: test 152' | tee -a ${LOGFILE} - exit 1 + fail 152 else - echo 'PASS: test 152' >>${LOGFILE} + pass 152 fi echo abc >>first-dir/subdir/a if (${testcvs} -q co aliasmodule | tee test153.tmp) \ >>${LOGFILE}; then - echo 'PASS: test 153' >>${LOGFILE} + pass 153 else - echo 'FAIL: test 153' | tee -a ${LOGFILE} - exit 1 + fail 153 fi echo 'M first-dir/subdir/a' >ans153.tmp if cmp test153.tmp ans153.tmp; then - echo 'PASS: test 154' >>${LOGFILE} + pass 154 else - echo 'FAIL: test 154' | tee -a ${LOGFILE} - exit 1 + fail 154 fi cd .. @@ -4193,7 +5308,7 @@ U first-dir/subdir/b" dotest modules-155c2 "${testcvs} add file1 file2" \ "${PROG}"' [a-z]*: scheduling file `file1'\'' for addition '"${PROG}"' [a-z]*: scheduling file `file2'\'' for addition -'"${PROG}"' [a-z]*: use '\''cvs commit'\'' to add these files permanently' +'"${PROG}"' [a-z]*: use .'"${PROG}"' commit. to add these files permanently' dotest modules-155c3 "${testcvs} -q ci -m add-it" \ "RCS file: ${TESTDIR}/cvsroot/first-dir/file1,v done @@ -4214,6 +5329,22 @@ done" "U first-dir/file1 U first-dir/file2" dotest modules-155c5 "${testcvs} -q co topfiles" "" + + # Make sure the right thing happens if we remove a file. + cd first-dir + dotest modules-155c6 "${testcvs} -q rm -f file1" \ +"${PROG} [a-z]*: use .${PROG} commit. to remove this file permanently" + dotest modules-155c7 "${testcvs} -q ci -m remove-it" \ +"Removing file1; +${TESTDIR}/cvsroot/first-dir/file1,v <-- file1 +new revision: delete; previous revision: 1\.1 +done" + cd .. + rm -r first-dir + dotest modules-155c8 "${testcvs} -q co topfiles" \ +"${PROG} [a-z]*: warning: first-dir/file1 is not (any longer) pertinent +U first-dir/file2" + cd .. rm -r 1 @@ -4222,8 +5353,28 @@ U first-dir/file2" modules2) # More tests of modules, in particular the & feature. - mkdir ${CVSROOT_DIRNAME}/first-dir - mkdir ${CVSROOT_DIRNAME}/second-dir + mkdir 1; cd 1 + dotest modules2-setup-1 "${testcvs} -q co -l ." '' + mkdir first-dir second-dir third-dir + dotest modules2-setup-2 \ +"${testcvs} add first-dir second-dir third-dir" \ +"Directory ${TESTDIR}/cvsroot/first-dir added to the repository +Directory ${TESTDIR}/cvsroot/second-dir added to the repository +Directory ${TESTDIR}/cvsroot/third-dir added to the repository" + cd third-dir + touch file3 + dotest modules2-setup-3 "${testcvs} add file3" \ +"${PROG} [a-z]*: scheduling file .file3. for addition +${PROG} [a-z]*: use .${PROG} commit. to add this file permanently" + dotest modules2-setup-4 "${testcvs} -q ci -m add file3" \ +"RCS file: ${TESTDIR}/cvsroot/third-dir/file3,v +done +Checking in file3; +${TESTDIR}/cvsroot/third-dir/file3,v <-- file3 +initial revision: 1\.1 +done" + cd ../.. + rm -r 1 mkdir 1 cd 1 @@ -4232,6 +5383,7 @@ U first-dir/file2" 'U CVSROOT/modules' cd CVSROOT echo 'ampermodule &first-dir &second-dir' > modules + echo 'combmodule third-dir file3 &first-dir' >> modules # Depending on whether the user also ran the modules test # we will be checking in revision 1.2 or 1.3. dotest modules2-2 "${testcvs} -q ci -m add-modules" \ @@ -4263,8 +5415,98 @@ EOF cd .. + # Now we create another directory named first-dir and make + # sure that CVS doesn't get them mixed up. + mkdir first-dir + # Note that this message should say "Updating ampermodule/first-dir" + # I suspect. This is a long-standing behavior/bug.... + dotest modules2-9 "${testcvs} co ampermodule" \ +"${PROG} [a-z]*: Updating first-dir +${PROG} [a-z]*: Updating second-dir" + touch ampermodule/first-dir/amper1 + dotest modules2-10 "${testcvs} add ampermodule/first-dir/amper1" \ +"${PROG} [a-z]*: scheduling file .ampermodule/first-dir/amper1. for addition +${PROG} [a-z]*: use .${PROG} commit. to add this file permanently" + + # As with the "Updating xxx" message, the "U first-dir/amper1" + # message (instead of "U ampermodule/first-dir/amper1") is + # rather fishy. + dotest modules2-12 "${testcvs} co ampermodule" \ +"${PROG} [a-z]*: Updating first-dir +A first-dir/amper1 +${PROG} [a-z]*: Updating second-dir" + + if test "$remote" = no; then + dotest modules2-13 "${testcvs} -q ci -m add-it ampermodule" \ +"RCS file: ${TESTDIR}/cvsroot/first-dir/amper1,v +done +Checking in ampermodule/first-dir/amper1; +${TESTDIR}/cvsroot/first-dir/amper1,v <-- amper1 +initial revision: 1\.1 +done" + else + # Trying this as above led to a "protocol error" message. + # Work around this bug. + cd ampermodule + dotest modules2-13 "${testcvs} -q ci -m add-it" \ +"RCS file: ${TESTDIR}/cvsroot/first-dir/amper1,v +done +Checking in first-dir/amper1; +${TESTDIR}/cvsroot/first-dir/amper1,v <-- amper1 +initial revision: 1\.1 +done" + cd .. + fi + + # Now test the "combmodule" module (combining regular modules + # and ampersand modules in the same module definition). + cd .. + rm -r 1 + mkdir 1; cd 1 + dotest modules2-14 "${testcvs} co combmodule" \ +"U combmodule/file3 +${PROG} [a-z]*: Updating first-dir +U first-dir/amper1" + dotest modules2-15 "test -f combmodule/file3" "" + dotest modules2-16 "test -f combmodule/first-dir/amper1" "" + cd combmodule + rm -r first-dir + # Might be possible to have a more graceful error message, + # but at least for now there is no way to tell CVS that + # some files/subdirectories come from one repository directory, + # and others from another. + if test "$remote" = no; then + dotest_fail modules2-17 "${testcvs} update -d" \ +"${PROG} [a-z]*: Updating \. +${PROG} [a-z]*: Updating first-dir +${PROG} \[[a-z]* aborted\]: cannot open directory ${TESTDIR}/cvsroot/third-dir/first-dir: No such file or directory" + # Clean up the droppings left by the previous command. + # This should definitely not be necessary (I think). + rm -r first-dir + else + # This seems like a pretty sensible behavior to me, in the + # sense that first-dir doesn't "really" exist within + # third-dir, so CVS just acts as if there is nothing there + # to do. + dotest modules2-17 "${testcvs} update -d" \ +"${PROG} server: Updating \." + fi + + cd .. + dotest modules2-18 "${testcvs} -q co combmodule" \ +"U first-dir/amper1" + dotest modules2-19 "test -f combmodule/first-dir/amper1" "" + cd .. + rm -r 1 + # Test that CVS gives an error if one combines -a with # other options. + # Probably would be better to break this out into a separate + # test. Although it is short, it shares no files/state with + # the rest of the modules2 tests. + mkdir 1; cd 1 + dotest modules2-a0.5 "${testcvs} -q co CVSROOT/modules" \ +'U CVSROOT/modules' cd CVSROOT echo 'aliasopt -a -d onedir first-dir' >modules dotest modules2-a0 "${testcvs} -q ci -m add-modules" \ @@ -4285,6 +5527,7 @@ ${PROG} \[[a-z]* aborted\]: cannot expand modules" rm -r 1 rm -rf ${CVSROOT_DIRNAME}/first-dir rm -rf ${CVSROOT_DIRNAME}/second-dir + rm -rf ${CVSROOT_DIRNAME}/third-dir ;; modules3) @@ -4303,7 +5546,7 @@ ${PROG} \[[a-z]* aborted\]: cannot expand modules" echo file1 >file1 dotest modules3-2 "${testcvs} add file1" \ "${PROG}"' [a-z]*: scheduling file `file1'\'' for addition -'"${PROG}"' [a-z]*: use '\''cvs commit'\'' to add this file permanently' +'"${PROG}"' [a-z]*: use .'"${PROG}"' commit. to add this file permanently' dotest modules3-3 "${testcvs} -q ci -m add-it" \ "RCS file: ${TESTDIR}/cvsroot/first-dir/file1,v done @@ -4313,8 +5556,8 @@ initial revision: 1\.1 done" cd .. - dotest modules3-4 "${testcvs} -q co CVSROOT/modules" \ -'U CVSROOT/modules' + dotest modules3-4 "${testcvs} -q update -d CVSROOT" \ +"U CVSROOT${DOTSTAR}" cd CVSROOT cat >modules <<EOF mod1 -a first-dir/file1 @@ -4323,6 +5566,7 @@ namednest -d src/sub/dir first-dir nestdeeper -d src/sub1/sub2/sub3/dir first-dir nestshallow -d src/dir second-dir/suba/subb path/in/modules &mod1 +another/path/test -d another/path/test first-dir EOF dotest modules3-5 "${testcvs} -q ci -m add-modules" \ "Checking in modules; @@ -4375,7 +5619,7 @@ ${PROG} [a-z]*: Updating second-dir/suba/subb" \ touch fileb dotest modules3-7c "${testcvs} add fileb" \ "${PROG} [a-z]*: scheduling file .fileb. for addition -${PROG} [a-z]*: use .cvs commit. to add this file permanently" +${PROG} [a-z]*: use .${PROG} commit. to add this file permanently" dotest modules3-7d "${testcvs} -q ci -m add-it" \ "RCS file: ${TESTDIR}/cvsroot/second-dir/suba/subb/fileb,v done @@ -4386,26 +5630,6 @@ done" cd ../../.. cd ..; rm -r 1 - mkdir 1; cd 1 - dotest modules3-7e "${testcvs} -q co nestshallow" \ -"U src/dir/fileb" - - # Using ${TESTDIR}/cvsroot/second-dir/suba instead of - # ${TESTDIR}/cvsroot/second-dir seems wrong, it seems like the - # 30 Dec 1996 change to build_dirs_and_chdir simply failed - # to consider what to put in CVS/Repository. - # Remote does "${TESTDIR}/cvsroot/\." which seems equally wrong, - # if in a different way, but variety is the spice of life, - # eh? - dotest modules3-7f "cat CVS/Repository" \ -"${TESTDIR}/cvsroot/second-dir/suba" "${TESTDIR}/cvsroot/\." - - dotest modules3-7g "cat src/CVS/Repository" \ -"${TESTDIR}/cvsroot/second-dir/suba" - dotest modules3-7h "cat src/dir/CVS/Repository" \ -"${TESTDIR}/cvsroot/second-dir/suba/subb" - cd ..; rm -r 1 - mkdir 1 cd 1 dotest modules3-8 "${testcvs} -q co namednest" \ @@ -4442,10 +5666,11 @@ done" # need to keep doing it, but it is what CVS currently does... # Skip it for remote; the remote code has the good sense to # not deal with it (on the minus side it gives - # "internal error: repository string too short." instead of a - # real error). - # I kind of suspect that it would be OK to just make it a fatal - # error to have '/' in a module name. + # "internal error: repository string too short." (CVS 1.9) or + # "warning: server is not creating directories one at a time" (now) + # instead of a real error). + # I'm tempted to just make it a fatal error to have '/' in a + # module name. But see comments at modules3-16. if test "x$remote" = xno; then mkdir 1; cd 1 dotest modules3-12 "${testcvs} -q co path/in/modules" \ @@ -4465,6 +5690,16 @@ done" cd ..; rm -r 1 fi # end of tests skipped for remote + # Some people seem to want this to work. I still suspect there + # are dark corners in slashes in module names. This probably wants + # more thought before we start hacking on CVS (one way or the other) + # or documenting this. + mkdir 2; cd 2 + dotest modules3-16 "${testcvs} -q co another/path/test" \ +"U another/path/test/file1" + dotest modules3-17 "cat another/path/test/file1" 'file1' + cd ..; rm -r 2 + rm -rf ${CVSROOT_DIRNAME}/first-dir rm -rf ${CVSROOT_DIRNAME}/second-dir ;; @@ -4477,49 +5712,43 @@ done" # Test handling of -m during import echo testa >>test if ${testcvs} import -m "$message" a-dir A A1 >>${LOGFILE} 2>&1;then - echo 'PASS: test 156' >>${LOGFILE} + pass 156 else - echo 'FAIL: test 156' | tee -a ${LOGFILE} - exit 1 + fail 156 fi # Must import twice since the first time uses inline code that # avoids RCS call. echo testb >>test if ${testcvs} import -m "$message" a-dir A A2 >>${LOGFILE} 2>&1;then - echo 'PASS: test 157' >>${LOGFILE} + pass 157 else - echo 'FAIL: test 157' | tee -a ${LOGFILE} - exit 1 + fail 157 fi # Test handling of -m during ci cd ..; rm -r a-dir if ${testcvs} co a-dir >>${LOGFILE} 2>&1; then - echo 'PASS: test 158' >>${LOGFILE} + pass 158 else - echo 'FAIL: test 158' | tee -a ${LOGFILE} - exit 1 + fail 158 fi cd a-dir echo testc >>test if ${testcvs} ci -m "$message" >>${LOGFILE} 2>&1; then - echo 'PASS: test 159' >>${LOGFILE} + pass 159 else - echo 'FAIL: test 159' | tee -a ${LOGFILE} - exit 1 + fail 159 fi # Test handling of -m during rm/ci rm test; if ${testcvs} rm test >>${LOGFILE} 2>&1; then - echo 'PASS: test 160' >>${LOGFILE} + pass 160 else - echo 'FAIL: test 160' | tee -a ${LOGFILE} - exit 1 + fail 160 fi if ${testcvs} ci -m "$message" >>${LOGFILE} 2>&1; then - echo 'PASS: test 161' >>${LOGFILE} + pass 161 else - echo 'FAIL: test 161' | tee -a ${LOGFILE} - exit 1 + fail 161 fi # Clean up cd .. @@ -4527,70 +5756,245 @@ done" rm -rf ${CVSROOT_DIRNAME}/a-dir done ;; + + editor) + # More tests of log messages, in this case the ability to + # run an external editor. + # TODO: + # * also test $EDITOR, $CVSEDITOR, &c. + # * test what happens if up-to-date check fails. + + # Our "editor" puts "x" at the start of each line, so we + # can see the "CVS:" lines. + cat >${TESTDIR}/editme <<EOF +#!${TESTSHELL} +sleep 1 +sed <\$1 -e 's/^/x&/g' >${TESTDIR}/edit.new +mv ${TESTDIR}/edit.new \$1 +exit 0 +EOF + chmod +x ${TESTDIR}/editme + + mkdir 1; cd 1 + dotest editor-1 "${testcvs} -q co -l ." '' + mkdir first-dir + dotest editor-2 "${testcvs} add first-dir" \ +"Directory ${TESTDIR}/cvsroot/first-dir added to the repository" + cd first-dir + touch file1 file2 + dotest editor-3 "${testcvs} add file1 file2" \ +"${PROG} [a-z]*: scheduling file .file1. for addition +${PROG} [a-z]*: scheduling file .file2. for addition +${PROG} [a-z]*: use .${PROG} commit. to add these files permanently" + dotest editor-4 "${testcvs} -e ${TESTDIR}/editme -q ci" \ +"RCS file: ${TESTDIR}/cvsroot/first-dir/file1,v +done +Checking in file1; +${TESTDIR}/cvsroot/first-dir/file1,v <-- file1 +initial revision: 1\.1 +done +RCS file: ${TESTDIR}/cvsroot/first-dir/file2,v +done +Checking in file2; +${TESTDIR}/cvsroot/first-dir/file2,v <-- file2 +initial revision: 1\.1 +done" + dotest editor-5 "${testcvs} -q tag -b br" "T file1 +T file2" + dotest editor-6 "${testcvs} -q update -r br" '' + echo modify >>file1 + dotest editor-7 "${testcvs} -e ${TESTDIR}/editme -q ci" \ +"Checking in file1; +${TESTDIR}/cvsroot/first-dir/file1,v <-- file1 +new revision: 1\.1\.2\.1; previous revision: 1\.1 +done" + # OK, now we want to make sure "ci -r" puts in the branch + # where appropriate. Note that we can check in on the branch + # without being on the branch, because there is not a revision + # already on the branch. If there were a revision on the branch, + # CVS would correctly give an up-to-date check failed. + dotest editor-8 "${testcvs} -q update -A" "U file1" + echo add a line >>file2 + dotest editor-9 "${testcvs} -q -e ${TESTDIR}/editme ci -rbr file2" \ +"Checking in file2; +${TESTDIR}/cvsroot/first-dir/file2,v <-- file2 +new revision: 1\.1\.2\.1; previous revision: 1\.1 +done" + + dotest editor-log-file1 "${testcvs} log -N file1" " +RCS file: ${TESTDIR}/cvsroot/first-dir/file1,v +Working file: file1 +head: 1\.1 +branch: +locks: strict +access list: +keyword substitution: kv +total revisions: 2; selected revisions: 2 +description: +---------------------------- +revision 1\.1 +date: [0-9/]* [0-9:]*; author: ${username}; state: Exp; +branches: 1\.1\.2; +x +xCVS: ---------------------------------------------------------------------- +xCVS: Enter Log. Lines beginning with .CVS:. are removed automatically +xCVS: +xCVS: Committing in . +xCVS: +xCVS: Added Files: +xCVS: file1 file2 +xCVS: ---------------------------------------------------------------------- +---------------------------- +revision 1\.1\.2\.1 +date: [0-9/]* [0-9:]*; author: ${username}; state: Exp; lines: ${PLUS}1 -0 +x +xCVS: ---------------------------------------------------------------------- +xCVS: Enter Log. Lines beginning with .CVS:. are removed automatically +xCVS: +xCVS: Committing in . +xCVS: +xCVS: Modified Files: +xCVS: Tag: br +xCVS: file1 +xCVS: ---------------------------------------------------------------------- +=============================================================================" + + # The only difference between the two expect strings is the + # presence or absence of "Committing in ." for 1.1.2.1. + dotest editor-log-file2 "${testcvs} log -N file2" " +RCS file: ${TESTDIR}/cvsroot/first-dir/file2,v +Working file: file2 +head: 1\.1 +branch: +locks: strict +access list: +keyword substitution: kv +total revisions: 2; selected revisions: 2 +description: +---------------------------- +revision 1\.1 +date: [0-9/]* [0-9:]*; author: ${username}; state: Exp; +branches: 1\.1\.2; +x +xCVS: ---------------------------------------------------------------------- +xCVS: Enter Log. Lines beginning with .CVS:. are removed automatically +xCVS: +xCVS: Committing in . +xCVS: +xCVS: Added Files: +xCVS: file1 file2 +xCVS: ---------------------------------------------------------------------- +---------------------------- +revision 1\.1\.2\.1 +date: [0-9/]* [0-9:]*; author: ${username}; state: Exp; lines: ${PLUS}1 -0 +x +xCVS: ---------------------------------------------------------------------- +xCVS: Enter Log. Lines beginning with .CVS:. are removed automatically +xCVS: +xCVS: Modified Files: +xCVS: Tag: br +xCVS: file2 +xCVS: ---------------------------------------------------------------------- +=============================================================================" " +RCS file: ${TESTDIR}/cvsroot/first-dir/file2,v +Working file: file2 +head: 1\.1 +branch: +locks: strict +access list: +keyword substitution: kv +total revisions: 2; selected revisions: 2 +description: +---------------------------- +revision 1\.1 +date: [0-9/]* [0-9:]*; author: ${username}; state: Exp; +branches: 1\.1\.2; +x +xCVS: ---------------------------------------------------------------------- +xCVS: Enter Log. Lines beginning with .CVS:. are removed automatically +xCVS: +xCVS: Committing in . +xCVS: +xCVS: Added Files: +xCVS: file1 file2 +xCVS: ---------------------------------------------------------------------- +---------------------------- +revision 1\.1\.2\.1 +date: [0-9/]* [0-9:]*; author: ${username}; state: Exp; lines: ${PLUS}1 -0 +x +xCVS: ---------------------------------------------------------------------- +xCVS: Enter Log. Lines beginning with .CVS:. are removed automatically +xCVS: +xCVS: Committing in . +xCVS: +xCVS: Modified Files: +xCVS: Tag: br +xCVS: file2 +xCVS: ---------------------------------------------------------------------- +=============================================================================" + cd ../.. + rm -r 1 + rm ${TESTDIR}/editme + rm -rf ${CVSROOT_DIRNAME}/first-dir + ;; + errmsg1) mkdir ${CVSROOT_DIRNAME}/1dir mkdir 1 cd 1 if ${testcvs} -q co 1dir; then - echo 'PASS: test 162' >>${LOGFILE} + pass 162 else - echo 'FAIL: test 162' | tee -a ${LOGFILE} - exit 1 + fail 162 fi cd 1dir touch foo if ${testcvs} add foo 2>>${LOGFILE}; then - echo 'PASS: test 163' >>${LOGFILE} + pass 163 else - echo 'FAIL: test 163' | tee -a ${LOGFILE} - exit 1 + fail 163 fi if ${testcvs} ci -m added >>${LOGFILE} 2>&1; then - echo 'PASS: test 164' >>${LOGFILE} + pass 164 else - echo 'FAIL: test 164' | tee -a ${LOGFILE} - exit 1 + fail 164 fi cd ../.. mkdir 2 cd 2 if ${testcvs} -q co 1dir >>${LOGFILE}; then - echo 'PASS: test 165' >>${LOGFILE} + pass 165 else - echo 'FAIL: test 165' | tee -a ${LOGFILE} - exit 1 + fail 165 fi chmod a-w 1dir cd ../1/1dir rm foo; if ${testcvs} rm foo >>${LOGFILE} 2>&1; then - echo 'PASS: test 166' >>${LOGFILE} + pass 166 else - echo 'FAIL: test 166' | tee -a ${LOGFILE} - exit 1 + fail 166 fi if ${testcvs} ci -m removed >>${LOGFILE} 2>&1; then - echo 'PASS: test 167' >>${LOGFILE} + pass 167 else - echo 'FAIL: test 167' | tee -a ${LOGFILE} - exit 1 + fail 167 fi cd ../../2/1dir - # FIXME: should be using dotest and PROG. + # FIXME: should be using dotest. ${testcvs} -q update 2>../tst167.err - CVSBASE=`basename $testcvs` # Get basename of CVS executable. + cat ../tst167.err >>${LOGFILE} cat <<EOF >../tst167.ans -$CVSBASE server: warning: foo is not (any longer) pertinent -$CVSBASE update: unable to remove ./foo: Permission denied +${PROG} server: warning: foo is not (any longer) pertinent +${PROG} update: unable to remove ./foo: Permission denied EOF if cmp ../tst167.ans ../tst167.err >/dev/null || - ( echo "$CVSBASE [update aborted]: cannot rename file foo to CVS/,,foo: Permission denied" | cmp - ../tst167.err >/dev/null ) + ( echo "${PROG} [update aborted]: cannot rename file foo to CVS/,,foo: Permission denied" | cmp - ../tst167.err >/dev/null ) then - echo 'PASS: test 168' >>${LOGFILE} + pass 168 else - echo 'FAIL: test 168' | tee -a ${LOGFILE} - exit 1 + fail 168 fi cd .. @@ -4600,47 +6004,166 @@ EOF rm -rf ${CVSROOT_DIRNAME}/1dir ;; + errmsg2) + # More tests of various miscellaneous error handling, + # and cvs add behavior in general. + # See also test basicb-4a, concerning "cvs ci CVS". + # Too many tests to mention test the simple cases of + # adding files and directories. + # Test basicb-2a10 tests cvs -n add. + + # First the usual setup; create a directory first-dir. + mkdir 1; cd 1 + dotest errmsg2-1 "${testcvs} -q co -l ." '' + mkdir first-dir + dotest errmsg2-2 "${testcvs} add first-dir" \ +"Directory ${TESTDIR}/cvsroot/first-dir added to the repository" + cd first-dir + dotest_fail errmsg2-3 "${testcvs} add CVS" \ +"${PROG} [a-z]*: cannot add special file .CVS.; skipping" + touch file1 + # For the most part add returns a failure exitstatus if + # there are any errors, even if the remaining files are + # processed without incident. The "cannot add + # special file" message fits this pattern, at + # least currently. + dotest_fail errmsg2-4 "${testcvs} add CVS file1" \ +"${PROG} [a-z]*: cannot add special file .CVS.; skipping +${PROG} [a-z]*: scheduling file .file1. for addition +${PROG} [a-z]*: use .${PROG} commit. to add this file permanently" + # I'm not sure these tests completely convey the various strange + # behaviors that CVS had before it specially checked for "." and + # "..". Suffice it to say that these are unlikely to work right + # without a special case. + dotest_fail errmsg2-5 "${testcvs} add ." \ +"${PROG} [a-z]*: cannot add special file .\..; skipping" + dotest_fail errmsg2-6 "${testcvs} add .." \ +"${PROG} [a-z]*: cannot add special file .\.\..; skipping" + # Make sure that none of the error messages left droppings + # which interfere with normal operation. + dotest errmsg2-7 "${testcvs} -q ci -m add-file1" \ +"RCS file: ${TESTDIR}/cvsroot/first-dir/file1,v +done +Checking in file1; +${TESTDIR}/cvsroot/first-dir/file1,v <-- file1 +initial revision: 1\.1 +done" + mkdir sdir + cd .. + dotest errmsg2-8 "${testcvs} add first-dir/sdir" \ +"Directory ${TESTDIR}/cvsroot/first-dir/sdir added to the repository" + + cd first-dir + + touch file10 + mkdir sdir10 + dotest errmsg2-10 "${testcvs} add file10 sdir10" \ +"${PROG} [a-z]*: scheduling file .file10. for addition +Directory ${TESTDIR}/cvsroot/first-dir/sdir10 added to the repository +${PROG} [a-z]*: use .${PROG} commit. to add this file permanently" + dotest errmsg2-11 "${testcvs} -q ci -m add-file10" \ +"RCS file: ${TESTDIR}/cvsroot/first-dir/file10,v +done +Checking in file10; +${TESTDIR}/cvsroot/first-dir/file10,v <-- file10 +initial revision: 1\.1 +done" + # Try to see that there are no droppings left by + # any of the previous tests. + dotest errmsg2-12 "${testcvs} -q update" "" + + # Now test adding files with '/' in the name, both one level + # down and more than one level down. + cd .. + mkdir first-dir/sdir10/ssdir + dotest errmsg2-13 "${testcvs} add first-dir/sdir10/ssdir" \ +"Directory ${TESTDIR}/cvsroot/first-dir/sdir10/ssdir added to the repository" + + touch first-dir/sdir10/ssdir/ssfile + dotest errmsg2-14 \ + "${testcvs} add first-dir/sdir10/ssdir/ssfile" \ +"${PROG} [a-z]*: scheduling file .first-dir/sdir10/ssdir/ssfile. for addition +${PROG} [a-z]*: use .${PROG} commit. to add this file permanently" + touch first-dir/file15 + dotest errmsg2-15 "${testcvs} add first-dir/file15" \ +"${PROG} [a-z]*: scheduling file .first-dir/file15. for addition +${PROG} [a-z]*: use .${PROG} commit. to add this file permanently" + + # Now the case where we try to give it a directory which is not + # under CVS control. + mkdir bogus-dir + touch bogus-dir/file16 + # The first message, from local CVS, is nice. The second one + # is not nice; would be good to fix remote CVS to give a clearer + # message (e.g. the one from local CVS). But at least it is an + # error message. + dotest_fail errmsg2-16 "${testcvs} add bogus-dir/file16" \ +"${PROG} [a-z]*: in directory bogus-dir: +${PROG} \[[a-z]* aborted\]: there is no version here; do .${PROG} checkout. first" \ +"${PROG} [a-z]*: cannot open CVS/Entries for reading: No such file or directory +${PROG} \[add aborted\]: no repository" + rm -r bogus-dir + + # One error condition we don't test for is trying to add a file + # or directory which already is there. + + dotest errmsg2-17 "${testcvs} -q ci -m checkin" \ +"RCS file: ${TESTDIR}/cvsroot/first-dir/file15,v +done +Checking in first-dir/file15; +${TESTDIR}/cvsroot/first-dir/file15,v <-- file15 +initial revision: 1\.1 +done +RCS file: ${TESTDIR}/cvsroot/first-dir/sdir10/ssdir/ssfile,v +done +Checking in first-dir/sdir10/ssdir/ssfile; +${TESTDIR}/cvsroot/first-dir/sdir10/ssdir/ssfile,v <-- ssfile +initial revision: 1\.1 +done" + + cd .. + rm -r 1 + rm -rf ${TESTDIR}/cvsroot/first-dir + ;; + devcom) mkdir ${CVSROOT_DIRNAME}/first-dir mkdir 1 cd 1 if ${testcvs} -q co first-dir >>${LOGFILE} ; then - echo 'PASS: test 169' >>${LOGFILE} + pass 169 else - echo 'FAIL: test 169' | tee -a ${LOGFILE} - exit 1 + fail 169 fi cd first-dir echo abb >abb if ${testcvs} add abb 2>>${LOGFILE}; then - echo 'PASS: test 170' >>${LOGFILE} + pass 170 else - echo 'FAIL: test 170' | tee -a ${LOGFILE} - exit 1 + fail 170 fi if ${testcvs} ci -m added >>${LOGFILE} 2>&1; then - echo 'PASS: test 171' >>${LOGFILE} + pass 171 else - echo 'FAIL: test 171' | tee -a ${LOGFILE} - exit 1 + fail 171 fi dotest_fail 171a0 "${testcvs} watch" "Usage${DOTSTAR}" if ${testcvs} watch on; then - echo 'PASS: test 172' >>${LOGFILE} + pass 172 else - echo 'FAIL: test 172' | tee -a ${LOGFILE} + fail 172 fi echo abc >abc if ${testcvs} add abc 2>>${LOGFILE}; then - echo 'PASS: test 173' >>${LOGFILE} + pass 173 else - echo 'FAIL: test 173' | tee -a ${LOGFILE} + fail 173 fi if ${testcvs} ci -m added >>${LOGFILE} 2>&1; then - echo 'PASS: test 174' >>${LOGFILE} + pass 174 else - echo 'FAIL: test 174' | tee -a ${LOGFILE} + fail 174 fi cd ../.. @@ -4648,119 +6171,117 @@ EOF cd 2 if ${testcvs} -q co first-dir >>${LOGFILE}; then - echo 'PASS: test 175' >>${LOGFILE} + pass 175 else - echo 'FAIL: test 175' | tee -a ${LOGFILE} + fail 175 fi cd first-dir if test -w abb; then - echo 'FAIL: test 176' | tee -a ${LOGFILE} + fail 176 else - echo 'PASS: test 176' >>${LOGFILE} + pass 176 fi if test -w abc; then - echo 'FAIL: test 177' | tee -a ${LOGFILE} + fail 177 else - echo 'PASS: test 177' >>${LOGFILE} + pass 177 fi if ${testcvs} editors >../ans178.tmp; then - echo 'PASS: test 178' >>${LOGFILE} + pass 178 else - echo 'FAIL: test 178' | tee -a ${LOGFILE} + fail 178 fi cat ../ans178.tmp >>${LOGFILE} if test -s ../ans178.tmp; then - echo 'FAIL: test 178a' | tee -a ${LOGFILE} + fail 178a else - echo 'PASS: test 178a' >>${LOGFILE} + pass 178a fi if ${testcvs} edit abb; then - echo 'PASS: test 179' >>${LOGFILE} + pass 179 else - echo 'FAIL: test 179' | tee -a ${LOGFILE} - exit 1 + fail 179 fi if ${testcvs} editors >../ans180.tmp; then - echo 'PASS: test 180' >>${LOGFILE} + pass 180 else - echo 'FAIL: test 180' | tee -a ${LOGFILE} - exit 1 + fail 180 fi cat ../ans180.tmp >>${LOGFILE} if test -s ../ans180.tmp; then - echo 'PASS: test 181' >>${LOGFILE} + pass 181 else - echo 'FAIL: test 181' | tee -a ${LOGFILE} + fail 181 fi echo aaaa >>abb if ${testcvs} ci -m modify abb >>${LOGFILE} 2>&1; then - echo 'PASS: test 182' >>${LOGFILE} + pass 182 else - echo 'FAIL: test 182' | tee -a ${LOGFILE} + fail 182 fi # Unedit of a file not being edited should be a noop. dotest 182.5 "${testcvs} unedit abb" '' if ${testcvs} editors >../ans183.tmp; then - echo 'PASS: test 183' >>${LOGFILE} + pass 183 else - echo 'FAIL: test 183' | tee -a ${LOGFILE} + fail 183 fi cat ../ans183.tmp >>${LOGFILE} if test -s ../ans183.tmp; then - echo 'FAIL: test 184' | tee -a ${LOGFILE} + fail 184 else - echo 'PASS: test 184' >>${LOGFILE} + pass 184 fi if test -w abb; then - echo 'FAIL: test 185' | tee -a ${LOGFILE} + fail 185 else - echo 'PASS: test 185' >>${LOGFILE} + pass 185 fi if ${testcvs} edit abc; then - echo 'PASS: test 186a1' >>${LOGFILE} + pass 186a1 else - echo 'FAIL: test 186a1' | tee -a ${LOGFILE} + fail 186a1 fi # Unedit of an unmodified file. if ${testcvs} unedit abc; then - echo 'PASS: test 186a2' >>${LOGFILE} + pass 186a2 else - echo 'FAIL: test 186a2' | tee -a ${LOGFILE} + fail 186a2 fi if ${testcvs} edit abc; then - echo 'PASS: test 186a3' >>${LOGFILE} + pass 186a3 else - echo 'FAIL: test 186a3' | tee -a ${LOGFILE} + fail 186a3 fi echo changedabc >abc # Try to unedit a modified file; cvs should ask for confirmation if (echo no | ${testcvs} unedit abc) >>${LOGFILE}; then - echo 'PASS: test 186a4' >>${LOGFILE} + pass 186a4 else - echo 'FAIL: test 186a4' | tee -a ${LOGFILE} + fail 186a4 fi if echo changedabc | cmp - abc; then - echo 'PASS: test 186a5' >>${LOGFILE} + pass 186a5 else - echo 'FAIL: test 186a5' | tee -a ${LOGFILE} + fail 186a5 fi # OK, now confirm the unedit if (echo yes | ${testcvs} unedit abc) >>${LOGFILE}; then - echo 'PASS: test 186a6' >>${LOGFILE} + pass 186a6 else - echo 'FAIL: test 186a6' | tee -a ${LOGFILE} + fail 186a6 fi if echo abc | cmp - abc; then - echo 'PASS: test 186a7' >>${LOGFILE} + pass 186a7 else - echo 'FAIL: test 186a7' | tee -a ${LOGFILE} + fail 186a7 fi dotest devcom-a0 "${testcvs} watchers" '' @@ -4771,11 +6292,11 @@ EOF dotest devcom-a1 "${testcvs} watch add" '' dotest devcom-a2 "${testcvs} watchers" \ -'abb [a-z0-9]* edit unedit commit -abc [a-z0-9]* edit unedit commit' +"abb ${username} edit unedit commit +abc ${username} edit unedit commit" dotest devcom-a3 "${testcvs} watch remove -a unedit abb" '' dotest devcom-a4 "${testcvs} watchers abb" \ -'abb [a-z0-9]* edit commit' +"abb ${username} edit commit" # Check tagging and checking out while we have a CVS # directory in the repository. @@ -4798,6 +6319,29 @@ T abc' # Since first-dir/abb is readonly, use -f. rm -rf 3 + # Test checking out the directory rather than the file. + mkdir 3 + cd 3 + dotest devcom-t2 "${testcvs} -q co -rtag first-dir" \ +'U first-dir/abb +U first-dir/abc' + cd .. + # Since the files are readonly, use -f. + rm -rf 3 + + # Now do it again, after removing the val-tags file created + # by devcom-t1 to force CVS to search the repository + # containing CVS directories. + rm ${CVSROOT_DIRNAME}/CVSROOT/val-tags + mkdir 3 + cd 3 + dotest devcom-t3 "${testcvs} -q co -rtag first-dir" \ +'U first-dir/abb +U first-dir/abc' + cd .. + # Since the files are readonly, use -f. + rm -rf 3 + # Now remove all the file attributes cd 2/first-dir dotest devcom-b0 "${testcvs} watch off" '' @@ -4872,6 +6416,26 @@ U first-dir/w3' dotest_fail devcom2-9 "test -w first-dir/w1" '' dotest_fail devcom2-10 "test -w first-dir/w2" '' dotest_fail devcom2-11 "test -w first-dir/w3" '' + + cd first-dir + # OK, now we want to try files in various states with cvs edit. + dotest devcom2-12 "${testcvs} edit w4" \ +"${PROG} edit: no such file w4; ignored" + # Try the same thing with a per-directory watch set. + dotest devcom2-13 "${testcvs} watch on" '' + dotest devcom2-14 "${testcvs} edit w5" \ +"${PROG} edit: no such file w5; ignored" + dotest devcom2-15 "${testcvs} editors" '' + dotest devcom2-16 "${testcvs} editors w4" '' + # Make sure there are no droppings lying around + dotest devcom2-17 "cat ${CVSROOT_DIRNAME}/first-dir/CVS/fileattr" \ +"Fw1 _watched= +Fw2 _watched= +Fw3 _watched= +Fnw1 _watched= +D _watched=" + cd .. + cd .. # Use -f because of the readonly files. @@ -4936,17 +6500,114 @@ G@#..!@#=&" rm -rf ${CVSROOT_DIRNAME}/first-dir ;; + watch4) + # More watch tests, including adding directories. + mkdir 1; cd 1 + dotest watch4-0a "${testcvs} -q co -l ." '' + mkdir first-dir + dotest watch4-0b "${testcvs} add first-dir" \ +"Directory ${TESTDIR}/cvsroot/first-dir added to the repository" + + cd first-dir + dotest watch4-1 "${testcvs} watch on" '' + # This is just like the 173 test + touch file1 + dotest watch4-2 "${testcvs} add file1" \ +"${PROG} [a-z]*: scheduling file .file1. for addition +${PROG} [a-z]*: use .${PROG} commit. to add this file permanently" + dotest watch4-3 "${testcvs} -q ci -m add" \ +"RCS file: ${TESTDIR}/cvsroot/first-dir/file1,v +done +Checking in file1; +${TESTDIR}/cvsroot/first-dir/file1,v <-- file1 +initial revision: 1\.1 +done" + # Now test the analogous behavior for directories. + mkdir subdir + dotest watch4-4 "${testcvs} add subdir" \ +"Directory ${TESTDIR}/cvsroot/first-dir/subdir added to the repository" + cd subdir + touch sfile + dotest watch4-5 "${testcvs} add sfile" \ +"${PROG} [a-z]*: scheduling file .sfile. for addition +${PROG} [a-z]*: use .${PROG} commit. to add this file permanently" + dotest watch4-6 "${testcvs} -q ci -m add" \ +"RCS file: ${TESTDIR}/cvsroot/first-dir/subdir/sfile,v +done +Checking in sfile; +${TESTDIR}/cvsroot/first-dir/subdir/sfile,v <-- sfile +initial revision: 1\.1 +done" + cd ../../.. + mkdir 2; cd 2 + dotest watch4-7 "${testcvs} -q co first-dir" "U first-dir/file1 +U first-dir/subdir/sfile" + dotest_fail watch4-8 "test -w first-dir/file1" '' + dotest_fail watch4-9 "test -w first-dir/subdir/sfile" '' + cd first-dir + dotest watch4-10 "${testcvs} edit file1" '' + echo 'edited in 2' >file1 + cd ../.. + + cd 1/first-dir + dotest watch4-11 "${testcvs} edit file1" '' + echo 'edited in 1' >file1 + dotest watch4-12 "${testcvs} -q ci -m edit-in-1" \ +"Checking in file1; +${TESTDIR}/cvsroot/first-dir/file1,v <-- file1 +new revision: 1\.2; previous revision: 1\.1 +done" + cd ../.. + cd 2/first-dir + dotest watch4-13 "${testcvs} -q update" \ +"RCS file: ${TESTDIR}/cvsroot/first-dir/file1,v +retrieving revision 1\.1 +retrieving revision 1\.2 +Merging differences between 1\.1 and 1\.2 into file1 +rcsmerge: warning: conflicts during merge +${PROG} [a-z]*: conflicts found in file1 +C file1" + if (echo yes | ${testcvs} unedit file1) >>${LOGFILE}; then + pass watch4-14 + else + fail watch4-15 + fi + # This could plausibly be defined to either go back to the revision + # which was cvs edit'd (the status quo), or back to revision 1.2 + # (that is, the merge could update CVS/Base/file1). We pick the + # former because it is easier to implement, not because we have + # thought much about which is better. + dotest watch4-16 "cat file1" '' + # Make sure CVS really thinks we are at 1.1. + dotest watch4-17 "${testcvs} -q update" "U file1" + dotest watch4-18 "cat file1" "edited in 1" + cd ../.. + + # As a sanity check, make sure we are in the right place. + dotest watch4-cleanup-1 "test -d 1" '' + dotest watch4-cleanup-1 "test -d 2" '' + # Specify -f because of the readonly files. + rm -rf 1 2 + rm -rf ${CVSROOT_DIRNAME}/first-dir + ;; + ignore) + # On Windows, we can't check out CVSROOT, because the case + # insensitivity means that this conflicts with cvsroot. + mkdir wnt + cd wnt + dotest 187a1 "${testcvs} -q co CVSROOT" "U CVSROOT/${DOTSTAR}" cd CVSROOT echo rootig.c >cvsignore dotest 187a2 "${testcvs} add cvsignore" "${PROG}"' [a-z]*: scheduling file `cvsignore'"'"' for addition -'"${PROG}"' [a-z]*: use '"'"'cvs commit'"'"' to add this file permanently' +'"${PROG}"' [a-z]*: use .'"${PROG}"' commit. to add this file permanently' # As of Jan 96, local CVS prints "Examining ." and remote doesn't. # Accept either. dotest 187a3 " ${testcvs} ci -m added" \ -"${DOTSTAR}CS file: ${TESTDIR}/cvsroot/CVSROOT/cvsignore,v +"${PROG} [a-z]*: Examining \. +RCS file: ${TESTDIR}/cvsroot/CVSROOT/cvsignore,v done Checking in cvsignore; ${TESTDIR}/cvsroot/CVSROOT/cvsignore,v <-- cvsignore @@ -4956,10 +6617,9 @@ ${PROG} [a-z]*: Rebuilding administrative file database" cd .. if echo "yes" | ${testcvs} release -d CVSROOT >>${LOGFILE} ; then - echo 'PASS: test 187a4' >>${LOGFILE} + pass 187a4 else - echo 'FAIL: test 187a4' | tee -a ${LOGFILE} - exit 1 + fail 187a4 fi # CVS looks at the home dir from getpwuid, not HOME (is that correct @@ -4969,32 +6629,27 @@ ${PROG} [a-z]*: Rebuilding administrative file database" mkdir dir-to-import cd dir-to-import touch foobar.c bar.c rootig.c defig.o envig.c optig.c - # We really should allow the files to be listed in any order. - # But we (kludgily) just list the orders which have been observed. - dotest 188a "${testcvs} import -m m -I optig.c first-dir tag1 tag2" \ - 'N first-dir/foobar.c -N first-dir/bar.c -I first-dir/rootig.c -I first-dir/defig.o -I first-dir/envig.c -I first-dir/optig.c + # We use sort because we can't predict the order in which + # the files will be listed. + dotest_sort 188a "${testcvs} import -m m -I optig.c first-dir tag1 tag2" \ +' -No conflicts created by this import' 'I first-dir/defig.o +I first-dir/defig.o I first-dir/envig.c I first-dir/optig.c -N first-dir/foobar.c -N first-dir/bar.c I first-dir/rootig.c - +N first-dir/bar.c +N first-dir/foobar.c No conflicts created by this import' - dotest 188b "${testcvs} import -m m -I ! second-dir tag3 tag4" \ - 'N second-dir/foobar.c + dotest_sort 188b "${testcvs} import -m m -I ! second-dir tag3 tag4" \ +' + N second-dir/bar.c -N second-dir/rootig.c N second-dir/defig.o N second-dir/envig.c +N second-dir/foobar.c N second-dir/optig.c - +N second-dir/rootig.c No conflicts created by this import' cd .. rm -r dir-to-import @@ -5015,11 +6670,12 @@ U first-dir/foobar.c' dotest 189c "${testcvs} -q update -I optig.c" "${QUESTION} notig.c" # The fact that CVS requires us to specify -I CVS here strikes me # as a bug. - dotest 189d "${testcvs} -q update -I ! -I CVS" "${QUESTION} rootig.c -${QUESTION} defig.o + dotest_sort 189d "${testcvs} -q update -I ! -I CVS" \ +"${QUESTION} defig.o ${QUESTION} envig.c +${QUESTION} notig.c ${QUESTION} optig.c -${QUESTION} notig.c" +${QUESTION} rootig.c" # Now test that commands other than update also print "? notig.c" # where appropriate. Only test this for remote, because local @@ -5045,26 +6701,17 @@ ${QUESTION} notig.c" echo notig.c >first-dir/.cvsignore echo foobar.c >second-dir/.cvsignore touch first-dir/notig.c second-dir/notig.c second-dir/foobar.c - dotest 190 "${testcvs} -qn update" \ + dotest_sort 190 "${testcvs} -qn update" \ "${QUESTION} first-dir/.cvsignore ${QUESTION} second-dir/.cvsignore -${QUESTION} second-dir/notig.c" \ +${QUESTION} second-dir/notig.c" + dotest_sort 191 "${testcvs} -qn update -I! -I CVS" \ "${QUESTION} first-dir/.cvsignore -${QUESTION} second-dir/notig.c -${QUESTION} second-dir/.cvsignore" - dotest 191 "${testcvs} -qn update -I! -I CVS" \ -"${QUESTION} first-dir/rootig.c ${QUESTION} first-dir/defig.o ${QUESTION} first-dir/envig.c -${QUESTION} first-dir/.cvsignore +${QUESTION} first-dir/rootig.c ${QUESTION} second-dir/.cvsignore -${QUESTION} second-dir/notig.c" \ -"${QUESTION} first-dir/rootig.c -${QUESTION} first-dir/defig.o -${QUESTION} first-dir/envig.c -${QUESTION} first-dir/.cvsignore -${QUESTION} second-dir/notig.c -${QUESTION} second-dir/.cvsignore" +${QUESTION} second-dir/notig.c" if echo yes | ${testcvs} release -d first-dir \ >${TESTDIR}/ignore.tmp; then @@ -5091,6 +6738,8 @@ You have \[1\] altered files in this repository. Are you sure you want to release (and delete) directory .second-dir': " cd .. rm -r 1 + cd .. + rm -r wnt rm ${TESTDIR}/ignore.tmp rm -rf ${CVSROOT_DIRNAME}/first-dir ${CVSROOT_DIRNAME}/second-dir ;; @@ -5107,7 +6756,7 @@ Are you sure you want to release (and delete) directory .second-dir': " cp ../binfile.dat binfile dotest binfiles-2 "${testcvs} add -kb binfile" \ "${PROG}"' [a-z]*: scheduling file `binfile'\'' for addition -'"${PROG}"' [a-z]*: use '\''cvs commit'\'' to add this file permanently' +'"${PROG}"' [a-z]*: use .'"${PROG}"' commit. to add this file permanently' dotest binfiles-3 "${testcvs} -q ci -m add-it" \ "RCS file: ${TESTDIR}/cvsroot/first-dir/binfile,v done @@ -5175,7 +6824,7 @@ done" echo 'edits in dir 2' >binfile dotest binfiles-con1 "${testcvs} -q update" \ "U binfile -${PROG} [a-z]*: binary file needs merge +${PROG} [a-z]*: nonmergeable file needs merge ${PROG} [a-z]*: revision 1\.3 from repository is now in binfile ${PROG} [a-z]*: file from working directory is now in \.#binfile\.1\.2 C binfile" @@ -5191,14 +6840,11 @@ done" cd ../../1/first-dir dotest binfiles-con5 "${testcvs} -q update" '[UP] binfile' - # The bugs which these test for are apparently not fixed for remote. - if test "$remote" = no; then - dotest binfiles-9 "${testcvs} -q update -A" '' - dotest binfiles-10 "${testcvs} -q update -kk" '[UP] binfile' - dotest binfiles-11 "${testcvs} -q update" '' - dotest binfiles-12 "${testcvs} -q update -A" '[UP] binfile' - dotest binfiles-13 "${testcvs} -q update -A" '' - fi + dotest binfiles-9 "${testcvs} -q update -A" '' + dotest binfiles-10 "${testcvs} -q update -kk" '[UP] binfile' + dotest binfiles-11 "${testcvs} -q update" '' + dotest binfiles-12 "${testcvs} -q update -A" '[UP] binfile' + dotest binfiles-13 "${testcvs} -q update -A" '' cd ../.. rm -r 1 @@ -5270,7 +6916,7 @@ File: binfile Status: Up-to-date # Do sticky options work when used with 'cvs update'? echo "Not a binary file." > nibfile dotest binfiles-sticky1 "${testcvs} -q add nibfile" \ -"${PROG} [a-z]*: use "\''cvs commit'\'' to add this file permanently' +"${PROG} [a-z]*: use .${PROG} commit. to add this file permanently" dotest binfiles-sticky2 "${testcvs} -q ci -m add-it nibfile" \ "RCS file: ${TESTDIR}/cvsroot/first-dir/nibfile,v done @@ -5289,7 +6935,53 @@ File: nibfile Status: Up-to-date Sticky Tag: (none) Sticky Date: (none) Sticky Options: -kb" - # Eventually we should test that -A removes the -kb here... + + # Now test that -A can clear the sticky option. + dotest binfiles-sticky5 "${testcvs} -q update -A nibfile" \ +"[UP] nibfile" + dotest binfiles-sticky6 "${testcvs} -q status nibfile" \ +"=================================================================== +File: nibfile Status: Up-to-date + + Working revision: 1\.1.* + Repository revision: 1\.1 ${TESTDIR}/cvsroot/first-dir/nibfile,v + Sticky Tag: (none) + Sticky Date: (none) + Sticky Options: (none)" + dotest binfiles-15 "${testcvs} -q admin -kb nibfile" \ +"RCS file: ${TESTDIR}/cvsroot/first-dir/nibfile,v +done" + dotest binfiles-16 "${testcvs} -q update nibfile" "[UP] nibfile" + dotest binfiles-17 "${testcvs} -q status nibfile" \ +"=================================================================== +File: nibfile Status: Up-to-date + + Working revision: 1\.1.* + Repository revision: 1\.1 ${TESTDIR}/cvsroot/first-dir/nibfile,v + Sticky Tag: (none) + Sticky Date: (none) + Sticky Options: -kb" + + dotest binfiles-o1 "${testcvs} admin -o1.3:: binfile" \ +"RCS file: ${TESTDIR}/cvsroot/first-dir/binfile,v +deleting revision 1\.5 +deleting revision 1\.4 +done" + dotest binfiles-o2 "${testcvs} admin -o::1.3 binfile" \ +"RCS file: ${TESTDIR}/cvsroot/first-dir/binfile,v +deleting revision 1\.2 +deleting revision 1\.1 +done" + dotest binfiles-o3 "${testcvs} -q log -h -N binfile" " +RCS file: ${TESTDIR}/cvsroot/first-dir/binfile,v +Working file: binfile +head: 1\.3 +branch: +locks: strict +access list: +keyword substitution: v +total revisions: 1 +=============================================================================" cd ../.. rm -rf ${CVSROOT_DIRNAME}/first-dir @@ -5302,56 +6994,342 @@ File: nibfile Status: Up-to-date # doesn't print "cannot merge binary files" or some such, in # situations where no merging is required. # See also "join" which does this with non-binary files. + # + # Cases (we are merging from the branch to the trunk): + # binfile.dat) File added on branch, not on trunk. + # File should be marked for addition. + # brmod) File modified on branch, not on trunk. + # File should be copied over to trunk (no merging is needed). + # brmod-trmod) File modified on branch, also on trunk. + # This is a conflict. Present the user with both files and + # let them figure it out. + # brmod-wdmod) File modified on branch, not modified in the trunk + # repository, but modified in the (trunk) working directory. + # This is also a conflict. mkdir ${CVSROOT_DIRNAME}/first-dir mkdir 1; cd 1 dotest binfiles2-1 "${testcvs} -q co first-dir" '' cd first-dir + + # The most important thing here is that binfile, binfile2, &c + # each be distinct from each other. We also make sure to include + # a few likely end-of-line patterns to make sure nothing is + # being munged as if in text mode. + awk 'BEGIN { printf "%c%c%c%c%c%c", 2, 10, 137, 0, 13, 10 }' \ + </dev/null >../binfile + cat ../binfile ../binfile >../binfile2 + cat ../binfile2 ../binfile >../binfile3 + # FIXCVS: unless a branch has at least one file on it, - # tag_check_valid won't know it exists. So creating a - # file here is a workaround. - touch dummy - dotest binfiles2-1a "${testcvs} add dummy" \ -"${PROG} [a-z]*: scheduling file .dummy. for addition -${PROG} [a-z]*: use .cvs commit. to add this file permanently" - dotest binfiles2-1b "${testcvs} -q ci -m add-it" \ -"RCS file: ${TESTDIR}/cvsroot/first-dir/dummy,v -done -Checking in dummy; -${TESTDIR}/cvsroot/first-dir/dummy,v <-- dummy + # tag_check_valid won't know it exists. So if brmod didn't + # exist, we would have to invent it. + cp ../binfile brmod + cp ../binfile brmod-trmod + cp ../binfile brmod-wdmod + dotest binfiles2-1a \ +"${testcvs} add -kb brmod brmod-trmod brmod-wdmod" \ +"${PROG} [a-z]*: scheduling file .brmod. for addition +${PROG} [a-z]*: scheduling file .brmod-trmod. for addition +${PROG} [a-z]*: scheduling file .brmod-wdmod. for addition +${PROG} [a-z]*: use .${PROG} commit. to add these files permanently" + dotest binfiles2-1b "${testcvs} -q ci -m add" \ +"RCS file: ${TESTDIR}/cvsroot/first-dir/brmod,v +done +Checking in brmod; +${TESTDIR}/cvsroot/first-dir/brmod,v <-- brmod +initial revision: 1\.1 +done +RCS file: ${TESTDIR}/cvsroot/first-dir/brmod-trmod,v +done +Checking in brmod-trmod; +${TESTDIR}/cvsroot/first-dir/brmod-trmod,v <-- brmod-trmod +initial revision: 1\.1 +done +RCS file: ${TESTDIR}/cvsroot/first-dir/brmod-wdmod,v +done +Checking in brmod-wdmod; +${TESTDIR}/cvsroot/first-dir/brmod-wdmod,v <-- brmod-wdmod initial revision: 1\.1 done" - dotest binfiles2-2 "${testcvs} -q tag -b br" 'T dummy' + dotest binfiles2-2 "${testcvs} -q tag -b br" 'T brmod +T brmod-trmod +T brmod-wdmod' dotest binfiles2-3 "${testcvs} -q update -r br" '' - awk 'BEGIN { printf "%c%c%c%c%c%c", 2, 10, 137, 0, 13, 10 }' \ - </dev/null >../binfile cp ../binfile binfile.dat dotest binfiles2-4 "${testcvs} add -kb binfile.dat" \ "${PROG} [a-z]*: scheduling file .binfile\.dat. for addition on branch .br. -${PROG} [a-z]*: use .cvs commit. to add this file permanently" - dotest binfiles2-5 "${testcvs} -q ci -m add-it" \ +${PROG} [a-z]*: use .${PROG} commit. to add this file permanently" + cp ../binfile2 brmod + cp ../binfile2 brmod-trmod + cp ../binfile2 brmod-wdmod + dotest binfiles2-5 "${testcvs} -q ci -m br-changes" \ "RCS file: ${TESTDIR}/cvsroot/first-dir/Attic/binfile\.dat,v done Checking in binfile\.dat; ${TESTDIR}/cvsroot/first-dir/Attic/binfile\.dat,v <-- binfile\.dat new revision: 1\.1\.2\.1; previous revision: 1\.1 +done +Checking in brmod; +${TESTDIR}/cvsroot/first-dir/brmod,v <-- brmod +new revision: 1\.1\.2\.1; previous revision: 1\.1 +done +Checking in brmod-trmod; +${TESTDIR}/cvsroot/first-dir/brmod-trmod,v <-- brmod-trmod +new revision: 1\.1\.2\.1; previous revision: 1\.1 +done +Checking in brmod-wdmod; +${TESTDIR}/cvsroot/first-dir/brmod-wdmod,v <-- brmod-wdmod +new revision: 1\.1\.2\.1; previous revision: 1\.1 done" dotest binfiles2-6 "${testcvs} -q update -A" \ -"${PROG} [a-z]*: warning: binfile\.dat is not (any longer) pertinent" +"${PROG} [a-z]*: warning: binfile\.dat is not (any longer) pertinent +[UP] brmod +[UP] brmod-trmod +[UP] brmod-wdmod" dotest_fail binfiles2-7 "test -f binfile.dat" '' - dotest binfiles2-8 "${testcvs} -q update -j br" "U binfile.dat" + dotest binfiles2-7-brmod "cmp ../binfile brmod" + cp ../binfile3 brmod-trmod + dotest binfiles2-7a "${testcvs} -q ci -m tr-modify" \ +"Checking in brmod-trmod; +${TESTDIR}/cvsroot/first-dir/brmod-trmod,v <-- brmod-trmod +new revision: 1\.2; previous revision: 1\.1 +done" + cp ../binfile3 brmod-wdmod + + dotest binfiles2-8 "${testcvs} -q update -j br" \ +"U binfile\.dat +U brmod +${PROG} [a-z]*: nonmergeable file needs merge +${PROG} [a-z]*: revision 1.1.2.1 from repository is now in brmod-trmod +${PROG} [a-z]*: file from working directory is now in .#brmod-trmod.1.2 +C brmod-trmod +M brmod-wdmod +${PROG} [a-z]*: nonmergeable file needs merge +${PROG} [a-z]*: revision 1.1.2.1 from repository is now in brmod-wdmod +${PROG} [a-z]*: file from working directory is now in .#brmod-wdmod.1.1 +C brmod-wdmod" + dotest binfiles2-9 "cmp ../binfile binfile.dat" + dotest binfiles2-9-brmod "cmp ../binfile2 brmod" + dotest binfiles2-9-brmod-trmod "cmp ../binfile2 brmod-trmod" + dotest binfiles2-9-brmod-trmod "cmp ../binfile2 brmod-wdmod" + dotest binfiles2-9a-brmod-trmod "cmp ../binfile3 .#brmod-trmod.1.2" + dotest binfiles2-9a-brmod-wdmod "cmp ../binfile3 .#brmod-wdmod.1.1" + + # Test that everything was properly scheduled. + dotest binfiles2-10 "${testcvs} -q ci -m checkin" \ +"Checking in binfile\.dat; +${TESTDIR}/cvsroot/first-dir/binfile\.dat,v <-- binfile\.dat +new revision: 1\.2; previous revision: 1\.1 +done +Checking in brmod; +${TESTDIR}/cvsroot/first-dir/brmod,v <-- brmod +new revision: 1\.2; previous revision: 1\.1 +done +Checking in brmod-trmod; +${TESTDIR}/cvsroot/first-dir/brmod-trmod,v <-- brmod-trmod +new revision: 1\.3; previous revision: 1\.2 +done +Checking in brmod-wdmod; +${TESTDIR}/cvsroot/first-dir/brmod-wdmod,v <-- brmod-wdmod +new revision: 1\.2; previous revision: 1\.1 +done" + + dotest_fail binfiles2-o1 "${testcvs} -q admin -o :1.2 brmod-trmod" \ +"RCS file: ${TESTDIR}/cvsroot/first-dir/brmod-trmod,v +deleting revision 1\.2 +${PROG} [a-z]*: ${TESTDIR}/cvsroot/first-dir/brmod-trmod,v: can't remove branch point 1\.1 +${PROG} [a-z]*: cannot modify RCS file for .brmod-trmod." + dotest binfiles2-o2 "${testcvs} -q admin -o 1.1.2.1: brmod-trmod" \ +"RCS file: ${TESTDIR}/cvsroot/first-dir/brmod-trmod,v +deleting revision 1\.1\.2\.1 +done" + dotest binfiles2-o3 "${testcvs} -q admin -o :1.2 brmod-trmod" \ +"RCS file: ${TESTDIR}/cvsroot/first-dir/brmod-trmod,v +deleting revision 1\.2 +deleting revision 1\.1 +done" + dotest binfiles2-o4 "${testcvs} -q log -N brmod-trmod" " +RCS file: ${TESTDIR}/cvsroot/first-dir/brmod-trmod,v +Working file: brmod-trmod +head: 1\.3 +branch: +locks: strict +access list: +keyword substitution: b +total revisions: 1; selected revisions: 1 +description: +---------------------------- +revision 1\.3 +date: [0-9/]* [0-9:]*; author: ${username}; state: Exp; +checkin +=============================================================================" + cd .. + cd .. + + rm -rf ${CVSROOT_DIRNAME}/first-dir + rm -r 1 + ;; + + mcopy) + # See comment at "mwrap" test for list of other wrappers tests. + # Test cvs's ability to handle nonmergeable files specified with + # -m 'COPY' in wrappers. Similar to the binfiles2 test, + # which tests the same thing for binary files + # (which are non-mergeable in the same sense). + # + # Cases (we are merging from the branch to the trunk): + # brmod) File modified on branch, not on trunk. + # File should be copied over to trunk (no merging is needed). + # brmod-trmod) File modified on branch, also on trunk. + # This is a conflict. Present the user with both files and + # let them figure it out. + # brmod-wdmod) File modified on branch, not modified in the trunk + # repository, but modified in the (trunk) working directory. + # This is also a conflict. + + # For the moment, remote CVS can't pass wrappers from CVSWRAPPERS + # (see wrap_send). So skip these tests for remote. + if test "x$remote" = xno; then + + mkdir ${CVSROOT_DIRNAME}/first-dir + mkdir 1; cd 1 + dotest mcopy-1 "${testcvs} -q co first-dir" '' + cd first-dir + + # FIXCVS: unless a branch has at least one file on it, + # tag_check_valid won't know it exists. So if brmod didn't + # exist, we would have to invent it. + echo 'brmod initial contents' >brmod + echo 'brmod-trmod initial contents' >brmod-trmod + echo 'brmod-wdmod initial contents' >brmod-wdmod + echo "* -m 'COPY'" >.cvswrappers + dotest mcopy-1a \ +"${testcvs} add .cvswrappers brmod brmod-trmod brmod-wdmod" \ +"${PROG} [a-z]*: scheduling file .\.cvswrappers. for addition +${PROG} [a-z]*: scheduling file .brmod. for addition +${PROG} [a-z]*: scheduling file .brmod-trmod. for addition +${PROG} [a-z]*: scheduling file .brmod-wdmod. for addition +${PROG} [a-z]*: use .${PROG} commit. to add these files permanently" + dotest mcopy-1b "${testcvs} -q ci -m add" \ +"RCS file: ${TESTDIR}/cvsroot/first-dir/\.cvswrappers,v +done +Checking in \.cvswrappers; +${TESTDIR}/cvsroot/first-dir/\.cvswrappers,v <-- \.cvswrappers +initial revision: 1\.1 +done +RCS file: ${TESTDIR}/cvsroot/first-dir/brmod,v +done +Checking in brmod; +${TESTDIR}/cvsroot/first-dir/brmod,v <-- brmod +initial revision: 1\.1 +done +RCS file: ${TESTDIR}/cvsroot/first-dir/brmod-trmod,v +done +Checking in brmod-trmod; +${TESTDIR}/cvsroot/first-dir/brmod-trmod,v <-- brmod-trmod +initial revision: 1\.1 +done +RCS file: ${TESTDIR}/cvsroot/first-dir/brmod-wdmod,v +done +Checking in brmod-wdmod; +${TESTDIR}/cvsroot/first-dir/brmod-wdmod,v <-- brmod-wdmod +initial revision: 1\.1 +done" + + # NOTE: .cvswrappers files are broken (see comment in + # src/wrapper.c). So doing everything via the environment + # variable is a workaround. Better would be to test them + # both. + CVSWRAPPERS="* -m 'COPY'" + export CVSWRAPPERS + dotest mcopy-2 "${testcvs} -q tag -b br" 'T \.cvswrappers +T brmod +T brmod-trmod +T brmod-wdmod' + dotest mcopy-3 "${testcvs} -q update -r br" '' + echo 'modify brmod on br' >brmod + echo 'modify brmod-trmod on br' >brmod-trmod + echo 'modify brmod-wdmod on br' >brmod-wdmod + dotest mcopy-5 "${testcvs} -q ci -m br-changes" \ +"Checking in brmod; +${TESTDIR}/cvsroot/first-dir/brmod,v <-- brmod +new revision: 1\.1\.2\.1; previous revision: 1\.1 +done +Checking in brmod-trmod; +${TESTDIR}/cvsroot/first-dir/brmod-trmod,v <-- brmod-trmod +new revision: 1\.1\.2\.1; previous revision: 1\.1 +done +Checking in brmod-wdmod; +${TESTDIR}/cvsroot/first-dir/brmod-wdmod,v <-- brmod-wdmod +new revision: 1\.1\.2\.1; previous revision: 1\.1 +done" + dotest mcopy-6 "${testcvs} -q update -A" \ +"[UP] brmod +[UP] brmod-trmod +[UP] brmod-wdmod" + dotest mcopy-7 "cat brmod brmod-trmod brmod-wdmod" \ +"brmod initial contents +brmod-trmod initial contents +brmod-wdmod initial contents" + + echo 'modify brmod-trmod again on trunk' >brmod-trmod + dotest mcopy-7a "${testcvs} -q ci -m tr-modify" \ +"Checking in brmod-trmod; +${TESTDIR}/cvsroot/first-dir/brmod-trmod,v <-- brmod-trmod +new revision: 1\.2; previous revision: 1\.1 +done" + echo 'modify brmod-wdmod in working dir' >brmod-wdmod + + dotest mcopy-8 "${testcvs} -q update -j br" \ +"U brmod +${PROG} [a-z]*: nonmergeable file needs merge +${PROG} [a-z]*: revision 1.1.2.1 from repository is now in brmod-trmod +${PROG} [a-z]*: file from working directory is now in .#brmod-trmod.1.2 +C brmod-trmod +M brmod-wdmod +${PROG} [a-z]*: nonmergeable file needs merge +${PROG} [a-z]*: revision 1.1.2.1 from repository is now in brmod-wdmod +${PROG} [a-z]*: file from working directory is now in .#brmod-wdmod.1.1 +C brmod-wdmod" + + dotest mcopy-9 "cat brmod brmod-trmod brmod-wdmod" \ +"modify brmod on br +modify brmod-trmod on br +modify brmod-wdmod on br" + dotest mcopy-9a "cat .#brmod-trmod.1.2 .#brmod-wdmod.1.1" \ +"modify brmod-trmod again on trunk +modify brmod-wdmod in working dir" + + # Test that everything was properly scheduled. + dotest mcopy-10 "${testcvs} -q ci -m checkin" \ +"Checking in brmod; +${TESTDIR}/cvsroot/first-dir/brmod,v <-- brmod +new revision: 1\.2; previous revision: 1\.1 +done +Checking in brmod-trmod; +${TESTDIR}/cvsroot/first-dir/brmod-trmod,v <-- brmod-trmod +new revision: 1\.3; previous revision: 1\.2 +done +Checking in brmod-wdmod; +${TESTDIR}/cvsroot/first-dir/brmod-wdmod,v <-- brmod-wdmod +new revision: 1\.2; previous revision: 1\.1 +done" cd .. cd .. rm -rf ${CVSROOT_DIRNAME}/first-dir rm -r 1 + unset CVSWRAPPERS + + fi # end of tests to be skipped for remote + ;; binwrap) # Test the ability to specify binary-ness based on file name. - # We could also be testing the ability to use the other - # ways to specify a wrapper (CVSROOT/cvswrappers, etc.). + # See "mwrap" for a list of other wrappers tests. mkdir dir-to-import cd dir-to-import @@ -5394,9 +7372,311 @@ File: foo\.exe Status: Up-to-date rm -rf ${CVSROOT_DIRNAME}/first-dir ;; + binwrap2) + # Test the ability to specify binary-ness based on file name. + # See "mwrap" for a list of other wrappers tests. + + mkdir dir-to-import + cd dir-to-import + touch foo.c foo.exe + + # Specify that all files are binary except *.c. + # The order seems to matter, with the earlier rules taking + # precedence. I'm not sure whether that is good or not, + # but it is the current behavior. + if ${testcvs} import -m message -I ! \ + -W "*.c -k 'o'" -W "* -k 'b'" \ + first-dir tag1 tag2 >>${LOGFILE}; then + pass binwrap2-1 + else + fail binwrap2-1 + fi + cd .. + rm -r dir-to-import + dotest binwrap2-2 "${testcvs} -q co first-dir" 'U first-dir/foo.c +U first-dir/foo.exe' + dotest binwrap2-3 "${testcvs} -q status first-dir" \ +"=================================================================== +File: foo\.c Status: Up-to-date + + Working revision: 1\.1\.1\.1.* + Repository revision: 1\.1\.1\.1 ${TESTDIR}/cvsroot/first-dir/foo\.c,v + Sticky Tag: (none) + Sticky Date: (none) + Sticky Options: -ko + +=================================================================== +File: foo\.exe Status: Up-to-date + + Working revision: 1\.1\.1\.1.* + Repository revision: 1\.1\.1\.1 ${TESTDIR}/cvsroot/first-dir/foo\.exe,v + Sticky Tag: (none) + Sticky Date: (none) + Sticky Options: -kb" + rm -r first-dir + rm -rf ${CVSROOT_DIRNAME}/first-dir + ;; + + binwrap3) + # Test communication of file-specified -k wrappers between + # client and server, in `import': + # + # 1. Set up a directory tree, populate it with files. + # 2. Give each directory a different .cvswrappers file. + # 3. Give the server its own .cvswrappers file. + # 4. Import the whole tree, see if the right files got set + # to binary. + # + # The tree has a top ("0th") level, and two subdirs, sub1/ + # and sub2/; sub2/ contains directory subsub/. Every + # directory has a .cvswrappers file as well as regular + # files. + # + # In the file names, "foo-b.*" should end up binary, and + # "foo-t.*" should end up text. Don't worry about the two + # letter extensions; they're just there to help me keep + # things straight. + # + # Here's the directory tree: + # + # ./ + # .cvswrappers + # foo-b.c0 + # foo-b.sb + # foo-t.c1 + # foo-t.st + # + # sub1/ sub2/ + # .cvswrappers .cvswrappers + # foo-b.c1 foo-b.sb + # foo-b.sb foo-b.st + # foo-t.c0 foo-t.c0 + # foo-t.st foo-t.c1 + # foo-t.c2 + # foo-t.c3 + # + # subsub/ + # .cvswrappers + # foo-b.c3 + # foo-b.sb + # foo-t.c0 + # foo-t.c1 + # foo-t.c2 + # foo-t.st + + binwrap3_line1="This is a test file " + binwrap3_line2="containing little of use " + binwrap3_line3="except this non-haiku" + + binwrap3_text="${binwrap3_line1}${binwrap3_line2}${binwrap3_line3}" + + cd ${TESTDIR} + + # On Windows, we can't check out CVSROOT, because the case + # insensitivity means that this conflicts with cvsroot. + mkdir wnt + cd wnt + + mkdir binwrap3 # the 0th dir + mkdir binwrap3/sub1 + mkdir binwrap3/sub2 + mkdir binwrap3/sub2/subsub + + echo "*.c0 -k 'b'" > binwrap3/.cvswrappers + echo "whatever -k 'b'" >> binwrap3/.cvswrappers + echo ${binwrap3_text} > binwrap3/foo-b.c0 + echo ${binwrap3_text} > binwrap3/foo-b.sb + echo ${binwrap3_text} > binwrap3/foo-t.c1 + echo ${binwrap3_text} > binwrap3/foo-t.st + + echo "*.c1 -k 'b'" > binwrap3/sub1/.cvswrappers + echo "whatever -k 'b'" >> binwrap3/sub1/.cvswrappers + echo ${binwrap3_text} > binwrap3/sub1/foo-b.c1 + echo ${binwrap3_text} > binwrap3/sub1/foo-b.sb + echo ${binwrap3_text} > binwrap3/sub1/foo-t.c0 + echo ${binwrap3_text} > binwrap3/sub1/foo-t.st + + echo "*.st -k 'b'" > binwrap3/sub2/.cvswrappers + echo ${binwrap3_text} > binwrap3/sub2/foo-b.sb + echo ${binwrap3_text} > binwrap3/sub2/foo-b.st + echo ${binwrap3_text} > binwrap3/sub2/foo-t.c0 + echo ${binwrap3_text} > binwrap3/sub2/foo-t.c1 + echo ${binwrap3_text} > binwrap3/sub2/foo-t.c2 + echo ${binwrap3_text} > binwrap3/sub2/foo-t.c3 + + echo "*.c3 -k 'b'" > binwrap3/sub2/subsub/.cvswrappers + echo "foo -k 'b'" >> binwrap3/sub2/subsub/.cvswrappers + echo "c0* -k 'b'" >> binwrap3/sub2/subsub/.cvswrappers + echo ${binwrap3_text} > binwrap3/sub2/subsub/foo-b.c3 + echo ${binwrap3_text} > binwrap3/sub2/subsub/foo-b.sb + echo ${binwrap3_text} > binwrap3/sub2/subsub/foo-t.c0 + echo ${binwrap3_text} > binwrap3/sub2/subsub/foo-t.c1 + echo ${binwrap3_text} > binwrap3/sub2/subsub/foo-t.c2 + echo ${binwrap3_text} > binwrap3/sub2/subsub/foo-t.st + + # Now set up CVSROOT/cvswrappers, the easy way: + dotest binwrap3-1 "${testcvs} -q co CVSROOT" "[UP] CVSROOT${DOTSTAR}" + cd CVSROOT + # This destroys anything currently in cvswrappers, but + # presumably other tests will take care of it themselves if + # they use cvswrappers: + echo "foo*.sb -k 'b'" > cvswrappers + dotest binwrap3-2 "${testcvs} -q ci -m cvswrappers-mod" \ +"Checking in cvswrappers; +${TESTDIR}/cvsroot/CVSROOT/cvswrappers,v <-- cvswrappers +new revision: 1\.[0-9]*; previous revision: 1\.[0-9]* +done +${PROG} [a-z]*: Rebuilding administrative file database" + cd .. + + # Avoid environmental interference + CVSWRAPPERS_SAVED=${CVSWRAPPERS} + unset CVSWRAPPERS + + # Do the import + cd binwrap3 + # Not importing .cvswrappers tests whether the client is really + # letting the server know "honestly" whether the file is binary, + # rather than just letting the server see the .cvswrappers file. + dotest binwrap3-2a \ +"${testcvs} import -m . -I .cvswrappers binwrap3 tag1 tag2" \ +"[NI] ${DOTSTAR}" + + # OK, now test "cvs add". + cd .. + rm -r binwrap3 + dotest binwrap3-2b "${testcvs} co binwrap3" "${DOTSTAR}" + cd binwrap3 + cd sub2 + echo "*.newbin -k 'b'" > .cvswrappers + echo .cvswrappers >.cvsignore + echo .cvsignore >>.cvsignore + touch file1.newbin file1.txt + dotest binwrap3-2c "${testcvs} add file1.newbin file1.txt" \ +"${PROG} [a-z]*: scheduling file .file1\.newbin. for addition +${PROG} [a-z]*: scheduling file .file1\.txt. for addition +${PROG} [a-z]*: use .${PROG} commit. to add these files permanently" + dotest binwrap3-2d "${testcvs} -q ci -m add" \ +"RCS file: ${TESTDIR}/cvsroot/binwrap3/sub2/file1\.newbin,v +done +Checking in file1\.newbin; +${TESTDIR}/cvsroot/binwrap3/sub2/file1\.newbin,v <-- file1\.newbin +initial revision: 1\.1 +done +RCS file: ${TESTDIR}/cvsroot/binwrap3/sub2/file1\.txt,v +done +Checking in file1\.txt; +${TESTDIR}/cvsroot/binwrap3/sub2/file1\.txt,v <-- file1\.txt +initial revision: 1\.1 +done" + cd .. + + # Now check out the module and see which files are binary. + cd .. + rm -r binwrap3 + dotest binwrap3-3 "${testcvs} co binwrap3" "${DOTSTAR}" + cd binwrap3 + + # Running "cvs status" and matching output is too + # error-prone, too likely to falsely fail. Instead, we'll + # just grep the Entries lines: + + dotest binwrap3-top1 "grep foo-b.c0 ./CVS/Entries" \ + "/foo-b.c0/1.1.1.1/[A-Za-z0-9 :]*/-kb/" + + dotest binwrap3-top2 "grep foo-b.sb ./CVS/Entries" \ + "/foo-b.sb/1.1.1.1/[A-Za-z0-9 :]*/-kb/" + + dotest binwrap3-top3 "grep foo-t.c1 ./CVS/Entries" \ + "/foo-t.c1/1.1.1.1/[A-Za-z0-9 :]*//" + + dotest binwrap3-top4 "grep foo-t.st ./CVS/Entries" \ + "/foo-t.st/1.1.1.1/[A-Za-z0-9 :]*//" + + dotest binwrap3-sub1-1 "grep foo-b.c1 sub1/CVS/Entries" \ + "/foo-b.c1/1.1.1.1/[A-Za-z0-9 :]*/-kb/" + + dotest binwrap3-sub1-2 "grep foo-b.sb sub1/CVS/Entries" \ + "/foo-b.sb/1.1.1.1/[A-Za-z0-9 :]*/-kb/" + + dotest binwrap3-sub1-3 "grep foo-t.c0 sub1/CVS/Entries" \ + "/foo-t.c0/1.1.1.1/[A-Za-z0-9 :]*//" + + dotest binwrap3-sub1-4 "grep foo-t.st sub1/CVS/Entries" \ + "/foo-t.st/1.1.1.1/[A-Za-z0-9 :]*//" + + dotest binwrap3-sub2-1 "grep foo-b.sb sub2/CVS/Entries" \ + "/foo-b.sb/1.1.1.1/[A-Za-z0-9 :]*/-kb/" + + dotest binwrap3-sub2-2 "grep foo-b.st sub2/CVS/Entries" \ + "/foo-b.st/1.1.1.1/[A-Za-z0-9 :]*/-kb/" + + dotest binwrap3-sub2-3 "grep foo-t.c0 sub2/CVS/Entries" \ + "/foo-t.c0/1.1.1.1/[A-Za-z0-9 :]*//" + + dotest binwrap3-sub2-4 "grep foo-t.c1 sub2/CVS/Entries" \ + "/foo-t.c1/1.1.1.1/[A-Za-z0-9 :]*//" + + dotest binwrap3-sub2-5 "grep foo-t.c2 sub2/CVS/Entries" \ + "/foo-t.c2/1.1.1.1/[A-Za-z0-9 :]*//" + + dotest binwrap3-sub2-6 "grep foo-t.c3 sub2/CVS/Entries" \ + "/foo-t.c3/1.1.1.1/[A-Za-z0-9 :]*//" + + dotest binwrap3-subsub1 "grep foo-b.c3 sub2/subsub/CVS/Entries" \ + "/foo-b.c3/1.1.1.1/[A-Za-z0-9 :]*/-kb/" + + dotest binwrap3-subsub2 "grep foo-b.sb sub2/subsub/CVS/Entries" \ + "/foo-b.sb/1.1.1.1/[A-Za-z0-9 :]*/-kb/" + + dotest binwrap3-subsub3 "grep foo-t.c0 sub2/subsub/CVS/Entries" \ + "/foo-t.c0/1.1.1.1/[A-Za-z0-9 :]*//" + + dotest binwrap3-subsub4 "grep foo-t.c1 sub2/subsub/CVS/Entries" \ + "/foo-t.c1/1.1.1.1/[A-Za-z0-9 :]*//" + + dotest binwrap3-subsub5 "grep foo-t.c2 sub2/subsub/CVS/Entries" \ + "/foo-t.c2/1.1.1.1/[A-Za-z0-9 :]*//" + + dotest binwrap3-subsub6 "grep foo-t.st sub2/subsub/CVS/Entries" \ + "/foo-t.st/1.1.1.1/[A-Za-z0-9 :]*//" + + dotest binwrap3-sub2-add1 "grep file1.newbin sub2/CVS/Entries" \ + "/file1.newbin/1.1/[A-Za-z0-9 :]*/-kb/" + dotest binwrap3-sub2-add2 "grep file1.txt sub2/CVS/Entries" \ + "/file1.txt/1.1/[A-Za-z0-9 :]*//" + + # Restore and clean up + cd .. + rm -r binwrap3 CVSROOT + cd .. + rm -r wnt + rm -rf ${CVSROOT_DIRNAME}/binwrap3 + CVSWRAPPERS=${CVSWRAPPERS_SAVED} + ;; + mwrap) - # Tests relating to the -m wrappers options. -k tests are in - # binwrap and -t/-f tests haven't been written yet. + # Tests of various wrappers features: + # -m 'COPY' and cvs update: mwrap + # -m 'COPY' and joining: mcopy + # -k: binwrap, binwrap2 + # -t/-f: hasn't been written yet. + # + # Tests of different ways of specifying wrappers: + # CVSROOT/cvswrappers: mwrap + # -W: binwrap, binwrap2 + # .cvswrappers in working directory, local: mcopy + # CVSROOT/cvswrappers, .cvswrappers remote: binwrap3 + # CVSWRAPPERS environment variable: mcopy + + # This test is similar to binfiles-con1; -m 'COPY' specifies + # non-mergeableness the same way that -kb does. + + # On Windows, we can't check out CVSROOT, because the case + # insensitivity means that this conflicts with cvsroot. + mkdir wnt + cd wnt + dotest mwrap-c1 "${testcvs} -q co CVSROOT" "[UP] CVSROOT${DOTSTAR}" cd CVSROOT echo "* -m 'COPY'" >>cvswrappers @@ -5416,7 +7696,7 @@ ${PROG} [a-z]*: Rebuilding administrative file database" touch aa dotest mwrap-3 "${testcvs} add aa" \ "${PROG} [a-z]*: scheduling file .aa. for addition -${PROG} [a-z]*: use .cvs commit. to add this file permanently" +${PROG} [a-z]*: use .${PROG} commit. to add this file permanently" dotest mwrap-4 "${testcvs} -q ci -m add" \ "RCS file: ${TESTDIR}/cvsroot/first-dir/aa,v done @@ -5438,14 +7718,14 @@ done" cd m1/first-dir echo "changed in m1" >aa dotest_fail mwrap-7 "${testcvs} -nq update" "C aa" - dotest_fail mwrap-8 "${testcvs} -q update" \ -"${PROG} [a-z]*: A -m .COPY. wrapper is specified -${PROG} [a-z]*: but file aa needs merge -${PROG} \[[a-z]* aborted\]: You probably want to avoid -m .COPY. wrappers" - # Under the old, dangerous behavior, this would have been - # "changed in m2" -- that is, the changes in the working directory - # would have been clobbered (!). - dotest mwrap-9 "cat aa" "changed in m1" + dotest mwrap-8 "${testcvs} -q update" \ +"U aa +${PROG} [a-z]*: nonmergeable file needs merge +${PROG} [a-z]*: revision 1\.2 from repository is now in aa +${PROG} [a-z]*: file from working directory is now in \.#aa\.1\.1 +C aa" + dotest mwrap-9 "cat aa" "changed in m2" + dotest mwrap-10 "cat .#aa.1.1" "changed in m1" cd ../.. cd CVSROOT echo '# comment out' >cvswrappers @@ -5458,11 +7738,26 @@ ${PROG} [a-z]*: Rebuilding administrative file database" cd .. rm -r CVSROOT rm -r m1 m2 + cd .. + rm -r wnt rm -rf ${CVSROOT_DIRNAME}/first-dir ;; info) - # Test CVS's ability to handle *info files. + # Administrative file tests. + # Here is a list of where each administrative file is tested: + # loginfo: info + # modules: modules, modules2, modules3 + # cvsignore: ignore + # verifymsg: info + # cvswrappers: mwrap + # config: config + + # On Windows, we can't check out CVSROOT, because the case + # insensitivity means that this conflicts with cvsroot. + mkdir wnt + cd wnt + dotest info-1 "${testcvs} -q co CVSROOT" "[UP] CVSROOT${DOTSTAR}" cd CVSROOT echo "ALL sh -c \"echo x\${=MYENV}\${=OTHER}y\${=ZEE}=\$USER=\$CVSROOT= >>$TESTDIR/testlog; cat >/dev/null\"" > loginfo @@ -5478,7 +7773,7 @@ ${PROG} [a-z]*: Rebuilding administrative file database" # with "cvs init". : dotest info-2 "${testcvs} add loginfo" \ "${PROG}"' [a-z]*: scheduling file `loginfo'"'"' for addition -'"${PROG}"' [a-z]*: use '"'"'cvs commit'"'"' to add this file permanently' +'"${PROG}"' [a-z]*: use .'"${PROG}"' commit. to add this file permanently' dotest info-3 "${testcvs} -q ci -m new-loginfo" \ "Checking in loginfo; @@ -5494,7 +7789,7 @@ ${PROG} [a-z]*: Rebuilding administrative file database" touch file1 dotest info-6 "${testcvs} add file1" \ "${PROG}"' [a-z]*: scheduling file `file1'\'' for addition -'"${PROG}"' [a-z]*: use '\''cvs commit'\'' to add this file permanently' +'"${PROG}"' [a-z]*: use .'"${PROG}"' commit. to add this file permanently' echo "cvs -s OTHER=not-this -s MYENV=env-" >>$HOME/.cvsrc dotest info-6a "${testcvs} -q -s OTHER=value ci -m add-it" \ "RCS file: ${TESTDIR}/cvsroot/first-dir/file1,v @@ -5511,7 +7806,7 @@ ${TESTDIR}/cvsroot/first-dir/file1,v <-- file1 new revision: 1\.2; previous revision: 1\.1 done" cd .. - dotest info-9 "cat $TESTDIR/testlog" "xenv-valueyz=[a-z0-9@][a-z0-9@]*=${TESTDIR}/cvsroot=" + dotest info-9 "cat $TESTDIR/testlog" "xenv-valueyz=${username}=${TESTDIR}/cvsroot=" dotest info-10 "cat $TESTDIR/testlog2" 'first-dir file1,NONE,1.1 first-dir 1.1 first-dir file1 @@ -5534,7 +7829,7 @@ ${PROG} [a-z]*: Rebuilding administrative file database" # Now test verifymsg cat >${TESTDIR}/vscript <<EOF -#!/bin/sh +#!${TESTSHELL} if head -1 < \$1 | grep '^BugId:[ ]*[0-9][0-9]*$' > /dev/null; then exit 0 else @@ -5598,12 +7893,58 @@ ${PROG} [a-z]*: Rebuilding administrative file database" else fail info-cleanup-2 fi + cd .. + rm -r wnt rm -rf ${CVSROOT_DIRNAME}/first-dir ;; + config) + # Tests of the CVSROOT/config file. See the comment at the + # "info" tests for a full list of administrative file tests. + + # On Windows, we can't check out CVSROOT, because the case + # insensitivity means that this conflicts with cvsroot. + mkdir wnt + cd wnt + + dotest config-1 "${testcvs} -q co CVSROOT" "U CVSROOT/${DOTSTAR}" + cd CVSROOT + echo 'bogus line' >config + dotest config-3 "${testcvs} -q ci -m change-to-bogus-line" \ +"Checking in config; +${TESTDIR}/cvsroot/CVSROOT/config,v <-- config +new revision: 1\.2; previous revision: 1\.1 +done +${PROG} [a-z]*: Rebuilding administrative file database" + echo 'BogusOption=yes' >config + dotest config-4 "${testcvs} -q ci -m change-to-bogus-opt" \ +"${PROG} [a-z]*: syntax error in ${TESTDIR}/cvsroot/CVSROOT/config: line 'bogus line' is missing '=' +Checking in config; +${TESTDIR}/cvsroot/CVSROOT/config,v <-- config +new revision: 1\.3; previous revision: 1\.2 +done +${PROG} [a-z]*: Rebuilding administrative file database" + echo '# No config is a good config' > config + dotest config-5 "${testcvs} -q ci -m change-to-comment" \ +"${PROG} [a-z]*: ${TESTDIR}/cvsroot/CVSROOT/config: unrecognized keyword 'BogusOption' +Checking in config; +${TESTDIR}/cvsroot/CVSROOT/config,v <-- config +new revision: 1\.4; previous revision: 1\.3 +done +${PROG} [a-z]*: Rebuilding administrative file database" + dotest config-6 "${testcvs} -q update" '' + + cd .. + rm -r CVSROOT + cd .. + rm -r wnt + ;; + serverpatch) # Test remote CVS handling of unpatchable files. This isn't # much of a test for local CVS. + # We test this with some keyword expansion games, but the situation + # also arises if the user modifies the file while CVS is running. mkdir ${CVSROOT_DIRNAME}/first-dir mkdir 1 cd 1 @@ -5616,7 +7957,7 @@ ${PROG} [a-z]*: Rebuilding administrative file database" echo '1' >> file1 dotest serverpatch-2 "${testcvs} add file1" \ "${PROG}"' [a-z]*: scheduling file `file1'\'' for addition -'"${PROG}"' [a-z]*: use '\''cvs commit'\'' to add this file permanently' +'"${PROG}"' [a-z]*: use .'"${PROG}"' commit. to add this file permanently' dotest serverpatch-3 "${testcvs} -q commit -m add" \ "RCS file: ${TESTDIR}/cvsroot/first-dir/file1,v @@ -5667,10 +8008,14 @@ U file1' log) # Test selecting revisions with cvs log. # See also log2 tests for more tests. - # See also rcs tests, for -d option to log. # See also branches-14.3 for logging with a branch off of a branch. # See also multibranch-14 for logging with several branches off the # same branchpoint. + # Tests of each option to cvs log: + # -h: admin-19a-log + # -N: log, log2, admin-19a-log + # -b, -r: log + # -d: rcs # Check in a file with a few revisions and branches. mkdir ${CVSROOT_DIRNAME}/first-dir @@ -5679,15 +8024,23 @@ U file1' echo 'first revision' > file1 dotest log-2 "${testcvs} add file1" \ "${PROG}"' [a-z]*: scheduling file `file1'\'' for addition -'"${PROG}"' [a-z]*: use '\''cvs commit'\'' to add this file permanently' - - dotest log-3 "${testcvs} -q commit -m 1" \ +'"${PROG}"' [a-z]*: use .'"${PROG}"' commit. to add this file permanently' + + # While we're at it, check multi-line comments, input from file, + # and trailing whitespace trimming + echo 'line 1 ' >${TESTDIR}/comment.tmp + echo ' ' >>${TESTDIR}/comment.tmp + echo 'line 2 ' >>${TESTDIR}/comment.tmp + echo ' ' >>${TESTDIR}/comment.tmp + echo ' ' >>${TESTDIR}/comment.tmp + dotest log-3 "${testcvs} -q commit -F ${TESTDIR}/comment.tmp" \ "RCS file: ${TESTDIR}/cvsroot/first-dir/file1,v done Checking in file1; ${TESTDIR}/cvsroot/first-dir/file1,v <-- file1 initial revision: 1\.1 done" + rm -f ${TESTDIR}/comment.tmp echo 'second revision' > file1 dotest log-4 "${testcvs} -q ci -m2 file1" \ @@ -5742,7 +8095,9 @@ revision' log_lines=" lines: ${PLUS}1 -1" log_rev1="${log_dash} 1\.1 ${log_date} -1" +line 1 + +line 2" log_rev2="${log_dash} 1\.2 ${log_date}${log_lines} branches: 1\.2\.2; @@ -5886,6 +8241,29 @@ ${log_rev2} ${log_rev1} ${log_trailer}" + dotest log-o0 "${testcvs} admin -o 1.2.2.2:: file1" \ +"RCS file: ${TESTDIR}/cvsroot/first-dir/file1,v +done" + dotest log-o1 "${testcvs} admin -o ::1.2.2.1 file1" \ +"RCS file: ${TESTDIR}/cvsroot/first-dir/file1,v +done" + dotest log-o2 "${testcvs} admin -o 1.2.2.1:: file1" \ +"RCS file: ${TESTDIR}/cvsroot/first-dir/file1,v +deleting revision 1\.2\.2\.2 +done" + dotest log-o3 "${testcvs} log file1" \ +"${log_header} +${log_tags} +${log_header2} +total revisions: 4; selected revisions: 4 +description: +${log_rev3} +${log_rev2} +${log_rev1} +${log_rev1b} +${log_trailer}" + dotest log-o4 "${testcvs} -q update -p -r 1.2.2.1 file1" \ +"first branch revision" cd .. rm -r first-dir rm -rf ${CVSROOT_DIRNAME}/first-dir @@ -5894,10 +8272,6 @@ ${log_trailer}" log2) # More "cvs log" tests, for example the file description. - # Setting the file description doesn't yet work client/server, so - # skip these tests for remote. - if test "x$remote" = xno; then - # Check in a file mkdir ${CVSROOT_DIRNAME}/first-dir dotest log2-1 "${testcvs} -q co first-dir" '' @@ -5905,7 +8279,7 @@ ${log_trailer}" echo 'first revision' > file1 dotest log2-2 "${testcvs} add -m file1-is-for-testing file1" \ "${PROG}"' [a-z]*: scheduling file `file1'\'' for addition -'"${PROG}"' [a-z]*: use '\''cvs commit'\'' to add this file permanently' +'"${PROG}"' [a-z]*: use .'"${PROG}"' commit. to add this file permanently' dotest log2-3 "${testcvs} -q commit -m 1" \ "RCS file: ${TESTDIR}/cvsroot/first-dir/file1,v done @@ -5913,6 +8287,10 @@ Checking in file1; ${TESTDIR}/cvsroot/first-dir/file1,v <-- file1 initial revision: 1\.1 done" + # Setting the file description with add -m doesn't yet work + # client/server, so skip log2-4 for remote. + if test "x$remote" = xno; then + dotest log2-4 "${testcvs} log -N file1" " RCS file: ${TESTDIR}/cvsroot/first-dir/file1,v Working file: file1 @@ -5930,13 +8308,204 @@ date: [0-9/]* [0-9:]*; author: ${username}; state: Exp; 1 =============================================================================" + fi # end of tests skipped for remote + + dotest log2-5 "${testcvs} admin -t-change-description file1" \ +"RCS file: ${TESTDIR}/cvsroot/first-dir/file1,v +done" + dotest log2-6 "${testcvs} log -N file1" " +RCS file: ${TESTDIR}/cvsroot/first-dir/file1,v +Working file: file1 +head: 1\.1 +branch: +locks: strict +access list: +keyword substitution: kv +total revisions: 1; selected revisions: 1 +description: +change-description +---------------------------- +revision 1\.1 +date: [0-9/]* [0-9:]*; author: ${username}; state: Exp; +1 +=============================================================================" + + # I believe that in Real Life (TM), this is broken for remote. + # That is, the filename in question must be the filename of a + # file on the server. It only happens to work here because the + # client machine and the server machine are one and the same. + echo 'longer description' >${TESTDIR}/descrip + echo 'with two lines' >>${TESTDIR}/descrip + dotest log2-7 "${testcvs} admin -t${TESTDIR}/descrip file1" \ +"RCS file: ${TESTDIR}/cvsroot/first-dir/file1,v +done" + dotest log2-8 "${testcvs} log -N file1" " +RCS file: ${TESTDIR}/cvsroot/first-dir/file1,v +Working file: file1 +head: 1\.1 +branch: +locks: strict +access list: +keyword substitution: kv +total revisions: 1; selected revisions: 1 +description: +longer description +with two lines +---------------------------- +revision 1\.1 +date: [0-9/]* [0-9:]*; author: ${username}; state: Exp; +1 +=============================================================================" + + # Reading the description from stdin is broken for remote. + # See comments in cvs.texinfo for a few more notes on this. + if test "x$remote" = xno; then + + if echo change from stdin | ${testcvs} admin -t -q file1 + then + pass log2-9 + else + fail log2-9 + fi + dotest log2-10 "${testcvs} log -N file1" " +RCS file: ${TESTDIR}/cvsroot/first-dir/file1,v +Working file: file1 +head: 1\.1 +branch: +locks: strict +access list: +keyword substitution: kv +total revisions: 1; selected revisions: 1 +description: +change from stdin +---------------------------- +revision 1\.1 +date: [0-9/]* [0-9:]*; author: ${username}; state: Exp; +1 +=============================================================================" + + fi # end of tests skipped for remote + cd .. + rm ${TESTDIR}/descrip rm -r first-dir rm -rf ${CVSROOT_DIRNAME}/first-dir - fi # end of tests skipped for remote + ;; + + ann) + # Tests of "cvs annotate". See also basica-10. + mkdir 1; cd 1 + dotest ann-1 "${testcvs} -q co -l ." '' + mkdir first-dir + dotest ann-2 "${testcvs} add first-dir" \ +"Directory ${TESTDIR}/cvsroot/first-dir added to the repository" + cd first-dir + cat >file1 <<EOF +this +is +the +ancestral +file +EOF + dotest ann-3 "${testcvs} add file1" \ +"${PROG} [a-z]*: scheduling file .file1. for addition +${PROG} [a-z]*: use .${PROG} commit. to add this file permanently" + dotest ann-4 "${testcvs} -q ci -m add file1" \ +"RCS file: ${TESTDIR}/cvsroot/first-dir/file1,v +done +Checking in file1; +${TESTDIR}/cvsroot/first-dir/file1,v <-- file1 +initial revision: 1\.1 +done" + cat >file1 <<EOF +this +is +a +file + +with +a +blank +line +EOF + dotest ann-5 "${testcvs} -q ci -m modify file1" \ +"Checking in file1; +${TESTDIR}/cvsroot/first-dir/file1,v <-- file1 +new revision: 1\.2; previous revision: 1\.1 +done" + dotest ann-6 "${testcvs} -q tag -b br" "T file1" + cat >file1 <<EOF +this +is +a +trunk file + +with +a +blank +line +EOF + dotest ann-7 "${testcvs} -q ci -m modify file1" \ +"Checking in file1; +${TESTDIR}/cvsroot/first-dir/file1,v <-- file1 +new revision: 1\.3; previous revision: 1\.2 +done" + dotest ann-8 "${testcvs} -q update -r br" "[UP] file1" + cat >file1 <<EOF +this +is +a +file + +with +a +blank +line +and some +branched content +EOF + dotest ann-9 "${testcvs} -q ci -m modify" \ +"Checking in file1; +${TESTDIR}/cvsroot/first-dir/file1,v <-- file1 +new revision: 1\.2\.2\.1; previous revision: 1\.2 +done" + # Note that this annotates the trunk despite the presence + # of a sticky tag in the current directory. This is + # fairly bogus, but it is the longstanding behavior for + # whatever that is worth. + dotest ann-10 "${testcvs} ann" \ +"Annotations for file1 +\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* +1\.1 (${username} *[0-9a-zA-Z-]*): this +1\.1 (${username} *[0-9a-zA-Z-]*): is +1\.2 (${username} *[0-9a-zA-Z-]*): a +1\.3 (${username} *[0-9a-zA-Z-]*): trunk file +1\.2 (${username} *[0-9a-zA-Z-]*): +1\.2 (${username} *[0-9a-zA-Z-]*): with +1\.2 (${username} *[0-9a-zA-Z-]*): a +1\.2 (${username} *[0-9a-zA-Z-]*): blank +1\.2 (${username} *[0-9a-zA-Z-]*): line" + dotest ann-11 "${testcvs} ann -r br" \ +"Annotations for file1 +\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* +1\.1 (${username} *[0-9a-zA-Z-]*): this +1\.1 (${username} *[0-9a-zA-Z-]*): is +1\.2 (${username} *[0-9a-zA-Z-]*): a +1\.1 (${username} *[0-9a-zA-Z-]*): file +1\.2 (${username} *[0-9a-zA-Z-]*): +1\.2 (${username} *[0-9a-zA-Z-]*): with +1\.2 (${username} *[0-9a-zA-Z-]*): a +1\.2 (${username} *[0-9a-zA-Z-]*): blank +1\.2 (${username} *[0-9a-zA-Z-]*): line +1\.2\.2\.1 (${username} *[0-9a-zA-Z-]*): and some +1\.2\.2\.1 (${username} *[0-9a-zA-Z-]*): branched content" + cd ../.. + rm -r 1 + rm -rf ${CVSROOT_DIRNAME}/first-dir ;; + crerepos) # Various tests relating to creating repositories, operating # on repositories created with old versions of CVS, etc. @@ -5983,12 +8552,17 @@ ${testcvs} -d ${TESTDIR}/crerepos release -d CVSROOT >>${LOGFILE}; then # The directory tmp should be empty dotest crerepos-6 "rmdir tmp" '' + CREREPOS_ROOT=${TESTDIR}/crerepos + else # For remote, just create the repository. We don't yet do # the various other tests above for remote but that should be # changed. mkdir crerepos mkdir crerepos/CVSROOT + + CREREPOS_ROOT=:ext:`hostname`:${TESTDIR}/crerepos + fi if test "x$remote" = "xno"; then @@ -6027,6 +8601,82 @@ ${testcvs} -d ${TESTDIR}/crerepos release -d CVSROOT >>${LOGFILE}; then dotest_fail crerepos-7 \ "test -f ${TESTDIR}/crerepos/CVSROOT/history" '' + # Now test mixing repositories. This kind of thing tends to + # happen accidentally when people work with several repositories. + mkdir 1; cd 1 + dotest crerepos-8 "${testcvs} -q co -l ." '' + mkdir first-dir + dotest crerepos-9 "${testcvs} add first-dir" \ +"Directory ${TESTDIR}/cvsroot/first-dir added to the repository" + cd first-dir + touch file1 + dotest crerepos-10 "${testcvs} add file1" \ +"${PROG} [a-z]*: scheduling file .file1. for addition +${PROG} [a-z]*: use .${PROG} commit. to add this file permanently" + dotest crerepos-11 "${testcvs} -q ci -m add-it" \ +"RCS file: ${TESTDIR}/cvsroot/first-dir/file1,v +done +Checking in file1; +${TESTDIR}/cvsroot/first-dir/file1,v <-- file1 +initial revision: 1\.1 +done" + cd ../.. + rm -r 1 + + mkdir 1; cd 1 + dotest crerepos-12 "${testcvs} -d ${CREREPOS_ROOT} -q co -l ." '' + mkdir crerepos-dir + dotest crerepos-13 "${testcvs} add crerepos-dir" \ +"Directory ${TESTDIR}/crerepos/crerepos-dir added to the repository" + cd crerepos-dir + touch cfile + dotest crerepos-14 "${testcvs} add cfile" \ +"${PROG} [a-z]*: scheduling file .cfile. for addition +${PROG} [a-z]*: use .${PROG} commit. to add this file permanently" + dotest crerepos-15 "${testcvs} -q ci -m add-it" \ +"RCS file: ${TESTDIR}/crerepos/crerepos-dir/cfile,v +done +Checking in cfile; +${TESTDIR}/crerepos/crerepos-dir/cfile,v <-- cfile +initial revision: 1\.1 +done" + cd ../.. + rm -r 1 + + mkdir 1; cd 1 + dotest crerepos-16 "${testcvs} co first-dir" \ +"${PROG} [a-z]*: Updating first-dir +U first-dir/file1" + dotest crerepos-17 "${testcvs} -d ${CREREPOS_ROOT} co crerepos-dir" \ +"${PROG} [a-z]*: Updating crerepos-dir +U crerepos-dir/cfile" + + if test x`cat CVS/Repository` = x.; then + # RELATIVE_REPOS + # Fatal error so that we don't go traipsing through the + # directories which happen to have the same names from the + # wrong repository. + dotest_fail crerepos-18 "${testcvs} -q update" \ +"${PROG} \[[a-z]* aborted\]: cannot open directory ${TESTDIR}/cvsroot/crerepos-dir: .*" '' + else + if test "$remote" = no; then + # The lack of an error doesn't mean CVS is really + # working (things are getting logged to the wrong + # history file and such). + dotest crerepos-18 "${testcvs} -q update" '' + else + # Fatal error so that we don't go traipsing through the + # directories which happen to have the same names from the + # wrong repository. + dotest_fail crerepos-18 "${testcvs} -q update" \ +"protocol error: directory .${TESTDIR}/crerepos/crerepos-dir. not within root .${TESTDIR}/cvsroot." + fi + fi + + cd .. + + rm -r 1 + rm -rf ${CVSROOT_DIRNAME}/first-dir ${TESTDIR}/crerepos ;; rcs) @@ -6035,20 +8685,27 @@ ${testcvs} -d ${TESTDIR}/crerepos release -d CVSROOT >>${LOGFILE}; then # implements this format, will be out there "forever" and # CVS must always be able to import such files. - # TODO: would be nice to have a corresponding test for exporting - # RCS files. Rather than try to write a rigorous check for whether - # the file CVS exports is legal, we could just write a simpler test - # for what CVS actually exports, and revise the check as needed. + # See tests admin-13, admin-25 and rcs-8a for exporting RCS files. mkdir ${CVSROOT_DIRNAME}/first-dir # Currently the way to import an RCS file is to copy it # directly into the repository. + # # This file was written by RCS 5.7, and then the dates were # hacked so that we test year 2000 stuff. Note also that # "author" names are just strings, as far as importing # RCS files is concerned--they need not correspond to user # IDs on any particular system. + # + # I also tried writing a file with the RCS supplied with + # HPUX A.09.05. According to "man rcsintro" this is + # "Revision Number: 3.0; Release Date: 83/05/11". There + # were a few minor differences like whitespace but at least + # in simple cases like this everything else seemed the same + # as the file written by RCS 5.7 (so I won't try to make it + # a separate test case). + cat <<EOF >${CVSROOT_DIRNAME}/first-dir/file1,v head 1.3; access; @@ -6200,6 +8857,243 @@ add file1 else fail rcs-4 fi + + # OK, here is another one. This one was written by hand based on + # doc/RCSFILES and friends. + cat <<EOF >${CVSROOT_DIRNAME}/first-dir/file2,v +head 1.5 ; + branch 1.2.6; +access ; +symbols; +locks; +testofanewphrase @without newphrase we'd have trouble extending @@ all@ ; +1.5 date 71.01.01.01.00.00; author joe; state bogus; branches; next 1.4; +1.4 date 71.01.01.00.00.05; author joe; state bogus; branches; next 1.3; +1.3 date 70.12.31.15.00.05; author joe; state bogus; branches; next 1.2; +1.2 date 70.12.31.12.15.05; author me; state bogus; branches 1.2.6.1; next 1.1; +1.1 date 70.12.31.11.00.05; author joe; state bogus; branches; next; newph; +1.2.6.1 date 71.01.01.08.00.05; author joe; state Exp; branches; next; +desc @@ +1.5 log @@ newphrase1; newphrase2 42; text @head revision@ +1.4 log @@ text @d1 1 +a1 1 +new year revision@ +1.3 log @@ text @d1 1 +a1 1 +old year revision@ +1.2 log @@ text @d1 1 +a1 1 +mid revision@ 1.1 + +log @@ text @d1 1 +a1 1 +start revision@ +1.2.6.1 log @@ text @d1 1 +a1 1 +branch revision@ +EOF + # First test the default branch. + dotest rcs-5 "${testcvs} -q update file2" "U file2" + dotest rcs-6 "cat file2" "branch revision" + + # Now get rid of the default branch, it will get in the way. + dotest rcs-7 "${testcvs} admin -b file2" \ +"RCS file: ${TESTDIR}/cvsroot/first-dir/file2,v +done" + # But we do want to make sure that "cvs admin" leaves the newphrases + # in the file. + # The extra whitespace regexps are for the RCS library, which does + # not preserve whitespace in the dogmatic manner of RCS 5.7. -twp + dotest rcs-8 \ +"grep testofanewphrase ${CVSROOT_DIRNAME}/first-dir/file2,v" \ +"testofanewphrase[ ][ ]*@without newphrase we'd have trouble extending @@ all@[ ]*;" + # The easiest way to test for newphrases in deltas and deltatexts + # is to just look at the whole file, I guess. + dotest rcs-8a "cat ${CVSROOT_DIRNAME}/first-dir/file2,v" \ +"head 1\.5; +access; +symbols; +locks; + +testofanewphrase @without newphrase we'd have trouble extending @@ all@; + +1\.5 +date 71\.01\.01\.01\.00\.00; author joe; state bogus; +branches; +next 1\.4; + +1\.4 +date 71\.01\.01\.00\.00\.05; author joe; state bogus; +branches; +next 1\.3; + +1\.3 +date 70\.12\.31\.15\.00\.05; author joe; state bogus; +branches; +next 1\.2; + +1\.2 +date 70\.12\.31\.12\.15\.05; author me; state bogus; +branches + 1\.2\.6\.1; +next 1\.1; + +1\.1 +date 70\.12\.31\.11\.00\.05; author joe; state bogus; +branches; +next ; +newph ; + +1\.2\.6\.1 +date 71\.01\.01\.08\.00\.05; author joe; state Exp; +branches; +next ; + + +desc +@@ + + +1\.5 +log +@@ +newphrase1 ; +newphrase2 42; +text +@head revision@ + + +1\.4 +log +@@ +text +@d1 1 +a1 1 +new year revision@ + + +1\.3 +log +@@ +text +@d1 1 +a1 1 +old year revision@ + + +1\.2 +log +@@ +text +@d1 1 +a1 1 +mid revision@ + + +1\.1 +log +@@ +text +@d1 1 +a1 1 +start revision@ + + +1\.2\.6\.1 +log +@@ +text +@d1 1 +a1 1 +branch revision@" + + # For remote, the "update -p -D" usage seems not to work. + # I'm not sure what is going on. + if test "x$remote" = "xno"; then + + if ${testcvs} -q update -p -D '1970-12-31 11:30 UT' file2 \ + >${TESTDIR}/rcs4.tmp + then + dotest rcs-9 "cat ${TESTDIR}/rcs4.tmp" "start revision" + else + fail rcs-9 + fi + + if ${testcvs} -q update -p -D '1970-12-31 12:30 UT' file2 \ + >${TESTDIR}/rcs4.tmp + then + dotest rcs-10 "cat ${TESTDIR}/rcs4.tmp" "mid revision" + else + fail rcs-10 + fi + + if ${testcvs} -q update -p -D '1971-01-01 00:30 UT' file2 \ + >${TESTDIR}/rcs4.tmp + then + dotest rcs-11 "cat ${TESTDIR}/rcs4.tmp" "new year revision" + else + fail rcs-11 + fi + + # Same test as rcs-10, but with am/pm. + if ${testcvs} -q update -p -D 'December 31, 1970 12:30pm UT' file2 \ + >${TESTDIR}/rcs4.tmp + then + dotest rcs-12 "cat ${TESTDIR}/rcs4.tmp" "mid revision" + else + fail rcs-12 + fi + + # Same test as rcs-11, but with am/pm. + if ${testcvs} -q update -p -D 'January 1, 1971 12:30am UT' file2 \ + >${TESTDIR}/rcs4.tmp + then + dotest rcs-13 "cat ${TESTDIR}/rcs4.tmp" "new year revision" + else + fail rcs-13 + fi + + fi # end of tests skipped for remote + + # OK, now make sure cvs log doesn't have any trouble with the + # newphrases and such. + dotest rcs-14 "${testcvs} -q log file2" " +RCS file: ${TESTDIR}/cvsroot/first-dir/file2,v +Working file: file2 +head: 1\.5 +branch: +locks: +access list: +symbolic names: +keyword substitution: kv +total revisions: 6; selected revisions: 6 +description: +---------------------------- +revision 1\.5 +date: 1971/01/01 01:00:00; author: joe; state: bogus; lines: ${PLUS}1 -1 +\*\*\* empty log message \*\*\* +---------------------------- +revision 1\.4 +date: 1971/01/01 00:00:05; author: joe; state: bogus; lines: ${PLUS}1 -1 +\*\*\* empty log message \*\*\* +---------------------------- +revision 1\.3 +date: 1970/12/31 15:00:05; author: joe; state: bogus; lines: ${PLUS}1 -1 +\*\*\* empty log message \*\*\* +---------------------------- +revision 1\.2 +date: 1970/12/31 12:15:05; author: me; state: bogus; lines: ${PLUS}1 -1 +branches: 1\.2\.6; +\*\*\* empty log message \*\*\* +---------------------------- +revision 1\.1 +date: 1970/12/31 11:00:05; author: joe; state: bogus; +\*\*\* empty log message \*\*\* +---------------------------- +revision 1\.2\.6\.1 +date: 1971/01/01 08:00:05; author: joe; state: Exp; lines: ${PLUS}1 -1 +\*\*\* empty log message \*\*\* +=============================================================================" cd .. rm -r first-dir ${TESTDIR}/rcs4.tmp @@ -6231,7 +9125,7 @@ add file1 done dotest big-2 "${testcvs} add file1" \ "${PROG} [a-z]*: scheduling file .file1. for addition -${PROG} [a-z]*: use .cvs commit. to add this file permanently" +${PROG} [a-z]*: use .${PROG} commit. to add this file permanently" dotest big-3 "${testcvs} -q ci -m add" \ "RCS file: ${TESTDIR}/cvsroot/first-dir/file1,v done @@ -6240,15 +9134,28 @@ ${TESTDIR}/cvsroot/first-dir/file1,v <-- file1 initial revision: 1\.1 done" cd .. - rm -r first-dir + mkdir 2 + cd 2 dotest big-4 "${testcvs} -q get first-dir" "U first-dir/file1" + cd ../first-dir + echo "add a line to the end" >>file1 + dotest big-5 "${testcvs} -q ci -m modify" \ +"Checking in file1; +${TESTDIR}/cvsroot/first-dir/file1,v <-- file1 +new revision: 1\.2; previous revision: 1\.1 +done" + cd ../2/first-dir + # The idea here is particularly to test the Rcs-diff response + # and the reallocing thereof, for remote. + dotest big-6 "${testcvs} -q update" "[UP] file1" + cd ../.. if test "$keep" = yes; then echo Keeping ${TESTDIR} and exiting due to --keep exit 0 fi - rm -r first-dir + rm -r first-dir 2 rm -rf ${CVSROOT_DIRNAME}/first-dir ;; @@ -6275,7 +9182,7 @@ done" touch aa dotest modes-3 "${testcvs} add aa" \ "${PROG} [a-z]*: scheduling file .aa. for addition -${PROG} [a-z]*: use .cvs commit. to add this file permanently" +${PROG} [a-z]*: use .${PROG} commit. to add this file permanently" dotest modes-4 "${testcvs} -q ci -m add" \ "RCS file: ${TESTDIR}/cvsroot/first-dir/aa,v done @@ -6318,7 +9225,7 @@ done" chmod +x ab dotest modes-8 "${testcvs} add ab" \ "${PROG} [a-z]*: scheduling file .ab. for addition -${PROG} [a-z]*: use .cvs commit. to add this file permanently" +${PROG} [a-z]*: use .${PROG} commit. to add this file permanently" dotest modes-9 "${testcvs} -q ci -m add" \ "RCS file: ${TESTDIR}/cvsroot/first-dir/ab,v done @@ -6345,7 +9252,7 @@ T ab' touch ac dotest modes-13 "${testcvs} add ac" \ "${PROG} [a-z]*: scheduling file .ac. for addition on branch .br. -${PROG} [a-z]*: use .cvs commit. to add this file permanently" +${PROG} [a-z]*: use .${PROG} commit. to add this file permanently" # Not sure it really makes sense to refer to a "previous revision" # when we are just now adding the file; as far as I know # that is longstanding CVS behavior, for what it's worth. @@ -6395,7 +9302,7 @@ done" dotest stamps-3 "${testcvs} add aa kw" \ "${PROG} [a-z]*: scheduling file .aa. for addition ${PROG} [a-z]*: scheduling file .kw. for addition -${PROG} [a-z]*: use .cvs commit. to add these files permanently" +${PROG} [a-z]*: use .${PROG} commit. to add these files permanently" ls -l aa >${TESTDIR}/1/stamp.aa.add ls -l kw >${TESTDIR}/1/stamp.kw.add # "cvs add" should not muck with the timestamp. @@ -6518,6 +9425,9 @@ done" sticky) # More tests of sticky tags, particularly non-branch sticky tags. + # See many tests (e.g. multibranch) for ordinary sticky tag + # operations such as adding files on branches. + # See "head" test for interaction between stick tags and HEAD. mkdir 1; cd 1 dotest sticky-1 "${testcvs} -q co -l ." '' mkdir first-dir @@ -6528,7 +9438,7 @@ done" touch file1 dotest sticky-3 "${testcvs} add file1" \ "${PROG} [a-z]*: scheduling file .file1. for addition -${PROG} [a-z]*: use .cvs commit. to add this file permanently" +${PROG} [a-z]*: use .${PROG} commit. to add this file permanently" dotest sticky-4 "${testcvs} -q ci -m add" \ "RCS file: ${TESTDIR}/cvsroot/first-dir/file1,v done @@ -6555,7 +9465,54 @@ ${QUESTION} file2" "${QUESTION} file2 [UP] file1" dotest sticky-13 "${testcvs} add file2" \ "${PROG} [a-z]*: scheduling file .file2. for addition -${PROG} [a-z]*: use .cvs commit. to add this file permanently" +${PROG} [a-z]*: use .${PROG} commit. to add this file permanently" + dotest sticky-14 "${testcvs} -q ci -m add" \ +"RCS file: ${TESTDIR}/cvsroot/first-dir/file2,v +done +Checking in file2; +${TESTDIR}/cvsroot/first-dir/file2,v <-- file2 +initial revision: 1\.1 +done" + + # Now back to tag1 + dotest sticky-15 "${testcvs} -q update -r tag1" "[UP] file1 +${PROG} [a-z]*: file2 is no longer in the repository" + + rm file1 + dotest sticky-16 "${testcvs} rm file1" \ +"${PROG} [a-z]*: scheduling .file1. for removal +${PROG} [a-z]*: use .${PROG} commit. to remove this file permanently" + # Hmm, this command seems to silently remove the tag from + # the file. This appears to be intentional. + # The silently part especially strikes me as odd, though. + dotest sticky-17 "${testcvs} -q ci -m remove-it" "" + dotest sticky-18 "${testcvs} -q update -A" "U file1 +U file2" + dotest sticky-19 "${testcvs} -q update -r tag1" \ +"${PROG} [a-z]*: file1 is no longer in the repository +${PROG} [a-z]*: file2 is no longer in the repository" + dotest sticky-20 "${testcvs} -q update -A" "U file1 +U file2" + + # Now try with a numeric revision. + dotest sticky-21 "${testcvs} -q update -r 1.1 file1" "U file1" + rm file1 + dotest sticky-22 "${testcvs} rm file1" \ +"${PROG} [a-z]*: cannot remove file .file1. which has a numeric sticky tag of .1\.1." + # The old behavior was that remove allowed this and then commit + # gave an error, which was somewhat hard to clear. I mean, you + # could get into a long elaborate discussion of this being a + # conflict and two ways to resolve it, but I don't really see + # why CVS should have a concept of conflict that arises, not from + # parallel development, but from CVS's own sticky tags. + + # I'm kind of surprised that the "file1 was lost" doesn't crop + # up elsewhere in the testsuite. It is a long-standing + # discrepency between local and remote CVS and should probably + # be cleaned up at some point. + dotest sticky-23 "${testcvs} -q update -A" \ +"${PROG} [a-z]*: warning: file1 was lost +U file1" "U file1" cd ../.. rm -r 1 @@ -6564,6 +9521,14 @@ ${PROG} [a-z]*: use .cvs commit. to add this file permanently" keyword) # Test keyword expansion. + # Various other tests relate to our ability to correctly + # set the keyword expansion mode. + # "binfiles" tests "cvs admin -k". + # "binfiles" and "binfiles2" test "cvs add -k". + # "rdiff" tests "cvs co -k". + # "binfiles" (and this test) test "cvs update -k". + # "binwrap" tests setting the mode from wrappers. + # I don't think any test is testing "cvs import -k". mkdir 1; cd 1 dotest keyword-1 "${testcvs} -q co -l ." '' mkdir first-dir @@ -6591,7 +9556,7 @@ ${PROG} [a-z]*: use .cvs commit. to add this file permanently" dotest keyword-3 "${testcvs} add file1" \ "${PROG} [a-z]*: scheduling file .file1. for addition -${PROG} [a-z]*: use .cvs commit. to add this file permanently" +${PROG} [a-z]*: use .${PROG} commit. to add this file permanently" dotest keyword-4 "${testcvs} -q ci -m add" \ "RCS file: ${TESTDIR}/cvsroot/first-dir/file1,v done @@ -6725,17 +9690,7 @@ xx "'\$'"Log"'\$' # Test the Name keyword. First go back to normal expansion. - # FIXME: When using remote, update -A does not revert the - # keyword expansion mode. We work around that bug here. - # This workaround should be removed when the bug is fixed. - if test "x$remote" = "xyes"; then - cd .. - rm -r first-dir - dotest keyword-17 "${testcvs} -q co first-dir" "U first-dir/file1" - cd first-dir - else - dotest keyword-17 "${testcvs} update -A file1" "U file1" - fi + dotest keyword-17 "${testcvs} update -A file1" "U file1" echo '$''Name$' > file1 dotest keyword-18 "${testcvs} ci -m modify file1" \ @@ -6759,44 +9714,160 @@ done" dotest keyword-23 "${testcvs} update -A file1" "[UP] file1" + cd ../.. + rm -r 1 + rm -rf ${CVSROOT_DIRNAME}/first-dir + ;; + + keywordlog) # Test the Log keyword. + mkdir 1; cd 1 + dotest keywordlog-1 "${testcvs} -q co -l ." '' + mkdir first-dir + dotest keywordlog-2 "${testcvs} add first-dir" \ +"Directory ${TESTDIR}/cvsroot/first-dir added to the repository" + cd first-dir + echo change >file1 + dotest keywordlog-3 "${testcvs} add file1" \ +"${PROG} [a-z]*: scheduling file .file1. for addition +${PROG} [a-z]*: use .${PROG} commit. to add this file permanently" + + # Note that we wanted to try "ci -r 1.3 -m add file1" and CVS + # seemed to get all confused, thinking it was adding on a branch + # or something. FIXME? Do something about this? Document it + # in BUGS or someplace? + + dotest keywordlog-4 "${testcvs} -q ci -m add file1" \ +"RCS file: ${TESTDIR}/cvsroot/first-dir/file1,v +done +Checking in file1; +${TESTDIR}/cvsroot/first-dir/file1,v <-- file1 +initial revision: 1\.1 +done" + + cd ../.. + mkdir 2; cd 2 + dotest keywordlog-4a "${testcvs} -q co first-dir" "U first-dir/file1" + cd ../1/first-dir + echo 'xx $''Log$' > file1 cat >${TESTDIR}/comment.tmp <<EOF First log line Second log line EOF - dotest keyword-24 "${testcvs} ci -F ${TESTDIR}/comment.tmp file1" \ + dotest keywordlog-5 "${testcvs} ci -F ${TESTDIR}/comment.tmp file1" \ "Checking in file1; ${TESTDIR}/cvsroot/first-dir/file1,v <-- file1 -new revision: 1\.4; previous revision: 1\.3 +new revision: 1\.2; previous revision: 1\.1 done" rm -f ${TESTDIR}/comment.tmp - dotest keyword-25 "cat file1" \ + dotest keywordlog-6 "${testcvs} -q tag -b br" "T file1" + dotest keywordlog-7 "cat file1" \ "xx "'\$'"Log: file1,v "'\$'" -xx Revision 1\.4 [0-9/]* [0-9:]* ${username} +xx Revision 1\.2 [0-9/]* [0-9:]* ${username} xx First log line xx Second log line xx" + cd ../../2/first-dir + dotest keywordlog-8 "${testcvs} -q update" "[UP] file1" + dotest keywordlog-9 "cat file1" \ +"xx "'\$'"Log: file1,v "'\$'" +xx Revision 1\.2 [0-9/]* [0-9:]* ${username} +xx First log line +xx Second log line +xx" + cd ../../1/first-dir + echo "change" >> file1 - dotest keyword-26 "${testcvs} ci -m modify file1" \ + dotest keywordlog-10 "${testcvs} ci -m modify file1" \ "Checking in file1; ${TESTDIR}/cvsroot/first-dir/file1,v <-- file1 -new revision: 1\.5; previous revision: 1\.4 +new revision: 1\.3; previous revision: 1\.2 done" - dotest keyword-27 "cat file1" \ + dotest keywordlog-11 "cat file1" \ +"xx "'\$'"Log: file1,v "'\$'" +xx Revision 1\.3 [0-9/]* [0-9:]* ${username} +xx modify +xx +xx Revision 1\.2 [0-9/]* [0-9:]* ${username} +xx First log line +xx Second log line +xx +change" + + cd ../../2/first-dir + dotest keywordlog-12 "${testcvs} -q update" "[UP] file1" + dotest keywordlog-13 "cat file1" \ "xx "'\$'"Log: file1,v "'\$'" -xx Revision 1\.5 [0-9/]* [0-9:]* ${username} +xx Revision 1\.3 [0-9/]* [0-9:]* ${username} xx modify xx -xx Revision 1\.4 [0-9/]* [0-9:]* ${username} +xx Revision 1\.2 [0-9/]* [0-9:]* ${username} xx First log line xx Second log line xx change" + cd ../../1/first-dir + dotest keywordlog-14 "${testcvs} -q update -r br" "[UP] file1" + echo br-change >>file1 + dotest keywordlog-15 "${testcvs} -q ci -m br-modify" \ +"Checking in file1; +${TESTDIR}/cvsroot/first-dir/file1,v <-- file1 +new revision: 1\.2\.2\.1; previous revision: 1\.2 +done" + dotest keywordlog-16 "cat file1" \ +"xx "'\$'"Log: file1,v "'\$'" +xx Revision 1\.2\.2\.1 [0-9/]* [0-9:]* ${username} +xx br-modify +xx +xx Revision 1\.2 [0-9/]* [0-9:]* ${username} +xx First log line +xx Second log line +xx +br-change" + cd ../../2/first-dir + dotest keywordlog-17 "${testcvs} -q update -r br" "[UP] file1" + dotest keywordlog-18 "cat file1" \ +"xx "'\$'"Log: file1,v "'\$'" +xx Revision 1\.2\.2\.1 [0-9/]* [0-9:]* ${username} +xx br-modify +xx +xx Revision 1\.2 [0-9/]* [0-9:]* ${username} +xx First log line +xx Second log line +xx +br-change" cd ../.. - rm -r 1 + dotest keywordlog-19 "${testcvs} -q co -p -r br first-dir/file1" \ +"xx "'\$'"Log: file1,v "'\$'" +xx Revision 1\.2\.2\.1 [0-9/]* [0-9:]* ${username} +xx br-modify +xx +xx Revision 1\.2 [0-9/]* [0-9:]* ${username} +xx First log line +xx Second log line +xx +br-change" + dotest keywordlog-20 "${testcvs} -q co -p first-dir/file1" \ +"xx "'\$'"Log: file1,v "'\$'" +xx Revision 1\.3 [0-9/]* [0-9:]* ${username} +xx modify +xx +xx Revision 1\.2 [0-9/]* [0-9:]* ${username} +xx First log line +xx Second log line +xx +change" + dotest keywordlog-21 "${testcvs} -q co -p -r 1.2 first-dir/file1" \ +"xx "'\$'"Log: file1,v "'\$'" +xx Revision 1\.2 [0-9/]* [0-9:]* ${username} +xx First log line +xx Second log line +xx" + + rm -r 1 2 rm -rf ${CVSROOT_DIRNAME}/first-dir ;; @@ -6811,15 +9882,16 @@ change" mkdir 1; cd 1 dotest toplevel-1 "${testcvs} -q co -l ." '' - mkdir top-dir - dotest toplevel-2 "${testcvs} add top-dir" \ -"Directory ${TESTDIR}/cvsroot/top-dir added to the repository" + mkdir top-dir second-dir + dotest toplevel-2 "${testcvs} add top-dir second-dir" \ +"Directory ${TESTDIR}/cvsroot/top-dir added to the repository +Directory ${TESTDIR}/cvsroot/second-dir added to the repository" cd top-dir touch file1 dotest toplevel-3 "${testcvs} add file1" \ "${PROG} [a-z]*: scheduling file .file1. for addition -${PROG} [a-z]*: use .cvs commit. to add this file permanently" +${PROG} [a-z]*: use .${PROG} commit. to add this file permanently" dotest toplevel-4 "${testcvs} -q ci -m add" \ "RCS file: ${TESTDIR}/cvsroot/top-dir/file1,v done @@ -6827,6 +9899,20 @@ Checking in file1; ${TESTDIR}/cvsroot/top-dir/file1,v <-- file1 initial revision: 1\.1 done" + cd .. + + cd second-dir + touch file2 + dotest toplevel-3s "${testcvs} add file2" \ +"${PROG} [a-z]*: scheduling file .file2. for addition +${PROG} [a-z]*: use .${PROG} commit. to add this file permanently" + dotest toplevel-4s "${testcvs} -q ci -m add" \ +"RCS file: ${TESTDIR}/cvsroot/second-dir/file2,v +done +Checking in file2; +${TESTDIR}/cvsroot/second-dir/file2,v <-- file2 +initial revision: 1\.1 +done" cd ../.. rm -r 1; mkdir 1; cd 1 @@ -6842,16 +9928,11 @@ ${PROG} [a-z]*: Updating top-dir" dotest toplevel-8 "${testcvs} update -d top-dir" \ "${PROG} [a-z]*: Updating top-dir" - # FIXME: This test fails in cvs starting from 1.9.2 because - # it updates "file1" in "1". Test modules3-7f also finds - # (and tolerates) this bug. The second expect string below - # should be removed when this is fixed. The first expect - # string is the behavior of remote CVS. There is some sentiment - # that + # There is some sentiment that # "${PROG} [a-z]*: Updating \. # ${PROG} [a-z]*: Updating top-dir" # is correct but it isn't clear why that would be correct instead - # of the remote CVS behavior. + # of the remote CVS behavior (which also updates CVSROOT). # # The DOTSTAR matches of a bunch of lines like # "U CVSROOT/checkoutlist". Trying to match them more precisely @@ -6862,13 +9943,3368 @@ ${PROG} [a-z]*: Updating top-dir" "${PROG} [a-z]*: Updating \. ${PROG} [a-z]*: Updating CVSROOT ${DOTSTAR} -${PROG} [a-z]*: Updating top-dir" \ -"${PROG} [a-z]*: Updating \. -U file1 ${PROG} [a-z]*: Updating top-dir" cd .. + rm -r 1; mkdir 1; cd 1 + dotest toplevel-10 "${testcvs} co top-dir" \ +"${PROG} [a-z]*: Updating top-dir +U top-dir/file1" + # This tests more or less the same thing, in a particularly + # "real life" example. + dotest toplevel-11 "${testcvs} -q update -d second-dir" \ +"U second-dir/file2" + + # Now remove the CVS directory (people may do this manually, + # especially if they formed their habits with CVS + # 1.9 and older, which didn't create it. Or perhaps the working + # directory itself was created with 1.9 or older). + rm -r CVS + # Now set the permissions so we can't recreate it. + chmod -w ../1 + # Now see whether CVS has trouble because it can't create CVS. + dotest toplevel-12 "${testcvs} co top-dir" \ +"${PROG} [a-z]*: warning: cannot make directory ./CVS: Permission denied +${PROG} [a-z]*: Updating top-dir" + chmod +w ../1 + + cd .. + rm -r 1 + rm -rf ${CVSROOT_DIRNAME}/top-dir + ;; + + head) + # Testing handling of the HEAD special tag. + # There are many cases involving added and removed files + # which we don't yet try to deal with. + # TODO: We also could be paying much closer attention to + # "head of the trunk" versus "head of the default branch". + # That is what "cvs import" is doing here (but I didn't really + # fully follow through on writing the tests for that case). + mkdir imp-dir + cd imp-dir + echo 'imported contents' >file1 + # It may seem like we don't do much with file2, but do note that + # the "cvs diff" invocations do also diff file2 (and come up empty). + echo 'imported contents' >file2 + dotest head-1 "${testcvs} import -m add first-dir tag1 tag2" \ +"N first-dir/file1 +N first-dir/file2 + +No conflicts created by this import" + cd .. + rm -r imp-dir + mkdir 1 + cd 1 + dotest head-2 "${testcvs} -q co first-dir" \ +"U first-dir/file1 +U first-dir/file2" + cd first-dir + echo 'add a line on trunk' >> file1 + dotest head-3 "${testcvs} -q ci -m modify" \ +"Checking in file1; +${TESTDIR}/cvsroot/first-dir/file1,v <-- file1 +new revision: 1\.2; previous revision: 1\.1 +done" + dotest head-4 "${testcvs} -q tag trunktag" "T file1 +T file2" + echo 'add a line on trunk after trunktag' >> file1 + dotest head-5 "${testcvs} -q ci -m modify" \ +"Checking in file1; +${TESTDIR}/cvsroot/first-dir/file1,v <-- file1 +new revision: 1\.3; previous revision: 1\.2 +done" + dotest head-6 "${testcvs} -q tag -b br1" "T file1 +T file2" + dotest head-7 "${testcvs} -q update -r br1" "" + echo 'modify on branch' >>file1 + dotest head-8 "${testcvs} -q ci -m modify" \ +"Checking in file1; +${TESTDIR}/cvsroot/first-dir/file1,v <-- file1 +new revision: 1\.3\.2\.1; previous revision: 1\.3 +done" + dotest head-9 "${testcvs} -q tag brtag" "T file1 +T file2" + echo 'modify on branch after brtag' >>file1 + dotest head-10 "${testcvs} -q ci -m modify" \ +"Checking in file1; +${TESTDIR}/cvsroot/first-dir/file1,v <-- file1 +new revision: 1\.3\.2\.2; previous revision: 1\.3\.2\.1 +done" + # With no sticky tags, HEAD is the head of the trunk. + dotest head-trunk-setup "${testcvs} -q update -A" "[UP] file1" + dotest head-trunk-update "${testcvs} -q update -r HEAD -p file1" \ +"imported contents +add a line on trunk +add a line on trunk after trunktag" + # and diff thinks so too. Case (a) from the comment in + # cvs.texinfo (Common options). + dotest_fail head-trunk-diff "${testcvs} -q diff -c -r HEAD -r br1" \ +"Index: file1 +=================================================================== +RCS file: ${TESTDIR}/cvsroot/first-dir/file1,v +retrieving revision 1\.3 +retrieving revision 1\.3\.2\.2 +diff -c -r1\.3 -r1\.3\.2\.2 +\*\*\* file1 [0-9/]* [0-9:]* 1\.3 +--- file1 [0-9/]* [0-9:]* 1\.3\.2\.2 +\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* +\*\*\* 1,3 \*\*\*\* +--- 1,5 ---- + imported contents + add a line on trunk + add a line on trunk after trunktag +${PLUS} modify on branch +${PLUS} modify on branch after brtag" + + # With a branch sticky tag, HEAD is the head of the trunk. + dotest head-br1-setup "${testcvs} -q update -r br1" "[UP] file1" + dotest head-br1-update "${testcvs} -q update -r HEAD -p file1" \ +"imported contents +add a line on trunk +add a line on trunk after trunktag" + # But diff thinks that HEAD is "br1". Case (b) from cvs.texinfo. + # Probably people are relying on it. + dotest head-br1-diff "${testcvs} -q diff -c -r HEAD -r br1" "" + + # With a nonbranch sticky tag on a branch, + # HEAD is the head of the trunk + dotest head-brtag-setup "${testcvs} -q update -r brtag" "[UP] file1" + dotest head-brtag-update "${testcvs} -q update -r HEAD -p file1" \ +"imported contents +add a line on trunk +add a line on trunk after trunktag" + # But diff thinks that HEAD is "brtag". Case (c) from + # cvs.texinfo (the "strange, maybe accidental" case). + dotest_fail head-brtag-diff "${testcvs} -q diff -c -r HEAD -r br1" \ +"Index: file1 +=================================================================== +RCS file: ${TESTDIR}/cvsroot/first-dir/file1,v +retrieving revision 1\.3\.2\.1 +retrieving revision 1\.3\.2\.2 +diff -c -r1\.3\.2\.1 -r1\.3\.2\.2 +\*\*\* file1 [0-9/]* [0-9:]* 1\.3\.2\.1 +--- file1 [0-9/]* [0-9:]* 1\.3\.2\.2 +\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* +\*\*\* 2,4 \*\*\*\* +--- 2,5 ---- + add a line on trunk + add a line on trunk after trunktag + modify on branch +${PLUS} modify on branch after brtag" + + # With a nonbranch sticky tag on the trunk, HEAD is the head + # of the trunk, I think. + dotest head-trunktag-setup "${testcvs} -q update -r trunktag" \ +"[UP] file1" + dotest head-trunktag-check "cat file1" "imported contents +add a line on trunk" + dotest head-trunktag-update "${testcvs} -q update -r HEAD -p file1" \ +"imported contents +add a line on trunk +add a line on trunk after trunktag" + # Like head-brtag-diff, HEAD is the sticky tag. Similarly + # questionable. + dotest_fail head-trunktag-diff \ + "${testcvs} -q diff -c -r HEAD -r br1" \ +"Index: file1 +=================================================================== +RCS file: ${TESTDIR}/cvsroot/first-dir/file1,v +retrieving revision 1\.2 +retrieving revision 1\.3\.2\.2 +diff -c -r1\.2 -r1\.3\.2\.2 +\*\*\* file1 [0-9/]* [0-9:]* 1\.2 +--- file1 [0-9/]* [0-9:]* 1\.3\.2\.2 +\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* +\*\*\* 1,2 \*\*\*\* +--- 1,5 ---- + imported contents + add a line on trunk +${PLUS} add a line on trunk after trunktag +${PLUS} modify on branch +${PLUS} modify on branch after brtag" + + # Also might test what happens if we setup with update -r + # HEAD. In general, if sticky tags matter, does the + # behavior of "update -r <foo>" (without -p) depend on the + # sticky tags before or after the update? + + # Note that we are testing both the case where this deletes + # a revision (file1) and the case where it does not (file2) + dotest_fail head-o0a "${testcvs} admin -o ::br1" \ +"${PROG} [a-z]*: Administrating \. +RCS file: ${TESTDIR}/cvsroot/first-dir/file1,v +${PROG} [a-z]*: cannot remove revision 1\.3\.2\.1 because it has tags +${PROG} [a-z]*: cannot modify RCS file for .file1. +RCS file: ${TESTDIR}/cvsroot/first-dir/file2,v +done" + dotest head-o0b "${testcvs} tag -d brtag" \ +"${PROG} [a-z]*: Untagging \. +D file1 +D file2" + dotest head-o1 "${testcvs} admin -o ::br1" \ +"${PROG} [a-z]*: Administrating \. +RCS file: ${TESTDIR}/cvsroot/first-dir/file1,v +deleting revision 1\.3\.2\.1 +done +RCS file: ${TESTDIR}/cvsroot/first-dir/file2,v +done" + cd ../.. + rm -r 1 + rm -rf ${CVSROOT_DIRNAME}/first-dir + ;; + + tagdate) + # Test combining -r and -D. + mkdir 1; cd 1 + dotest tagdate-1 "${testcvs} -q co -l ." '' + mkdir first-dir + dotest tagdate-2 "${testcvs} add first-dir" \ +"Directory ${TESTDIR}/cvsroot/first-dir added to the repository" + cd first-dir + + echo trunk-1 >file1 + dotest tagdate-3 "${testcvs} add file1" \ +"${PROG} [a-z]*: scheduling file .file1. for addition +${PROG} [a-z]*: use .${PROG} commit. to add this file permanently" + dotest tagdate-4 "${testcvs} -q ci -m add" \ +"RCS file: ${TESTDIR}/cvsroot/first-dir/file1,v +done +Checking in file1; +${TESTDIR}/cvsroot/first-dir/file1,v <-- file1 +initial revision: 1\.1 +done" + dotest tagdate-5 "${testcvs} -q tag -b br1" "T file1" + dotest tagdate-6 "${testcvs} -q tag -b br2" "T file1" + echo trunk-2 >file1 + dotest tagdate-7 "${testcvs} -q ci -m modify-on-trunk" \ +"Checking in file1; +${TESTDIR}/cvsroot/first-dir/file1,v <-- file1 +new revision: 1\.2; previous revision: 1\.1 +done" + # We are testing -r -D where br1 is a (magic) branch without + # any revisions. First the case where br2 doesn't have any + # revisions either: + dotest tagdate-8 "${testcvs} -q update -p -r br1 -D now" "trunk-1" + dotest tagdate-9 "${testcvs} -q update -r br2" "[UP] file1" + echo br2-1 >file1 + dotest tagdate-10 "${testcvs} -q ci -m modify-on-br2" \ +"Checking in file1; +${TESTDIR}/cvsroot/first-dir/file1,v <-- file1 +new revision: 1\.1\.4\.1; previous revision: 1\.1 +done" + # Then the case where br2 does have revisions: + dotest tagdate-11 "${testcvs} -q update -p -r br1 -D now" "trunk-1" + + cd ../.. + rm -r 1 + rm -rf ${CVSROOT_DIRNAME}/first-dir + ;; + + multibranch2) + # Commit the first delta on branch A when there is an older + # branch, B, that already has a delta. A and B come from the + # same branch point. Then verify that branches A and B are + # in the right order. + mkdir 1; cd 1 + dotest multibranch2-1 "${testcvs} -q co -l ." '' + mkdir first-dir + dotest multibranch2-2 "${testcvs} add first-dir" \ +"Directory ${TESTDIR}/cvsroot/first-dir added to the repository" + cd first-dir + + echo trunk-1 >file1 + dotest multibranch2-3 "${testcvs} add file1" \ +"${PROG} [a-z]*: scheduling file .file1. for addition +${PROG} [a-z]*: use .${PROG} commit. to add this file permanently" + dotest multibranch2-4 "${testcvs} -q ci -m add" \ +"RCS file: ${TESTDIR}/cvsroot/first-dir/file1,v +done +Checking in file1; +${TESTDIR}/cvsroot/first-dir/file1,v <-- file1 +initial revision: 1\.1 +done" + dotest multibranch2-5 "${testcvs} -q tag -b A" "T file1" + dotest multibranch2-6 "${testcvs} -q tag -b B" "T file1" + + dotest multibranch2-7 "${testcvs} -q update -r B" '' + echo branch-B >file1 + dotest multibranch2-8 "${testcvs} -q ci -m modify-on-B" \ +"Checking in file1; +${TESTDIR}/cvsroot/first-dir/file1,v <-- file1 +new revision: 1\.1\.4\.1; previous revision: 1\.1 +done" + + dotest multibranch2-9 "${testcvs} -q update -r A" '[UP] file1' + echo branch-A >file1 + # When using cvs-1.9.20, this commit gets a failed assertion in rcs.c. + dotest multibranch2-10 "${testcvs} -q ci -m modify-on-A" \ +"Checking in file1; +${TESTDIR}/cvsroot/first-dir/file1,v <-- file1 +new revision: 1\.1\.2\.1; previous revision: 1\.1 +done" + + dotest multibranch2-11 "${testcvs} -q log" \ +" +RCS file: ${TESTDIR}/cvsroot/first-dir/file1,v +Working file: file1 +head: 1\.1 +branch: +locks: strict +access list: +symbolic names: + B: 1\.1\.0\.4 + A: 1\.1\.0\.2 +keyword substitution: kv +total revisions: 3; selected revisions: 3 +description: +---------------------------- +revision 1\.1 +date: [0-9/]* [0-9:]*; author: $username; state: Exp; +branches: 1\.1\.2; 1\.1\.4; +add +---------------------------- +revision 1\.1\.4\.1 +date: [0-9/]* [0-9:]*; author: $username; state: Exp; lines: ${PLUS}1 -1 +modify-on-B +---------------------------- +revision 1\.1\.2\.1 +date: [0-9/]* [0-9:]*; author: $username; state: Exp; lines: ${PLUS}1 -1 +modify-on-A +=============================================================================" + + # This one is more concise. + dotest multibranch2-12 "${testcvs} -q log -r1.1" \ +" +RCS file: ${TESTDIR}/cvsroot/first-dir/file1,v +Working file: file1 +head: 1\.1 +branch: +locks: strict +access list: +symbolic names: + B: 1\.1\.0\.4 + A: 1\.1\.0\.2 +keyword substitution: kv +total revisions: 3; selected revisions: 1 +description: +---------------------------- +revision 1\.1 +date: [0-9/]* [0-9:]*; author: $username; state: Exp; +branches: 1\.1\.2; 1\.1\.4; +add +=============================================================================" + + cd ../.. + rm -r 1 + rm -rf ${CVSROOT_DIRNAME}/first-dir + ;; + + + admin) + # More "cvs admin" tests. + # The basicb-21 test tests rejecting an illegal option. + # For -l and -u, see "reserved" and "keyword" tests. + # "binfiles" test has a test of "cvs admin -k". + # "log2" test has tests of -t and -q options to cvs admin. + # "rcs" tests -b option also. + # For -o, see: + # admin-22-o1 through admin-23 (various cases not involving ::) + # binfiles2-o* (:rev, rev on trunk; rev:, deleting entire branch) + # basica-o1 through basica-o3 (basic :: usage) + # head-o1 (::branch, where this deletes a revision or is noop) + # branches-o1 (::branch, similar, with different branch topology) + # log-o1 (1.3.2.1::) + # binfiles-o1 (1.3:: and ::1.3) + # Also could be testing: + # 1.3.2.6::1.3.2.8 + # 1.3.2.6::1.3.2 + # 1.3.2.1::1.3.2.6 + # 1.3::1.3.2.6 (error? or synonym for ::1.3.2.6?) + + mkdir 1; cd 1 + dotest admin-1 "${testcvs} -q co -l ." '' + mkdir first-dir + dotest admin-2 "${testcvs} add first-dir" \ +"Directory ${TESTDIR}/cvsroot/first-dir added to the repository" + cd first-dir + + dotest_fail admin-3 "${testcvs} -q admin -i file1" \ +"${PROG} admin: the -i option to admin is not supported +${PROG} admin: run add or import to create an RCS file +${PROG} \[admin aborted\]: specify ${PROG} -H admin for usage information" + dotest_fail admin-4 "${testcvs} -q log file1" \ +"${PROG} [a-z]*: nothing known about file1" + + # Set up some files, file2 a plain one and file1 with a revision + # on a branch. + touch file1 file2 + dotest admin-5 "${testcvs} add file1 file2" \ +"${PROG} [a-z]*: scheduling file .file1. for addition +${PROG} [a-z]*: scheduling file .file2. for addition +${PROG} [a-z]*: use .${PROG} commit. to add these files permanently" + dotest admin-6 "${testcvs} -q ci -m add" \ +"RCS file: ${TESTDIR}/cvsroot/first-dir/file1,v +done +Checking in file1; +${TESTDIR}/cvsroot/first-dir/file1,v <-- file1 +initial revision: 1\.1 +done +RCS file: ${TESTDIR}/cvsroot/first-dir/file2,v +done +Checking in file2; +${TESTDIR}/cvsroot/first-dir/file2,v <-- file2 +initial revision: 1\.1 +done" + dotest admin-7 "${testcvs} -q tag -b br" "T file1 +T file2" + dotest admin-8 "${testcvs} -q update -r br" "" + echo 'add a line on the branch' >> file1 + dotest admin-9 "${testcvs} -q ci -m modify-on-branch" \ +"Checking in file1; +${TESTDIR}/cvsroot/first-dir/file1,v <-- file1 +new revision: 1\.1\.2\.1; previous revision: 1\.1 +done" + dotest admin-10 "${testcvs} -q update -A" "U file1" + + # Try to recurse with a numeric revision arg. + # If we wanted to comprehensive about this, we would also test + # this for -l, -u, and all the different -o syntaxes. + dotest_fail admin-10a "${testcvs} -q admin -b1.1.2" \ +"${PROG} [a-z]*: while processing more than one file: +${PROG} \[[a-z]* aborted\]: attempt to specify a numeric revision" + dotest_fail admin-10b "${testcvs} -q admin -m1.1:bogus file1 file2" \ +"${PROG} [a-z]*: while processing more than one file: +${PROG} \[[a-z]* aborted\]: attempt to specify a numeric revision" + + # Note that -s option applies to the new default branch, not + # the old one. + # Also note that the implementation of -a via "rcs" requires + # no space between -a and the argument. However, we expect + # to change that once CVS parses options. + dotest admin-11 "${testcvs} -q admin -afoo,bar -abaz \ +-b1.1.2 -cxx -U -sfoo file1" \ +"RCS file: ${TESTDIR}/cvsroot/first-dir/file1,v +done" + + dotest admin-12 "${testcvs} log -N file1" " +RCS file: ${TESTDIR}/cvsroot/first-dir/file1,v +Working file: file1 +head: 1\.1 +branch: 1\.1\.2 +locks: +access list: + foo + bar + baz +keyword substitution: kv +total revisions: 2; selected revisions: 2 +description: +---------------------------- +revision 1\.1 +date: [0-9/]* [0-9:]*; author: ${username}; state: Exp; +branches: 1\.1\.2; +add +---------------------------- +revision 1\.1\.2\.1 +date: [0-9/]* [0-9:]*; author: ${username}; state: foo; lines: ${PLUS}1 -0 +modify-on-branch +=============================================================================" + + # "cvs log" doesn't print the comment leader. RCS 5.7 will print + # the comment leader only if one specifies "-V4" to rlog. So it + # seems like the only way to test it is by looking at the RCS file + # directly. This also serves as a test of exporting RCS files + # (analogous to the import tests in "rcs"). + # Rather than try to write a rigorous check for whether the + # file CVS exports is legal, we just write a simpler + # test for what CVS actually exports, and figure we can revise + # the check as needed (within the confines of the RCS5 format as + # documented in RCSFILES). + dotest admin-13 "cat ${CVSROOT_DIRNAME}/first-dir/file1,v" \ +"head 1\.1; +branch 1\.1\.2; +access + foo + bar + baz; +symbols + br:1\.1\.0\.2; +locks; +comment @xx@; + + +1\.1 +date [0-9][0-9]\.[0-9][0-9]\.[0-9][0-9]\.[0-9][0-9]\.[0-9][0-9]\.[0-9][0-9]; author ${username}; state Exp; +branches + 1\.1\.2\.1; +next ; + +1\.1\.2\.1 +date [0-9][0-9]\.[0-9][0-9]\.[0-9][0-9]\.[0-9][0-9]\.[0-9][0-9]\.[0-9][0-9]; author ${username}; state foo; +branches; +next ; + + +desc +@@ + + +1\.1 +log +@add +@ +text +@@ + + +1\.1\.2\.1 +log +@modify-on-branch +@ +text +@a0 1 +add a line on the branch +@" + dotest admin-14 "${testcvs} -q admin -aauth3 -aauth2,foo \ +-soneone:1.1 -m1.1:changed-log-message -ntagone: file2" \ +"RCS file: ${TESTDIR}/cvsroot/first-dir/file2,v +done" + dotest admin-15 "${testcvs} -q log file2" " +RCS file: ${TESTDIR}/cvsroot/first-dir/file2,v +Working file: file2 +head: 1\.1 +branch: +locks: strict +access list: + auth3 + auth2 + foo +symbolic names: + tagone: 1\.1 + br: 1\.1\.0\.2 +keyword substitution: kv +total revisions: 1; selected revisions: 1 +description: +---------------------------- +revision 1\.1 +date: [0-9/]* [0-9:]*; author: ${username}; state: oneone; +changed-log-message +=============================================================================" + + dotest admin-16 "${testcvs} -q admin \ +-A${CVSROOT_DIRNAME}/first-dir/file2,v -b -L -Nbr:1.1 file1" \ +"RCS file: ${TESTDIR}/cvsroot/first-dir/file1,v +done" + dotest admin-17 "${testcvs} -q log file1" " +RCS file: ${TESTDIR}/cvsroot/first-dir/file1,v +Working file: file1 +head: 1\.1 +branch: +locks: strict +access list: + foo + bar + baz + auth3 + auth2 +symbolic names: + br: 1\.1 +keyword substitution: kv +total revisions: 2; selected revisions: 2 +description: +---------------------------- +revision 1\.1 +date: [0-9/]* [0-9:]*; author: ${username}; state: Exp; +branches: 1\.1\.2; +add +---------------------------- +revision 1\.1\.2\.1 +date: [0-9/]* [0-9:]*; author: ${username}; state: foo; lines: ${PLUS}1 -0 +modify-on-branch +=============================================================================" + + dotest_fail admin-18 "${testcvs} -q admin -nbr:1.1.2 file1" \ +"RCS file: ${TESTDIR}/cvsroot/first-dir/file1,v +${PROG} [a-z]*: ${TESTDIR}/cvsroot/first-dir/file1,v: symbolic name br already bound to 1\.1 +${PROG} [a-z]*: cannot modify RCS file for .file1." + dotest admin-19 "${testcvs} -q admin -ebaz -ebar,auth3 -nbr file1" \ +"RCS file: ${TESTDIR}/cvsroot/first-dir/file1,v +done" + dotest admin-20 "${testcvs} -q log file1" " +RCS file: ${TESTDIR}/cvsroot/first-dir/file1,v +Working file: file1 +head: 1\.1 +branch: +locks: strict +access list: + foo + auth2 +symbolic names: +keyword substitution: kv +total revisions: 2; selected revisions: 2 +description: +---------------------------- +revision 1\.1 +date: [0-9/]* [0-9:]*; author: ${username}; state: Exp; +branches: 1\.1\.2; +add +---------------------------- +revision 1.1.2.1 +date: [0-9/]* [0-9:]*; author: ${username}; state: foo; lines: ${PLUS}1 -0 +modify-on-branch +=============================================================================" + + # OK, this is starting to get ridiculous, in terms of + # testing a feature (access lists) which doesn't do anything + # useful, but what about nonexistent files and + # relative pathnames in admin -A? + dotest_fail admin-19a-nonexist \ +"${testcvs} -q admin -A${TESTDIR}/foo/bar file1" \ +"RCS file: ${TESTDIR}/cvsroot/first-dir/file1,v +${PROG} [a-z]*: Couldn't open rcs file .${TESTDIR}/foo/bar.: No such file or directory +${PROG} \[[a-z]* aborted\]: cannot continue" + + # In the remote case, we are cd'd off into the temp directory + # and so these tests give "No such file or directory" errors. + if test "x$remote" = xno; then + + dotest admin-19a-admin "${testcvs} -q admin -A../../cvsroot/first-dir/file2,v file1" \ +"RCS file: ${TESTDIR}/cvsroot/first-dir/file1,v +done" + dotest admin-19a-log "${testcvs} -q log -h -N file1" " +RCS file: ${TESTDIR}/cvsroot/first-dir/file1,v +Working file: file1 +head: 1\.1 +branch: +locks: strict +access list: + foo + auth2 + auth3 +keyword substitution: kv +total revisions: 2 +=============================================================================" + # Put the access list back, to avoid special cases later. + dotest admin-19a-fix "${testcvs} -q admin -eauth3 file1" \ +"RCS file: ${TESTDIR}/cvsroot/first-dir/file1,v +done" + fi # end of tests skipped for remote + + # Add another revision to file2, so we can delete one. + echo 'add a line' >> file2 + dotest admin-21 "${testcvs} -q ci -m modify file2" \ +"Checking in file2; +${TESTDIR}/cvsroot/first-dir/file2,v <-- file2 +new revision: 1\.2; previous revision: 1\.1 +done" + dotest admin-22 "${testcvs} -q admin -o1.1 file2" \ +"RCS file: ${TESTDIR}/cvsroot/first-dir/file2,v +deleting revision 1\.1 +done" + # Test admin -o. More variants that we could be testing: + # * REV: [on branch] + # * REV1:REV2 [deleting whole branch] + # * high branch numbers (e.g. 1.2.2.3.2.3) + # ... and probably others. See RCS_delete_revs for ideas. + + echo first rev > aaa + dotest admin-22-o1 "${testcvs} add aaa" \ +"${PROG} [a-z]*: scheduling file .aaa. for addition +${PROG} [a-z]*: use .${PROG} commit. to add this file permanently" + dotest admin-22-o2 "${testcvs} -q ci -m first aaa" \ +"RCS file: ${TESTDIR}/cvsroot/first-dir/aaa,v +done +Checking in aaa; +${TESTDIR}/cvsroot/first-dir/aaa,v <-- aaa +initial revision: 1\.1 +done" + echo second rev >> aaa + dotest admin-22-o3 "${testcvs} -q ci -m second aaa" \ +"Checking in aaa; +${TESTDIR}/cvsroot/first-dir/aaa,v <-- aaa +new revision: 1\.2; previous revision: 1\.1 +done" + echo third rev >> aaa + dotest admin-22-o4 "${testcvs} -q ci -m third aaa" \ +"Checking in aaa; +${TESTDIR}/cvsroot/first-dir/aaa,v <-- aaa +new revision: 1\.3; previous revision: 1\.2 +done" + echo fourth rev >> aaa + dotest admin-22-o5 "${testcvs} -q ci -m fourth aaa" \ +"Checking in aaa; +${TESTDIR}/cvsroot/first-dir/aaa,v <-- aaa +new revision: 1\.4; previous revision: 1\.3 +done" + echo fifth rev >>aaa + dotest admin-22-o6 "${testcvs} -q ci -m fifth aaa" \ +"Checking in aaa; +${TESTDIR}/cvsroot/first-dir/aaa,v <-- aaa +new revision: 1\.5; previous revision: 1\.4 +done" + echo sixth rev >> aaa + dotest admin-22-o7 "${testcvs} -q ci -m sixth aaa" \ +"Checking in aaa; +${TESTDIR}/cvsroot/first-dir/aaa,v <-- aaa +new revision: 1\.6; previous revision: 1\.5 +done" + dotest admin-22-o8 "${testcvs} admin -l1.6 aaa" \ +"RCS file: ${TESTDIR}/cvsroot/first-dir/aaa,v +1\.6 locked +done" + dotest admin-22-o9 "${testcvs} log -r1.6 aaa" " +RCS file: ${TESTDIR}/cvsroot/first-dir/aaa,v +Working file: aaa +head: 1\.6 +branch: +locks: strict + ${username}: 1\.6 +access list: +symbolic names: +keyword substitution: kv +total revisions: 6; selected revisions: 1 +description: +---------------------------- +revision 1\.6 locked by: ${username}; +date: [0-9/]* [0-9:]*; author: ${username}; state: Exp; lines: ${PLUS}1 -0 +sixth +=============================================================================" + dotest_fail admin-22-o10 "${testcvs} admin -o1.5: aaa" \ +"RCS file: ${TESTDIR}/cvsroot/first-dir/aaa,v +${PROG} [a-z]*: ${TESTDIR}/cvsroot/first-dir/aaa,v: can't remove locked revision 1\.6 +${PROG} [a-z]*: cannot modify RCS file for .aaa." + dotest admin-22-o11 "${testcvs} admin -u aaa" \ +"RCS file: ${TESTDIR}/cvsroot/first-dir/aaa,v +1\.6 unlocked +done" + dotest admin-22-o12 "${testcvs} admin -o1.5: aaa" \ +"RCS file: ${TESTDIR}/cvsroot/first-dir/aaa,v +deleting revision 1\.6 +deleting revision 1\.5 +done" + dotest admin-22-o13 "${testcvs} log aaa" " +RCS file: ${TESTDIR}/cvsroot/first-dir/aaa,v +Working file: aaa +head: 1\.4 +branch: +locks: strict +access list: +symbolic names: +keyword substitution: kv +total revisions: 4; selected revisions: 4 +description: +---------------------------- +revision 1\.4 +date: [0-9/]* [0-9:]*; author: ${username}; state: Exp; lines: ${PLUS}1 -0 +fourth +---------------------------- +revision 1\.3 +date: [0-9/]* [0-9:]*; author: ${username}; state: Exp; lines: ${PLUS}1 -0 +third +---------------------------- +revision 1\.2 +date: [0-9/]* [0-9:]*; author: ${username}; state: Exp; lines: ${PLUS}1 -0 +second +---------------------------- +revision 1\.1 +date: [0-9/]* [0-9:]*; author: ${username}; state: Exp; +first +=============================================================================" + + dotest admin-22-o14 "${testcvs} tag -b -r1.3 br1 aaa" "T aaa" + dotest admin-22-o15 "${testcvs} update -rbr1 aaa" "U aaa" + echo new branch rev >> aaa + dotest admin-22-o16 "${testcvs} ci -m new-branch aaa" \ +"Checking in aaa; +${TESTDIR}/cvsroot/first-dir/aaa,v <-- aaa +new revision: 1\.3\.2\.1; previous revision: 1\.3 +done" + dotest_fail admin-22-o17 "${testcvs} admin -o1.2:1.4 aaa" \ +"RCS file: ${TESTDIR}/cvsroot/first-dir/aaa,v +deleting revision 1\.4 +${PROG} [a-z]*: ${TESTDIR}/cvsroot/first-dir/aaa,v: can't remove branch point 1\.3 +${PROG} [a-z]*: cannot modify RCS file for .aaa." + dotest admin-22-o18 "${testcvs} update -p -r1.4 aaa" \ +"=================================================================== +Checking out aaa +RCS: ${TESTDIR}/cvsroot/first-dir/aaa,v +VERS: 1\.4 +\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* +first rev +second rev +third rev +fourth rev" + echo second branch rev >> aaa + dotest admin-22-o19 "${testcvs} ci -m branch-two aaa" \ +"Checking in aaa; +${TESTDIR}/cvsroot/first-dir/aaa,v <-- aaa +new revision: 1\.3\.2\.2; previous revision: 1\.3\.2\.1 +done" + echo third branch rev >> aaa + dotest admin-22-o20 "${testcvs} ci -m branch-three aaa" \ +"Checking in aaa; +${TESTDIR}/cvsroot/first-dir/aaa,v <-- aaa +new revision: 1\.3\.2\.3; previous revision: 1\.3\.2\.2 +done" + echo fourth branch rev >> aaa + dotest admin-22-o21 "${testcvs} ci -m branch-four aaa" \ +"Checking in aaa; +${TESTDIR}/cvsroot/first-dir/aaa,v <-- aaa +new revision: 1\.3\.2\.4; previous revision: 1\.3\.2\.3 +done" + dotest admin-22-o22 "${testcvs} admin -o:1.3.2.3 aaa" \ +"RCS file: ${TESTDIR}/cvsroot/first-dir/aaa,v +deleting revision 1\.3\.2\.1 +deleting revision 1\.3\.2\.2 +deleting revision 1\.3\.2\.3 +done" + dotest admin-22-o23 "${testcvs} log aaa" " +RCS file: ${TESTDIR}/cvsroot/first-dir/aaa,v +Working file: aaa +head: 1\.4 +branch: +locks: strict +access list: +symbolic names: + br1: 1\.3\.0\.2 +keyword substitution: kv +total revisions: 5; selected revisions: 5 +description: +---------------------------- +revision 1\.4 +date: [0-9/]* [0-9:]*; author: ${username}; state: Exp; lines: ${PLUS}1 -0 +fourth +---------------------------- +revision 1\.3 +date: [0-9/]* [0-9:]*; author: ${username}; state: Exp; lines: ${PLUS}1 -0 +branches: 1\.3\.2; +third +---------------------------- +revision 1\.2 +date: [0-9/]* [0-9:]*; author: ${username}; state: Exp; lines: ${PLUS}1 -0 +second +---------------------------- +revision 1\.1 +date: [0-9/]* [0-9:]*; author: ${username}; state: Exp; +first +---------------------------- +revision 1\.3\.2\.4 +date: [0-9/]* [0-9:]*; author: ${username}; state: Exp; lines: ${PLUS}4 -0 +branch-four +=============================================================================" + + dotest admin-22-o24 "${testcvs} -q update -p -r 1.3.2.4 aaa" \ +"first rev +second rev +third rev +new branch rev +second branch rev +third branch rev +fourth branch rev" + + # The bit here about how there is a "tagone" tag pointing to + # a nonexistent revision is documented by rcs. I dunno, I + # wonder whether the "cvs admin -o" should give a warning in + # this case. + dotest admin-23 "${testcvs} -q log file2" " +RCS file: ${TESTDIR}/cvsroot/first-dir/file2,v +Working file: file2 +head: 1\.2 +branch: +locks: strict +access list: + auth3 + auth2 + foo +symbolic names: + tagone: 1\.1 + br: 1\.1\.0\.2 +keyword substitution: kv +total revisions: 1; selected revisions: 1 +description: +---------------------------- +revision 1\.2 +date: [0-9/]* [0-9:]*; author: ${username}; state: Exp; +modify +=============================================================================" + + dotest admin-25 "cat ${CVSROOT_DIRNAME}/first-dir/file1,v" \ +"head 1\.1; +access + foo + auth2; +symbols; +locks; strict; +comment @xx@; + + +1\.1 +date [0-9][0-9]\.[0-9][0-9]\.[0-9][0-9]\.[0-9][0-9]\.[0-9][0-9]\.[0-9][0-9]; author ${username}; state Exp; +branches + 1\.1\.2\.1; +next ; + +1\.1\.2\.1 +date [0-9][0-9]\.[0-9][0-9]\.[0-9][0-9]\.[0-9][0-9]\.[0-9][0-9]\.[0-9][0-9]; author ${username}; state foo; +branches; +next ; + + +desc +@@ + + +1\.1 +log +@add +@ +text +@@ + + +1\.1\.2\.1 +log +@modify-on-branch +@ +text +@a0 1 +add a line on the branch +@" + + cd ../.. + rm -r 1 + rm -rf ${CVSROOT_DIRNAME}/first-dir + ;; + + reserved) + # Tests of reserved checkouts. Eventually this will test + # rcslock.pl (or equivalent) and all kinds of stuff. Right + # now it just does some very basic checks on cvs admin -u + # and cvs admin -l. + # Also should test locking on a branch (and making sure that + # locks from one branch don't get mixed up with those from + # another. Both the case where one of the branches is the + # main branch, and in which neither one is). + # See also test keyword, which tests that keywords and -kkvl + # do the right thing in the presence of locks. + + # The usual setup, directory first-dir containing file file1. + mkdir 1; cd 1 + dotest reserved-1 "${testcvs} -q co -l ." '' + mkdir first-dir + dotest reserved-2 "${testcvs} add first-dir" \ +"Directory ${TESTDIR}/cvsroot/first-dir added to the repository" + cd first-dir + touch file1 + dotest reserved-3 "${testcvs} add file1" \ +"${PROG} [a-z]*: scheduling file .file1. for addition +${PROG} [a-z]*: use .${PROG} commit. to add this file permanently" + dotest reserved-4 "${testcvs} -q ci -m add" \ +"RCS file: ${TESTDIR}/cvsroot/first-dir/file1,v +done +Checking in file1; +${TESTDIR}/cvsroot/first-dir/file1,v <-- file1 +initial revision: 1\.1 +done" + + dotest reserved-5 "${testcvs} -q admin -l file1" \ +"RCS file: ${TESTDIR}/cvsroot/first-dir/file1,v +1\.1 locked +done" + dotest reserved-6 "${testcvs} log -N file1" " +RCS file: ${TESTDIR}/cvsroot/first-dir/file1,v +Working file: file1 +head: 1\.1 +branch: +locks: strict + ${username}: 1\.1 +access list: +keyword substitution: kv +total revisions: 1; selected revisions: 1 +description: +---------------------------- +revision 1\.1 locked by: ${username}; +date: [0-9/]* [0-9:]*; author: ${username}; state: Exp; +add +=============================================================================" + + # Note that this just tests the owner of the lock giving + # it up. It doesn't test breaking a lock. + dotest reserved-7 "${testcvs} -q admin -u file1" \ +"RCS file: ${TESTDIR}/cvsroot/first-dir/file1,v +1\.1 unlocked +done" + + dotest reserved-8 "${testcvs} log -N file1" " +RCS file: ${TESTDIR}/cvsroot/first-dir/file1,v +Working file: file1 +head: 1\.1 +branch: +locks: strict +access list: +keyword substitution: kv +total revisions: 1; selected revisions: 1 +description: +---------------------------- +revision 1\.1 +date: [0-9/]* [0-9:]*; author: ${username}; state: Exp; +add +=============================================================================" + + # rcslock.pl tests. Of course, the point isn't to test + # rcslock.pl from the distribution but equivalent + # functionality (for example, many sites may have an old + # rcslock.pl). The functionality of this hook falls + # short of the real rcslock.pl though. + # Note that we can use rlog or look at the RCS file directly, + # but we can't use "cvs log" because "cvs commit" has a lock. + + cat >${TESTDIR}/lockme <<EOF +#!${TESTSHELL} +line=\`grep <\$1/\$2,v 'locks ${username}:1\.[0-9];'\` +if test -z "\$line"; then + # It isn't locked + exit 0 +else + user=\`echo \$line | sed -e 's/locks \\(${username}\\):[0-9.]*;.*/\\1/'\` + version=\`echo \$line | sed -e 's/locks ${username}:\\([0-9.]*\\);.*/\\1/'\` + echo "\$user has file a-lock locked for version \$version" + exit 1 +fi +EOF + chmod +x ${TESTDIR}/lockme + + echo stuff > a-lock + dotest reserved-9 "${testcvs} add a-lock" \ +"${PROG} [a-z]*: scheduling file .a-lock. for addition +${PROG} [a-z]*: use .${PROG} commit. to add this file permanently" + dotest reserved-10 "${testcvs} -q ci -m new a-lock" \ +"RCS file: ${TESTDIR}/cvsroot/first-dir/a-lock,v +done +Checking in a-lock; +${TESTDIR}/cvsroot/first-dir/a-lock,v <-- a-lock +initial revision: 1\.1 +done" + # FIXME: the contents of CVSROOT fluctuate a lot + # here. Maybe the expect pattern should just + # confirm that commitinfo is one of the files checked out, + # but for now we just check that CVS exited with success. + cd .. + if ${testcvs} -q co CVSROOT >>${LOGFILE} ; then + pass reserved-11 + else + fail reserved-11 + fi + cd CVSROOT + echo "DEFAULT ${TESTDIR}/lockme" >>commitinfo + dotest reserved-12 "${testcvs} -q ci -m rcslock commitinfo" \ +"Checking in commitinfo; +${TESTDIR}/cvsroot/CVSROOT/commitinfo,v <-- commitinfo +new revision: 1\.2; previous revision: 1\.1 +done +${PROG} [a-z]*: Rebuilding administrative file database" + cd ..; cd first-dir + + # Simulate (approximately) what a-lock would look like + # if someone else had locked revision 1.1. + sed -e 's/locks; strict;/locks fred:1.1; strict;/' ${TESTDIR}/cvsroot/first-dir/a-lock,v > a-lock,v + chmod 644 ${TESTDIR}/cvsroot/first-dir/a-lock,v + dotest reserved-13 "mv a-lock,v ${TESTDIR}/cvsroot/first-dir/a-lock,v" + chmod 444 ${TESTDIR}/cvsroot/first-dir/a-lock,v + echo more stuff >> a-lock + dotest_fail reserved-13b "${testcvs} ci -m '' a-lock" \ +"fred has file a-lock locked for version 1\.1 +${PROG} [a-z]*: Pre-commit check failed +${PROG} \[[a-z]* aborted\]: correct above errors first!" + + dotest reserved-14 "${testcvs} admin -u1.1 a-lock" \ +"RCS file: ${TESTDIR}/cvsroot/first-dir/a-lock,v +1\.1 unlocked +done" + dotest reserved-15 "${testcvs} -q ci -m success a-lock" \ +"Checking in a-lock; +${TESTDIR}/cvsroot/first-dir/a-lock,v <-- a-lock +new revision: 1\.2; previous revision: 1\.1 +done" + + # undo commitinfo changes + cd ../CVSROOT + echo '# vanilla commitinfo' >commitinfo + dotest reserved-16 "${testcvs} -q ci -m back commitinfo" \ +"Checking in commitinfo; +${TESTDIR}/cvsroot/CVSROOT/commitinfo,v <-- commitinfo +new revision: 1\.3; previous revision: 1\.2 +done +${PROG} [a-z]*: Rebuilding administrative file database" + cd ..; rm -r CVSROOT; cd first-dir + + cd ../.. rm -r 1 + rm ${TESTDIR}/lockme + rm -rf ${CVSROOT_DIRNAME}/first-dir + ;; + + cvsadm) + # These test check the content of CVS' administrative + # files as they are checked out in various configurations. + # (As a side note, I'm not using the "-q" flag in any of + # this code, which should provide some extra checking for + # those messages which don't seem to be checked thoroughly + # anywhere else.) To do a thorough test, we need to make + # a bunch of modules in various configurations. + # + # <1mod> is a directory at the top level of cvsroot + # ``foo bar'' + # <2mod> is a directory at the second level of cvsroot + # ``foo bar/baz'' + # <1d1mod> is a directory at the top level which is + # checked out into another directory + # ``foo -d bar baz'' + # <1d2mod> is a directory at the second level which is + # checked out into another directory + # ``foo -d bar baz/quux'' + # <2d1mod> is a directory at the top level which is + # checked out into a directory that is two deep + # ``foo -d bar/baz quux'' + # <2d2mod> is a directory at the second level which is + # checked out into a directory that is two deep + # ``foo -d bar/baz quux'' + # + # The tests do each of these types separately and in twos. + # We also repeat each test -d flag for 1-deep and 2-deep + # directories. + # + # Each test should check the output for the Repository + # file, since that is the one which varies depending on + # the directory and how it was checked out. + # + # Yes, this is verbose, but at least it's very thorough. + + # convenience variables + REP=${CVSROOT} + + # First, check out the modules file and edit it. + mkdir 1; cd 1 + dotest cvsadm-1 "${testcvs} co CVSROOT/modules" \ +"U CVSROOT/modules" + + # Try to determine whether RELATIVE_REPOS is defined + # so that we can make the following a lot less + # verbose. + + echo "${CVSROOT_DIRNAME}/." > ${TESTDIR}/dotest.abs + echo "." > ${TESTDIR}/dotest.rel + if cmp ${TESTDIR}/dotest.abs CVS/Repository >/dev/null 2>&1; then + AREP="${CVSROOT_DIRNAME}/" + elif cmp ${TESTDIR}/dotest.rel CVS/Repository >/dev/null 2>&1; then + AREP="" + else + fail "Cannot figure out if RELATIVE_REPOS is defined." + fi + + # Test CVS/Root once. Since there is only one part of + # the code which writes CVS/Root files (Create_Admin), + # there is no point in testing this every time. + dotest cvsadm-1a "cat CVS/Root" ${REP} + dotest cvsadm-1b "cat CVS/Repository" \ +"${AREP}\." + dotest cvsadm-1c "cat CVSROOT/CVS/Root" ${REP} + dotest cvsadm-1d "cat CVSROOT/CVS/Repository" \ +"${AREP}CVSROOT" + # All of the defined module names begin with a number. + # All of the top-level directory names begin with "dir". + # All of the subdirectory names begin with "sub". + # All of the top-level modules begin with "mod". + echo "# Module defs for cvsadm tests" > CVSROOT/modules + echo "1mod mod1" >> CVSROOT/modules + echo "1mod-2 mod1-2" >> CVSROOT/modules + echo "2mod mod2/sub2" >> CVSROOT/modules + echo "2mod-2 mod2-2/sub2-2" >> CVSROOT/modules + echo "1d1mod -d dir1d1 mod1" >> CVSROOT/modules + echo "1d1mod-2 -d dir1d1-2 mod1-2" >> CVSROOT/modules + echo "1d2mod -d dir1d2 mod2/sub2" >> CVSROOT/modules + echo "1d2mod-2 -d dir1d2-2 mod2-2/sub2-2" >> CVSROOT/modules + echo "2d1mod -d dir2d1/sub2d1 mod1" >> CVSROOT/modules + echo "2d1mod-2 -d dir2d1-2/sub2d1-2 mod1-2" >> CVSROOT/modules + echo "2d2mod -d dir2d2/sub2d2 mod2/sub2" >> CVSROOT/modules + echo "2d2mod-2 -d dir2d2-2/sub2d2-2 mod2-2/sub2-2" >> CVSROOT/modules + dotest cvsadm-1e "${testcvs} ci -m add-modules" \ +"${PROG} [a-z]*: Examining . +${PROG} [a-z]*: Examining CVSROOT +Checking in CVSROOT/modules; +${CVSROOT_DIRNAME}/CVSROOT/modules,v <-- modules +new revision: 1\.[0-9]*; previous revision: 1\.[0-9]* +done +${PROG} [a-z]*: Rebuilding administrative file database" + rm -rf CVS CVSROOT; + + # Create the various modules + mkdir ${CVSROOT_DIRNAME}/mod1 + mkdir ${CVSROOT_DIRNAME}/mod1-2 + mkdir ${CVSROOT_DIRNAME}/mod2 + mkdir ${CVSROOT_DIRNAME}/mod2/sub2 + mkdir ${CVSROOT_DIRNAME}/mod2-2 + mkdir ${CVSROOT_DIRNAME}/mod2-2/sub2-2 + dotest cvsadm-2 "${testcvs} co mod1 mod1-2 mod2 mod2-2" \ +"${PROG} [a-z]*: Updating mod1 +${PROG} [a-z]*: Updating mod1-2 +${PROG} [a-z]*: Updating mod2 +${PROG} [a-z]*: Updating mod2/sub2 +${PROG} [a-z]*: Updating mod2-2 +${PROG} [a-z]*: Updating mod2-2/sub2-2" + + # Populate the directories for the halibut + echo "file1" > mod1/file1 + echo "file1-2" > mod1-2/file1-2 + echo "file2" > mod2/sub2/file2 + echo "file2-2" > mod2-2/sub2-2/file2-2 + dotest cvsadm-2a "${testcvs} add mod1/file1 mod1-2/file1-2 mod2/sub2/file2 mod2-2/sub2-2/file2-2" \ +"${PROG} [a-z]*: scheduling file .mod1/file1. for addition +${PROG} [a-z]*: scheduling file .mod1-2/file1-2. for addition +${PROG} [a-z]*: scheduling file .mod2/sub2/file2. for addition +${PROG} [a-z]*: scheduling file .mod2-2/sub2-2/file2-2. for addition +${PROG} [a-z]*: use '${PROG} commit' to add these files permanently" + + dotest cvsadm-2b "${testcvs} ci -m yup mod1 mod1-2 mod2 mod2-2" \ +"${PROG} [a-z]*: Examining mod1 +${PROG} [a-z]*: Examining mod1-2 +${PROG} [a-z]*: Examining mod2 +${PROG} [a-z]*: Examining mod2/sub2 +${PROG} [a-z]*: Examining mod2-2 +${PROG} [a-z]*: Examining mod2-2/sub2-2 +RCS file: ${CVSROOT_DIRNAME}/mod1/file1,v +done +Checking in mod1/file1; +${CVSROOT_DIRNAME}/mod1/file1,v <-- file1 +initial revision: 1.1 +done +RCS file: ${CVSROOT_DIRNAME}/mod1-2/file1-2,v +done +Checking in mod1-2/file1-2; +${CVSROOT_DIRNAME}/mod1-2/file1-2,v <-- file1-2 +initial revision: 1.1 +done +RCS file: ${CVSROOT_DIRNAME}/mod2/sub2/file2,v +done +Checking in mod2/sub2/file2; +${CVSROOT_DIRNAME}/mod2/sub2/file2,v <-- file2 +initial revision: 1.1 +done +RCS file: ${CVSROOT_DIRNAME}/mod2-2/sub2-2/file2-2,v +done +Checking in mod2-2/sub2-2/file2-2; +${CVSROOT_DIRNAME}/mod2-2/sub2-2/file2-2,v <-- file2-2 +initial revision: 1.1 +done" + # Finished creating the modules -- clean up. + rm -rf CVS mod1 mod1-2 mod2 mod2-2 + # Done. + + ################################################## + ## Start the dizzying array of possibilities. + ## Begin with each module type separately. + ################################################## + + # Pattern -- after each checkout, first check the top-level + # CVS directory. Then, check the directories in numerical + # order. + + dotest cvsadm-3 "${testcvs} co 1mod" \ +"${PROG} [a-z]*: Updating 1mod +U 1mod/file1" + dotest cvsadm-3b "cat CVS/Repository" \ +"${AREP}\." + dotest cvsadm-3d "cat 1mod/CVS/Repository" \ +"${AREP}mod1" + rm -rf CVS 1mod + + dotest cvsadm-4 "${testcvs} co 2mod" \ +"${PROG} [a-z]*: Updating 2mod +U 2mod/file2" + dotest cvsadm-4b "cat CVS/Repository" \ +"${AREP}\." + dotest cvsadm-4d "cat 2mod/CVS/Repository" \ +"${AREP}mod2/sub2" + rm -rf CVS 2mod + + dotest cvsadm-5 "${testcvs} co 1d1mod" \ +"${PROG} [a-z]*: Updating dir1d1 +U dir1d1/file1" + dotest cvsadm-5b "cat CVS/Repository" \ +"${AREP}\." + dotest cvsadm-5d "cat dir1d1/CVS/Repository" \ +"${AREP}mod1" + rm -rf CVS dir1d1 + + dotest cvsadm-6 "${testcvs} co 1d2mod" \ +"${PROG} [a-z]*: Updating dir1d2 +U dir1d2/file2" + dotest cvsadm-6b "cat CVS/Repository" \ +"${AREP}\." + dotest cvsadm-6d "cat dir1d2/CVS/Repository" \ +"${AREP}mod2/sub2" + rm -rf CVS dir1d2 + + dotest cvsadm-7 "${testcvs} co 2d1mod" \ +"${PROG} [a-z]*: Updating dir2d1/sub2d1 +U dir2d1/sub2d1/file1" + dotest cvsadm-7b "cat CVS/Repository" \ +"${AREP}\." + dotest cvsadm-7d "cat dir2d1/CVS/Repository" \ +"${AREP}CVSROOT/Emptydir" + dotest cvsadm-7f "cat dir2d1/sub2d1/CVS/Repository" \ +"${AREP}mod1" + rm -rf CVS dir2d1 + + dotest cvsadm-8 "${testcvs} co 2d2mod" \ +"${PROG} [a-z]*: Updating dir2d2/sub2d2 +U dir2d2/sub2d2/file2" + dotest cvsadm-8b "cat CVS/Repository" \ +"${AREP}\." + dotest cvsadm-8d "cat dir2d2/CVS/Repository" \ +"${AREP}CVSROOT/Emptydir" + dotest cvsadm-8f "cat dir2d2/sub2d2/CVS/Repository" \ +"${AREP}mod2/sub2" + rm -rf CVS dir2d2 + + ################################################## + ## You are in a shell script of twisted little + ## module combination statements, all alike. + ################################################## + + ### 1mod + + dotest cvsadm-9 "${testcvs} co 1mod 1mod-2" \ +"${PROG} [a-z]*: Updating 1mod +U 1mod/file1 +${PROG} [a-z]*: Updating 1mod-2 +U 1mod-2/file1-2" + # the usual for the top level + dotest cvsadm-9b "cat CVS/Repository" \ +"${AREP}\." + # the usual for 1mod + dotest cvsadm-9d "cat 1mod/CVS/Repository" \ +"${AREP}mod1" + # the usual for 1mod copy + dotest cvsadm-9f "cat 1mod-2/CVS/Repository" \ +"${AREP}mod1-2" + rm -rf CVS 1mod 1mod-2 + + # 1mod 2mod redmod bluemod + dotest cvsadm-10 "${testcvs} co 1mod 2mod" \ +"${PROG} [a-z]*: Updating 1mod +U 1mod/file1 +${PROG} [a-z]*: Updating 2mod +U 2mod/file2" + # the usual for the top level + dotest cvsadm-10b "cat CVS/Repository" \ +"${AREP}\." + # the usual for 1mod + dotest cvsadm-10d "cat 1mod/CVS/Repository" \ +"${AREP}mod1" + # the usual for 2dmod + dotest cvsadm-10f "cat 2mod/CVS/Repository" \ +"${AREP}mod2/sub2" + rm -rf CVS 1mod 2mod + + dotest cvsadm-11 "${testcvs} co 1mod 1d1mod" \ +"${PROG} [a-z]*: Updating 1mod +U 1mod/file1 +${PROG} [a-z]*: Updating dir1d1 +U dir1d1/file1" + # the usual for the top level + dotest cvsadm-11b "cat CVS/Repository" \ +"${AREP}\." + # the usual for 1mod + dotest cvsadm-11d "cat 1mod/CVS/Repository" \ +"${AREP}mod1" + # the usual for 1d1mod + dotest cvsadm-11f "cat dir1d1/CVS/Repository" \ +"${AREP}mod1" + rm -rf CVS 1mod dir1d1 + + dotest cvsadm-12 "${testcvs} co 1mod 1d2mod" \ +"${PROG} [a-z]*: Updating 1mod +U 1mod/file1 +${PROG} [a-z]*: Updating dir1d2 +U dir1d2/file2" + # the usual for the top level + dotest cvsadm-12b "cat CVS/Repository" \ +"${AREP}\." + # the usual for 1mod + dotest cvsadm-12d "cat 1mod/CVS/Repository" \ +"${AREP}mod1" + # the usual for 1d2mod + dotest cvsadm-12f "cat dir1d2/CVS/Repository" \ +"${AREP}mod2/sub2" + rm -rf CVS 1mod dir1d2 + + dotest cvsadm-13 "${testcvs} co 1mod 2d1mod" \ +"${PROG} [a-z]*: Updating 1mod +U 1mod/file1 +${PROG} [a-z]*: Updating dir2d1/sub2d1 +U dir2d1/sub2d1/file1" + # the usual for the top level + dotest cvsadm-13b "cat CVS/Repository" \ +"${AREP}\." + # the usual for 1mod + dotest cvsadm-13d "cat 1mod/CVS/Repository" \ +"${AREP}mod1" + # the usual for 2d1mod + dotest cvsadm-13f "cat dir2d1/CVS/Repository" \ +"${AREP}CVSROOT/Emptydir" + dotest cvsadm-13h "cat dir2d1/sub2d1/CVS/Repository" \ +"${AREP}mod1" + rm -rf CVS 1mod dir2d1 + + dotest cvsadm-14 "${testcvs} co 1mod 2d2mod" \ +"${PROG} [a-z]*: Updating 1mod +U 1mod/file1 +${PROG} [a-z]*: Updating dir2d2/sub2d2 +U dir2d2/sub2d2/file2" + # the usual for the top level + dotest cvsadm-14b "cat CVS/Repository" \ +"${AREP}\." + # the usual for 1mod + dotest cvsadm-14d "cat 1mod/CVS/Repository" \ +"${AREP}mod1" + # the usual for 2d2mod + dotest cvsadm-14f "cat dir2d2/CVS/Repository" \ +"${AREP}CVSROOT/Emptydir" + dotest cvsadm-14h "cat dir2d2/sub2d2/CVS/Repository" \ +"${AREP}mod2/sub2" + rm -rf CVS 1mod dir2d2 + + + ### 2mod + + dotest cvsadm-15 "${testcvs} co 2mod 2mod-2" \ +"${PROG} [a-z]*: Updating 2mod +U 2mod/file2 +${PROG} [a-z]*: Updating 2mod-2 +U 2mod-2/file2-2" + # the usual for the top level + dotest cvsadm-15b "cat CVS/Repository" \ +"${AREP}\." + # the usual for 2mod + dotest cvsadm-15d "cat 2mod/CVS/Repository" \ +"${AREP}mod2/sub2" + # the usual for 2mod copy + dotest cvsadm-15f "cat 2mod-2/CVS/Repository" \ +"${AREP}mod2-2/sub2-2" + rm -rf CVS 2mod 2mod-2 + + + dotest cvsadm-16 "${testcvs} co 2mod 1d1mod" \ +"${PROG} [a-z]*: Updating 2mod +U 2mod/file2 +${PROG} [a-z]*: Updating dir1d1 +U dir1d1/file1" + # the usual for the top level + dotest cvsadm-16b "cat CVS/Repository" \ +"${AREP}\." + # the usual for 2mod + dotest cvsadm-16d "cat 2mod/CVS/Repository" \ +"${AREP}mod2/sub2" + # the usual for 1d1mod + dotest cvsadm-16f "cat dir1d1/CVS/Repository" \ +"${AREP}mod1" + rm -rf CVS 2mod dir1d1 + + dotest cvsadm-17 "${testcvs} co 2mod 1d2mod" \ +"${PROG} [a-z]*: Updating 2mod +U 2mod/file2 +${PROG} [a-z]*: Updating dir1d2 +U dir1d2/file2" + # the usual for the top level + dotest cvsadm-17b "cat CVS/Repository" \ +"${AREP}\." + # the usual for 2mod + dotest cvsadm-17d "cat 2mod/CVS/Repository" \ +"${AREP}mod2/sub2" + # the usual for 1d2mod + dotest cvsadm-17f "cat dir1d2/CVS/Repository" \ +"${AREP}mod2/sub2" + rm -rf CVS 2mod dir1d2 + + dotest cvsadm-18 "${testcvs} co 2mod 2d1mod" \ +"${PROG} [a-z]*: Updating 2mod +U 2mod/file2 +${PROG} [a-z]*: Updating dir2d1/sub2d1 +U dir2d1/sub2d1/file1" + # the usual for the top level + dotest cvsadm-18b "cat CVS/Repository" \ +"${AREP}\." + # the usual for 2mod + dotest cvsadm-18d "cat 2mod/CVS/Repository" \ +"${AREP}mod2/sub2" + # the usual for 2d1mod + dotest cvsadm-18f "cat dir2d1/CVS/Repository" \ +"${AREP}CVSROOT/Emptydir" + dotest cvsadm-18h "cat dir2d1/sub2d1/CVS/Repository" \ +"${AREP}mod1" + rm -rf CVS 2mod dir2d1 + + dotest cvsadm-19 "${testcvs} co 2mod 2d2mod" \ +"${PROG} [a-z]*: Updating 2mod +U 2mod/file2 +${PROG} [a-z]*: Updating dir2d2/sub2d2 +U dir2d2/sub2d2/file2" + # the usual for the top level + dotest cvsadm-19b "cat CVS/Repository" \ +"${AREP}\." + # the usual for 2mod + dotest cvsadm-19d "cat 2mod/CVS/Repository" \ +"${AREP}mod2/sub2" + # the usual for 2d2mod + dotest cvsadm-19f "cat dir2d2/CVS/Repository" \ +"${AREP}CVSROOT/Emptydir" + dotest cvsadm-19h "cat dir2d2/sub2d2/CVS/Repository" \ +"${AREP}mod2/sub2" + rm -rf CVS 2mod dir2d2 + + + ### 1d1mod + + dotest cvsadm-20 "${testcvs} co 1d1mod 1d1mod-2" \ +"${PROG} [a-z]*: Updating dir1d1 +U dir1d1/file1 +${PROG} [a-z]*: Updating dir1d1-2 +U dir1d1-2/file1-2" + # the usual for the top level + dotest cvsadm-20b "cat CVS/Repository" \ +"${AREP}\." + # the usual for 1d1mod + dotest cvsadm-20d "cat dir1d1/CVS/Repository" \ +"${AREP}mod1" + # the usual for 1d1mod copy + dotest cvsadm-20f "cat dir1d1-2/CVS/Repository" \ +"${AREP}mod1-2" + rm -rf CVS dir1d1 dir1d1-2 + + dotest cvsadm-21 "${testcvs} co 1d1mod 1d2mod" \ +"${PROG} [a-z]*: Updating dir1d1 +U dir1d1/file1 +${PROG} [a-z]*: Updating dir1d2 +U dir1d2/file2" + # the usual for the top level + dotest cvsadm-21b "cat CVS/Repository" \ +"${AREP}\." + # the usual for 1d1mod + dotest cvsadm-21d "cat dir1d1/CVS/Repository" \ +"${AREP}mod1" + # the usual for 1d2mod + dotest cvsadm-21f "cat dir1d2/CVS/Repository" \ +"${AREP}mod2/sub2" + rm -rf CVS dir1d1 dir1d2 + + dotest cvsadm-22 "${testcvs} co 1d1mod 2d1mod" \ +"${PROG} [a-z]*: Updating dir1d1 +U dir1d1/file1 +${PROG} [a-z]*: Updating dir2d1/sub2d1 +U dir2d1/sub2d1/file1" + # the usual for the top level + dotest cvsadm-22b "cat CVS/Repository" \ +"${AREP}\." + # the usual for 1d1mod + dotest cvsadm-22d "cat dir1d1/CVS/Repository" \ +"${AREP}mod1" + # the usual for 2d1mod + dotest cvsadm-22f "cat dir2d1/CVS/Repository" \ +"${AREP}CVSROOT/Emptydir" + dotest cvsadm-22h "cat dir2d1/sub2d1/CVS/Repository" \ +"${AREP}mod1" + rm -rf CVS dir1d1 dir2d1 + + dotest cvsadm-23 "${testcvs} co 1d1mod 2d2mod" \ +"${PROG} [a-z]*: Updating dir1d1 +U dir1d1/file1 +${PROG} [a-z]*: Updating dir2d2/sub2d2 +U dir2d2/sub2d2/file2" + # the usual for the top level + dotest cvsadm-23b "cat CVS/Repository" \ +"${AREP}\." + # the usual for 1d1mod + dotest cvsadm-23d "cat dir1d1/CVS/Repository" \ +"${AREP}mod1" + # the usual for 2d2mod + dotest cvsadm-23f "cat dir2d2/CVS/Repository" \ +"${AREP}CVSROOT/Emptydir" + dotest cvsadm-23h "cat dir2d2/sub2d2/CVS/Repository" \ +"${AREP}mod2/sub2" + rm -rf CVS dir1d1 dir2d2 + + + ### 1d2mod + + dotest cvsadm-24 "${testcvs} co 1d2mod 1d2mod-2" \ +"${PROG} [a-z]*: Updating dir1d2 +U dir1d2/file2 +${PROG} [a-z]*: Updating dir1d2-2 +U dir1d2-2/file2-2" + # the usual for the top level + dotest cvsadm-24b "cat CVS/Repository" \ +"${AREP}\." + # the usual for 1d2mod + dotest cvsadm-24d "cat dir1d2/CVS/Repository" \ +"${AREP}mod2/sub2" + # the usual for 1d2mod copy + dotest cvsadm-24f "cat dir1d2-2/CVS/Repository" \ +"${AREP}mod2-2/sub2-2" + rm -rf CVS dir1d2 dir1d2-2 + + dotest cvsadm-25 "${testcvs} co 1d2mod 2d1mod" \ +"${PROG} [a-z]*: Updating dir1d2 +U dir1d2/file2 +${PROG} [a-z]*: Updating dir2d1/sub2d1 +U dir2d1/sub2d1/file1" + # the usual for the top level + dotest cvsadm-25b "cat CVS/Repository" \ +"${AREP}\." + # the usual for 1d2mod + dotest cvsadm-25d "cat dir1d2/CVS/Repository" \ +"${AREP}mod2/sub2" + # the usual for 2d1mod + dotest cvsadm-25f "cat dir2d1/CVS/Repository" \ +"${AREP}CVSROOT/Emptydir" + dotest cvsadm-25h "cat dir2d1/sub2d1/CVS/Repository" \ +"${AREP}mod1" + rm -rf CVS dir1d2 dir2d1 + + dotest cvsadm-26 "${testcvs} co 1d2mod 2d2mod" \ +"${PROG} [a-z]*: Updating dir1d2 +U dir1d2/file2 +${PROG} [a-z]*: Updating dir2d2/sub2d2 +U dir2d2/sub2d2/file2" + # the usual for the top level + dotest cvsadm-26b "cat CVS/Repository" \ +"${AREP}\." + # the usual for 1d2mod + dotest cvsadm-26d "cat dir1d2/CVS/Repository" \ +"${AREP}mod2/sub2" + # the usual for 2d2mod + dotest cvsadm-26f "cat dir2d2/CVS/Repository" \ +"${AREP}CVSROOT/Emptydir" + dotest cvsadm-26h "cat dir2d2/sub2d2/CVS/Repository" \ +"${AREP}mod2/sub2" + rm -rf CVS dir1d2 dir2d2 + + + # 2d1mod + + dotest cvsadm-27 "${testcvs} co 2d1mod 2d1mod-2" \ +"${PROG} [a-z]*: Updating dir2d1/sub2d1 +U dir2d1/sub2d1/file1 +${PROG} [a-z]*: Updating dir2d1-2/sub2d1-2 +U dir2d1-2/sub2d1-2/file1-2" + # the usual for the top level + dotest cvsadm-27b "cat CVS/Repository" \ +"${AREP}\." + # the usual for 2d1mod + dotest cvsadm-27d "cat dir2d1/CVS/Repository" \ +"${AREP}CVSROOT/Emptydir" + dotest cvsadm-27f "cat dir2d1/sub2d1/CVS/Repository" \ +"${AREP}mod1" + # the usual for 2d1mod + dotest cvsadm-27h "cat dir2d1-2/CVS/Repository" \ +"${AREP}CVSROOT/Emptydir" + dotest cvsadm-27j "cat dir2d1-2/sub2d1-2/CVS/Repository" \ +"${AREP}mod1-2" + rm -rf CVS dir2d1 dir2d1-2 + + dotest cvsadm-28 "${testcvs} co 2d1mod 2d2mod" \ +"${PROG} [a-z]*: Updating dir2d1/sub2d1 +U dir2d1/sub2d1/file1 +${PROG} [a-z]*: Updating dir2d2/sub2d2 +U dir2d2/sub2d2/file2" + # the usual for the top level + dotest cvsadm-28b "cat CVS/Repository" \ +"${AREP}\." + # the usual for 2d1mod + dotest cvsadm-28d "cat dir2d1/CVS/Repository" \ +"${AREP}CVSROOT/Emptydir" + dotest cvsadm-28f "cat dir2d1/sub2d1/CVS/Repository" \ +"${AREP}mod1" + # the usual for 2d2mod + dotest cvsadm-28h "cat dir2d2/CVS/Repository" \ +"${AREP}CVSROOT/Emptydir" + dotest cvsadm-28j "cat dir2d2/sub2d2/CVS/Repository" \ +"${AREP}mod2/sub2" + rm -rf CVS dir2d1 dir2d2 + + + # 2d2mod + + dotest cvsadm-29 "${testcvs} co 2d2mod 2d2mod-2" \ +"${PROG} [a-z]*: Updating dir2d2/sub2d2 +U dir2d2/sub2d2/file2 +${PROG} [a-z]*: Updating dir2d2-2/sub2d2-2 +U dir2d2-2/sub2d2-2/file2-2" + # the usual for the top level + dotest cvsadm-29b "cat CVS/Repository" \ +"${AREP}\." + # the usual for 2d2mod + dotest cvsadm-29d "cat dir2d2/CVS/Repository" \ +"${AREP}CVSROOT/Emptydir" + dotest cvsadm-29f "cat dir2d2/sub2d2/CVS/Repository" \ +"${AREP}mod2/sub2" + # the usual for 2d2mod + dotest cvsadm-29h "cat dir2d2-2/CVS/Repository" \ +"${AREP}CVSROOT/Emptydir" + dotest cvsadm-29j "cat dir2d2-2/sub2d2-2/CVS/Repository" \ +"${AREP}mod2-2/sub2-2" + rm -rf CVS dir2d2 dir2d2-2 + + ################################################## + ## And now, all of that again using the "-d" flag + ## on the command line. + ################################################## + + dotest cvsadm-1d3 "${testcvs} co -d dir 1mod" \ +"${PROG} [a-z]*: Updating dir +U dir/file1" + dotest cvsadm-1d3b "cat CVS/Repository" \ +"${AREP}\." + dotest cvsadm-1d3d "cat dir/CVS/Repository" \ +"${AREP}mod1" + rm -rf CVS dir + + dotest cvsadm-1d4 "${testcvs} co -d dir 2mod" \ +"${PROG} [a-z]*: Updating dir +U dir/file2" + dotest cvsadm-1d4b "cat CVS/Repository" \ +"${AREP}\." + dotest cvsadm-1d4d "cat dir/CVS/Repository" \ +"${AREP}mod2/sub2" + rm -rf CVS dir + + dotest cvsadm-1d5 "${testcvs} co -d dir 1d1mod" \ +"${PROG} [a-z]*: Updating dir +U dir/file1" + dotest cvsadm-1d5b "cat CVS/Repository" \ +"${AREP}\." + dotest cvsadm-1d5d "cat dir/CVS/Repository" \ +"${AREP}mod1" + rm -rf CVS dir + + dotest cvsadm-1d6 "${testcvs} co -d dir 1d2mod" \ +"${PROG} [a-z]*: Updating dir +U dir/file2" + dotest cvsadm-1d6b "cat CVS/Repository" \ +"${AREP}\." + dotest cvsadm-1d6d "cat dir/CVS/Repository" \ +"${AREP}mod2/sub2" + rm -rf CVS dir + + dotest cvsadm-1d7 "${testcvs} co -d dir 2d1mod" \ +"${PROG} [a-z]*: Updating dir +U dir/file1" + dotest cvsadm-1d7b "cat CVS/Repository" \ +"${AREP}\." + dotest cvsadm-1d7d "cat dir/CVS/Repository" \ +"${AREP}mod1" + rm -rf CVS dir + + dotest cvsadm-1d8 "${testcvs} co -d dir 2d2mod" \ +"${PROG} [a-z]*: Updating dir +U dir/file2" + dotest cvsadm-1d8b "cat CVS/Repository" \ +"${AREP}\." + dotest cvsadm-1d8d "cat dir/CVS/Repository" \ +"${AREP}mod2/sub2" + rm -rf CVS dir + + ################################################## + ## Los Combonaciones + ################################################## + + ### 1mod + + dotest cvsadm-1d9 "${testcvs} co -d dir 1mod 1mod-2" \ +"${PROG} [a-z]*: Updating dir/1mod +U dir/1mod/file1 +${PROG} [a-z]*: Updating dir/1mod-2 +U dir/1mod-2/file1-2" + # the usual for the top level + dotest cvsadm-1d9b "cat CVS/Repository" \ +"${AREP}\." + # the usual for the dir level + dotest cvsadm-1d9d "cat dir/CVS/Repository" \ +"${AREP}\." + # the usual for 1mod + dotest cvsadm-1d9f "cat dir/1mod/CVS/Repository" \ +"${AREP}mod1" + # the usual for 1mod copy + dotest cvsadm-1d9h "cat dir/1mod-2/CVS/Repository" \ +"${AREP}mod1-2" + rm -rf CVS dir + + # 1mod 2mod redmod bluemod + dotest cvsadm-1d10 "${testcvs} co -d dir 1mod 2mod" \ +"${PROG} [a-z]*: Updating dir/1mod +U dir/1mod/file1 +${PROG} [a-z]*: Updating dir/2mod +U dir/2mod/file2" + dotest cvsadm-1d10b "cat CVS/Repository" \ +"${AREP}\." + # the usual for the dir level + dotest cvsadm-1d10d "cat dir/CVS/Repository" \ +"${AREP}\." + # the usual for 1mod + dotest cvsadm-1d10f "cat dir/1mod/CVS/Repository" \ +"${AREP}mod1" + # the usual for 2dmod + dotest cvsadm-1d10h "cat dir/2mod/CVS/Repository" \ +"${AREP}mod2/sub2" + rm -rf CVS dir + + dotest cvsadm-1d11 "${testcvs} co -d dir 1mod 1d1mod" \ +"${PROG} [a-z]*: Updating dir/1mod +U dir/1mod/file1 +${PROG} [a-z]*: Updating dir/dir1d1 +U dir/dir1d1/file1" + dotest cvsadm-1d11b "cat CVS/Repository" \ +"${AREP}\." + # the usual for the dir level + dotest cvsadm-1d11d "cat dir/CVS/Repository" \ +"${AREP}\." + # the usual for 1mod + dotest cvsadm-1d11f "cat dir/1mod/CVS/Repository" \ +"${AREP}mod1" + # the usual for 1d1mod + dotest cvsadm-1d11h "cat dir/dir1d1/CVS/Repository" \ +"${AREP}mod1" + rm -rf CVS dir + + dotest cvsadm-1d12 "${testcvs} co -d dir 1mod 1d2mod" \ +"${PROG} [a-z]*: Updating dir/1mod +U dir/1mod/file1 +${PROG} [a-z]*: Updating dir/dir1d2 +U dir/dir1d2/file2" + dotest cvsadm-1d12b "cat CVS/Repository" \ +"${AREP}\." + # the usual for the dir level + dotest cvsadm-1d12d "cat dir/CVS/Repository" \ +"${AREP}\." + # the usual for 1mod + dotest cvsadm-1d12f "cat dir/1mod/CVS/Repository" \ +"${AREP}mod1" + # the usual for 1d2mod + dotest cvsadm-1d12h "cat dir/dir1d2/CVS/Repository" \ +"${AREP}mod2/sub2" + rm -rf CVS dir + + dotest cvsadm-1d13 "${testcvs} co -d dir 1mod 2d1mod" \ +"${PROG} [a-z]*: Updating dir/1mod +U dir/1mod/file1 +${PROG} [a-z]*: Updating dir/dir2d1/sub2d1 +U dir/dir2d1/sub2d1/file1" + dotest cvsadm-1d13b "cat CVS/Repository" \ +"${AREP}\." + # the usual for the dir level + dotest cvsadm-1d13d "cat dir/CVS/Repository" \ +"${AREP}\." + # the usual for 1mod + dotest cvsadm-1d13f "cat dir/1mod/CVS/Repository" \ +"${AREP}mod1" + # the usual for 2d1mod + dotest cvsadm-1d13h "cat dir/dir2d1/CVS/Repository" \ +"${AREP}CVSROOT/Emptydir" + dotest cvsadm-1d13j "cat dir/dir2d1/sub2d1/CVS/Repository" \ +"${AREP}mod1" + rm -rf CVS dir + + dotest cvsadm-1d14 "${testcvs} co -d dir 1mod 2d2mod" \ +"${PROG} [a-z]*: Updating dir/1mod +U dir/1mod/file1 +${PROG} [a-z]*: Updating dir/dir2d2/sub2d2 +U dir/dir2d2/sub2d2/file2" + dotest cvsadm-1d14b "cat CVS/Repository" \ +"${AREP}\." + # the usual for the dir level + dotest cvsadm-1d14d "cat dir/CVS/Repository" \ +"${AREP}\." + # the usual for 1mod + dotest cvsadm-1d14f "cat dir/1mod/CVS/Repository" \ +"${AREP}mod1" + # the usual for 2d2mod + dotest cvsadm-1d14h "cat dir/dir2d2/CVS/Repository" \ +"${AREP}CVSROOT/Emptydir" + dotest cvsadm-1d14j "cat dir/dir2d2/sub2d2/CVS/Repository" \ +"${AREP}mod2/sub2" + rm -rf CVS dir + + + ### 2mod + + dotest cvsadm-1d15 "${testcvs} co -d dir 2mod 2mod-2" \ +"${PROG} [a-z]*: Updating dir/2mod +U dir/2mod/file2 +${PROG} [a-z]*: Updating dir/2mod-2 +U dir/2mod-2/file2-2" + dotest cvsadm-1d15b "cat CVS/Repository" \ +"${AREP}\." + # the usual for the dir level + dotest cvsadm-1d15d "cat dir/CVS/Repository" \ +"${AREP}\." + # the usual for 2mod + dotest cvsadm-1d15f "cat dir/2mod/CVS/Repository" \ +"${AREP}mod2/sub2" + # the usual for 2mod copy + dotest cvsadm-1d15h "cat dir/2mod-2/CVS/Repository" \ +"${AREP}mod2-2/sub2-2" + rm -rf CVS dir + + dotest cvsadm-1d16 "${testcvs} co -d dir 2mod 1d1mod" \ +"${PROG} [a-z]*: Updating dir/2mod +U dir/2mod/file2 +${PROG} [a-z]*: Updating dir/dir1d1 +U dir/dir1d1/file1" + dotest cvsadm-1d16b "cat CVS/Repository" \ +"${AREP}\." + # the usual for the dir level + dotest cvsadm-1d16d "cat dir/CVS/Repository" \ +"${AREP}\." + # the usual for 2mod + dotest cvsadm-1d16f "cat dir/2mod/CVS/Repository" \ +"${AREP}mod2/sub2" + # the usual for 1d1mod + dotest cvsadm-1d16h "cat dir/dir1d1/CVS/Repository" \ +"${AREP}mod1" + rm -rf CVS dir + + dotest cvsadm-1d17 "${testcvs} co -d dir 2mod 1d2mod" \ +"${PROG} [a-z]*: Updating dir/2mod +U dir/2mod/file2 +${PROG} [a-z]*: Updating dir/dir1d2 +U dir/dir1d2/file2" + dotest cvsadm-1d17b "cat CVS/Repository" \ +"${AREP}\." + # the usual for the dir level + dotest cvsadm-1d17d "cat dir/CVS/Repository" \ +"${AREP}\." + # the usual for 2mod + dotest cvsadm-1d17f "cat dir/2mod/CVS/Repository" \ +"${AREP}mod2/sub2" + # the usual for 1d2mod + dotest cvsadm-1d17h "cat dir/dir1d2/CVS/Repository" \ +"${AREP}mod2/sub2" + rm -rf CVS dir + + dotest cvsadm-1d18 "${testcvs} co -d dir 2mod 2d1mod" \ +"${PROG} [a-z]*: Updating dir/2mod +U dir/2mod/file2 +${PROG} [a-z]*: Updating dir/dir2d1/sub2d1 +U dir/dir2d1/sub2d1/file1" + dotest cvsadm-1d18b "cat CVS/Repository" \ +"${AREP}\." + # the usual for the dir level + dotest cvsadm-1d18d "cat dir/CVS/Repository" \ +"${AREP}\." + # the usual for 2mod + dotest cvsadm-1d18f "cat dir/2mod/CVS/Repository" \ +"${AREP}mod2/sub2" + # the usual for 2d1mod + dotest cvsadm-1d18h "cat dir/dir2d1/CVS/Repository" \ +"${AREP}CVSROOT/Emptydir" + dotest cvsadm-1d18j "cat dir/dir2d1/sub2d1/CVS/Repository" \ +"${AREP}mod1" + rm -rf CVS dir + + dotest cvsadm-1d19 "${testcvs} co -d dir 2mod 2d2mod" \ +"${PROG} [a-z]*: Updating dir/2mod +U dir/2mod/file2 +${PROG} [a-z]*: Updating dir/dir2d2/sub2d2 +U dir/dir2d2/sub2d2/file2" + dotest cvsadm-1d19b "cat CVS/Repository" \ +"${AREP}\." + # the usual for the dir level + dotest cvsadm-1d19d "cat dir/CVS/Repository" \ +"${AREP}\." + # the usual for 2mod + dotest cvsadm-1d19f "cat dir/2mod/CVS/Repository" \ +"${AREP}mod2/sub2" + # the usual for 2d2mod + dotest cvsadm-1d19h "cat dir/dir2d2/CVS/Repository" \ +"${AREP}CVSROOT/Emptydir" + dotest cvsadm-1d19j "cat dir/dir2d2/sub2d2/CVS/Repository" \ +"${AREP}mod2/sub2" + rm -rf CVS dir + + + ### 1d1mod + + dotest cvsadm-1d20 "${testcvs} co -d dir 1d1mod 1d1mod-2" \ +"${PROG} [a-z]*: Updating dir/dir1d1 +U dir/dir1d1/file1 +${PROG} [a-z]*: Updating dir/dir1d1-2 +U dir/dir1d1-2/file1-2" + dotest cvsadm-1d20b "cat CVS/Repository" \ +"${AREP}\." + # the usual for the dir level + dotest cvsadm-1d20d "cat dir/CVS/Repository" \ +"${AREP}\." + # the usual for 1d1mod + dotest cvsadm-1d20f "cat dir/dir1d1/CVS/Repository" \ +"${AREP}mod1" + # the usual for 1d1mod copy + dotest cvsadm-1d20h "cat dir/dir1d1-2/CVS/Repository" \ +"${AREP}mod1-2" + rm -rf CVS dir + + dotest cvsadm-1d21 "${testcvs} co -d dir 1d1mod 1d2mod" \ +"${PROG} [a-z]*: Updating dir/dir1d1 +U dir/dir1d1/file1 +${PROG} [a-z]*: Updating dir/dir1d2 +U dir/dir1d2/file2" + dotest cvsadm-1d21b "cat CVS/Repository" \ +"${AREP}\." + # the usual for the dir level + dotest cvsadm-1d21d "cat dir/CVS/Repository" \ +"${AREP}\." + # the usual for 1d1mod + dotest cvsadm-1d21f "cat dir/dir1d1/CVS/Repository" \ +"${AREP}mod1" + # the usual for 1d2mod + dotest cvsadm-1d21h "cat dir/dir1d2/CVS/Repository" \ +"${AREP}mod2/sub2" + rm -rf CVS dir + + dotest cvsadm-1d22 "${testcvs} co -d dir 1d1mod 2d1mod" \ +"${PROG} [a-z]*: Updating dir/dir1d1 +U dir/dir1d1/file1 +${PROG} [a-z]*: Updating dir/dir2d1/sub2d1 +U dir/dir2d1/sub2d1/file1" + dotest cvsadm-1d22b "cat CVS/Repository" \ +"${AREP}\." + # the usual for the dir level + dotest cvsadm-1d22d "cat dir/CVS/Repository" \ +"${AREP}\." + # the usual for 1d1mod + dotest cvsadm-1d22f "cat dir/dir1d1/CVS/Repository" \ +"${AREP}mod1" + # the usual for 2d1mod + dotest cvsadm-1d22h "cat dir/dir2d1/CVS/Repository" \ +"${AREP}CVSROOT/Emptydir" + dotest cvsadm-1d22j "cat dir/dir2d1/sub2d1/CVS/Repository" \ +"${AREP}mod1" + rm -rf CVS dir + + dotest cvsadm-1d23 "${testcvs} co -d dir 1d1mod 2d2mod" \ +"${PROG} [a-z]*: Updating dir/dir1d1 +U dir/dir1d1/file1 +${PROG} [a-z]*: Updating dir/dir2d2/sub2d2 +U dir/dir2d2/sub2d2/file2" + dotest cvsadm-1d23b "cat CVS/Repository" \ +"${AREP}\." + # the usual for the dir level + dotest cvsadm-1d23d "cat dir/CVS/Repository" \ +"${AREP}\." + # the usual for 1d1mod + dotest cvsadm-1d23f "cat dir/dir1d1/CVS/Repository" \ +"${AREP}mod1" + # the usual for 2d2mod + dotest cvsadm-1d23h "cat dir/dir2d2/CVS/Repository" \ +"${AREP}CVSROOT/Emptydir" + dotest cvsadm-1d23j "cat dir/dir2d2/sub2d2/CVS/Repository" \ +"${AREP}mod2/sub2" + rm -rf CVS dir + + + ### 1d2mod + + dotest cvsadm-1d24 "${testcvs} co -d dir 1d2mod 1d2mod-2" \ +"${PROG} [a-z]*: Updating dir/dir1d2 +U dir/dir1d2/file2 +${PROG} [a-z]*: Updating dir/dir1d2-2 +U dir/dir1d2-2/file2-2" + dotest cvsadm-1d24b "cat CVS/Repository" \ +"${AREP}\." + # the usual for the dir level + dotest cvsadm-1d24d "cat dir/CVS/Repository" \ +"${AREP}\." + # the usual for 1d2mod + dotest cvsadm-1d24f "cat dir/dir1d2/CVS/Repository" \ +"${AREP}mod2/sub2" + # the usual for 1d2mod copy + dotest cvsadm-1d24h "cat dir/dir1d2-2/CVS/Repository" \ +"${AREP}mod2-2/sub2-2" + rm -rf CVS dir + + dotest cvsadm-1d25 "${testcvs} co -d dir 1d2mod 2d1mod" \ +"${PROG} [a-z]*: Updating dir/dir1d2 +U dir/dir1d2/file2 +${PROG} [a-z]*: Updating dir/dir2d1/sub2d1 +U dir/dir2d1/sub2d1/file1" + dotest cvsadm-1d25b "cat CVS/Repository" \ +"${AREP}\." + # the usual for the dir level + dotest cvsadm-1d25d "cat dir/CVS/Repository" \ +"${AREP}\." + # the usual for 1d2mod + dotest cvsadm-1d25f "cat dir/dir1d2/CVS/Repository" \ +"${AREP}mod2/sub2" + # the usual for 2d1mod + dotest cvsadm-1d25h "cat dir/dir2d1/CVS/Repository" \ +"${AREP}CVSROOT/Emptydir" + dotest cvsadm-1d25j "cat dir/dir2d1/sub2d1/CVS/Repository" \ +"${AREP}mod1" + rm -rf CVS dir + + dotest cvsadm-1d26 "${testcvs} co -d dir 1d2mod 2d2mod" \ +"${PROG} [a-z]*: Updating dir/dir1d2 +U dir/dir1d2/file2 +${PROG} [a-z]*: Updating dir/dir2d2/sub2d2 +U dir/dir2d2/sub2d2/file2" + dotest cvsadm-1d26b "cat CVS/Repository" \ +"${AREP}\." + # the usual for the dir level + dotest cvsadm-1d26d "cat dir/CVS/Repository" \ +"${AREP}\." + # the usual for 1d2mod + dotest cvsadm-1d26f "cat dir/dir1d2/CVS/Repository" \ +"${AREP}mod2/sub2" + # the usual for 2d2mod + dotest cvsadm-1d26h "cat dir/dir2d2/CVS/Repository" \ +"${AREP}CVSROOT/Emptydir" + dotest cvsadm-1d26j "cat dir/dir2d2/sub2d2/CVS/Repository" \ +"${AREP}mod2/sub2" + rm -rf CVS dir + + + # 2d1mod + + dotest cvsadm-1d27 "${testcvs} co -d dir 2d1mod 2d1mod-2" \ +"${PROG} [a-z]*: Updating dir/dir2d1/sub2d1 +U dir/dir2d1/sub2d1/file1 +${PROG} [a-z]*: Updating dir/dir2d1-2/sub2d1-2 +U dir/dir2d1-2/sub2d1-2/file1-2" + dotest cvsadm-1d27b "cat CVS/Repository" \ +"${AREP}\." + # the usual for the dir level + dotest cvsadm-1d27d "cat dir/CVS/Repository" \ +"${AREP}\." + # the usual for 2d1mod + dotest cvsadm-1d27f "cat dir/dir2d1/CVS/Repository" \ +"${AREP}CVSROOT/Emptydir" + dotest cvsadm-1d27h "cat dir/dir2d1/sub2d1/CVS/Repository" \ +"${AREP}mod1" + # the usual for 2d1mod + dotest cvsadm-1d27j "cat dir/dir2d1-2/CVS/Repository" \ +"${AREP}CVSROOT/Emptydir" + dotest cvsadm-1d27l "cat dir/dir2d1-2/sub2d1-2/CVS/Repository" \ +"${AREP}mod1-2" + rm -rf CVS dir + + dotest cvsadm-1d28 "${testcvs} co -d dir 2d1mod 2d2mod" \ +"${PROG} [a-z]*: Updating dir/dir2d1/sub2d1 +U dir/dir2d1/sub2d1/file1 +${PROG} [a-z]*: Updating dir/dir2d2/sub2d2 +U dir/dir2d2/sub2d2/file2" + dotest cvsadm-1d28b "cat CVS/Repository" \ +"${AREP}\." + # the usual for the dir level + dotest cvsadm-1d28d "cat dir/CVS/Repository" \ +"${AREP}\." + # the usual for 2d1mod + dotest cvsadm-1d28f "cat dir/dir2d1/CVS/Repository" \ +"${AREP}CVSROOT/Emptydir" + dotest cvsadm-1d28h "cat dir/dir2d1/sub2d1/CVS/Repository" \ +"${AREP}mod1" + # the usual for 2d2mod + dotest cvsadm-1d28j "cat dir/dir2d2/CVS/Repository" \ +"${AREP}CVSROOT/Emptydir" + dotest cvsadm-1d28l "cat dir/dir2d2/sub2d2/CVS/Repository" \ +"${AREP}mod2/sub2" + rm -rf CVS dir + + + # 2d2mod + + dotest cvsadm-1d29 "${testcvs} co -d dir 2d2mod 2d2mod-2" \ +"${PROG} [a-z]*: Updating dir/dir2d2/sub2d2 +U dir/dir2d2/sub2d2/file2 +${PROG} [a-z]*: Updating dir/dir2d2-2/sub2d2-2 +U dir/dir2d2-2/sub2d2-2/file2-2" + dotest cvsadm-1d29b "cat CVS/Repository" \ +"${AREP}\." + # the usual for the dir level + dotest cvsadm-1d29d "cat dir/CVS/Repository" \ +"${AREP}\." + # the usual for 2d2mod + dotest cvsadm-1d29f "cat dir/dir2d2/CVS/Repository" \ +"${AREP}CVSROOT/Emptydir" + dotest cvsadm-1d29h "cat dir/dir2d2/sub2d2/CVS/Repository" \ +"${AREP}mod2/sub2" + # the usual for 2d2mod + dotest cvsadm-1d29j "cat dir/dir2d2-2/CVS/Repository" \ +"${AREP}CVSROOT/Emptydir" + dotest cvsadm-1d29l "cat dir/dir2d2-2/sub2d2-2/CVS/Repository" \ +"${AREP}mod2-2/sub2-2" + rm -rf CVS dir + + ################################################## + ## And now, some of that again using the "-d" flag + ## on the command line, but use a longer path. + ################################################## + + dotest cvsadm-2d3 "${testcvs} co -d dir/dir2 1mod" \ +"${PROG} [a-z]*: Updating dir/dir2 +U dir/dir2/file1" + dotest cvsadm-2d3b "cat CVS/Repository" \ +"${AREP}\." + dotest cvsadm-2d3d "cat dir/CVS/Repository" \ +"${AREP}CVSROOT/Emptydir" + dotest cvsadm-2d3f "cat dir/dir2/CVS/Repository" \ +"${AREP}mod1" + rm -rf CVS dir + + dotest cvsadm-2d4 "${testcvs} co -d dir/dir2 2mod" \ +"${PROG} [a-z]*: Updating dir/dir2 +U dir/dir2/file2" + dotest cvsadm-2d4b "cat CVS/Repository" \ +"${AREP}\." + dotest cvsadm-2d4d "cat dir/CVS/Repository" \ +"${AREP}CVSROOT/Emptydir" + dotest cvsadm-2d4f "cat dir/dir2/CVS/Repository" \ +"${AREP}mod2/sub2" + rm -rf CVS dir + + dotest cvsadm-2d5 "${testcvs} co -d dir/dir2 1d1mod" \ +"${PROG} [a-z]*: Updating dir/dir2 +U dir/dir2/file1" + dotest cvsadm-2d5b "cat CVS/Repository" \ +"${AREP}\." + dotest cvsadm-2d5d "cat dir/CVS/Repository" \ +"${AREP}CVSROOT/Emptydir" + dotest cvsadm-2d5f "cat dir/dir2/CVS/Repository" \ +"${AREP}mod1" + rm -rf CVS dir + + dotest cvsadm-2d6 "${testcvs} co -d dir/dir2 1d2mod" \ +"${PROG} [a-z]*: Updating dir/dir2 +U dir/dir2/file2" + dotest cvsadm-2d6b "cat CVS/Repository" \ +"${AREP}\." + dotest cvsadm-2d6d "cat dir/CVS/Repository" \ +"${AREP}CVSROOT/Emptydir" + dotest cvsadm-2d6f "cat dir/dir2/CVS/Repository" \ +"${AREP}mod2/sub2" + rm -rf CVS dir + + dotest cvsadm-2d7 "${testcvs} co -d dir/dir2 2d1mod" \ +"${PROG} [a-z]*: Updating dir/dir2 +U dir/dir2/file1" + dotest cvsadm-2d7b "cat CVS/Repository" \ +"${AREP}\." + dotest cvsadm-2d7d "cat dir/CVS/Repository" \ +"${AREP}CVSROOT/Emptydir" + dotest cvsadm-2d7f "cat dir/dir2/CVS/Repository" \ +"${AREP}mod1" + rm -rf CVS dir + + dotest cvsadm-2d8 "${testcvs} co -d dir/dir2 2d2mod" \ +"${PROG} [a-z]*: Updating dir/dir2 +U dir/dir2/file2" + dotest cvsadm-2d8b "cat CVS/Repository" \ +"${AREP}\." + dotest cvsadm-2d8d "cat dir/CVS/Repository" \ +"${AREP}CVSROOT/Emptydir" + dotest cvsadm-2d8f "cat dir/dir2/CVS/Repository" \ +"${AREP}mod2/sub2" + rm -rf CVS dir + + ################################################## + ## And now, a few of those tests revisited to + ## test the behavior of the -N flag. + ################################################## + + dotest cvsadm-N3 "${testcvs} co -N 1mod" \ +"${PROG} [a-z]*: Updating 1mod +U 1mod/file1" + dotest cvsadm-N3b "cat CVS/Repository" \ +"${AREP}\." + dotest cvsadm-N3d "cat 1mod/CVS/Repository" \ +"${AREP}mod1" + rm -rf CVS 1mod + + dotest cvsadm-N4 "${testcvs} co -N 2mod" \ +"${PROG} [a-z]*: Updating 2mod +U 2mod/file2" + dotest cvsadm-N4b "cat CVS/Repository" \ +"${AREP}\." + dotest cvsadm-N4d "cat 2mod/CVS/Repository" \ +"${AREP}mod2/sub2" + rm -rf CVS 2mod + + dotest cvsadm-N5 "${testcvs} co -N 1d1mod" \ +"${PROG} [a-z]*: Updating dir1d1 +U dir1d1/file1" + dotest cvsadm-N5b "cat CVS/Repository" \ +"${AREP}\." + dotest cvsadm-N5d "cat dir1d1/CVS/Repository" \ +"${AREP}mod1" + rm -rf CVS dir1d1 + + dotest cvsadm-N6 "${testcvs} co -N 1d2mod" \ +"${PROG} [a-z]*: Updating dir1d2 +U dir1d2/file2" + dotest cvsadm-N6b "cat CVS/Repository" \ +"${AREP}\." + dotest cvsadm-N6d "cat dir1d2/CVS/Repository" \ +"${AREP}mod2/sub2" + rm -rf CVS dir1d2 + + dotest cvsadm-N7 "${testcvs} co -N 2d1mod" \ +"${PROG} [a-z]*: Updating dir2d1/sub2d1 +U dir2d1/sub2d1/file1" + dotest cvsadm-N7b "cat CVS/Repository" \ +"${AREP}\." + dotest cvsadm-N7d "cat dir2d1/CVS/Repository" \ +"${AREP}CVSROOT/Emptydir" + dotest cvsadm-N7f "cat dir2d1/sub2d1/CVS/Repository" \ +"${AREP}mod1" + rm -rf CVS dir2d1 + + dotest cvsadm-N8 "${testcvs} co -N 2d2mod" \ +"${PROG} [a-z]*: Updating dir2d2/sub2d2 +U dir2d2/sub2d2/file2" + dotest cvsadm-N8b "cat CVS/Repository" \ +"${AREP}\." + dotest cvsadm-N8d "cat dir2d2/CVS/Repository" \ +"${AREP}CVSROOT/Emptydir" + dotest cvsadm-N8f "cat dir2d2/sub2d2/CVS/Repository" \ +"${AREP}mod2/sub2" + rm -rf CVS dir2d2 + + ## the ones in one-deep directories + + dotest cvsadm-N1d3 "${testcvs} co -N -d dir 1mod" \ +"${PROG} [a-z]*: Updating dir/1mod +U dir/1mod/file1" + dotest cvsadm-N1d3b "cat CVS/Repository" \ +"${AREP}\." + dotest cvsadm-N1d3d "cat dir/CVS/Repository" \ +"${AREP}\." + dotest cvsadm-N1d3f "cat dir/1mod/CVS/Repository" \ +"${AREP}mod1" + rm -rf CVS dir + + dotest cvsadm-N1d4 "${testcvs} co -N -d dir 2mod" \ +"${PROG} [a-z]*: Updating dir/2mod +U dir/2mod/file2" + dotest cvsadm-N1d4b "cat CVS/Repository" \ +"${AREP}\." + dotest cvsadm-N1d4d "cat dir/CVS/Repository" \ +"${AREP}\." + dotest cvsadm-N1d4f "cat dir/2mod/CVS/Repository" \ +"${AREP}mod2/sub2" + rm -rf CVS dir + + dotest cvsadm-N1d5 "${testcvs} co -N -d dir 1d1mod" \ +"${PROG} [a-z]*: Updating dir/dir1d1 +U dir/dir1d1/file1" + dotest cvsadm-N1d5b "cat CVS/Repository" \ +"${AREP}\." + dotest cvsadm-N1d5d "cat dir/CVS/Repository" \ +"${AREP}\." + dotest cvsadm-N1d5d "cat dir/dir1d1/CVS/Repository" \ +"${AREP}mod1" + rm -rf CVS dir + + dotest cvsadm-N1d6 "${testcvs} co -N -d dir 1d2mod" \ +"${PROG} [a-z]*: Updating dir/dir1d2 +U dir/dir1d2/file2" + dotest cvsadm-N1d6b "cat CVS/Repository" \ +"${AREP}\." + dotest cvsadm-N1d6d "cat dir/CVS/Repository" \ +"${AREP}\." + dotest cvsadm-N1d6f "cat dir/dir1d2/CVS/Repository" \ +"${AREP}mod2/sub2" + rm -rf CVS dir + + dotest cvsadm-N1d7 "${testcvs} co -N -d dir 2d1mod" \ +"${PROG} [a-z]*: Updating dir/dir2d1/sub2d1 +U dir/dir2d1/sub2d1/file1" + dotest cvsadm-N1d7b "cat CVS/Repository" \ +"${AREP}\." + dotest cvsadm-N1d7d "cat dir/CVS/Repository" \ +"${AREP}\." + dotest cvsadm-N1d7f "cat dir/dir2d1/CVS/Repository" \ +"${AREP}CVSROOT/Emptydir" + dotest cvsadm-N1d7h "cat dir/dir2d1/sub2d1/CVS/Repository" \ +"${AREP}mod1" + rm -rf CVS dir + + dotest cvsadm-N1d8 "${testcvs} co -N -d dir 2d2mod" \ +"${PROG} [a-z]*: Updating dir/dir2d2/sub2d2 +U dir/dir2d2/sub2d2/file2" + dotest cvsadm-N1d8b "cat CVS/Repository" \ +"${AREP}\." + dotest cvsadm-N1d8d "cat dir/CVS/Repository" \ +"${AREP}\." + dotest cvsadm-N1d8d "cat dir/dir2d2/CVS/Repository" \ +"${AREP}CVSROOT/Emptydir" + dotest cvsadm-N1d8d "cat dir/dir2d2/sub2d2/CVS/Repository" \ +"${AREP}mod2/sub2" + rm -rf CVS dir + + ## the ones in two-deep directories + + dotest cvsadm-N2d3 "${testcvs} co -N -d dir/dir2 1mod" \ +"${PROG} [a-z]*: Updating dir/dir2/1mod +U dir/dir2/1mod/file1" + dotest cvsadm-N2d3b "cat CVS/Repository" \ +"${AREP}\." + dotest cvsadm-N2d3d "cat dir/CVS/Repository" \ +"${AREP}CVSROOT/Emptydir" + dotest cvsadm-N2d3f "cat dir/dir2/CVS/Repository" \ +"${AREP}\." + dotest cvsadm-N2d3h "cat dir/dir2/1mod/CVS/Repository" \ +"${AREP}mod1" + rm -rf CVS dir + + dotest cvsadm-N2d4 "${testcvs} co -N -d dir/dir2 2mod" \ +"${PROG} [a-z]*: Updating dir/dir2/2mod +U dir/dir2/2mod/file2" + dotest cvsadm-N2d4b "cat CVS/Repository" \ +"${AREP}\." + dotest cvsadm-N2d4d "cat dir/CVS/Repository" \ +"${AREP}CVSROOT/Emptydir" + dotest cvsadm-N2d4f "cat dir/dir2/CVS/Repository" \ +"${AREP}\." + dotest cvsadm-N2d4h "cat dir/dir2/2mod/CVS/Repository" \ +"${AREP}mod2/sub2" + rm -rf CVS dir + + dotest cvsadm-N2d5 "${testcvs} co -N -d dir/dir2 1d1mod" \ +"${PROG} [a-z]*: Updating dir/dir2/dir1d1 +U dir/dir2/dir1d1/file1" + dotest cvsadm-N2d5b "cat CVS/Repository" \ +"${AREP}\." + dotest cvsadm-N2d5d "cat dir/CVS/Repository" \ +"${AREP}CVSROOT/Emptydir" + dotest cvsadm-N2d5f "cat dir/dir2/CVS/Repository" \ +"${AREP}\." + dotest cvsadm-N2d5h "cat dir/dir2/dir1d1/CVS/Repository" \ +"${AREP}mod1" + rm -rf CVS dir + + dotest cvsadm-N2d6 "${testcvs} co -N -d dir/dir2 1d2mod" \ +"${PROG} [a-z]*: Updating dir/dir2/dir1d2 +U dir/dir2/dir1d2/file2" + dotest cvsadm-N2d6b "cat CVS/Repository" \ +"${AREP}\." + dotest cvsadm-N2d6d "cat dir/CVS/Repository" \ +"${AREP}CVSROOT/Emptydir" + dotest cvsadm-N2d6f "cat dir/dir2/CVS/Repository" \ +"${AREP}\." + dotest cvsadm-N2d6h "cat dir/dir2/dir1d2/CVS/Repository" \ +"${AREP}mod2/sub2" + rm -rf CVS dir + + dotest cvsadm-N2d7 "${testcvs} co -N -d dir/dir2 2d1mod" \ +"${PROG} [a-z]*: Updating dir/dir2/dir2d1/sub2d1 +U dir/dir2/dir2d1/sub2d1/file1" + dotest cvsadm-N2d7b "cat CVS/Repository" \ +"${AREP}\." + dotest cvsadm-N2d7d "cat dir/CVS/Repository" \ +"${AREP}CVSROOT/Emptydir" + dotest cvsadm-N2d7f "cat dir/dir2/CVS/Repository" \ +"${AREP}\." + dotest cvsadm-N2d7f "cat dir/dir2/dir2d1/CVS/Repository" \ +"${AREP}CVSROOT/Emptydir" + dotest cvsadm-N2d7h "cat dir/dir2/dir2d1/sub2d1/CVS/Repository" \ +"${AREP}mod1" + rm -rf CVS dir + + dotest cvsadm-N2d8 "${testcvs} co -N -d dir/dir2 2d2mod" \ +"${PROG} [a-z]*: Updating dir/dir2/dir2d2/sub2d2 +U dir/dir2/dir2d2/sub2d2/file2" + dotest cvsadm-N2d8b "cat CVS/Repository" \ +"${AREP}\." + dotest cvsadm-N2d8d "cat dir/CVS/Repository" \ +"${AREP}CVSROOT/Emptydir" + dotest cvsadm-N2d8f "cat dir/dir2/CVS/Repository" \ +"${AREP}\." + dotest cvsadm-N2d8h "cat dir/dir2/dir2d2/CVS/Repository" \ +"${AREP}CVSROOT/Emptydir" + dotest cvsadm-N2d8j "cat dir/dir2/dir2d2/sub2d2/CVS/Repository" \ +"${AREP}mod2/sub2" + rm -rf CVS dir + + ################################################## + ## That's enough of that, thank you very much. + ################################################## + + # remove our junk + cd .. + rm -rf 1 + rm -rf ${CVSROOT_DIRNAME}/1mod + rm -rf ${CVSROOT_DIRNAME}/1mod-2 + rm -rf ${CVSROOT_DIRNAME}/2mod + rm -rf ${CVSROOT_DIRNAME}/2mod-2 + ;; + + diffmerge1) + # Make sure CVS can merge correctly in circumstances where it + # used to mess up (due to a bug which existed in diffutils 2.7 + # and 2.6, but not 2.5, and which has been fixed in CVS's diff + # lib by Paul Eggert, bless his bitty heart). + + # This first test involves two working copies, "mine" and + # "yours", checked out from the same repository at the same + # time. In yours, you remove some text from the end of the + # file and check it in; meanwhile, "me" has commented out some + # lines earlier in the file, and I go to check it in right + # after you checked yours in. CVS naturally tells me the file + # is not up-to-date, so I run cvs update, but it updates + # incorrectly, leaving in the lines of text you just deleted. + # Bad! I'm in too much of a hurry to actually look at the + # file, so I check it in and go home, and so your changes have + # been lost. Later you discover this, and you suspect me of + # deliberately sabotaging your work, so you let all the air + # out of my tires. Only after a series of expensive lawsuits + # and countersuits do we discover it this was all CVS's + # fault. + # + # Luckily, this problem has been fixed now, as our test will + # handily confirm, no doubt: + + # First make a repository containing the original text: + + # We should be here anyway, but cd to it just in case: + cd ${TESTDIR} + + mkdir diffmerge1 + cd diffmerge1 + + # The text of the file is inlined here because `echo' loses + # newlines, and I don't know how portable the -e flag is. + # + # This is the file we both start out with: + echo "// Button.java + +package random.application; + +import random.util.star; + +public class Button +{ + /star Instantiates a Button with origin (0, 0) and zero width and height. + star You must call an initializer method to properly initialize the Button. + star/ + public Button () + { + super (); + + _titleColor = Color.black; + _disabledTitleColor = Color.gray; + _titleFont = Font.defaultFont (); + } + + /star Convenience constructor for instantiating a Button with + star bounds x, y, width, and height. Equivalent to + star foo = new Button (); + star foo.init (x, y, width, height); + star/ + public Button (int x, int y, int width, int height) + { + this (); + init (x, y, width, height); + } +}" > the_file + + dotest diffmerge1_import \ + "${testcvs} import -m import diffmerge1 tag1 tag2" \ + "${DOTSTAR}No conflicts created by this import" + cd .. + rm -rf diffmerge1 + + # Check out two working copies, one for "you" and one for "me" + ${testcvs} checkout diffmerge1 >/dev/null 2>&1 + mv diffmerge1 diffmerge1_yours + ${testcvs} checkout diffmerge1 >/dev/null 2>&1 + mv diffmerge1 diffmerge1_mine + + # In your working copy, you'll remove the Button() method, and + # then check in your change before I check in mine: + cd diffmerge1_yours + echo "// Button.java + +package random.application; + +import random.util.star; + +public class Button +{ + /star Instantiates a Button with origin (0, 0) and zero width and height. + star You must call an initializer method to properly initialize the Button. + star/ + public Button () + { + super (); + + _titleColor = Color.black; + _disabledTitleColor = Color.gray; + _titleFont = Font.defaultFont (); + } +}" > the_file + dotest diffmerge1_yours \ + "${testcvs} ci -m yours" \ + "${DOTSTAR}hecking in ${DOTSTAR}" + + # My working copy still has the Button() method, but I + # comment out some code at the top of the class. Then I + # update, after both my modifications and your checkin: + cd ../diffmerge1_mine + echo "// Button.java + +package random.application; + +import random.util.star; + +public class Button +{ + /star Instantiates a Button with origin (0, 0) and zero width and height. + star You must call an initializer method to properly initialize the Button. + star/ + public Button () + { + super (); + + // _titleColor = Color.black; + // _disabledTitleColor = Color.gray; + // _titleFont = Font.defaultFont (); + } + + /star Convenience constructor for instantiating a Button with + star bounds x, y, width, and height. Equivalent to + star foo = new Button (); + star foo.init (x, y, width, height); + star/ + public Button (int x, int y, int width, int height) + { + this (); + init (x, y, width, height); + } +}" > the_file + dotest diffmerge1_mine \ + "${testcvs} update" \ + "${DOTSTAR}erging${DOTSTAR}" + + # So if your changes didn't make it into my working copy, or + # in any case if the file does not look like the final text as + # quoted below, then the test flunks: + echo "// Button.java + +package random.application; + +import random.util.star; + +public class Button +{ + /star Instantiates a Button with origin (0, 0) and zero width and height. + star You must call an initializer method to properly initialize the Button. + star/ + public Button () + { + super (); + + // _titleColor = Color.black; + // _disabledTitleColor = Color.gray; + // _titleFont = Font.defaultFont (); + } +}" > comp_me + dotest diffmerge1_cmp "cmp the_file comp_me" '' + + # Clean up after ourselves: + cd .. + rm -rf diffmerge1_yours diffmerge1_mine ${CVSROOT_DIRNAME}/diffmerge1 + + ;; + + diffmerge2) + + # FIXME: This test should be rewritten to be much more concise. + # It currently weighs in at something like 600 lines, but the + # same thing could probably be tested in more like 50-100 lines. + mkdir diffmerge2 + + # This tests for another diffmerge bug reported by Martin + # Tomes; actually, his bug was probably caused by an initial + # fix for the bug in test diffmerge1, and likely wasn't ever + # a problem in CVS as long as one was using a normal + # distribution of diff or a version of CVS that has the diff + # lib in it. + # + # Nevertheless, once burned twice cautious, so we test for his + # bug here. + # + # Here is his report, more or less verbatim: + # ------------------------------------------ + # + # Put the attached file (sgrid.h,v) into your repository + # somewhere, check out the module and do this: + # + # cvs update -j Review_Phase_2_Enhancements sgrid.h + # cvs diff -r Review_V1p3 sgrid.h + # + # As there have been no changes made on the trunk there + # should be no differences, however this is output: + # + # % cvs diff -r Review_V1p3 sgrid.h + # Index: sgrid.h + # =================================================================== + # RCS file: /usr/local/repository/play/fred/sgrid.h,v + # retrieving revision 1.1.2.1 + # diff -r1.1.2.1 sgrid.h + # 178a179,184 + # > /*-------------------------------------------------------------- + # > INLINE FUNCTION : HORIZONTALLINES + # > NOTES : Description at the end of the file + # > ----------------------------------------------------------------*/ + # > uint16 horizontalLines( void ); + # > + # + # I did a cvs diff -c -r 1.1 -r 1.1.2.1 sgrid.h and patched those + # differences to sgrid.h version 1.1 and got the correct result + # so it looks like the built in patch is faulty. + # ------------------------------------------------------------------- + # + # This is the RCS file, sgrid.h,v, that he sent: + + echo "head 1.1; +access; +symbols + Review_V1p3:1.1.2.1 + Review_V1p3C:1.1.2.1 + Review_1p3A:1.1.2.1 + Review_V1p3A:1.1.2.1 + Review_Phase_2_Enhancements:1.1.0.2 + Review_V1p2:1.1 + Review_V1p2B:1.1 + Review_V1p2A:1.1 + Review_V1p1:1.1 + Review_1p1:1.1; +locks; strict; +comment @ * @; + + +1.1 +date 97.04.02.11.20.05; author colinl; state Exp; +branches + 1.1.2.1; +next ; + +1.1.2.1 +date 97.06.09.10.00.07; author colinl; state Exp; +branches; +next ; + + +desc +@@ + + +1.1 +log +@Project: DEV1175 +DCN: +Tested By: Colin Law +Reviewed By: +Reason for Change: Initial Revision of all files + +Design Change Details: + +Implications: +@ +text +@/* \$""Header: L:/gpanels/dis/sgrid.h_v 1.1.1.0 24 Jan 1996 14:59:20 PAULT \$ */ +/* + * \$""Log: L:/gpanels/dis/sgrid.h_v \$ + * + * Rev 1.1.1.0 24 Jan 1996 14:59:20 PAULT + * Branched + * + * Rev 1.1 24 Jan 1996 12:09:52 PAULT + * Consolidated 4100 code merged to trunk + * + * Rev 1.0.2.0 01 Jun 1995 14:18:58 DAVEH + * Branched + * + * Rev 1.0 19 Apr 1995 16:32:48 COLINL + * Initial revision. +*/ +/***************************************************************************** +FILE : SGRID.H +VERSION : 2.1 +AUTHOR : Dave Hartley +SYSTEM : Borland C++ +DESCRIPTION : The declaration of the scrolling grid class + +*****************************************************************************/ +#if !defined(__SGRID_H) +#define __SGRID_H + +#if !defined(__SCROLL_H) +#include <scroll.h> +#endif + +#if !defined(__GKI_H) +#include \"gki.h\" +#endif + +#if defined PRINTING_SUPPORT +class Printer; +#endif + +/***************************************************************************** +CLASS : ScrollingGrid +DESCRIPTION: This class inherits from a grid and a scrollable, and + can therefore use all the PUBLIC services provided by these + classes. A description of these can be found in + GRID.H and SCROLL.H. + A scrolling grid is a set of horizontal and vertical lines + that scroll and continually update to provide a complete grid + +*****************************************************************************/ + +class ScrollingGrid : public Scrollable +{ + public: +#if defined _WINDOWS +/*--------------------------------------------------------------------------- +FUNCTION : CONSTRUCTOR +DESCRIPTION : sets up the details of the grid, ready for painting +ARGUMENTS : name : sgColour + - the colour of the grid + sgLineType + - the syle of line + sgHorizontalTotal + - the total number of horizontal grid lines + verticalSpacingMin + - the min distance between the vertical grid lines + on the scrolling axis + currentTimestamp + - timestamp value now + ticksPerSecond + - number of timestamp ticks per second + ticksPerPixel + - number of timestamp ticks per pixel required + +RETURN : None +NOTES : +---------------------------------------------------------------------------*/ + ScrollingGrid( GkiColour sgColour, GkiLineType sgLineType, + uint16 sgHorizontalTotal, + uint16 verticalSpacingMin, uint32 currentTimestamp, + uint16 ticksPerSecond, uint32 ticksPerPixel ); +#else +/*--------------------------------------------------------------------------- +FUNCTION : CONSTRUCTOR +DESCRIPTION : sets up the details of the grid, ready for painting +ARGUMENTS : name : sgColour + - the colour of the grid + sgLineType + - the syle of line + sgHorizontalTotal ( THE MAX NUMBER OF LINES IS 100 ) + - the total number of horizontal grid lines + sgVerticalSpacing + - the distance between the vertical grid lines + on the scrolling axis + +RETURN : None +NOTES : If the caller does not get the total grid lines value, synced + with the overall size of the viewport, the spacing between + grid lines will not be consistent. + +---------------------------------------------------------------------------*/ + ScrollingGrid( GkiColour sgColour, GkiLineType sgLineType + , uint16 sgHorizontalTotal, uint16 sgVerticalSpacing ); +#endif +/*--------------------------------------------------------------------------- +FUNCTION : DESTRUCTOR +DESCRIPTION : tidies it all up +ARGUMENTS : name : + +RETURN : None +NOTES : +---------------------------------------------------------------------------*/ + ~ScrollingGrid( void ); + +/*--------------------------------------------------------------------------- +FUNCTION : ATTACH +DESCRIPTION : This service overloads the base class service, as it does + additional work at the time of attachment. + +ARGUMENTS : name : tDrawingArea + - the scrolled viewport to attach this trend to + +RETURN : None +NOTES : +---------------------------------------------------------------------------*/ + void attach( SViewport *tDrawingArea ); + +#if defined _WINDOWS +/*--------------------------------------------------------------------------- +FUNCTION : calculateVerticalSpacing +DESCRIPTION : determines optimum spacing along time axis +ARGUMENTS : +RETURN : None +NOTES : +---------------------------------------------------------------------------*/ + void calculateVerticalSpacing(); + +/*--------------------------------------------------------------------------- +FUNCTION : gridSpacingTicks +DESCRIPTION : Provides the grid spacing in the time axis in ticks +ARGUMENTS : +RETURN : Number of ticks +NOTES : +---------------------------------------------------------------------------*/ + uint32 gridSpacingTicks(); + +#endif + +/*--------------------------------------------------------------------------- +INLINE FUNCTION : HORIZONTALLINES +NOTES : Description at the end of the file +---------------------------------------------------------------------------*/ + uint16 horizontalLines( void ); + +#if defined _WINDOWS +// In Windows the OnDraw() function replaces paint() +/*--------------------------------------------------------------------------- +FUNCTION : ScrollingGrid OnDraw +DESCRIPTION : Paints the given area of the grid. + Pure virtual +ARGUMENTS : pDC pointer to the device context to use for display + Note that the device context operates in the coords + of the window owning the viewport +RETURN : None +NOTES : +---------------------------------------------------------------------------*/ + virtual void OnDraw( CDC *pDC ); + +#else // not Windows + +/*--------------------------------------------------------------------------- +FUNCTION : PAINT +DESCRIPTION : This extends the standard grid paint method to paint the + viewport relative to its current position. + +ARGUMENTS : name : + +RETURN : None +NOTES : +---------------------------------------------------------------------------*/ + void paint( void ); +#endif + +/*--------------------------------------------------------------------------- +FUNCTION : P A I N T T E X T M A R K E R S +DESCRIPTION : this service allow the text markers to be painted seperatley + from the grid lines + +ARGUMENTS : name : + +RETURN : None +NOTES : +---------------------------------------------------------------------------*/ + void paintTextMarkers(); + +#if defined PRINTING_SUPPORT +/*--------------------------------------------------------------------------- +FUNCTION : P R I N T +DESCRIPTION : This print service prints a grid marker ( being either a + timestamp or a date, IF there is one at the plot position + given + +ARGUMENTS : name : + displayPosition + - Where in the log to look to see if there is an + entry to print + + - printerPtr + the printer to print to + +RETURN : None +NOTES : +---------------------------------------------------------------------------*/ + void print( uint16 currentPrintPos, Printer *printerPtr ); +#endif + +/*--------------------------------------------------------------------------- +FUNCTION : S E T D R I V E D I R E C T I O N +DESCRIPTION : Sets direction for update and scrolling forwards or backwards +ARGUMENTS : direction - required direction +RETURN : None +NOTES : +---------------------------------------------------------------------------*/ + void setDriveDirection( ScrollDirection direction ); + +/*--------------------------------------------------------------------------- +FUNCTION : S E T U P +DESCRIPTION : service that will setup the grid prior to a paint + +ARGUMENTS : name : + - newTimestamp + + + - newTimeBase + the number of ticks that represent a plot point on + the trendgraph. + +RETURN : None +NOTES : +---------------------------------------------------------------------------*/ + void setup( uint32 newTimestamp, uint32 newTimeBase ); + +#if defined PRINTING_SUPPORT +/*--------------------------------------------------------------------------- +FUNCTION : S E T U P F O R P R I N T +DESCRIPTION : This service iis to be called prior to printing. It allows + the grid to prepare its markers ready for the print + commands + +ARGUMENTS : name : + +RETURN : None +NOTES : +---------------------------------------------------------------------------*/ + void setupForPrint(); +#endif + +/*--------------------------------------------------------------------------- +FUNCTION : UPDATE +DESCRIPTION : When this service is called it will calculate what needs to + be painted and fill in the display again. + +ARGUMENTS : name : timeStamp + - the reference time of this update. + +RETURN : None +NOTES : +---------------------------------------------------------------------------*/ + void update( uint32 timeStamp ); + +/*--------------------------------------------------------------------------- +FUNCTION : U P D A T E B U F F E R +DESCRIPTION : When a display update is not required, use this method. It + updates the internal data ready for a call to paint that + will then show the grid in the right position + +ARGUMENTS : name : + +RETURN : None +NOTES : +---------------------------------------------------------------------------*/ + void updateBuffer( void ); + + private: + +/*--------------------------------------------------------------------------- +FUNCTION : M A K E G R I D M A R K E R +DESCRIPTION : service that perpares a string for display. The string will + either be a short date, or short time. this is determined + by the current setting of the dateMarker flag + +ARGUMENTS : name : timestampVal + - the value to convert + + storePtr + - the place to put the string + +RETURN : None +NOTES : +---------------------------------------------------------------------------*/ + void makeGridMarker( uint32 timestampVal, char *storePtr ); + +/*--------------------------------------------------------------------------- +FUNCTION : P A I N T G R I D M A R K E R +DESCRIPTION : given a position will put the string on the display + +ARGUMENTS : name : + yPos + - were it goes on the Y-axis + + gridMarkerPtr + - what it is + +RETURN : None +NOTES : +---------------------------------------------------------------------------*/ + void paintGridMarker( uint16 yPos, char *gridMarkerPtr ); + +#if defined _WINDOWS +/*--------------------------------------------------------------------------- +FUNCTION : PAINTHORIZONTALLINES +DESCRIPTION : responsible for painting the grids horizontal lines +ARGUMENTS : pRectToDraw pointer to rectangle that needs refreshing. + in viewport coords + pDC pointer to device context to use + +RETURN : None +NOTES : +---------------------------------------------------------------------------*/ + void paintHorizontalLines(RectCoords* pRectToDraw, CDC* pDC ); +#else +/*--------------------------------------------------------------------------- +FUNCTION : PAINTHORIZONTALLINES +DESCRIPTION : responsible for painting the grids horizontal lines +ARGUMENTS : name: xStart + - the starting X co-ordinate for the horizontal line + xEnd + - the ending X co-ordinate for the horizontal line + +RETURN : None +NOTES : Remember lines are drawn from origin. The origin in a + horizontal viewport will be the top. +---------------------------------------------------------------------------*/ + void paintHorizontalLines( uint16 xStart, uint16 xEnd ); +#endif + +#if defined _WINDOWS +/*--------------------------------------------------------------------------- +FUNCTION : PAINTVERTICALLINES +DESCRIPTION : responsible for painting the grids vertical lines +ARGUMENTS : pRectToDraw pointer to rectangle that needs refreshing. + in viewport coords + offset offset from rhs that rightmost line would be + drawn if rectangle included whole viewport + pDC pointer to device context to use +RETURN : None +NOTES : +---------------------------------------------------------------------------*/ + void paintVerticalLines( RectCoords* pRectToDraw, uint16 offset, + CDC* pDC ); +#else +/*--------------------------------------------------------------------------- +FUNCTION : PAINTVERTICALLINES +DESCRIPTION : responsible for painting the grids vertical lines +ARGUMENTS : name : yStart + - the starting Y co-ordinate for the vertical line + yEnd + - the ending Y co-ordinate for the vertical line + offset + - a starting point offset that determines at what X + position the first line will be drawn + + +RETURN : None +NOTES : +---------------------------------------------------------------------------*/ + void paintVerticalLines( uint16 yStart, uint16 yEnd, uint16 offset ); +#endif + +#if defined _WINDOWS +/*--------------------------------------------------------------------------- +FUNCTION : PAINTVERTICALLINE +DESCRIPTION : paints one line at the position specified, and length +ARGUMENTS : name : yStart + - the starting point on the y axis for the line + yEnd + - the end point on the y axis for the line + xPosition + - The horizontal offset from the start of the viewport + pDC pointer to device context to use + +RETURN : None +NOTES : There is not an equivalent horizontal method as yet. This + is a seperate method because the service is useful to a + derivation of this class +---------------------------------------------------------------------------*/ + void paintVerticalLine( uint16 yStart, uint16 yEnd + , uint16 xPosition, CDC *pDC ); +#else +/*--------------------------------------------------------------------------- +FUNCTION : PAINTVERTICALLINE +DESCRIPTION : paints one line at the position specified, and length +ARGUMENTS : name : yStart + - the starting point on the y axis for the line + yEnd + - the end point on the y axis for the line + xPosition + - The horizontal offset from the start of the viewport + +RETURN : None +NOTES : There is not an equivalent horizontal method as yet. This + is a seperate method because the service is useful to a + derivation of this class +---------------------------------------------------------------------------*/ + void paintVerticalLine( uint16 yStart, uint16 yEnd + , uint16 xPosition ); +#endif + +/*--------------------------------------------------------------------------- +INLINE FUNCTION : VERTICALSPACING +NOTES : Description at the end of the file +---------------------------------------------------------------------------*/ + uint16 verticalSpacing( void ); + + + // Position in viewport that we are now writing to if going forwards + // Note that if this is greater than viewport length then we have + // just scrolled and value must be adjusted before use. + sint16 forwardsOutputPosition; + + // Position in viewport that we are now writing to if going backwards + // Note that if this is less than zero then we have + // just scrolled and value must be adjusted before use. + sint16 backwardsOutputPosition; + + // position in grid cycle of forwards output position. + // if zero then it is time to output a grid line + sint16 forwardsIntervalCount; + + // position in grid cycle of forwards output position. + // if zero then it is time to output a grid line + sint16 backwardsIntervalCount; + + uint32 lastUpdateTimestamp; + uint32 timeBase; // ticks per pixel + uint16 currentOutputPosition; + uint16 gridTimestampSpacing; + uint16 intervalCount; + uint16 horizontalTotal; + uint16 vSpacing; +#if defined PRINTING_SUPPORT + uint16 numberOfGridMarkersPrinted; +#endif + bool firstTime; // indicates first time through + bool dateMarker; + + GkiLineType lineType; + GkiColour gridColour; + + #if defined _WINDOWS + uint16 ticksPerSec; // number of time ticks per second + uint16 vSpacingMin; // minimum pixels per division along time axis + CPen *pPen; // the pen to use for drawing in windows + #endif + +}; + + +/***************************************************************************** + I N L I N E F U N C T I O N S +*****************************************************************************/ + +/*--------------------------------------------------------------------------- +FUNCTION : HORIZONTALLINES +DESCRIPTION : supplies the number of horizontal lines in the grid +ARGUMENTS : name : + +RETURN : +NOTES : +---------------------------------------------------------------------------*/ +inline uint16 ScrollingGrid::horizontalLines( void ) +{ + return( horizontalTotal ); +} +/*--------------------------------------------------------------------------- +FUNCTION : VERTICALSPACING +DESCRIPTION : returns the distance between adjacent vertical lines +ARGUMENTS : name : + +RETURN : None +NOTES : +---------------------------------------------------------------------------*/ +inline uint16 ScrollingGrid::verticalSpacing( void ) +{ + return( vSpacing ); +} + +#endif +@ + + +1.1.2.1 +log +@DEV1194:DS4 Provision of major and minor grid lines +@ +text +@d1 1 +a1 1 +/* \$""Header: /usr/local/repository/cmnsrc/review/src/sgrid.h,v 1.1 1997/04/02 11:20:05 colinl Exp \$ */ +d3 1 +a3 12 + * \$""Log: sgrid.h,v \$ + * Revision 1.1 1997/04/02 11:20:05 colinl + * Project: DEV1175 + * DCN: + * Tested By: Colin Law + * Reviewed By: + * Reason for Change: Initial Revision of all files + * + * Design Change Details: + * + * Implications: + * +d58 6 +a63 5 +ARGUMENTS : name : majorColour colour for major grid lines + minorColour colour for minor grid lines + sgLineType line type for minor grid lines + yMajorGridLines number of major y lines on grid + yMinorGridLines number of major y lines on grid +d77 2 +a78 3 + ScrollingGrid( GkiColour majorColour, GkiColour minorColour, + GkiLineType sgLineType, + uint16 yMajorGridLines, uint16 yMinorGridLines, +a137 17 +FUNCTION : DrawHorizontalGridLines + +DESCRIPTION : Draws major or minor grid lines +ARGUMENTS : pDC device context + pPen pen to use + numLines total lines required + yLow, yHigh, xLow, xHigh rectangle to draw in + yMax max y value +RETURN : None +NOTES : +---------------------------------------------------------------------------*/ + void DrawHorizontalGridLines( CDC* pDC, CPen* pPen, + uint16 numLines, + uint16 yLow, uint16 yHigh, uint16 xLow, uint16 xHigh, + uint16 yMax ); + +/*--------------------------------------------------------------------------- +d148 6 +d448 1 +a448 2 + uint16 m_yMajorGridLines; + uint16 m_yMinorGridLines; +d456 2 +a457 3 + GkiLineType lineType; // line type for minor grid lines + GkiColour m_majorColour; + GkiColour m_minorColour; +d462 1 +a462 2 + CPen *pMajorPen; // pen to use for drawing major grid lines + CPen *pMinorPen; // pen to use for drawing minor grid lines +d472 12 +@" > diffmerge2/sgrid.h,v + + # We have to put the RCS file in the repository by hand for + # this test: + mkdir ${CVSROOT_DIRNAME}/diffmerge2 + cp diffmerge2/sgrid.h,v ${CVSROOT_DIRNAME}/diffmerge2/sgrid.h,v + rm -rf diffmerge2 + dotest diffmerge2_co \ + "${testcvs} co diffmerge2" "${DOTSTAR}U ${DOTSTAR}" + cd diffmerge2 + dotest diffmerge2_update \ + "${testcvs} update -j Review_Phase_2_Enhancements sgrid.h" \ + "${DOTSTAR}erging ${DOTSTAR}" + # This is the one that counts -- there should be no output: + dotest diffmerge2_diff \ + "${testcvs} diff -r Review_V1p3 sgrid.h" '' + ;; *) @@ -6891,7 +13327,6 @@ echo "OK, all tests completed." # * Test all flags in modules file. # Test that ciprog gets run both on checkin in that directory, or a # higher-level checkin which recurses into it. -# * More tests of keyword expansion. # * Test operations on a directory that contains other directories but has # no files of its own. # * -t global option @@ -6909,7 +13344,8 @@ echo "OK, all tests completed." # same). # * Test that remote edit and/or unedit works when disconnected from # server (e.g. set CVS_SERVER to "foobar"). -# * Test things to do with the CVS/* files, esp. CVS/Root.... +# * Test the contents of adm files other than Root and Repository. +# Entries seems the next most important thing. # End of TODO list. # Remove the test directory, but first change out of it. diff --git a/contrib/cvs/src/scramble.c b/contrib/cvs/src/scramble.c index 07094a6..77376fa 100644 --- a/contrib/cvs/src/scramble.c +++ b/contrib/cvs/src/scramble.c @@ -50,23 +50,23 @@ */ static unsigned char -shifts[] = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, -17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 114, 120, -53, 79, 96, 109, 72, 108, 70, 64, 76, 67, 116, 74, 68, 87, 111, 52, -75, 119, 49, 34, 82, 81, 95, 65, 112, 86, 118, 110, 122, 105, 41, 57, -83, 43, 46, 102, 40, 89, 38, 103, 45, 50, 42, 123, 91, 35, 125, 55, -54, 66, 124, 126, 59, 47, 92, 71, 115, 78, 88, 107, 106, 56, 36, 121, -117, 104, 101, 100, 69, 73, 99, 63, 94, 93, 39, 37, 61, 48, 58, 113, -32, 90, 44, 98, 60, 51, 33, 97, 62, 77, 84, 80, 85, 223, 225, 216, -187, 166, 229, 189, 222, 188, 141, 249, 148, 200, 184, 136, 248, 190, -199, 170, 181, 204, 138, 232, 218, 183, 255, 234, 220, 247, 213, 203, -226, 193, 174, 172, 228, 252, 217, 201, 131, 230, 197, 211, 145, 238, -161, 179, 160, 212, 207, 221, 254, 173, 202, 146, 224, 151, 140, 196, -205, 130, 135, 133, 143, 246, 192, 159, 244, 239, 185, 168, 215, 144, -139, 165, 180, 157, 147, 186, 214, 176, 227, 231, 219, 169, 175, 156, -206, 198, 129, 164, 150, 210, 154, 177, 134, 127, 182, 128, 158, 208, -162, 132, 167, 209, 149, 241, 153, 251, 237, 236, 171, 195, 243, 233, -253, 240, 194, 250, 191, 155, 142, 137, 245, 235, 163, 242, 178, 152 }; +shifts[] = { + 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, + 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, + 114,120, 53, 79, 96,109, 72,108, 70, 64, 76, 67,116, 74, 68, 87, + 111, 52, 75,119, 49, 34, 82, 81, 95, 65,112, 86,118,110,122,105, + 41, 57, 83, 43, 46,102, 40, 89, 38,103, 45, 50, 42,123, 91, 35, + 125, 55, 54, 66,124,126, 59, 47, 92, 71,115, 78, 88,107,106, 56, + 36,121,117,104,101,100, 69, 73, 99, 63, 94, 93, 39, 37, 61, 48, + 58,113, 32, 90, 44, 98, 60, 51, 33, 97, 62, 77, 84, 80, 85,223, + 225,216,187,166,229,189,222,188,141,249,148,200,184,136,248,190, + 199,170,181,204,138,232,218,183,255,234,220,247,213,203,226,193, + 174,172,228,252,217,201,131,230,197,211,145,238,161,179,160,212, + 207,221,254,173,202,146,224,151,140,196,205,130,135,133,143,246, + 192,159,244,239,185,168,215,144,139,165,180,157,147,186,214,176, + 227,231,219,169,175,156,206,198,129,164,150,210,154,177,134,127, + 182,128,158,208,162,132,167,209,149,241,153,251,237,236,171,195, + 243,233,253,240,194,250,191,155,142,137,245,235,163,242,178,152 }; /* SCRAMBLE and DESCRAMBLE work like this: @@ -85,57 +85,56 @@ shifts[] = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, /* Return a malloc'd, scrambled version of STR. */ char * scramble (str) - char *str; + char *str; { - int i; - char *s; + int i; + char *s; - /* +2 to hold the 'A' prefix that indicates which version of - * scrambling this is (the first, obviously, since we only do one - * kind of scrambling so far), and then the '\0' of course. - */ - s = (char *) xmalloc (strlen (str) + 2); + /* +2 to hold the 'A' prefix that indicates which version of + scrambling this is (the first, obviously, since we only do one + kind of scrambling so far), and then the '\0' of course. */ + s = (char *) xmalloc (strlen (str) + 2); - s[0] = 'A'; /* Scramble (TM) version prefix. */ - strcpy (s + 1, str); + /* Scramble (TM) version prefix. */ + s[0] = 'A'; + strcpy (s + 1, str); - for (i = 1; s[i]; i++) - s[i] = shifts[(unsigned char)(s[i])]; + for (i = 1; s[i]; i++) + s[i] = shifts[(unsigned char)(s[i])]; - return s; + return s; } /* Decode the string in place. */ char * descramble (str) - char *str; + char *str; { - char *s; - int i; + char *s; + int i; - /* For now we can only handle one kind of scrambling. In the future - * there may be other kinds, and this `if' will become a `switch'. - */ - if (str[0] != 'A') + /* For now we can only handle one kind of scrambling. In the future + there may be other kinds, and this `if' will become a `switch'. */ + if (str[0] != 'A') #ifndef DIAGNOSTIC - error (1, 0, "descramble: unknown scrambling method"); + error (1, 0, "descramble: unknown scrambling method"); #else /* DIAGNOSTIC */ - { - fprintf (stderr, "descramble: unknown scrambling method\n", str); - fflush (stderr); - exit (EXIT_FAILURE); - } + { + fprintf (stderr, "descramble: unknown scrambling method\n", str); + fflush (stderr); + exit (EXIT_FAILURE); + } #endif /* DIAGNOSTIC */ - /* Method `A' is symmetrical, so scramble again to decrypt. */ - s = scramble (str + 1); + /* Method `A' is symmetrical, so scramble again to decrypt. */ + s = scramble (str + 1); - /* Shift the whole string one char to the left, pushing the unwanted - 'A' off the left end. Safe, because s is null-terminated. */ - for (i = 0; s[i]; i++) - s[i] = s[i + 1]; + /* Shift the whole string one char to the left, pushing the unwanted + 'A' off the left end. Safe, because s is null-terminated. */ + for (i = 0; s[i]; i++) + s[i] = s[i + 1]; - return s; + return s; } #endif /* (AUTH_CLIENT_SUPPORT || AUTH_SERVER_SUPPORT) from top of file */ @@ -144,38 +143,38 @@ descramble (str) int main () { - int i; - char *e, *m, biggie[256]; - - char *cleartexts[5]; - cleartexts[0] = "first"; - cleartexts[1] = "the second"; - cleartexts[2] = "this is the third"; - cleartexts[3] = "$#% !!\\3"; - cleartexts[4] = biggie; - - /* Set up the most important test string: */ - /* Can't have a real ASCII zero in the string, because we want to - use printf, so we substitute the character zero. */ - biggie[0] = '0'; - /* The rest of the string gets straight ascending ASCII. */ - for (i = 1; i < 256; i++) - biggie[i] = i; - - /* Test all the strings. */ - for (i = 0; i < 5; i++) + int i; + char *e, *m, biggie[256]; + + char *cleartexts[5]; + cleartexts[0] = "first"; + cleartexts[1] = "the second"; + cleartexts[2] = "this is the third"; + cleartexts[3] = "$#% !!\\3"; + cleartexts[4] = biggie; + + /* Set up the most important test string: */ + /* Can't have a real ASCII zero in the string, because we want to + use printf, so we substitute the character zero. */ + biggie[0] = '0'; + /* The rest of the string gets straight ascending ASCII. */ + for (i = 1; i < 256; i++) + biggie[i] = i; + + /* Test all the strings. */ + for (i = 0; i < 5; i++) { - printf ("clear%d: %s\n", i, cleartexts[i]); - e = scramble (cleartexts[i]); - printf ("scram%d: %s\n", i, e); - m = descramble (e); - free (e); - printf ("clear%d: %s\n\n", i, m); - free (m); + printf ("clear%d: %s\n", i, cleartexts[i]); + e = scramble (cleartexts[i]); + printf ("scram%d: %s\n", i, e); + m = descramble (e); + free (e); + printf ("clear%d: %s\n\n", i, m); + free (m); } - fflush (stdout); - return 0; + fflush (stdout); + return 0; } #endif /* DIAGNOSTIC */ diff --git a/contrib/cvs/src/server.c b/contrib/cvs/src/server.c index dece2ca..8d7d119 100644 --- a/contrib/cvs/src/server.c +++ b/contrib/cvs/src/server.c @@ -22,16 +22,16 @@ #include <winsock.h> #endif -#if defined (AUTH_SERVER_SUPPORT) || defined (HAVE_KERBEROS) +#if defined (AUTH_SERVER_SUPPORT) || defined (HAVE_KERBEROS) || defined (HAVE_GSSAPI) #include <sys/socket.h> #endif #ifdef HAVE_KERBEROS -#include <netinet/in.h> -#include <krb.h> -#ifndef HAVE_KRB_GET_ERR_TEXT -#define krb_get_err_text(status) krb_err_txt[status] -#endif +# include <netinet/in.h> +# include <krb.h> +# ifndef HAVE_KRB_GET_ERR_TEXT +# define krb_get_err_text(status) krb_err_txt[status] +# endif /* Information we need if we are going to use Kerberos encryption. */ static C_Block kblock; @@ -39,6 +39,34 @@ static Key_schedule sched; #endif +#ifdef HAVE_GSSAPI + +#include <netdb.h> +#include <gssapi/gssapi.h> +#include <gssapi/gssapi_generic.h> + +/* We use Kerberos 5 routines to map the GSSAPI credential to a user + name. */ +#include <krb5.h> + +/* We need this to wrap data. */ +static gss_ctx_id_t gcontext; + +static void gserver_authenticate_connection PROTO((void)); + +/* Whether we are already wrapping GSSAPI communication. */ +static int cvs_gssapi_wrapping; + +# ifdef ENCRYPTION +/* Whether to encrypt GSSAPI communication. We use a global variable + like this because we use the same buffer type (gssapi_wrap) to + handle both authentication and encryption, and we don't want + multiple instances of that buffer in the communication stream. */ +int cvs_gssapi_encrypt; +# endif + +#endif + /* for select */ #include <sys/types.h> #ifdef HAVE_SYS_BSDTYPES_H @@ -76,12 +104,12 @@ static Key_schedule sched; #ifdef HAVE_GETSPNAM #include <shadow.h> #endif +#endif /* AUTH_SERVER_SUPPORT */ + /* For initgroups(). */ #if HAVE_INITGROUPS #include <grp.h> #endif /* HAVE_INITGROUPS */ -#endif /* AUTH_SERVER_SUPPORT */ - #ifdef AUTH_SERVER_SUPPORT @@ -95,6 +123,10 @@ char *CVS_Username = NULL; later CVS protocol. Exported because root.c also uses. */ char *Pserver_Repos = NULL; +/* Should we check for system usernames/passwords? Can be changed by + CVSROOT/config. */ +int system_auth = 1; + #endif /* AUTH_SERVER_SUPPORT */ @@ -329,7 +361,7 @@ mkdir_p (dir) { strncpy (q, dir, p - dir); q[p - dir] = '\0'; - if (CVS_MKDIR (q, 0777) < 0) + if (q[p - dir - 1] != '/' && CVS_MKDIR (q, 0777) < 0) { int saved_errno = errno; @@ -437,6 +469,8 @@ alloc_pending (size) return 1; } +static void serve_is_modified PROTO ((char *)); + static int supported_response PROTO ((char *)); static int @@ -526,8 +560,30 @@ serve_root (arg) "E Root %s must be an absolute pathname", arg); return; } + + /* Sending "Root" twice is illegal. It would also be nice to + check for the other case, in which there is no Root request + prior to a request which requires one. + + The other way to handle a duplicate Root requests would be as a + request to clear out all state and start over as if it was a + new connection. Doing this would cause interoperability + headaches, so it should be a different request, if there is + any reason why such a feature is needed. */ + if (CVSroot_directory != NULL) + { + if (alloc_pending (80 + strlen (arg))) + sprintf (pending_error_text, + "E Protocol error: Duplicate Root request, for %s", arg); + return; + } + set_local_cvsroot (arg); + /* For pserver, this will already have happened, and the call will do + nothing. But for rsh, we need to do it now. */ + parse_config (CVSroot_directory); + path = xmalloc (strlen (CVSroot_directory) + sizeof (CVSROOTADM) + sizeof (CVSROOTADM_HISTORY) @@ -629,6 +685,7 @@ dirswitch (dir, repos) int status; FILE *f; char *b; + size_t dir_len; server_write_entries (); @@ -637,20 +694,22 @@ dirswitch (dir, repos) if (dir_name != NULL) free (dir_name); + dir_len = strlen (dir); + /* Check for a trailing '/'. This is not ISDIRSEP because \ in the protocol is an ordinary character, not a directory separator (of course, it is perhaps unwise to use it in directory names, but that is another issue). */ - if (strlen (dir) > 0 - && dir[strlen (dir) - 1] == '/') + if (dir_len > 0 + && dir[dir_len - 1] == '/') { - if (alloc_pending (80 + strlen (dir))) + if (alloc_pending (80 + dir_len)) sprintf (pending_error_text, - "E protocol error: illegal directory syntax in %s", dir); + "E protocol error: invalid directory syntax in %s", dir); return; } - dir_name = malloc (strlen (server_temp_dir) + strlen (dir) + 40); + dir_name = malloc (strlen (server_temp_dir) + dir_len + 40); if (dir_name == NULL) { pending_error = ENOMEM; @@ -671,6 +730,12 @@ dirswitch (dir, repos) return; } + /* Note that this call to Subdir_Register will be a noop if the parent + directory does not yet exist (for example, if the client sends + "Directory foo" followed by "Directory .", then the subdirectory does + not get registered, but if the client sends "Directory ." followed + by "Directory foo", then the subdirectory does get registered. + This seems pretty fishy, but maybe it is the way it needs to work. */ b = strrchr (dir_name, '/'); *b = '\0'; Subdir_Register ((List *) NULL, dir_name, b + 1); @@ -774,6 +839,24 @@ serve_directory (arg) status = buf_read_line (buf_from_net, &repos, (int *) NULL); if (status == 0) { + /* I think isabsolute (repos) should always be true, and that + any RELATIVE_REPOS stuff should only be in CVS/Repository + files, not the protocol (for compatibility), but I'm putting + in the in isabsolute check just in case. */ + if (isabsolute (repos) + && strncmp (CVSroot_directory, + repos, + strlen (CVSroot_directory)) != 0) + { + if (alloc_pending (strlen (CVSroot_directory) + + strlen (repos) + + 80)) + sprintf (pending_error_text, "\ +E protocol error: directory '%s' not within root '%s'", + repos, CVSroot_directory); + return; + } + dirswitch (arg, repos); free (repos); } @@ -1004,6 +1087,11 @@ receive_file (size, file, gzipped) } } +/* Kopt for the next file sent in Modified or Is-modified. */ +static char *kopt; + +static void serve_modified PROTO ((char *)); + static void serve_modified (arg) char *arg; @@ -1118,6 +1206,13 @@ serve_modified (arg) return; } } + + /* Make sure that the Entries indicate the right kopt. We probably + could do this even in the non-kopt case and, I think, save a stat() + call in time_stamp_server. But for conservatism I'm leaving the + non-kopt case alone. */ + if (kopt != NULL) + serve_is_modified (arg); } @@ -1174,8 +1269,6 @@ serve_unchanged (arg) } } -static void serve_is_modified PROTO ((char *)); - static void serve_is_modified (arg) char *arg; @@ -1212,6 +1305,16 @@ serve_is_modified (arg) } *timefield = 'M'; } + if (kopt != NULL) + { + if (alloc_pending (strlen (name) + 80)) + sprintf (pending_error_text, + "E protocol error: both Kopt and Entry for %s", + arg); + free (kopt); + kopt = NULL; + return; + } found = 1; break; } @@ -1220,22 +1323,36 @@ serve_is_modified (arg) { /* We got Is-modified but no Entry. Add a dummy entry. The "D" timestamp is what makes it a dummy. */ - struct an_entry *p; p = (struct an_entry *) malloc (sizeof (struct an_entry)); if (p == NULL) { pending_error = ENOMEM; return; } - p->entry = xmalloc (strlen (arg) + 80); + p->entry = malloc (strlen (arg) + 80); + if (p->entry == NULL) + { + pending_error = ENOMEM; + free (p); + return; + } strcpy (p->entry, "/"); strcat (p->entry, arg); - strcat (p->entry, "//D//"); + strcat (p->entry, "//D/"); + if (kopt != NULL) + { + strcat (p->entry, kopt); + free (kopt); + kopt = NULL; + } + strcat (p->entry, "/"); p->next = entries; entries = p; } } +static void serve_entry PROTO ((char *)); + static void serve_entry (arg) char *arg; @@ -1262,6 +1379,45 @@ serve_entry (arg) entries = p; } +static void serve_kopt PROTO ((char *)); + +static void +serve_kopt (arg) + char *arg; +{ + if (error_pending ()) + return; + + if (kopt != NULL) + { + if (alloc_pending (80 + strlen (arg))) + sprintf (pending_error_text, + "E protocol error: duplicate Kopt request: %s", arg); + return; + } + + /* Do some sanity checks. In particular, that it is not too long. + This lets the rest of the code not worry so much about buffer + overrun attacks. Probably should call RCS_check_kflag here, + but that would mean changing RCS_check_kflag to handle errors + other than via exit(), fprintf(), and such. */ + if (strlen (arg) > 10) + { + if (alloc_pending (80 + strlen (arg))) + sprintf (pending_error_text, + "E protocol error: invalid Kopt request: %s", arg); + return; + } + + kopt = malloc (strlen (arg) + 1); + if (kopt == NULL) + { + pending_error = ENOMEM; + return; + } + strcpy (kopt, arg); +} + static void server_write_entries () { @@ -1609,6 +1765,7 @@ serve_set (arg) } #ifdef ENCRYPTION + #ifdef HAVE_KERBEROS static void @@ -1626,7 +1783,68 @@ serve_kerberos_encrypt (arg) } #endif /* HAVE_KERBEROS */ + +#ifdef HAVE_GSSAPI + +static void +serve_gssapi_encrypt (arg) + char *arg; +{ + if (cvs_gssapi_wrapping) + { + /* We're already using a gssapi_wrap buffer for stream + authentication. Flush everything we've output so far, and + turn on encryption for future data. On the input side, we + should only have unwrapped as far as the Gssapi-encrypt + command, so future unwrapping will become encrypted. */ + buf_flush (buf_to_net, 1); + cvs_gssapi_encrypt = 1; + return; + } + + /* All future communication with the client will be encrypted. */ + + cvs_gssapi_encrypt = 1; + + buf_to_net = cvs_gssapi_wrap_buffer_initialize (buf_to_net, 0, + gcontext, + buf_to_net->memory_error); + buf_from_net = cvs_gssapi_wrap_buffer_initialize (buf_from_net, 1, + gcontext, + buf_from_net->memory_error); + + cvs_gssapi_wrapping = 1; +} + +#endif /* HAVE_GSSAPI */ + #endif /* ENCRYPTION */ + +#ifdef HAVE_GSSAPI + +static void +serve_gssapi_authenticate (arg) + char *arg; +{ + if (cvs_gssapi_wrapping) + { + /* We're already using a gssapi_wrap buffer for encryption. + That includes authentication, so we don't have to do + anything further. */ + return; + } + + buf_to_net = cvs_gssapi_wrap_buffer_initialize (buf_to_net, 0, + gcontext, + buf_to_net->memory_error); + buf_from_net = cvs_gssapi_wrap_buffer_initialize (buf_from_net, 1, + gcontext, + buf_from_net->memory_error); + + cvs_gssapi_wrapping = 1; +} + +#endif /* HAVE_GSSAPI */ #ifdef SERVER_FLOWCONTROL /* The maximum we'll queue to the remote client before blocking. */ @@ -1814,10 +2032,18 @@ check_command_legal_p (cmd_name) CVSROOTADM, CVSROOTADM_READERS); fp = fopen (fname, "r"); - free (fname); if (fp == NULL) - goto do_writers; + { + if (!existence_error (errno)) + { + /* Need to deny access, so that attackers can't fool + us with some sort of denial of service attack. */ + error (0, errno, "cannot open %s", fname); + free (fname); + return 0; + } + } else /* successfully opened readers file */ { while ((num_red = getline (&linebuf, &linebuf_len, fp)) >= 0) @@ -1835,16 +2061,19 @@ check_command_legal_p (cmd_name) if (strcmp (linebuf, CVS_Username) == 0) goto handle_illegal; } + if (num_red < 0 && !feof (fp)) + error (0, errno, "cannot read %s", fname); /* If not listed specifically as a reader, then this user has write access by default unless writers are also specified in a file . */ - fclose (fp); - goto do_writers; + if (fclose (fp) < 0) + error (0, errno, "cannot close %s", fname); } + free (fname); + + /* Now check the writers file. */ - do_writers: - flen = strlen (CVSroot_directory) + strlen (CVSROOTADM) + strlen (CVSROOTADM_WRITERS) @@ -1855,19 +2084,28 @@ check_command_legal_p (cmd_name) CVSROOTADM, CVSROOTADM_WRITERS); fp = fopen (fname, "r"); - free (fname); if (fp == NULL) { - /* writers file does not exist, so everyone is a writer, - by default */ if (linebuf) free (linebuf); - return 1; + if (existence_error (errno)) + { + /* Writers file does not exist, so everyone is a writer, + by default. */ + free (fname); + return 1; + } + else + { + /* Need to deny access, so that attackers can't fool + us with some sort of denial of service attack. */ + error (0, errno, "cannot read %s", fname); + free (fname); + return 0; + } } - /* else */ - found_it = 0; while ((num_red = getline (&linebuf, &linebuf_len, fp)) >= 0) { @@ -1881,20 +2119,26 @@ check_command_legal_p (cmd_name) break; } } + if (num_red < 0 && !feof (fp)) + error (0, errno, "cannot read %s", fname); if (found_it) { - fclose (fp); + if (fclose (fp) < 0) + error (0, errno, "cannot close %s", fname); if (linebuf) free (linebuf); + free (fname); return 1; } else /* writers file exists, but this user not listed in it */ { handle_illegal: - fclose (fp); + if (fclose (fp) < 0) + error (0, errno, "cannot close %s", fname); if (linebuf) free (linebuf); + free (fname); return 0; } } @@ -2813,7 +3057,7 @@ static void serve_log (arg) char *arg; { - do_cvs_command ("cvslog", cvslog); + do_cvs_command ("log", cvslog); } static void @@ -3085,6 +3329,8 @@ server_modtime (finfo, vers_ts) {"Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec"}; + assert (vers_ts->vn_rcs != NULL); + if (!supported_response ("Mod-time")) return; @@ -3117,7 +3363,18 @@ server_updated (finfo, vers, updated, file_info, checksum) unsigned char *checksum; { if (noexec) + { + /* Hmm, maybe if we did the same thing for entries_file, we + could get rid of the kludges in server_register and + server_scratch which refrain from warning if both + Scratch_Entry and Register get called. Maybe. */ + if (scratched_file) + { + free (scratched_file); + scratched_file = NULL; + } return; + } if (entries_line != NULL && scratched_file == NULL) { @@ -3559,6 +3816,11 @@ expand_proc (pargc, argv, where, mwhere, mfile, shorten, if (mwhere != NULL) { buf_output0 (buf_to_net, "Module-expansion "); + if (server_dir != NULL) + { + buf_output0 (buf_to_net, server_dir); + buf_output0 (buf_to_net, "/"); + } buf_output0 (buf_to_net, mwhere); if (mfile != NULL) { @@ -3574,6 +3836,11 @@ expand_proc (pargc, argv, where, mwhere, mfile, shorten, if (*pargc == 1) { buf_output0 (buf_to_net, "Module-expansion "); + if (server_dir != NULL) + { + buf_output0 (buf_to_net, server_dir); + buf_output0 (buf_to_net, "/"); + } buf_output0 (buf_to_net, dir); buf_append_char (buf_to_net, '\n'); } @@ -3582,6 +3849,11 @@ expand_proc (pargc, argv, where, mwhere, mfile, shorten, for (i = 1; i < *pargc; ++i) { buf_output0 (buf_to_net, "Module-expansion "); + if (server_dir != NULL) + { + buf_output0 (buf_to_net, server_dir); + buf_output0 (buf_to_net, "/"); + } buf_output0 (buf_to_net, dir); buf_append_char (buf_to_net, '/'); buf_output0 (buf_to_net, argv[i]); @@ -3760,6 +4032,7 @@ struct request requests[] = REQ_LINE("Checkin-prog", serve_checkin_prog, rq_optional), REQ_LINE("Update-prog", serve_update_prog, rq_optional), REQ_LINE("Entry", serve_entry, rq_essential), + REQ_LINE("Kopt", serve_kopt, rq_optional), REQ_LINE("Modified", serve_modified, rq_essential), REQ_LINE("Is-modified", serve_is_modified, rq_optional), @@ -3778,9 +4051,15 @@ struct request requests[] = REQ_LINE("Gzip-stream", serve_gzip_stream, rq_optional), REQ_LINE("Set", serve_set, rq_optional), #ifdef ENCRYPTION -#ifdef HAVE_KERBEROS +# ifdef HAVE_KERBEROS REQ_LINE("Kerberos-encrypt", serve_kerberos_encrypt, rq_optional), +# endif +# ifdef HAVE_GSSAPI + REQ_LINE("Gssapi-encrypt", serve_gssapi_encrypt, rq_optional), +# endif #endif +#ifdef HAVE_GSSAPI + REQ_LINE("Gssapi-authenticate", serve_gssapi_authenticate, rq_optional), #endif REQ_LINE("expand-modules", serve_expand_modules, rq_optional), REQ_LINE("ci", serve_ci, rq_essential), @@ -4024,50 +4303,6 @@ server (argc, argv) protocol to report error messages. */ error_use_protocol = 1; - /* - * Put Rcsbin at the start of PATH, so that rcs programs can find - * themselves. - */ -#ifdef HAVE_PUTENV - if (Rcsbin != NULL && *Rcsbin) - { - char *p; - char *env; - - p = getenv ("PATH"); - if (p != NULL) - { - env = malloc (strlen (Rcsbin) + strlen (p) + sizeof "PATH=:"); - if (env != NULL) - sprintf (env, "PATH=%s:%s", Rcsbin, p); - } - else - { - env = malloc (strlen (Rcsbin) + sizeof "PATH="); - if (env != NULL) - sprintf (env, "PATH=%s", Rcsbin); - } - if (env == NULL) - { - printf ("E Fatal server error, aborting.\n\ -error ENOMEM Virtual memory exhausted.\n"); - - /* I'm doing this manually rather than via error_exit () - because I'm not sure whether we want to call server_cleanup. - Needs more investigation.... */ - -#ifdef SYSTEM_CLEANUP - /* Hook for OS-specific behavior, for example socket subsystems on - NT and OS2 or dealing with windows and arguments on Mac. */ - SYSTEM_CLEANUP (); -#endif - - exit (EXIT_FAILURE); - } - putenv (env); - } -#endif - /* OK, now figure out where we stash our temporary files. */ { char *p; @@ -4220,8 +4455,6 @@ error ENOMEM Virtual memory exhausted.\n"); by this server" or something like that instead of usage message. */ argument_vector[0] = "cvs server"; - server_active = 1; - while (1) { char *cmd, *orig_cmd; @@ -4274,7 +4507,7 @@ error ENOMEM Virtual memory exhausted.\n"); } -#if defined (HAVE_KERBEROS) || defined (AUTH_SERVER_SUPPORT) +#if defined (HAVE_KERBEROS) || defined (AUTH_SERVER_SUPPORT) || defined (HAVE_GSSAPI) static void switch_to_user PROTO((const char *)); static void @@ -4301,6 +4534,15 @@ error 0 %s: no such user\n", username); exit (EXIT_FAILURE); } + /* FIXME? We don't check for errors from initgroups, setuid, &c. + I think this mainly would come up if someone is trying to run + the server as a non-root user. I think we should be checking for + errors and aborting (as with the error above from getpwnam) if + there is an error (presumably EPERM). That means that pserver + should continue to work right if all of the "system usernames" + in CVSROOT/passwd match the user which the server is being run + as (in inetd.conf), but fail otherwise. */ + #if HAVE_INITGROUPS initgroups (pw->pw_name, pw->pw_gid); #endif /* HAVE_INITGROUPS */ @@ -4471,7 +4713,7 @@ check_password (username, password, repository) /* host_user already set by reference, so just return. */ goto handle_return; } - else if (rc == 0) + else if (rc == 0 && system_auth) { /* No cvs password found, so try /etc/passwd. */ @@ -4530,6 +4772,27 @@ error 0 %s: no such user\n", username); goto handle_return; } } + else if (rc == 0) + { + /* Note that the message _does_ distinguish between the case in + which we check for a system password and the case in which + we do not. It is a real pain to track down why it isn't + letting you in if it won't say why, and I am not convinced + that the potential information disclosure to an attacker + outweighs this. */ + printf ("error 0 no such user %s in CVSROOT/passwd\n", username); + + /* I'm doing this manually rather than via error_exit () + because I'm not sure whether we want to call server_cleanup. + Needs more investigation.... */ + +#ifdef SYSTEM_CLEANUP + /* Hook for OS-specific behavior, for example socket subsystems on + NT and OS2 or dealing with windows and arguments on Mac. */ + SYSTEM_CLEANUP (); +#endif + exit (EXIT_FAILURE); + } else { /* Something strange happened. We don't know what it was, but @@ -4550,6 +4813,10 @@ handle_return: return host_user; } +#endif /* AUTH_SERVER_SUPPORT */ + +#if defined (AUTH_SERVER_SUPPORT) || defined (HAVE_GSSAPI) + /* Read username and password from client (i.e., stdin). If correct, then switch to run as that user and send an ACK to the client via stdout, else send NACK and die. */ @@ -4558,6 +4825,7 @@ pserver_authenticate_connection () { char *tmp = NULL; size_t tmp_allocated = 0; +#ifdef AUTH_SERVER_SUPPORT char *repository = NULL; size_t repository_allocated = 0; char *username = NULL; @@ -4567,6 +4835,7 @@ pserver_authenticate_connection () char *host_user; char *descrambled_password; +#endif /* AUTH_SERVER_SUPPORT */ int verify_and_exit = 0; /* The Authentication Protocol. Client sends: @@ -4631,9 +4900,27 @@ pserver_authenticate_connection () if (strcmp (tmp, "BEGIN VERIFICATION REQUEST\n") == 0) verify_and_exit = 1; - else if (strcmp (tmp, "BEGIN AUTH REQUEST\n") != 0) + else if (strcmp (tmp, "BEGIN AUTH REQUEST\n") == 0) + ; + else if (strcmp (tmp, "BEGIN GSSAPI REQUEST\n") == 0) + { +#ifdef HAVE_GSSAPI + free (tmp); + gserver_authenticate_connection (); + return; +#else + error (1, 0, "GSSAPI authentication not supported by this server"); +#endif + } + else error (1, 0, "bad auth protocol start: %s", tmp); +#ifndef AUTH_SERVER_SUPPORT + + error (1, 0, "Password authentication not supported by this server"); + +#else /* AUTH_SERVER_SUPPORT */ + /* Get the three important pieces of information in order. */ /* See above comment about error handling. */ getline (&repository, &repository_allocated, stdin); @@ -4656,14 +4943,21 @@ pserver_authenticate_connection () error (1, 0, "bad auth protocol end: %s", tmp); } if (!root_allow_ok (repository)) - /* At least for the moment I'm going to do the paranoid - security thing and not tell them how it failed. I'm not - sure that is a good idea; it is a real pain when one needs - to track down what is going on for legitimate reasons. - The other issue is that the protocol doesn't really have - a good way for anything other than I HATE YOU. */ + /* Just give a generic I HATE YOU. This is because CVS 1.9.10 + and older clients do not support "error". Once more recent + clients are more widespread, probably want to fix this (it is + a real pain to track down why it isn't letting you in if it + won't say why, and I am not convinced that the potential + information disclosure to an attacker outweighs this). */ goto i_hate_you; + /* OK, now parse the config file, so we can use it to control how + to check passwords. If there was an error parsing the config + file, parse_config already printed an error. We keep going. + Why? Because if we didn't, then there would be no way to check + in a new CVSROOT/config file to fix the broken one! */ + parse_config (repository); + /* We need the real cleartext before we hash it. */ descrambled_password = descramble (password); host_user = check_password (username, descrambled_password, repository); @@ -4715,9 +5009,11 @@ pserver_authenticate_connection () free (repository); free (username); free (password); -} #endif /* AUTH_SERVER_SUPPORT */ +} + +#endif /* AUTH_SERVER_SUPPORT || HAVE_GSSAPI */ #ifdef HAVE_KERBEROS @@ -4797,6 +5093,122 @@ error 0 kerberos: can't get local name: %s\n", krb_get_err_text(status)); } #endif /* HAVE_KERBEROS */ +#ifdef HAVE_GSSAPI + +#ifndef MAXHOSTNAMELEN +#define MAXHOSTNAMELEN (256) +#endif + +/* Authenticate a GSSAPI connection. This is called from + pserver_authenticate_connection, and it handles success and failure + the same way. */ + +static void +gserver_authenticate_connection () +{ + char hostname[MAXHOSTNAMELEN]; + struct hostent *hp; + gss_buffer_desc tok_in, tok_out; + char buf[1024]; + OM_uint32 stat_min, ret; + gss_name_t server_name, client_name; + gss_cred_id_t server_creds; + int nbytes; + gss_OID mechid; + + gethostname (hostname, sizeof hostname); + hp = gethostbyname (hostname); + if (hp == NULL) + error (1, 0, "can't get canonical hostname"); + + sprintf (buf, "cvs@%s", hp->h_name); + tok_in.value = buf; + tok_in.length = strlen (buf); + + if (gss_import_name (&stat_min, &tok_in, gss_nt_service_name, + &server_name) != GSS_S_COMPLETE) + error (1, 0, "could not import GSSAPI service name %s", buf); + + /* Acquire the server credential to verify the client's + authentication. */ + if (gss_acquire_cred (&stat_min, server_name, 0, GSS_C_NULL_OID_SET, + GSS_C_ACCEPT, &server_creds, + NULL, NULL) != GSS_S_COMPLETE) + error (1, 0, "could not acquire GSSAPI server credentials"); + + gss_release_name (&stat_min, &server_name); + + /* The client will send us a two byte length followed by that many + bytes. */ + if (fread (buf, 1, 2, stdin) != 2) + error (1, errno, "read of length failed"); + + nbytes = ((buf[0] & 0xff) << 8) | (buf[1] & 0xff); + assert (nbytes <= sizeof buf); + + if (fread (buf, 1, nbytes, stdin) != nbytes) + error (1, errno, "read of data failed"); + + gcontext = GSS_C_NO_CONTEXT; + tok_in.length = nbytes; + tok_in.value = buf; + + if (gss_accept_sec_context (&stat_min, + &gcontext, /* context_handle */ + server_creds, /* verifier_cred_handle */ + &tok_in, /* input_token */ + NULL, /* channel bindings */ + &client_name, /* src_name */ + &mechid, /* mech_type */ + &tok_out, /* output_token */ + &ret, + NULL, /* ignore time_rec */ + NULL) /* ignore del_cred_handle */ + != GSS_S_COMPLETE) + { + error (1, 0, "could not verify credentials"); + } + + /* FIXME: Use Kerberos v5 specific code to authenticate to a user. + We could instead use an authentication to access mapping. */ + { + krb5_context kc; + krb5_principal p; + gss_buffer_desc desc; + + krb5_init_context (&kc); + if (gss_display_name (&stat_min, client_name, &desc, + &mechid) != GSS_S_COMPLETE + || krb5_parse_name (kc, ((gss_buffer_t) &desc)->value, &p) != 0 + || krb5_aname_to_localname (kc, p, sizeof buf, buf) != 0 + || krb5_kuserok (kc, p, buf) != TRUE) + { + error (1, 0, "access denied"); + } + krb5_free_principal (kc, p); + krb5_free_context (kc); + } + + if (tok_out.length != 0) + { + char cbuf[2]; + + cbuf[0] = (tok_out.length >> 8) & 0xff; + cbuf[1] = tok_out.length & 0xff; + if (fwrite (cbuf, 1, 2, stdout) != 2 + || (fwrite (tok_out.value, 1, tok_out.length, stdout) + != tok_out.length)) + error (1, errno, "fwrite failed"); + } + + switch_to_user (buf); + + printf ("I LOVE YOU\n"); + fflush (stdout); +} + +#endif /* HAVE_GSSAPI */ + #endif /* SERVER_SUPPORT */ #if defined (CLIENT_SUPPORT) || defined (SERVER_SUPPORT) @@ -4805,320 +5217,232 @@ error 0 kerberos: can't get local name: %s\n", krb_get_err_text(status)); the command line. */ int cvsencrypt; -#ifdef ENCRYPTION +/* This global variable is non-zero if the users requests stream + authentication on the command line. */ +int cvsauthenticate; -#ifdef HAVE_KERBEROS +#ifdef HAVE_GSSAPI -/* An encryption interface using Kerberos. This is built on top of - the buffer structure. We encrypt using a big endian two byte count - field followed by a block of encrypted data. */ +/* An buffer interface using GSSAPI. This is built on top of a + packetizing buffer. */ -/* This structure is the closure field of a Kerberos encryption - buffer. */ +/* This structure is the closure field of the GSSAPI translation + routines. */ -struct krb_encrypt_buffer +struct cvs_gssapi_wrap_data { - /* The underlying buffer. */ - struct buffer *buf; - /* The Kerberos key schedule. */ - Key_schedule sched; - /* The Kerberos DES block. */ - C_Block block; - /* For an input buffer, we may have to buffer up data here. */ - /* This is non-zero if the buffered data is decrypted. Otherwise, - the buffered data is encrypted, and starts with the two byte - count. */ - int clear; - /* The amount of buffered data. */ - int holdsize; - /* The buffer allocated to hold the data. */ - char *holdbuf; - /* The size of holdbuf. */ - int holdbufsize; - /* If clear is set, we need another data pointer to track where we - are in holdbuf. If clear is zero, then this pointer is not - used. */ - char *holddata; + /* The GSSAPI context. */ + gss_ctx_id_t gcontext; }; -static int krb_encrypt_buffer_input PROTO((void *, char *, int, int, int *)); -static int krb_encrypt_buffer_output PROTO((void *, const char *, int, int *)); -static int krb_encrypt_buffer_flush PROTO((void *)); -static int krb_encrypt_buffer_block PROTO((void *, int)); -static int krb_encrypt_buffer_shutdown PROTO((void *)); +static int cvs_gssapi_wrap_input PROTO((void *, const char *, char *, int)); +static int cvs_gssapi_wrap_output PROTO((void *, const char *, char *, int, + int *)); -/* Create an encryption buffer. */ +/* Create a GSSAPI wrapping buffer. We use a packetizing buffer with + GSSAPI wrapping routines. */ struct buffer * -krb_encrypt_buffer_initialize (buf, input, sched, block, memory) +cvs_gssapi_wrap_buffer_initialize (buf, input, gcontext, memory) struct buffer *buf; int input; - Key_schedule sched; - C_Block block; + gss_ctx_id_t gcontext; void (*memory) PROTO((struct buffer *)); { - struct krb_encrypt_buffer *kb; + struct cvs_gssapi_wrap_data *gd; - kb = (struct krb_encrypt_buffer *) xmalloc (sizeof *kb); - memset (kb, 0, sizeof *kb); - - kb->buf = buf; - memcpy (kb->sched, sched, sizeof (Key_schedule)); - memcpy (kb->block, block, sizeof (C_Block)); - if (input) - { - /* We add some space to the buffer to hold the length. */ - kb->holdbufsize = BUFFER_DATA_SIZE + 16; - kb->holdbuf = xmalloc (kb->holdbufsize); - } + gd = (struct cvs_gssapi_wrap_data *) xmalloc (sizeof *gd); + gd->gcontext = gcontext; - return buf_initialize (input ? krb_encrypt_buffer_input : NULL, - input ? NULL : krb_encrypt_buffer_output, - input ? NULL : krb_encrypt_buffer_flush, - krb_encrypt_buffer_block, - krb_encrypt_buffer_shutdown, - memory, - kb); + return (packetizing_buffer_initialize + (buf, + input ? cvs_gssapi_wrap_input : NULL, + input ? NULL : cvs_gssapi_wrap_output, + gd, + memory)); } -/* Input data from a Kerberos encryption buffer. */ +/* Unwrap data using GSSAPI. */ static int -krb_encrypt_buffer_input (closure, data, need, size, got) - void *closure; - char *data; - int need; +cvs_gssapi_wrap_input (fnclosure, input, output, size) + void *fnclosure; + const char *input; + char *output; int size; - int *got; { - struct krb_encrypt_buffer *kb = (struct krb_encrypt_buffer *) closure; + struct cvs_gssapi_wrap_data *gd = + (struct cvs_gssapi_wrap_data *) fnclosure; + gss_buffer_desc inbuf, outbuf; + OM_uint32 stat_min; + int conf; - *got = 0; + inbuf.value = (void *) input; + inbuf.length = size; - if (kb->holdsize > 0 && kb->clear) + if (gss_unwrap (&stat_min, gd->gcontext, &inbuf, &outbuf, &conf, NULL) + != GSS_S_COMPLETE) { - int copy; - - copy = kb->holdsize; - - if (copy > size) - { - memcpy (data, kb->holddata, size); - kb->holdsize -= size; - kb->holddata += size; - *got = size; - return 0; - } - - memcpy (data, kb->holddata, copy); - kb->holdsize = 0; - kb->clear = 0; - - data += copy; - need -= copy; - size -= copy; - *got = copy; + error (1, 0, "gss_unwrap failed"); } - while (need > 0 || *got == 0) - { - int get, status, nread, count, dcount; - char *bytes; - char stackoutbuf[BUFFER_DATA_SIZE + 16]; - char *outbuf; + if (outbuf.length > size) + abort (); - /* If we don't already have the two byte count, get it. */ - if (kb->holdsize < 2) - { - get = 2 - kb->holdsize; - status = buf_read_data (kb->buf, get, &bytes, &nread); - if (status != 0) - { - /* buf_read_data can return -2, but a buffer input - function is only supposed to return -1, 0, or an - error code. */ - if (status == -2) - status = ENOMEM; - return status; - } + memcpy (output, outbuf.value, outbuf.length); - if (nread == 0) - { - /* The buffer is in nonblocking mode, and we didn't - manage to read anything. */ - return 0; - } + /* The real packet size is stored in the data, so we don't need to + remember outbuf.length. */ - if (get == 1) - kb->holdbuf[1] = bytes[0]; - else - { - kb->holdbuf[0] = bytes[0]; - if (nread < 2) - { - /* We only got one byte, but we needed two. Stash - the byte we got, and try again. */ - kb->holdsize = 1; - continue; - } - kb->holdbuf[1] = bytes[1]; - } - kb->holdsize = 2; - } + gss_release_buffer (&stat_min, &outbuf); - /* Read the encrypted block of data. */ + return 0; +} - count = (((kb->holdbuf[0] & 0xff) << 8) - + (kb->holdbuf[1] & 0xff)); +/* Wrap data using GSSAPI. */ - if (count + 2 > kb->holdbufsize) - { - char *n; +static int +cvs_gssapi_wrap_output (fnclosure, input, output, size, translated) + void *fnclosure; + const char *input; + char *output; + int size; + int *translated; +{ + struct cvs_gssapi_wrap_data *gd = + (struct cvs_gssapi_wrap_data *) fnclosure; + gss_buffer_desc inbuf, outbuf; + OM_uint32 stat_min; + int conf_req, conf; - /* This should be impossible, since we should have - allocated space for the largest possible block in the - initialize function. However, we handle it just in - case something changes in the future, so that a current - server can handle a later client. */ + inbuf.value = (void *) input; + inbuf.length = size; - n = realloc (kb->holdbuf, count + 2); - if (n == NULL) - { - (*kb->buf->memory_error) (kb->buf); - return ENOMEM; - } - kb->holdbuf = n; - kb->holdbufsize = count + 2; - } +#ifdef ENCRYPTION + conf_req = cvs_gssapi_encrypt; +#else + conf_req = 0; +#endif - get = count - (kb->holdsize - 2); + if (gss_wrap (&stat_min, gd->gcontext, conf_req, GSS_C_QOP_DEFAULT, + &inbuf, &conf, &outbuf) != GSS_S_COMPLETE) + error (1, 0, "gss_wrap failed"); - status = buf_read_data (kb->buf, get, &bytes, &nread); - if (status != 0) - { - /* buf_read_data can return -2, but a buffer input - function is only supposed to return -1, 0, or an error - code. */ - if (status == -2) - status = ENOMEM; - return status; - } + /* The packetizing buffer only permits us to add 100 bytes. + FIXME: I don't know what, if anything, is guaranteed by GSSAPI. + This may need to be increased for a different GSSAPI + implementation, or we may need a different algorithm. */ + if (outbuf.length > size + 100) + abort (); - if (nread == 0) - { - /* We did not get any data. Presumably the buffer is in - nonblocking mode. */ - return 0; - } + memcpy (output, outbuf.value, outbuf.length); - /* FIXME: We could complicate the code here to avoid this - memcpy in the common case of kb->holdsize == 2 && nread == - get. */ - memcpy (kb->holdbuf + kb->holdsize, bytes, nread); - kb->holdsize += nread; + *translated = outbuf.length; - if (nread < get) - { - /* We did not get all the data we need. buf_read_data - does not promise to return all the bytes requested, so - we must try again. */ - continue; - } + gss_release_buffer (&stat_min, &outbuf); - /* We have a complete encrypted block of COUNT bytes at - KB->HOLDBUF + 2. Decrypt it. */ + return 0; +} - if (count <= sizeof stackoutbuf) - outbuf = stackoutbuf; - else - { - /* I believe this is currently impossible, but we handle - it for the benefit of future client changes. */ - outbuf = malloc (count); - if (outbuf == NULL) - { - (*kb->buf->memory_error) (kb->buf); - return ENOMEM; - } - } +#endif /* HAVE_GSSAPI */ - des_cbc_encrypt ((C_Block *) (kb->holdbuf + 2), (C_Block *) outbuf, - count, kb->sched, &kb->block, 0); +#ifdef ENCRYPTION - /* The first two bytes in the decrypted buffer are the real - (unaligned) length. */ - dcount = ((outbuf[0] & 0xff) << 8) + (outbuf[1] & 0xff); +#ifdef HAVE_KERBEROS - if (((dcount + 2 + 7) & ~7) != count) - error (1, 0, "Decryption failure"); +/* An encryption interface using Kerberos. This is built on top of a + packetizing buffer. */ - if (dcount > size) - { - /* We have too much data for the buffer. We need to save - some of it for the next call. */ +/* This structure is the closure field of the Kerberos translation + routines. */ - memcpy (data, outbuf + 2, size); - *got += size; +struct krb_encrypt_data +{ + /* The Kerberos key schedule. */ + Key_schedule sched; + /* The Kerberos DES block. */ + C_Block block; +}; - kb->holdsize = dcount - size; - memcpy (kb->holdbuf, outbuf + 2 + size, dcount - size); - kb->holddata = kb->holdbuf; - kb->clear = 1; +static int krb_encrypt_input PROTO((void *, const char *, char *, int)); +static int krb_encrypt_output PROTO((void *, const char *, char *, int, + int *)); - if (outbuf != stackoutbuf) - free (outbuf); +/* Create a Kerberos encryption buffer. We use a packetizing buffer + with Kerberos encryption translation routines. */ - return 0; - } +struct buffer * +krb_encrypt_buffer_initialize (buf, input, sched, block, memory) + struct buffer *buf; + int input; + Key_schedule sched; + C_Block block; + void (*memory) PROTO((struct buffer *)); +{ + struct krb_encrypt_data *kd; - memcpy (data, outbuf + 2, dcount); + kd = (struct krb_encrypt_data *) xmalloc (sizeof *kd); + memcpy (kd->sched, sched, sizeof (Key_schedule)); + memcpy (kd->block, block, sizeof (C_Block)); - if (outbuf != stackoutbuf) - free (outbuf); + return packetizing_buffer_initialize (buf, + input ? krb_encrypt_input : NULL, + input ? NULL : krb_encrypt_output, + kd, + memory); +} - kb->holdsize = 0; +/* Decrypt Kerberos data. */ - data += dcount; - need -= dcount; - size -= dcount; - *got += dcount; - } +static int +krb_encrypt_input (fnclosure, input, output, size) + void *fnclosure; + const char *input; + char *output; + int size; +{ + struct krb_encrypt_data *kd = (struct krb_encrypt_data *) fnclosure; + int tcount; + + des_cbc_encrypt ((C_Block *) input, (C_Block *) output, + size, kd->sched, &kd->block, 0); + + /* SIZE is the size of the buffer, which is set by the encryption + routine. The packetizing buffer will arrange for the first two + bytes in the decrypted buffer to be the real (unaligned) + length. As a safety check, make sure that the length in the + buffer corresponds to SIZE. Note that the length in the buffer + is just the length of the data. We must add 2 to account for + the buffer count itself. */ + tcount = ((output[0] & 0xff) << 8) + (output[1] & 0xff); + if (((tcount + 2 + 7) & ~7) != size) + error (1, 0, "Decryption failure"); return 0; } -/* Output data to a Kerberos encryption buffer. */ +/* Encrypt Kerberos data. */ static int -krb_encrypt_buffer_output (closure, data, have, wrote) - void *closure; - const char *data; - int have; - int *wrote; +krb_encrypt_output (fnclosure, input, output, size, translated) + void *fnclosure; + const char *input; + char *output; + int size; + int *translated; { - struct krb_encrypt_buffer *kb = (struct krb_encrypt_buffer *) closure; - char inbuf[BUFFER_DATA_SIZE + 16]; - char outbuf[BUFFER_DATA_SIZE + 16]; + struct krb_encrypt_data *kd = (struct krb_encrypt_data *) fnclosure; int aligned; - if (have > BUFFER_DATA_SIZE) - { - /* It would be easy to malloc a buffer, but I don't think this - case can ever arise. */ - abort (); - } - - inbuf[0] = (have >> 8) & 0xff; - inbuf[1] = have & 0xff; - memcpy (inbuf + 2, data, have); - /* For security against a known plaintext attack, we should initialize any padding bytes to random values. Instead, we just pick up whatever is on the stack, which is at least better than using zero. */ - /* Align (have + 2) (plus 2 for the count) to an 8 byte boundary. */ - aligned = (have + 2 + 7) & ~7; + /* Align SIZE to an 8 byte boundary. Note that SIZE includes the + two byte buffer count at the start of INPUT which was added by + the packetizing buffer. */ + aligned = (size + 7) & ~7; /* We use des_cbc_encrypt rather than krb_mk_priv because the latter sticks a timestamp in the block, and krb_rd_priv expects @@ -5127,65 +5451,12 @@ krb_encrypt_buffer_output (closure, data, have, wrote) fail over a long network connection. We trust krb_recvauth to guard against a replay attack. */ - des_cbc_encrypt ((C_Block *) inbuf, (C_Block *) (outbuf + 2), aligned, - kb->sched, &kb->block, 1); - - outbuf[0] = (aligned >> 8) & 0xff; - outbuf[1] = aligned & 0xff; - - /* FIXME: It would be more efficient to get des_cbc_encrypt to put - its output directly into a buffer_data structure, which we - could then append to kb->buf. That would save a memcpy. */ - - buf_output (kb->buf, outbuf, aligned + 2); - - *wrote = have; - - /* We will only be here because buf_send_output was called on the - encryption buffer. That means that we should now call - buf_send_output on the underlying buffer. */ - return buf_send_output (kb->buf); -} - -/* Flush data to a Kerberos encryption buffer. */ - -static int -krb_encrypt_buffer_flush (closure) - void *closure; -{ - struct krb_encrypt_buffer *kb = (struct krb_encrypt_buffer *) closure; - - /* Flush the underlying buffer. Note that if the original call to - buf_flush passed 1 for the BLOCK argument, then the buffer will - already have been set into blocking mode, so we should always - pass 0 here. */ - return buf_flush (kb->buf, 0); -} - -/* The block routine for a Kerberos encryption buffer. */ + des_cbc_encrypt ((C_Block *) input, (C_Block *) output, aligned, + kd->sched, &kd->block, 1); -static int -krb_encrypt_buffer_block (closure, block) - void *closure; - int block; -{ - struct krb_encrypt_buffer *kb = (struct krb_encrypt_buffer *) closure; - - if (block) - return set_block (kb->buf); - else - return set_nonblock (kb->buf); -} - -/* Shut down a Kerberos encryption buffer. */ - -static int -krb_encrypt_buffer_shutdown (closure) - void *closure; -{ - struct krb_encrypt_buffer *kb = (struct krb_encrypt_buffer *) closure; + *translated = aligned; - return buf_shutdown (kb->buf); + return 0; } #endif /* HAVE_KERBEROS */ @@ -5221,6 +5492,13 @@ cvs_output (str, len) size_t to_write = len; const char *p = str; + /* For symmetry with cvs_outerr we would call fflush (stderr) + here. I guess the assumption is that stderr will be + unbuffered, so we don't need to. That sounds like a sound + assumption from the manpage I looked at, but if there was + something fishy about it, my guess is that calling fflush + would not produce a significant performance problem. */ + while (to_write > 0) { written = fwrite (p, 1, to_write, stdout); @@ -5232,6 +5510,90 @@ cvs_output (str, len) } } +/* Output LEN bytes at STR in binary mode. If LEN is zero, then + output zero bytes. */ + +void +cvs_output_binary (str, len) + char *str; + size_t len; +{ +#ifdef SERVER_SUPPORT + if (error_use_protocol || server_active) + { + struct buffer *buf; + char size_text[40]; + + if (error_use_protocol) + buf = buf_to_net; + else if (server_active) + buf = protocol; + + if (!supported_response ("Mbinary")) + { + error (0, 0, "\ +this client does not support writing binary files to stdout"); + return; + } + + buf_output0 (buf, "Mbinary\012"); + sprintf (size_text, "%lu\012", (unsigned long) len); + buf_output0 (buf, size_text); + + /* Not sure what would be involved in using buf_append_data here + without stepping on the toes of our caller (which is responsible + for the memory allocation of STR). */ + buf_output (buf, str, len); + + if (!error_use_protocol) + buf_send_counted (protocol); + } + else +#endif + { + size_t written; + size_t to_write = len; + const char *p = str; + + /* For symmetry with cvs_outerr we would call fflush (stderr) + here. I guess the assumption is that stderr will be + unbuffered, so we don't need to. That sounds like a sound + assumption from the manpage I looked at, but if there was + something fishy about it, my guess is that calling fflush + would not produce a significant performance problem. */ +#ifdef USE_SETMODE_STDOUT + int oldmode; + + /* It is possible that this should be the same ifdef as + USE_SETMODE_BINARY but at least for the moment we keep them + separate. Mostly this is just laziness and/or a question + of what has been tested where. Also there might be an + issue of setmode vs. _setmode. */ + /* The Windows doc says to call setmode only right after startup. + I assume that what they are talking about can also be helped + by flushing the stream before changing the mode. */ + fflush (stdout); + oldmode = _setmode (_fileno (stdout), _O_BINARY); + if (oldmode < 0) + error (0, errno, "failed to setmode on stdout"); +#endif + + while (to_write > 0) + { + written = fwrite (p, 1, to_write, stdout); + if (written == 0) + break; + p += written; + to_write -= written; + } +#ifdef USE_SETMODE_STDOUT + fflush (stdout); + if (_setmode (_fileno (stdout), oldmode) != _O_BINARY) + error (0, errno, "failed to setmode on stdout"); +#endif + } +} + /* Like CVS_OUTPUT but output is for stderr not stdout. */ void @@ -5325,3 +5687,62 @@ cvs_flushout () #endif fflush (stdout); } + +/* Output TEXT, tagging it according to TAG. There are lots more + details about what TAG means in cvsclient.texi but for the simple + case (e.g. non-client/server), TAG is just "newline" to output a + newline (in which case TEXT must be NULL), and any other tag to + output normal text. + + Note that there is no way to output either \0 or \n as part of TEXT. */ + +void +cvs_output_tagged (tag, text) + char *tag; + char *text; +{ + if (text != NULL && strchr (text, '\n') != NULL) + /* Uh oh. The protocol has no way to cope with this. For now + we dump core, although that really isn't such a nice + response given that this probably can be caused by newlines + in filenames and other causes other than bugs in CVS. Note + that we don't want to turn this into "MT newline" because + this case is a newline within a tagged item, not a newline + as extraneous sugar for the user. */ + assert (0); + + /* Start and end tags don't take any text, per cvsclient.texi. */ + if (tag[0] == '+' || tag[0] == '-') + assert (text == NULL); + +#ifdef SERVER_SUPPORT + if (server_active && supported_response ("MT")) + { + struct buffer *buf; + + if (error_use_protocol) + buf = buf_to_net; + else + buf = protocol; + + buf_output0 (buf, "MT "); + buf_output0 (buf, tag); + if (text != NULL) + { + buf_output (buf, " ", 1); + buf_output0 (buf, text); + } + buf_output (buf, "\n", 1); + + if (!error_use_protocol) + buf_send_counted (protocol); + } + else +#endif + { + if (strcmp (tag, "newline") == 0) + cvs_output ("\n", 1); + else if (text != NULL) + cvs_output (text, 0); + } +} diff --git a/contrib/cvs/src/server.h b/contrib/cvs/src/server.h index 743f090..e5a3c3f 100644 --- a/contrib/cvs/src/server.h +++ b/contrib/cvs/src/server.h @@ -113,6 +113,7 @@ extern void server_pause_check PROTO((void)); #ifdef AUTH_SERVER_SUPPORT extern char *CVS_Username; +extern int system_auth; #endif /* AUTH_SERVER_SUPPORT */ #endif /* SERVER_SUPPORT */ @@ -161,3 +162,8 @@ struct request /* Table of requests ending with an entry with a NULL name. */ extern struct request requests[]; + +/* Gzip library, see zlib.c. */ +extern void gunzip_and_write PROTO ((int, char *, unsigned char *, size_t)); +extern void read_and_gzip PROTO ((int, char *, unsigned char **, size_t *, + size_t *, int)); diff --git a/contrib/cvs/src/status.c b/contrib/cvs/src/status.c index cdc0949..98be085 100644 --- a/contrib/cvs/src/status.c +++ b/contrib/cvs/src/status.c @@ -3,7 +3,7 @@ * Copyright (c) 1989-1992, Brian Berliner * * You may distribute under the terms of the GNU General Public License as - * specified in the README file that comes with the CVS 1.4 kit. + * specified in the README file that comes with the CVS source distribution. * * Status Information */ @@ -26,6 +26,7 @@ static const char *const status_usage[] = "\t-v\tVerbose format; includes tag information for the file\n", "\t-l\tProcess this directory only (not recursive).\n", "\t-R\tProcess directories recursively.\n", + "(Specify the --help global option for a list of other help options)\n", NULL }; @@ -77,13 +78,21 @@ status (argc, argv) send_arg("-l"); send_file_names (argc, argv, SEND_EXPAND_WILD); - /* Note that by setting SEND_NO_CONTENTS, we do prevent the + + /* For a while, we tried setting SEND_NO_CONTENTS here so this + could be a fast operation. That prevents the server from updating our timestamp if the timestamp is - unchanged and the file is unmodified. And I think it is a - user-visible thing in that case (shows "locally modified" - instead of "up to date" I would think). But the speed seems - to be worth it. */ - send_files (argc, argv, local, 0, SEND_NO_CONTENTS); + changed but the file is unmodified. Worse, it is user-visible + (shows "locally modified" instead of "up to date" if + timestamp is changed but file is not). And there is no good + workaround (you might not want to run "cvs update"; "cvs -n + update" doesn't update CVS/Entries; "cvs diff --brief" or + something perhaps could be made to work but somehow that + seems nonintuitive to me even if so). Given that timestamps + seem to have the potential to get munged for any number of + reasons, it seems better to not rely too much on them. */ + + send_files (argc, argv, local, 0, 0); send_to_server ("status\012", 0); err = get_responses_and_close (); @@ -243,7 +252,7 @@ status_fileproc (callerdat, finfo) { char *branch = NULL; - if (RCS_isbranch (finfo->rcs, edata->tag)) + if (RCS_nodeisbranch (finfo->rcs, edata->tag)) branch = RCS_whatbranch(finfo->rcs, edata->tag); cvs_output (" Sticky Tag:\t\t", 0); @@ -328,7 +337,7 @@ tag_list_proc (p, closure) char *branch = NULL; char *buf; - if (RCS_isbranch (xrcsnode, p->key)) + if (RCS_nodeisbranch (xrcsnode, p->key)) branch = RCS_whatbranch(xrcsnode, p->key) ; buf = xmalloc (80 + strlen (p->key) diff --git a/contrib/cvs/src/subr.c b/contrib/cvs/src/subr.c index d29942b..61b3103 100644 --- a/contrib/cvs/src/subr.c +++ b/contrib/cvs/src/subr.c @@ -3,7 +3,7 @@ * Copyright (c) 1989-1992, Brian Berliner * * You may distribute under the terms of the GNU General Public License as - * specified in the README file that comes with the CVS 1.4 kit. + * specified in the README file that comes with the CVS source distribution. * * Various useful functions for the CVS support code. */ @@ -30,7 +30,8 @@ xmalloc (bytes) cp = malloc (bytes); if (cp == NULL) - error (1, 0, "can not allocate %lu bytes", (unsigned long) bytes); + error (1, 0, "out of memory; can not allocate %lu bytes", + (unsigned long) bytes); return (cp); } @@ -181,16 +182,17 @@ free_names (pargc, argv) *pargc = 0; /* and set it to zero when done */ } -/* Convert LINE into arguments separated by space and tab. Set *ARGC +/* Convert LINE into arguments separated by SEPCHARS. Set *ARGC to the number of arguments found, and (*ARGV)[0] to the first argument, (*ARGV)[1] to the second, etc. *ARGV is malloc'd and so are each of (*ARGV)[0], (*ARGV)[1], ... Use free_names() to return the memory allocated here back to the free pool. */ void -line2argv (pargc, argv, line) +line2argv (pargc, argv, line, sepchars) int *pargc; char ***argv; char *line; + char *sepchars; { char *cp; /* Could make a case for size_t or some other unsigned type, but @@ -205,7 +207,7 @@ line2argv (pargc, argv, line) *argv = (char **) xmalloc (argv_allocated * sizeof (**argv)); *pargc = 0; - for (cp = strtok (line, " \t"); cp; cp = strtok ((char *) NULL, " \t")) + for (cp = strtok (line, sepchars); cp; cp = strtok ((char *) NULL, sepchars)) { if (*pargc == argv_allocated) { @@ -234,6 +236,56 @@ numdots (s) return (dots); } +/* Compare revision numbers REV1 and REV2 by consecutive fields. + Return negative, zero, or positive in the manner of strcmp. The + two revision numbers must have the same number of fields, or else + compare_revnums will return an inaccurate result. */ +int +compare_revnums (rev1, rev2) + const char *rev1; + const char *rev2; +{ + const char *s, *sp; + const char *t, *tp; + char *snext, *tnext; + int result = 0; + + sp = s = rev1; + tp = t = rev2; + while (result == 0) + { + result = strtoul (sp, &snext, 10) - strtoul (tp, &tnext, 10); + if (*snext == '\0' || *tnext == '\0') + break; + sp = snext + 1; + tp = tnext + 1; + } + + return result; +} + +char * +increment_revnum (rev) + const char *rev; +{ + char *newrev, *p; + int lastfield; + size_t len = strlen (rev); + + newrev = (char *) xmalloc (len + 2); + memcpy (newrev, rev, len + 1); + p = strrchr (newrev, '.'); + if (p == NULL) + { + free (newrev); + return NULL; + } + lastfield = atoi (++p); + sprintf (p, "%d", lastfield + 1); + + return newrev; +} + /* Return the username by which the caller should be identified in CVS, in contexts such as the author field of RCS files, various logs, etc. @@ -244,10 +296,12 @@ numdots (s) char * getcaller () { +#ifndef SYSTEM_GETCALLER static char uidname[20]; struct passwd *pw; char *name; uid_t uid; +#endif /* If there is a CVS username, return it. */ #ifdef AUTH_SERVER_SUPPORT @@ -255,6 +309,9 @@ getcaller () return CVS_Username; #endif +#ifdef SYSTEM_GETCALLER + return SYSTEM_GETCALLER (); +#else /* Get the caller's login from his uid. If the real uid is "root" try LOGNAME USER or getlogin(). If getlogin() and getpwuid() both fail, return the uid as a string. */ @@ -273,6 +330,7 @@ getcaller () return (uidname); } return (pw->pw_name); +#endif } #ifdef lint @@ -296,12 +354,12 @@ get_date (date, now) char * gca (rev1, rev2) - char *rev1; - char *rev2; + const char *rev1; + const char *rev2; { int dots; char *gca; - char *p[2]; + const char *p[2]; int j[2]; char *retval; @@ -370,7 +428,7 @@ gca (rev1, rev2) /* revisions differ in trunk major number. */ char *q; - char *s; + const char *s; s = (j[0] < j[1]) ? p[0] : p[1]; @@ -408,29 +466,80 @@ gca (rev1, rev2) return retval; } +/* Give fatal error if REV is numeric and ARGC,ARGV imply we are + planning to operate on more than one file. The current directory + should be the working directory. Note that callers assume that we + will only be checking the first character of REV; it need not have + '\0' at the end of the tag name and other niceties. Right now this + is only called from admin.c, but if people like the concept it probably + should also be called from diff -r, update -r, get -r, and log -r. */ + +void +check_numeric (rev, argc, argv) + const char *rev; + int argc; + char **argv; +{ + if (rev == NULL || !isdigit (*rev)) + return; + + /* Note that the check for whether we are processing more than one + file is (basically) syntactic; that is, we don't behave differently + depending on whether a directory happens to contain only a single + file or whether it contains more than one. I strongly suspect this + is the least confusing behavior. */ + if (argc != 1 + || (!wrap_name_has (argv[0], WRAP_TOCVS) && isdir (argv[0]))) + { + error (0, 0, "while processing more than one file:"); + error (1, 0, "attempt to specify a numeric revision"); + } +} + /* * Sanity checks and any required fix-up on message passed to RCS via '-m'. * RCS 5.7 requires that a non-total-whitespace, non-null message be provided - * with '-m'. Returns the original argument or a pointer to readonly - * static storage. + * with '-m'. Returns a newly allocated, non-empty buffer with whitespace + * stripped from end of lines and end of buffer. + * + * TODO: We no longer use RCS to manage repository files, so maybe this + * nonsense about non-empty log fields can be dropped. */ char * make_message_rcslegal (message) char *message; { - if ((message == NULL) || (*message == '\0') || isspace (*message)) + char *dst, *dp, *mp; + + if (message == NULL) message = ""; + + /* Strip whitespace from end of lines and end of string. */ + dp = dst = (char *) xmalloc (strlen (message) + 1); + for (mp = message; *mp != '\0'; ++mp) { - char *t; + if (*mp == '\n') + { + /* At end-of-line; backtrack to last non-space. */ + while (dp > dst && (dp[-1] == ' ' || dp[-1] == '\t')) + --dp; + } + *dp++ = *mp; + } - if (message) - for (t = message; *t; t++) - if (!isspace (*t)) - return message; + /* Backtrack to last non-space at end of string, and truncate. */ + while (dp > dst && isspace (dp[-1])) + --dp; + *dp = '\0'; - return "*** empty log message ***\n"; + /* After all that, if there was no non-space in the string, + substitute a non-empty message. */ + if (*dst == '\0') + { + free (dst); + dst = xstrdup ("*** empty log message ***"); } - return message; + return dst; } /* Does the file FINFO contain conflict markers? The whole concept @@ -440,7 +549,7 @@ make_message_rcslegal (message) is what we do. */ int file_has_markers (finfo) - struct file_info *finfo; + const struct file_info *finfo; { FILE *fp; char *line = NULL; @@ -468,3 +577,95 @@ out: free (line); return result; } + +/* Read the entire contents of the file NAME into *BUF. + If NAME is NULL, read from stdin. *BUF + is a pointer returned from malloc (or NULL), pointing to *BUFSIZE + bytes of space. The actual size is returned in *LEN. On error, + give a fatal error. The name of the file to use in error messages + (typically will include a directory if we have changed directory) + is FULLNAME. MODE is "r" for text or "rb" for binary. */ + +void +get_file (name, fullname, mode, buf, bufsize, len) + const char *name; + const char *fullname; + const char *mode; + char **buf; + size_t *bufsize; + size_t *len; +{ + struct stat s; + size_t nread; + char *tobuf; + FILE *e; + size_t filesize; + + if (name == NULL) + { + e = stdin; + filesize = 100; /* force allocation of minimum buffer */ + } + else + { + if (CVS_STAT (name, &s) < 0) + error (1, errno, "can't stat %s", fullname); + /* Convert from signed to unsigned. */ + filesize = s.st_size; + + e = open_file (name, mode); + } + + if (*bufsize < filesize) + { + *bufsize = filesize; + *buf = xrealloc (*buf, *bufsize); + } + + tobuf = *buf; + nread = 0; + while (1) + { + size_t got; + + got = fread (tobuf, 1, *bufsize - (tobuf - *buf), e); + if (ferror (e)) + error (1, errno, "can't read %s", fullname); + nread += got; + tobuf += got; + + if (feof (e)) + break; + + /* It's probably paranoid to think S.ST_SIZE might be + too small to hold the entire file contents, but we + handle it just in case. */ + if (tobuf == *buf + *bufsize) + { + int c; + long off; + + c = getc (e); + if (c == EOF) + break; + off = tobuf - *buf; + expand_string (buf, bufsize, *bufsize + 100); + tobuf = *buf + off; + *tobuf++ = c; + ++nread; + } + } + + if (e != stdin && fclose (e) < 0) + error (0, errno, "cannot close %s", fullname); + + *len = nread; + + /* Force *BUF to be large enough to hold a null terminator. */ + if (*buf != NULL) + { + if (nread == *bufsize) + expand_string (buf, bufsize, *bufsize + 1); + (*buf)[nread] = '\0'; + } +} diff --git a/contrib/cvs/src/tag.c b/contrib/cvs/src/tag.c index 93e6c67..a97da5c 100644 --- a/contrib/cvs/src/tag.c +++ b/contrib/cvs/src/tag.c @@ -3,7 +3,7 @@ * Copyright (c) 1989-1992, Brian Berliner * * You may distribute under the terms of the GNU General Public License as - * specified in the README file that comes with the CVS 1.4 kit. + * specified in the README file that comes with the CVS source distribution. * * Tag * @@ -63,11 +63,13 @@ static const char *const tag_usage[] = "\t-l\tLocal directory only, not recursive.\n", "\t-R\tProcess directories recursively.\n", "\t-d\tDelete the given tag.\n", - "\t-[rD]\tExisting tag or date.\n", + "\t-r rev\tExisting revision/tag.\n", + "\t-D\tExisting date.\n", "\t-f\tForce a head revision if specified tag not found.\n", "\t-b\tMake the tag a \"branch\" tag, allowing concurrent development.\n", "\t-F\tMove tag if it already exists.\n", "\t-c\tCheck that working files are unmodified.\n", + "(Specify the --help global option for a list of other help options)\n", NULL }; @@ -370,11 +372,10 @@ pretag_proc(repository, filter) } free(s); } - run_setup("%s %s %s %s", - filter, - symtag, - delete_flag ? "del" : force_tag_move ? "mov" : "add", - repository); + run_setup (filter); + run_arg (symtag); + run_arg (delete_flag ? "del" : force_tag_move ? "mov" : "add"); + run_arg (repository); walklist(tlist, pretag_list_proc, NULL); return (run_exec(RUN_TTY, RUN_TTY, RUN_TTY, RUN_NORMAL|RUN_REALLY)); } @@ -480,7 +481,7 @@ tag_fileproc (callerdat, finfo) } free (version); - if ((retcode = RCS_deltag(vers->srcfile, symtag, 1)) != 0) + if ((retcode = RCS_deltag(vers->srcfile, symtag)) != 0) { if (!quiet) error (0, retcode == -1 ? errno : 0, @@ -489,6 +490,7 @@ tag_fileproc (callerdat, finfo) freevers_ts (&vers); return (1); } + RCS_rewrite (vers->srcfile, NULL, NULL); /* warm fuzzies */ if (!really_quiet) @@ -554,7 +556,7 @@ tag_fileproc (callerdat, finfo) (int *) NULL); if (oversion != NULL) { - int isbranch = RCS_isbranch (finfo->rcs, symtag); + int isbranch = RCS_nodeisbranch (finfo->rcs, symtag); /* * if versions the same and neither old or new are branches don't have @@ -598,6 +600,7 @@ tag_fileproc (callerdat, finfo) freevers_ts (&vers); return (1); } + RCS_rewrite (vers->srcfile, NULL, NULL); /* more warm fuzzies */ if (!really_quiet) @@ -752,6 +755,11 @@ Numeric tag %s contains characters other than digits and '.'", name); || strcmp (name, TAG_HEAD) == 0) return; + /* FIXME: This routine doesn't seem to do any locking whatsoever + (and it is called from places which don't have locks in place). + If two processes try to write val-tags at the same time, it would + seem like we are in trouble. */ + mytag.dptr = name; mytag.dsize = strlen (name); diff --git a/contrib/cvs/src/update.c b/contrib/cvs/src/update.c index 8196c1f..48bed3b 100644 --- a/contrib/cvs/src/update.c +++ b/contrib/cvs/src/update.c @@ -3,7 +3,7 @@ * Copyright (c) 1989-1992, Brian Berliner * * You may distribute under the terms of the GNU General Public License as - * specified in the README file that comes with the CVS 1.4 kit. + * specified in the README file that comes with the CVS source distribution. * * "update" updates the version in the present directory with respect to the RCS * repository. The present version must have been created by "checkout". The @@ -64,12 +64,8 @@ static int update_fileproc PROTO ((void *callerdat, struct file_info *)); static int update_filesdone_proc PROTO ((void *callerdat, int err, char *repository, char *update_dir, List *entries)); -static int write_letter PROTO((char *file, int letter, char *update_dir)); -#ifdef SERVER_SUPPORT -static void join_file PROTO ((struct file_info *finfo, Vers_TS *vers_ts)); -#else +static void write_letter PROTO ((struct file_info *finfo, int letter)); static void join_file PROTO ((struct file_info *finfo, Vers_TS *vers_ts)); -#endif static char *options = NULL; static char *tag = NULL; @@ -113,6 +109,7 @@ static const char *const update_usage[] = "\t-j rev\tMerge in changes made between current revision and rev.\n", "\t-I ign\tMore files to ignore (! to reset).\n", "\t-W spec\tWrappers specification line.\n", + "(Specify the --help global option for a list of other help options)\n", NULL }; @@ -259,16 +256,18 @@ update (argc, argv) /* If the server supports the command "update-patches", that means that it knows how to handle the -u argument to update, which - means to send patches instead of complete files. */ + means to send patches instead of complete files. + + We don't send -u if failed_patches != NULL, so that the + server doesn't try to send patches which will just fail + again. At least currently, the client also clobbers the + file and tells the server it is lost, which also will get + a full file instead of a patch, but it seems clean to omit + -u. */ if (failed_patches == NULL) { -#ifndef DONT_USE_PATCH - /* Systems which don't have the patch program ported to them - will want to define DONT_USE_PATCH; then CVS won't try to - invoke patch. */ if (supported_request ("update-patches")) send_arg ("-u"); -#endif } if (failed_patches == NULL) @@ -548,44 +547,17 @@ update_fileproc (callerdat, finfo) break; case T_CONFLICT: /* old punt-type errors */ retval = 1; - (void) write_letter (finfo->file, 'C', finfo->update_dir); + write_letter (finfo, 'C'); break; case T_NEEDS_MERGE: /* needs merging */ if (noexec) { retval = 1; - (void) write_letter (finfo->file, 'C', finfo->update_dir); + write_letter (finfo, 'C'); } else { - if (wrap_merge_is_copy (finfo->file)) -#if 0 - /* Look, we can't clobber the user's file. We - know it is modified and we're going to - overwrite their mod? Puh-leeze. The - correct behavior is probably something like - what merge_file does for -kb, which is to - give the users both files and tell them - what the two filenames are. Of course, -m - in wrappers needs to be documented *much* - better. Anyway, until then, make this a - fatal error. */ - - /* Should we be warning the user that we are - * overwriting the user's copy of the file? */ - retval = - checkout_file (finfo, vers, 0); -#else - { - error (0, 0, "A -m 'COPY' wrapper is specified"); - error (0, 0, "but file %s needs merge", - finfo->fullname); - error (1, 0, "\ -You probably want to avoid -m 'COPY' wrappers"); -#endif - } - else - retval = merge_file (finfo, vers); + retval = merge_file (finfo, vers); } break; case T_MODIFIED: /* locally modified */ @@ -622,7 +594,7 @@ You probably want to avoid -m 'COPY' wrappers"); if (!retcode) { - (void) write_letter (finfo->file, 'C', finfo->update_dir); + write_letter (finfo, 'C'); retval = 1; } else @@ -634,7 +606,10 @@ You probably want to avoid -m 'COPY' wrappers"); } } if (!retval) - retval = write_letter (finfo->file, 'M', finfo->update_dir); + { + write_letter (finfo, 'M'); + retval = 0; + } break; #ifdef SERVER_SUPPORT case T_PATCH: /* needs patch */ @@ -658,10 +633,9 @@ You probably want to avoid -m 'COPY' wrappers"); break; } } - /* Fall through. */ /* If we're not running as a server, just check the - file out. It's simpler and faster than starting up - two new processes (diff and patch). */ + file out. It's simpler and faster than producing + and applying patches. */ /* Fall through. */ #endif case T_CHECKOUT: /* needs checkout */ @@ -674,10 +648,12 @@ You probably want to avoid -m 'COPY' wrappers"); #endif break; case T_ADDED: /* added but not committed */ - retval = write_letter (finfo->file, 'A', finfo->update_dir); + write_letter (finfo, 'A'); + retval = 0; break; case T_REMOVED: /* removed but not committed */ - retval = write_letter (finfo->file, 'R', finfo->update_dir); + write_letter (finfo, 'R'); + retval = 0; break; case T_REMOVE_ENTRY: /* needs to be un-registered */ retval = scratch_file (finfo); @@ -727,7 +703,23 @@ update_ignproc (file, dir) char *file; char *dir; { - (void) write_letter (file, '?', dir); + struct file_info finfo; + + memset (&finfo, 0, sizeof (finfo)); + finfo.file = file; + finfo.update_dir = dir; + if (dir[0] == '\0') + finfo.fullname = xstrdup (file); + else + { + finfo.fullname = xmalloc (strlen (file) + strlen (dir) + 10); + strcpy (finfo.fullname, dir); + strcat (finfo.fullname, "/"); + strcat (finfo.fullname, file); + } + + write_letter (&finfo, '?'); + free (finfo.fullname); } /* ARGSUSED */ @@ -808,7 +800,7 @@ update_dirent_proc (callerdat, dir, repository, update_dir, entries) if (noexec) { /* ignore the missing dir if -n is specified */ - error (0, 0, "New directory `%s' -- ignored", dir); + error (0, 0, "New directory `%s' -- ignored", update_dir); return (R_SKIP_ALL); } else @@ -818,6 +810,7 @@ update_dirent_proc (callerdat, dir, repository, update_dir, entries) Create_Admin (dir, update_dir, repository, tag, date, /* This is a guess. We will rewrite it later via WriteTag. */ + 0, 0); rewrite_tag = 1; nonbranch = 0; @@ -920,7 +913,8 @@ update_dirleave_proc (callerdat, dir, err, update_dir, entries) { if ((cp = strrchr (line, '\n')) != NULL) *cp = '\0'; - run_setup ("%s %s", line, repository); + run_setup (line); + run_arg (repository); cvs_output (program_name, 0); cvs_output (" ", 1); cvs_output (command_name, 0); @@ -1080,6 +1074,9 @@ checkout_file (finfo, vers_ts, adding) int status; int file_is_dead; + /* Solely to suppress a warning from gcc -Wall. */ + backup = NULL; + /* don't screw with backup files if we're going to stdout */ if (!pipeout) { @@ -1093,7 +1090,13 @@ checkout_file (finfo, vers_ts, adding) else /* If -f/-t wrappers are being used to wrap up a directory, then backup might be a directory instead of just a file. */ - (void) unlink_file_dir (backup); + if (unlink_file_dir (backup) < 0) + { + /* Not sure if the existence_error check is needed here. */ + if (!existence_error (errno)) + /* FIXME: should include update_dir in message. */ + error (0, errno, "error removing %s", backup); + } } file_is_dead = RCS_isdead (vers_ts->srcfile, vers_ts->vn_rcs); @@ -1133,7 +1136,7 @@ VERS: ", 0); { Vers_TS *xvers_ts; - if (cvswrite == TRUE + if (cvswrite && !file_is_dead && !fileattr_get (finfo->file, "_watched")) xchmod (finfo->file, 1); @@ -1155,13 +1158,11 @@ VERS: ", 0); } /* set the time from the RCS file iff it was unknown before */ - if (vers_ts->vn_user == NULL || - strncmp (vers_ts->ts_rcs, "Initial", 7) == 0) - { - set_time = 1; - } - else - set_time = 0; + set_time = + (!noexec + && (vers_ts->vn_user == NULL || + strncmp (vers_ts->ts_rcs, "Initial", 7) == 0) + && !file_is_dead); wrap_fromcvs_process_file (finfo->file); @@ -1222,7 +1223,7 @@ VERS: ", 0); if (!really_quiet && !file_is_dead) { - write_letter (finfo->file, 'U', finfo->update_dir); + write_letter (finfo, 'U'); } } } @@ -1243,7 +1244,13 @@ VERS: ", 0); { /* If -f/-t wrappers are being used to wrap up a directory, then backup might be a directory instead of just a file. */ - (void) unlink_file_dir (backup); + if (unlink_file_dir (backup) < 0) + { + /* Not sure if the existence_error check is needed here. */ + if (!existence_error (errno)) + /* FIXME: should include update_dir in message. */ + error (0, errno, "error removing %s", backup); + } free (backup); } @@ -1306,6 +1313,27 @@ patch_file (finfo, vers_ts, docheckout, file_info, checksum) return 0; } + /* First check that the first revision exists. If it has been nuked + by cvs admin -o, then just fall back to checking out entire + revisions. In some sense maybe we don't have to do this; after + all cvs.texinfo says "Make sure that no-one has checked out a + copy of the revision you outdate" but then again, that advice + doesn't really make complete sense, because "cvs admin" operates + on a working directory and so _someone_ will almost always have + _some_ revision checked out. */ + { + char *rev; + + rev = RCS_gettag (finfo->rcs, vers_ts->vn_user, 1, NULL); + if (rev == NULL) + { + *docheckout = 1; + return 0; + } + else + free (rev); + } + backup = xmalloc (strlen (finfo->file) + sizeof (CVSADM) + sizeof (CVSPREFIX) @@ -1382,7 +1410,7 @@ patch_file (finfo, vers_ts, docheckout, file_info, checksum) retcode = 0; if (! fail) { - const char *diff_options; + char *diff_options; /* FIXME: It might be better to come up with a diff library which can be shared with the diffutils. */ @@ -1400,21 +1428,22 @@ patch_file (finfo, vers_ts, docheckout, file_info, checksum) } else { - /* FIXME: We should use -a if diff supports it. We should - probably just copy over most or all of the diff - handling in the RCS configure script. */ - /* IMHO, we shouldn't copy over anything which even - vaguely resembles the RCS configure script. That kind of - thing tends to be ugly, slow, and fragile. It also is a - a support headache for CVS to behave differently in subtle - ways based on whether it was installed correctly. Instead we - should come up with a diff library. -kingdon, Apr 1997. */ + /* Now that diff is librarified, we could be passing -a if + we wanted to. However, it is unclear to me whether we + would want to. Does diff -a, in any significant + percentage of cases, produce patches which are smaller + than the files it is patching? I guess maybe text + files with character sets which diff regards as + 'binary'. Conversely, do they tend to be much larger + in the bad cases? This needs some more + thought/investigation, I suspect. */ + diff_options = "-n"; } - run_setup ("%s %s %s %s", DIFF, diff_options, file1, file2); + retcode = diff_exec (file1, file2, diff_options, finfo->file); /* A retcode of 0 means no differences. 1 means some differences. */ - if ((retcode = run_exec (RUN_TTY, finfo->file, RUN_TTY, RUN_NORMAL)) != 0 + if (retcode != 0 && retcode != 1) { fail = 1; @@ -1434,7 +1463,7 @@ patch_file (finfo, vers_ts, docheckout, file_info, checksum) file_info->st_mode & ~(S_IWRITE | S_IWGRP | S_IWOTH)) < 0) error (0, errno, "cannot change mode of file %s", finfo->file); - if (cvswrite == TRUE + if (cvswrite && !fileattr_get (finfo->file, "_watched")) xchmod (finfo->file, 1); @@ -1482,7 +1511,7 @@ patch_file (finfo, vers_ts, docheckout, file_info, checksum) if (!really_quiet) { - write_letter (finfo->file, 'P', finfo->update_dir); + write_letter (finfo, 'P'); } } else @@ -1528,7 +1557,7 @@ patch_file_write (callerdat, buffer, len) data->final_nl = (buffer[len - 1] == '\n'); if (data->compute_checksum) - MD5Update (&data->context, buffer, len); + MD5Update (&data->context, (unsigned char *) buffer, len); } #endif /* SERVER_SUPPORT */ @@ -1537,27 +1566,45 @@ patch_file_write (callerdat, buffer, len) * Several of the types we process only print a bit of information consisting * of a single letter and the name. */ -static int -write_letter (file, letter, update_dir) - char *file; +static void +write_letter (finfo, letter) + struct file_info *finfo; int letter; - char *update_dir; { if (!really_quiet) { - char buf[2]; + char *tag = NULL; + /* Big enough for "+updated" or any of its ilk. */ + char buf[80]; + + switch (letter) + { + case 'U': + tag = "updated"; + break; + default: + /* We don't yet support tagged output except for "U". */ + break; + } + + if (tag != NULL) + { + sprintf (buf, "+%s", tag); + cvs_output_tagged (buf, NULL); + } buf[0] = letter; buf[1] = ' '; - cvs_output (buf, 2); - if (update_dir[0]) + buf[2] = '\0'; + cvs_output_tagged ("text", buf); + cvs_output_tagged ("fname", finfo->fullname); + cvs_output_tagged ("newline", NULL); + if (tag != NULL) { - cvs_output (update_dir, 0); - cvs_output ("/", 1); + sprintf (buf, "-%s", tag); + cvs_output_tagged (buf, NULL); } - cvs_output (file, 0); - cvs_output ("\n", 1); } - return (0); + return; } /* @@ -1590,7 +1637,8 @@ merge_file (finfo, vers) copy_file (finfo->file, backup); xchmod (finfo->file, 1); - if (strcmp (vers->options, "-kb") == 0) + if (strcmp (vers->options, "-kb") == 0 + || wrap_merge_is_copy (finfo->file)) { /* For binary files, a merge is always a conflict. We give the user the two files, and let them resolve it. It is possible @@ -1609,11 +1657,15 @@ merge_file (finfo, vers) (struct stat *) NULL, (unsigned char *) NULL); } #endif - error (0, 0, "binary file needs merge"); + /* Is there a better term than "nonmergeable file"? What we + really mean is, not something that CVS cannot or does not + want to merge (there might be an external manual or + automatic merge process). */ + error (0, 0, "nonmergeable file needs merge"); error (0, 0, "revision %s from repository is now in %s", vers->vn_rcs, finfo->fullname); error (0, 0, "file from working directory is now in %s", backup); - write_letter (finfo->file, 'C', finfo->update_dir); + write_letter (finfo, 'C'); history_write ('C', finfo->update_dir, vers->vn_rcs, finfo->file, finfo->repository); @@ -1621,7 +1673,7 @@ merge_file (finfo, vers) goto out; } - status = RCS_merge(vers->srcfile->path, + status = RCS_merge(finfo->rcs, vers->srcfile->path, finfo->file, vers->options, vers->vn_user, vers->vn_rcs); if (status != 0 && status != 1) { @@ -1684,7 +1736,7 @@ merge_file (finfo, vers) if (!noexec) error (0, 0, "conflicts found in %s", finfo->fullname); - write_letter (finfo->file, 'C', finfo->update_dir); + write_letter (finfo, 'C'); history_write ('C', finfo->update_dir, vers->vn_rcs, finfo->file, finfo->repository); @@ -1696,7 +1748,7 @@ merge_file (finfo, vers) } else { - write_letter (finfo->file, 'M', finfo->update_dir); + write_letter (finfo, 'M'); history_write ('G', finfo->update_dir, vers->vn_rcs, finfo->file, finfo->repository); } @@ -1731,14 +1783,6 @@ join_file (finfo, vers) jdate1 = date_rev1; jdate2 = date_rev2; - if (wrap_merge_is_copy (finfo->file)) - { - error (0, 0, - "Cannot merge %s because it is a merge-by-copy file.", - finfo->fullname); - return; - } - /* Determine if we need to do anything at all. */ if (vers->srcfile == NULL || vers->srcfile->path == NULL) @@ -2034,7 +2078,7 @@ join_file (finfo, vers) "failed to check out %s file", finfo->fullname); } #endif - + /* * The users currently modified file is moved to a backup file name * ".#filename.version", so that it will stay around for a few days @@ -2053,14 +2097,96 @@ join_file (finfo, vers) xchmod (finfo->file, 1); options = vers->options; -#ifdef HAVE_RCS5 #if 0 if (*options == '\0') options = "-kk"; /* to ignore keyword expansions */ #endif -#endif - status = RCS_merge (vers->srcfile->path, options, rev1, rev2); + /* If the source of the merge is the same as the working file + revision, then we can just RCS_checkout the target (no merging + as such). In the text file case, this is probably quite + similar to the RCS_merge, but in the binary file case, + RCS_merge gives all kinds of trouble. */ + if (vers->vn_user != NULL + && strcmp (rev1, vers->vn_user) == 0 + /* See comments above about how No_Difference has already been + called. */ + && vers->ts_user != NULL + && strcmp (vers->ts_user, vers->ts_rcs) == 0 + + /* This is because of the worry below about $Name. If that + isn't a problem, I suspect this code probably works for + text files too. */ + && (strcmp (options, "-kb") == 0 + || wrap_merge_is_copy (finfo->file))) + { + /* FIXME: what about nametag? What does RCS_merge do with + $Name? */ + if (RCS_checkout (finfo->rcs, finfo->file, rev2, NULL, options, + RUN_TTY, (RCSCHECKOUTPROC)0, NULL) != 0) + status = 2; + else + status = 0; + + /* OK, this is really stupid. RCS_checkout carefully removes + write permissions, and we carefully put them back. But + until someone gets around to fixing it, that seems like the + easiest way to get what would seem to be the right mode. + I don't check CVSWRITE or _watched; I haven't thought about + that in great detail, but it seems like a watched file should + be checked out (writable) after a merge. */ + xchmod (finfo->file, 1); + + /* Traditionally, the text file case prints a whole bunch of + scary looking and verbose output which fails to tell the user + what is really going on (it gives them rev1 and rev2 but doesn't + indicate in any way that rev1 == vn_user). I think just a + simple "U foo" is good here; it seems analogous to the case in + which the file was added on the branch in terms of what to + print. */ + write_letter (finfo, 'U'); + } + else if (strcmp (options, "-kb") == 0 + || wrap_merge_is_copy (finfo->file)) + { + /* We are dealing with binary files, but real merging would + need to take place. This is a conflict. We give the user + the two files, and let them resolve it. It is possible + that we should require a "touch foo" or similar step before + we allow a checkin. */ + if (RCS_checkout (finfo->rcs, finfo->file, rev2, NULL, options, + RUN_TTY, (RCSCHECKOUTPROC)0, NULL) != 0) + status = 2; + else + status = 0; + + /* OK, this is really stupid. RCS_checkout carefully removes + write permissions, and we carefully put them back. But + until someone gets around to fixing it, that seems like the + easiest way to get what would seem to be the right mode. + I don't check CVSWRITE or _watched; I haven't thought about + that in great detail, but it seems like a watched file should + be checked out (writable) after a merge. */ + xchmod (finfo->file, 1); + + /* Hmm. We don't give them REV1 anywhere. I guess most people + probably don't have a 3-way merge tool for the file type in + question, and might just get confused if we tried to either + provide them with a copy of the file from REV1, or even just + told them what REV1 is so they can get it themself, but it + might be worth thinking about. */ + /* See comment in merge_file about the "nonmergeable file" + terminology. */ + error (0, 0, "nonmergeable file needs merge"); + error (0, 0, "revision %s from repository is now in %s", + rev2, finfo->fullname); + error (0, 0, "file from working directory is now in %s", backup); + write_letter (finfo, 'C'); + } + else + status = RCS_merge (finfo->rcs, vers->srcfile->path, finfo->file, + options, rev1, rev2); + if (status != 0 && status != 1) { error (0, status == -1 ? errno : 0, diff --git a/contrib/cvs/src/vers_ts.c b/contrib/cvs/src/vers_ts.c index 613e52e..bae3a43 100644 --- a/contrib/cvs/src/vers_ts.c +++ b/contrib/cvs/src/vers_ts.c @@ -3,7 +3,7 @@ * Copyright (c) 1989-1992, Brian Berliner * * You may distribute under the terms of the GNU General Public License as - * specified in the README file that comes with the CVS 1.4 kit. + * specified in the README file that comes with the CVS source distribution. */ #include "cvs.h" @@ -12,14 +12,16 @@ static void time_stamp_server PROTO((char *, Vers_TS *, Entnode *)); #endif -/* - * Fill in and return a Vers_TS structure "user" is the name of the local - * file; entries is the entries file - preparsed for our pleasure. rcs is - * the current source control file - preparsed for our pleasure. - */ +/* Fill in and return a Vers_TS structure for the file FINFO. TAG and + DATE are from the command line. */ + Vers_TS * Version_TS (finfo, options, tag, date, force_tag_match, set_time) struct file_info *finfo; + + /* Keyword expansion options, I think generally from the command + line. Can be either NULL or "" to indicate none are specified + here. */ char *options; char *tag; char *date; @@ -57,6 +59,18 @@ Version_TS (finfo, options, tag, date, force_tag_match, set_time) { entdata = (Entnode *) p->data; + if (entdata->type == ENT_SUBDIR) + { + /* According to cvs.texinfo, the various fields in the Entries + file for a directory (other than the name) do not have a + defined meaning. We need to pass them along without getting + confused based on what is in them. Therefore we make sure + not to set vn_user and the like from Entries, add.c and + perhaps other code will expect these fields to be NULL for + a directory. */ + vers_ts->entdata = entdata; + } + else #ifdef SERVER_SUPPORT /* An entries line with "D" in the timestamp indicates that the client sent Is-modified without sending Entry. So we want to @@ -79,22 +93,25 @@ Version_TS (finfo, options, tag, date, force_tag_match, set_time) if (!(sdtp && sdtp->aflag)) vers_ts->date = xstrdup (entdata->date); } - if (!options || (options && *options == '\0')) - { - if (!(sdtp && sdtp->aflag)) - vers_ts->options = xstrdup (entdata->options); - } vers_ts->entdata = entdata; } + /* Even if we don't have an "entries line" as such + (vers_ts->entdata), we want to pick up options which could + have been from a Kopt protocol request. */ + if (!options || (options && *options == '\0')) + { + if (!(sdtp && sdtp->aflag)) + vers_ts->options = xstrdup (entdata->options); + } } /* * -k options specified on the command line override (and overwrite) * options stored in the entries file */ - if (options) + if (options && *options != '\0') vers_ts->options = xstrdup (options); - else if (!vers_ts->options) + else if (!vers_ts->options || *vers_ts->options == '\0') { if (finfo->rcs != NULL) { @@ -175,7 +192,7 @@ Version_TS (finfo, options, tag, date, force_tag_match, set_time) * get the Date the revision was checked in. If "user" exists, set * its mtime. */ - if (set_time) + if (set_time && vers_ts->vn_rcs != NULL) { #ifdef SERVER_SUPPORT if (server_active) @@ -186,15 +203,18 @@ Version_TS (finfo, options, tag, date, force_tag_match, set_time) struct utimbuf t; memset (&t, 0, sizeof (t)); - if (vers_ts->vn_rcs) + t.modtime = + RCS_getrevtime (rcsdata, vers_ts->vn_rcs, 0, 0); + if (t.modtime != (time_t) -1) { - t.modtime = - RCS_getrevtime (rcsdata, vers_ts->vn_rcs, 0, 0); - if (t.modtime != (time_t) -1) - { - t.actime = t.modtime; - (void) utime (finfo->file, &t); - } + t.actime = t.modtime; + + /* This used to need to ignore existence_errors + (for cases like where update.c now clears + set_time if noexec, but didn't used to). I + think maybe now it doesn't (server_modtime does + not like those kinds of cases). */ + (void) utime (finfo->file, &t); } } } diff --git a/contrib/cvs/src/version.c b/contrib/cvs/src/version.c index c442179..19a9973 100644 --- a/contrib/cvs/src/version.c +++ b/contrib/cvs/src/version.c @@ -12,7 +12,7 @@ #include "cvs.h" -char *version_string = "\nConcurrent Versions System (CVS) 1.9.10"; +char *version_string = "\nConcurrent Versions System (CVS) 1.9.23"; #ifdef CLIENT_SUPPORT #ifdef SERVER_SUPPORT diff --git a/contrib/cvs/src/watch.c b/contrib/cvs/src/watch.c index 6cec157..d9ba1d7 100644 --- a/contrib/cvs/src/watch.c +++ b/contrib/cvs/src/watch.c @@ -24,6 +24,7 @@ const char *const watch_usage[] = "-R (on/off/add/remove): Process directories recursively\n", "-a (add/remove): Specify what actions, one of\n", " edit,unedit,commit,all,none\n", + "(Specify the --help global option for a list of other help options)\n", NULL }; @@ -417,6 +418,7 @@ static const char *const watchers_usage[] = "Usage: %s %s [-lR] [files...]\n", "\t-l\tProcess this directory only (not recursive).\n", "\t-R\tProcess directories recursively.\n", + "(Specify the --help global option for a list of other help options)\n", NULL }; diff --git a/contrib/cvs/src/wrapper.c b/contrib/cvs/src/wrapper.c index 825cdcd..dc8342a 100644 --- a/contrib/cvs/src/wrapper.c +++ b/contrib/cvs/src/wrapper.c @@ -57,12 +57,17 @@ static int wrap_size=0; static int wrap_count=0; static int wrap_tempcount=0; -/* FIXME: wrap_saved_count is never set to any non-zero value. - wrap_name_has and wrap_matching_entry should be using - wrap_tempcount instead. I believe the consequence of this is that - .cvswrappers files are ignored (that was my own experience when I - tried to use one). If this bug is fixed, would be nice to write a - sanity.sh testcase for .cvswrappers files. */ +/* FIXME: the relationship between wrap_count, wrap_tempcount, + * wrap_saved_count, and wrap_saved_tempcount is not entirely clear; + * it is certainly suspicious that wrap_saved_count is never set to a + * value other than zero! If the variable isn't being used, it should + * be removed. And in general, we should describe how temporary + * vs. permanent wrappers are implemented, and then make sure the + * implementation is actually doing that. + * + * Right now things seem to be working, but that's no guarantee there + * isn't a bug lurking somewhere in the murk. + */ static int wrap_saved_count=0; @@ -79,7 +84,7 @@ void wrap_restore_saved PROTO((void)); void wrap_setup() { - struct passwd *pw; + char *homedir; #ifdef CLIENT_SUPPORT if (!client_active) @@ -102,14 +107,14 @@ void wrap_setup() } /* Then add entries found in home dir, (if user has one) and file - exists. (FIXME: I think this probably should be using - get_homedir, i.e. $HOME). */ - if ((pw = (struct passwd *) getpwuid (getuid ())) && pw->pw_dir) + exists. */ + homedir = get_homedir (); + if (homedir != NULL) { char *file; - file = xmalloc (strlen (pw->pw_dir) + sizeof (CVSDOTWRAPPER) + 10); - (void) sprintf (file, "%s/%s", pw->pw_dir, CVSDOTWRAPPER); + file = xmalloc (strlen (homedir) + sizeof (CVSDOTWRAPPER) + 10); + (void) sprintf (file, "%s/%s", homedir, CVSDOTWRAPPER); if (isfile (file)) { wrap_add_file (file, 0); @@ -383,7 +388,7 @@ wrap_name_has (name,has) const char *name; WrapMergeHas has; { - int x,count=wrap_count+wrap_saved_count; + int x,count=wrap_count+wrap_tempcount; char *temp; for(x=0;x<count;++x) @@ -415,7 +420,7 @@ static WrapperEntry * wrap_matching_entry (name) const char *name; { - int x,count=wrap_count+wrap_saved_count; + int x,count=wrap_count+wrap_tempcount; for(x=0;x<count;++x) if (CVS_FNMATCH (wrap_list[x]->wildCard, name, 0) == 0) @@ -456,6 +461,7 @@ wrap_tocvs_process_file(fileName) { WrapperEntry *e=wrap_matching_entry(fileName); static char *buf = NULL; + char *args; if(e==NULL || e->tocvsFilter==NULL) return NULL; @@ -464,8 +470,16 @@ wrap_tocvs_process_file(fileName) free (buf); buf = cvs_temp_name (); - run_setup(e->tocvsFilter,fileName,buf); + args = xmalloc (strlen (e->tocvsFilter) + + strlen (fileName) + + strlen (buf)); + /* FIXME: sprintf will blow up if the format string contains items other + than %s, or contains too many %s's. We should instead be parsing + e->tocvsFilter ourselves and giving a real error. */ + sprintf (args, e->tocvsFilter, fileName, buf); + run_setup (args); run_exec(RUN_TTY, RUN_TTY, RUN_TTY, RUN_NORMAL|RUN_REALLY ); + free (args); return buf; } @@ -485,12 +499,20 @@ void wrap_fromcvs_process_file(fileName) const char *fileName; { + char *args; WrapperEntry *e=wrap_matching_entry(fileName); if(e==NULL || e->fromcvsFilter==NULL) return; - run_setup(e->fromcvsFilter,fileName); + args = xmalloc (strlen (e->fromcvsFilter) + + strlen (fileName)); + /* FIXME: sprintf will blow up if the format string contains items other + than %s, or contains too many %s's. We should instead be parsing + e->fromcvsFilter ourselves and giving a real error. */ + sprintf (args, e->fromcvsFilter, fileName); + run_setup (args); run_exec(RUN_TTY, RUN_TTY, RUN_TTY, RUN_NORMAL ); + free (args); return; } diff --git a/contrib/cvs/src/zlib.c b/contrib/cvs/src/zlib.c index 02ad70c..ca50130 100644 --- a/contrib/cvs/src/zlib.c +++ b/contrib/cvs/src/zlib.c @@ -426,4 +426,197 @@ compress_buffer_shutdown_output (closure) return buf_shutdown (cb->buf); } + + +/* Here is our librarified gzip implementation. It is very minimal + but attempts to be RFC1952 compliant. */ +/* Note that currently only the client uses the gzip library. If we + make the server use it too (which should be straightforward), then + filter_stream_through_program, filter_through_gzip, and + filter_through_gunzip can go away. */ + +/* BUF should contain SIZE bytes of gzipped data (RFC1952/RFC1951). + We are to uncompress the data and write the result to the file + descriptor FD. If something goes wrong, give an error message + mentioning FULLNAME as the name of the file for FD (and make it a + fatal error if we can't recover from it). */ + +void +gunzip_and_write (fd, fullname, buf, size) + int fd; + char *fullname; + unsigned char *buf; + size_t size; +{ + size_t pos; + z_stream zstr; + int zstatus; + unsigned char outbuf[32768]; + unsigned long crc; + + if (buf[0] != 31 || buf[1] != 139) + error (1, 0, "gzipped data does not start with gzip identification"); + if (buf[2] != 8) + error (1, 0, "only the deflate compression method is supported"); + + /* Skip over the fixed header, and then skip any of the variable-length + fields. */ + pos = 10; + if (buf[3] & 4) + pos += buf[pos] + (buf[pos + 1] << 8) + 2; + if (buf[3] & 8) + pos += strlen (buf + pos) + 1; + if (buf[3] & 16) + pos += strlen (buf + pos) + 1; + if (buf[3] & 2) + pos += 2; + + memset (&zstr, 0, sizeof zstr); + /* Passing a negative argument tells zlib not to look for a zlib + (RFC1950) header. This is an undocumented feature; I suppose if + we wanted to be anal we could synthesize a header instead, + but why bother? */ + zstatus = inflateInit2 (&zstr, -15); + + if (zstatus != Z_OK) + compress_error (1, zstatus, &zstr, fullname); + + /* I don't see why we should have to include the 8 byte trailer in + avail_in. But I see that zlib/gzio.c does, and it seemed to fix + a fairly rare bug in which we'd get a Z_BUF_ERROR for no obvious + reason. */ + zstr.avail_in = size - pos; + zstr.next_in = buf + pos; + + crc = crc32 (0, NULL, 0); + + do + { + zstr.avail_out = sizeof (outbuf); + zstr.next_out = outbuf; + zstatus = inflate (&zstr, Z_NO_FLUSH); + if (zstatus != Z_STREAM_END && zstatus != Z_OK) + compress_error (1, zstatus, &zstr, fullname); + if (write (fd, outbuf, sizeof (outbuf) - zstr.avail_out) < 0) + error (1, errno, "writing decompressed file %s", fullname); + crc = crc32 (crc, outbuf, sizeof (outbuf) - zstr.avail_out); + } while (zstatus != Z_STREAM_END); + zstatus = inflateEnd (&zstr); + if (zstatus != Z_OK) + compress_error (0, zstatus, &zstr, fullname); + + if (crc != (buf[zstr.total_in + 10] + + (buf[zstr.total_in + 11] << 8) + + (buf[zstr.total_in + 12] << 16) + + (buf[zstr.total_in + 13] << 24))) + error (1, 0, "CRC error uncompressing %s", fullname); + + if (zstr.total_out != (buf[zstr.total_in + 14] + + (buf[zstr.total_in + 15] << 8) + + (buf[zstr.total_in + 16] << 16) + + (buf[zstr.total_in + 17] << 24))) + error (1, 0, "invalid length uncompressing %s", fullname); +} + +/* Read all of FD and put the gzipped data (RFC1952/RFC1951) into *BUF, + replacing previous contents of *BUF. *BUF is malloc'd and *SIZE is + its allocated size. Put the actual number of bytes of data in + *LEN. If something goes wrong, give an error message mentioning + FULLNAME as the name of the file for FD (and make it a fatal error + if we can't recover from it). LEVEL is the compression level (1-9). */ + +void +read_and_gzip (fd, fullname, buf, size, len, level) + int fd; + char *fullname; + unsigned char **buf; + size_t *size; + size_t *len; + int level; +{ + z_stream zstr; + int zstatus; + unsigned char inbuf[8192]; + int nread; + unsigned long crc; + + if (*size < 1024) + { + *size = 1024; + *buf = (unsigned char *) xrealloc (*buf, *size); + } + (*buf)[0] = 31; + (*buf)[1] = 139; + (*buf)[2] = 8; + (*buf)[3] = 0; + (*buf)[4] = (*buf)[5] = (*buf)[6] = (*buf)[7] = 0; + /* Could set this based on level, but why bother? */ + (*buf)[8] = 0; + (*buf)[9] = 255; + + memset (&zstr, 0, sizeof zstr); + zstatus = deflateInit2 (&zstr, level, Z_DEFLATED, -15, 8, + Z_DEFAULT_STRATEGY); + crc = crc32 (0, NULL, 0); + if (zstatus != Z_OK) + compress_error (1, zstatus, &zstr, fullname); + zstr.avail_out = *size; + zstr.next_out = *buf + 10; + + while (1) + { + int finish = 0; + + nread = read (fd, inbuf, sizeof inbuf); + if (nread < 0) + error (1, errno, "cannot read %s", fullname); + else if (nread == 0) + /* End of file. */ + finish = 1; + crc = crc32 (crc, inbuf, nread); + zstr.next_in = inbuf; + zstr.avail_in = nread; + + do + { + size_t offset; + + /* I don't see this documented anywhere, but deflate seems + to tend to dump core sometimes if we pass it Z_FINISH and + a small (e.g. 2147 byte) avail_out. So we insist on at + least 4096 bytes (that is what zlib/gzio.c uses). */ + + if (zstr.avail_out < 4096) + { + offset = zstr.next_out - *buf; + *size *= 2; + *buf = xrealloc (*buf, *size); + zstr.next_out = *buf + offset; + zstr.avail_out = *size - offset; + } + + zstatus = deflate (&zstr, finish ? Z_FINISH : 0); + if (zstatus == Z_STREAM_END) + goto done; + else if (zstatus != Z_OK) + compress_error (0, zstatus, &zstr, fullname); + } while (zstr.avail_out == 0); + } + done: + *(*buf + zstr.total_out + 10) = crc & 0xff; + *(*buf + zstr.total_out + 11) = (crc >> 8) & 0xff; + *(*buf + zstr.total_out + 12) = (crc >> 16) & 0xff; + *(*buf + zstr.total_out + 13) = (crc >> 24) & 0xff; + + *(*buf + zstr.total_out + 14) = zstr.total_in & 0xff; + *(*buf + zstr.total_out + 15) = (zstr.total_in >> 8) & 0xff; + *(*buf + zstr.total_out + 16) = (zstr.total_in >> 16) & 0xff; + *(*buf + zstr.total_out + 17) = (zstr.total_in >> 24) & 0xff; + + *len = zstr.total_out + 18; + + zstatus = deflateEnd (&zstr); + if (zstatus != Z_OK) + compress_error (0, zstatus, &zstr, fullname); +} #endif /* defined (SERVER_SUPPORT) || defined (CLIENT_SUPPORT) */ diff --git a/contrib/cvs/tools/pcl-cvs/ChangeLog b/contrib/cvs/tools/pcl-cvs/ChangeLog index a9e6f47..7a4b2c3 100644 --- a/contrib/cvs/tools/pcl-cvs/ChangeLog +++ b/contrib/cvs/tools/pcl-cvs/ChangeLog @@ -1,3 +1,8 @@ +1998-01-03 Jim Blandy <jimb@totoro.red-bean.com> + + * (cvs-changelog-ours-p): Recognize Emacs 20-style ChangeLog + entries. + Mon Oct 14 19:19:17 1996 Jim Blandy <jimb@totoro.cyclic.com> * pcl-cvs.el (cvs-parse-stderr): Ignore messages about patch hunks diff --git a/contrib/cvs/tools/pcl-cvs/INSTALL b/contrib/cvs/tools/pcl-cvs/INSTALL index c4cf8dc..56ff80d 100644 --- a/contrib/cvs/tools/pcl-cvs/INSTALL +++ b/contrib/cvs/tools/pcl-cvs/INSTALL @@ -91,4 +91,4 @@ from `pcl-cvs.texinfo'. -- -#ident "@(#)cvs/contrib/pcl-cvs:$Name: $Id: INSTALL,v 1.2 1996/04/15 06:33:16 kfogel Exp $" +#ident "@(#)cvs/contrib/pcl-cvs:$Name: $Id$" diff --git a/contrib/cvs/tools/pcl-cvs/ToDo b/contrib/cvs/tools/pcl-cvs/ToDo index 04eb557..8e317f8 100644 --- a/contrib/cvs/tools/pcl-cvs/ToDo +++ b/contrib/cvs/tools/pcl-cvs/ToDo @@ -41,4 +41,4 @@ help generate full releases) files -- -#ident "@(#)cvs/contrib/pcl-cvs:$Name: $Id$" +#ident "@(#)cvs/contrib/pcl-cvs:$Name: $Id: ToDo,v 1.1 1996/04/14 15:17:57 kfogel Exp $" diff --git a/contrib/cvs/tools/pcl-cvs/pcl-cvs.el b/contrib/cvs/tools/pcl-cvs/pcl-cvs.el index 8a13122..1dd7cae 100644 --- a/contrib/cvs/tools/pcl-cvs/pcl-cvs.el +++ b/contrib/cvs/tools/pcl-cvs/pcl-cvs.el @@ -1,7 +1,7 @@ ;;; ;;;#ident "@(#)OrigId: pcl-cvs.el,v 1.93 1993/05/31 22:44:00 ceder Exp " ;;; -;;;#ident "@(#)cvs/contrib/pcl-cvs:$Name: $:$Id: pcl-cvs.el,v 1.6 1996/11/06 17:29:31 jimb Exp $" +;;;#ident "@(#)cvs/contrib/pcl-cvs:$Name: $:$Id: pcl-cvs.el,v 1.7 1998/01/04 14:24:13 kingdon Exp $" ;;; ;;; pcl-cvs.el -- A Front-end to CVS 1.3 or later. ;;; Release 1.05-CVS-$Name: $. @@ -1014,7 +1014,7 @@ ERR-BUF should be 'STDOUT or 'STDERR." (insert "Pcl-cvs Version: " "@(#)OrigId: pcl-cvs.el,v 1.93 1993/05/31 22:44:00 ceder Exp\n") (insert "CVS Version: " - "@(#)cvs/contrib/pcl-cvs:$Name: $:$Id: pcl-cvs.el,v 1.6 1996/11/06 17:29:31 jimb Exp $\n\n") + "@(#)cvs/contrib/pcl-cvs:$Name: $:$Id: pcl-cvs.el,v 1.7 1998/01/04 14:24:13 kingdon Exp $\n\n") (insert (format "--- Contents of stdout buffer (%d chars) ---\n" (length stdout))) (insert stdout) @@ -3288,7 +3288,13 @@ for more details." "See if ChangeLog entry at point is for the current user, today. Return non-nil iff it is." ;; Code adapted from add-change-log-entry. - (looking-at (concat (regexp-quote (substring (current-time-string) + (or (looking-at + (regexp-quote (format "%s %s <%s>" + (format-time-string "%Y-%m-%d") + add-log-full-name + add-log-mailing-address))) + (looking-at + (concat (regexp-quote (substring (current-time-string) 0 10)) ".* " (regexp-quote (substring (current-time-string) -4)) @@ -3301,7 +3307,7 @@ Return non-nil iff it is." (regexp-quote (if (and (boundp 'add-log-mailing-address) add-log-mailing-address) add-log-mailing-address - user-mail-address))))) + user-mail-address)))))) (defun cvs-relative-path (base child) "Return a directory path relative to BASE for CHILD. |
