diff options
| author | peter <peter@FreeBSD.org> | 1999-03-18 09:21:42 +0000 |
|---|---|---|
| committer | peter <peter@FreeBSD.org> | 1999-03-18 09:21:42 +0000 |
| commit | 308b60f66831aa65a459a7b347ea6ca14b6e4799 (patch) | |
| tree | 1b2cd3bad90a2dd8ccb449f73ddfb9e295c0737d /contrib/cvs/doc | |
| parent | 0c111e2b51cac7eead56494b30c5977e4ec9a8ea (diff) | |
| download | FreeBSD-src-308b60f66831aa65a459a7b347ea6ca14b6e4799.zip FreeBSD-src-308b60f66831aa65a459a7b347ea6ca14b6e4799.tar.gz | |
Import cvs-1.10 onto vendor branch. Merge to follow shortly.
Obtained from: cyclic.com
Diffstat (limited to 'contrib/cvs/doc')
| -rw-r--r-- | contrib/cvs/doc/ChangeLog | 135 | ||||
| -rw-r--r-- | contrib/cvs/doc/RCSFILES | 65 | ||||
| -rw-r--r-- | contrib/cvs/doc/cvs.texinfo | 977 | ||||
| -rw-r--r-- | contrib/cvs/doc/cvsclient.texi | 47 |
4 files changed, 563 insertions, 661 deletions
diff --git a/contrib/cvs/doc/ChangeLog b/contrib/cvs/doc/ChangeLog index 9a01d1b..e9e4925 100644 --- a/contrib/cvs/doc/ChangeLog +++ b/contrib/cvs/doc/ChangeLog @@ -1,3 +1,122 @@ +Sun Jul 26 02:42:20 1998 Noel Cragg <noel@swish.red-bean.com> + + * cvs.texinfo (config): TopLevelAdmin variable. + + * cvsclient.texi (Requests): fix typo. + +1998-07-14 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvsclient.texi (Requests): "remove" is like "add" in the sense + that it is the "ci" request which does most of the work. + +1998-06-23 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvs.texinfo (Excluding directories): Fix order of + "!first-dir/sdir" and "first-dir" to match what CVS actually + accepts. Reported by Tim McIntosh of sterling.com. + +1998-06-09 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvs.texinfo (Using keywords): Rewrite to be less specific to + source code in C. The old text was worse than that; it was + specific to certain versions of GCC (not even current GCC's, I + don't think) (reported most recently by Mitchell Perilstein; + if memory serves by others before that). + +1998-06-08 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvs.texinfo (Concurrency): Also mention #cvs.lock. Don't + mention #cvs.tfl; it is quite old (before CVS 1.5). + (Locks, Backing up, Concurrency): Add more index entries. + +1998-06-03 Ian Lance Taylor <ian@cygnus.com> + + * cvs.texinfo (Tracking sources): Clarify that the vendor branch + is only made the head revision when you import a new file, not any + time you import a file. + +1998-05-23 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvs.texinfo (What is CVS?): info-cvs-request is now at gnu.org + and is no longer handled by a human (hallelujah). + +1998-05-12 Jim Meyering <meyering@ascend.com> + + * cvs.texinfo: Add an info dir entry. + Remove trailing white space. + +1998-05-05 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvs.texinfo (Wrappers): Be more explicit that -m 'COPY' has no + effect on binary files. + +1998-05-02 Jim Kingdon <kingdon@harvey.cyclic.com> + + * RCSFILES: Add more discussion of the order of the revisions. + +1998-04-27 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvs.texinfo (loginfo example): Also give example of sending + mail. Use internal variable $USER rather than expecting CVS to + set the environment variable $USER. Change unnecessary 'sed' + invocation to 'cat' (it suffered from the same problem in terms of + internal variables versus environment variables). + + * cvs.texinfo (Error messages): Add "conflict: removed FILE was + modified by second party". + +1998-04-20 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvs.texinfo (Common options): Update comment about meaning of + HEAD in cvs diff. + +1998-04-12 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvsclient.texi (Dates): Also mention log -d. + + * cvs.texinfo (Invoking CVS): No space is allowed between -r or -w + and its argument, for the log command. + +1998-04-11 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvsclient.texi (Dates): New section, explaining the deal with + date formats. + +1998-04-09 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvs.texinfo (Global options, Invoking CVS): Fix typo + ("files files" -> "files"). + (Invoking CVS): Make -q and -Q more concise. + (Invoking CVS): Use @var for metavariables in "diff -r". + +1998-03-17 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvs.texinfo (~/.cvsrc): In example, put "checkout" rather than + "co" into .cvsrc; we just finished explaining that only the former + works! Thanks to Lenny Foner for reporting this. + + * cvs.texinfo (Copying): Remove this node. This basically + restores the status quo prior to 18 Oct 1996 (before then the node + existed but was empty). + (before Top): Adjust copyright notice accordingly. + +1998-03-12 Tim Pierce <twp@skepsis.com> + + * RCSFILES: Updated description of `hardlinks' newphrases. + +1998-03-07 Jim Kingdon <kingdon@harvey.cyclic.com> + + * cvs.texinfo (Tags, Sticky tags, Creating a branch, Accessing + branches): Rename release-0-1 tag to rel-0-1 and likewise for + release-0-1-patches and release-0-4. This fixes an overfull hbox. + (diff options): Reformat table to fix underfull hboxes and such. + +1998-03-07 Tim Pierce <twp@skepsis.com> + + * cvs.texinfo (Editing files, Special Files): Document hardlinks. + Various cleanups to PreservePermissions text. + * RCSFILES: Document PreservePermissions newphrases. + 1998-03-04 Jim Kingdon <kingdon@harvey.cyclic.com> * cvs.texinfo (Special Files): Add notes about client/server CVS @@ -213,13 +332,13 @@ 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> +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. + (Protocol): added some introductory material. Rearranged menu into General Conventions, Protocol specification, and Example etc sections. (File Modes): replaces Modes, for consistency. @@ -418,7 +537,7 @@ Sat Sep 6 11:29:15 1997 Jim Kingdon <kingdon@harvey.cyclic.com> 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 + on http://www.cyclic.com, as it might go away in a future reorganization. * DIFFUTILS-2.7-BUG: Further info from Eggert. @@ -1229,7 +1348,7 @@ Tue Mar 18 15:50:47 1997 Jim Kingdon <kingdon@harvey.cyclic.com> (A sample session): Add comment about how we need an introduction and what might go into one. Also bring in the paragraph from Basic concepts introducing modules, but comment it out. - (Viewing differences): Add comment about + (Viewing differences): Add comment about (Basic concepts): Removed; its content has been farmed out as described above, and as the comment said, it was fundamentally flawed. @@ -1544,7 +1663,7 @@ Thu Nov 14 10:22:58 1996 Jim Kingdon <kingdon@harvey.cyclic.com> chunks, and about atomicity to be focused more on the protocol than the current implementation. (Notes): Remove this node. The attempt to describe the basic - model has pretty much been replaced by the Introduction. + model has pretty much been replaced by the Introduction. The material about how to start the client is incomplete and better left to cvs.texinfo. And the item about the lack of SERVER_FLOWCONTROL is obsolete now that SERVER_FLOWCONTROL is the @@ -1700,7 +1819,7 @@ Mon Sep 30 18:17:34 1996 Greg A. Woods <woods@most.weird.com> GREPBIN. (export examples): add one. (import options): describe the effect of '-b 1'. - + Mon Sep 30 08:09:53 1996 Jim Kingdon <kingdon@harvey.cyclic.com> * cvs.texinfo: Adjust comments concerning A4 vs. US letter, @@ -2404,14 +2523,14 @@ Sun Dec 31 10:53:47 1995 Jim Kingdon <kingdon@harvey.cyclic.com> Sun Dec 24 02:37:51 1995 Karl Fogel <kfogel@floss.cyclic.com> - * cvs.texinfo (Using the client with password authentication): + * cvs.texinfo (Using the client with password authentication): tixed fypos. Sun Dec 24 00:00:16 1995 Karl Fogel <kfogel@floss.cyclic.com> * cvs.texinfo (Remote repositories): use @code{rsh} most places, because it is the name of a program, and because I am a pedant. - Refer to new node "Password authenticated". + Refer to new node "Password authenticated". (Password authenticated): new node. (Setting up the server for password authentication): new node. (Using the client with password authentication): new node. diff --git a/contrib/cvs/doc/RCSFILES b/contrib/cvs/doc/RCSFILES index 6d600b8..13c4f93 100644 --- a/contrib/cvs/doc/RCSFILES +++ b/contrib/cvs/doc/RCSFILES @@ -24,12 +24,33 @@ several other output formats. If you just want some source code to look at, the part of CVS which applies these is RCS_deltas in src/rcs.c. -The first time I read rcsfile.5 I didn't really notice the part about -the order of the revisions. This order _is_ important and CVS relies -on it. It is documented but it would be clearer if the example in -rcsfile.5 also showed the order of the revisions (and the "next" and -"branch" fields and anything else where it would be useful to have an -example of how a revision tree is represented in an RCS file). +The rcsfile.5 documentation only _very_ briefly touches on the order +of the revisions. The order _is_ important and CVS relies on it. +Here is an example of what I was able to find, based on the join3 +sanity.sh testcase (and the behavior I am documenting here seems to be +the same for RCS 5.7 and CVS 1.9.27): + + 1.1 -----------------> 1.2 + \---> 1.1.2.1 \---> 1.2.2.1 + +Here is how this shows up in the RCS file (omitting irrelevant parts): + + admin: head 1.2; + deltas: + 1.2 branches 1.2.2.1; next 1.1; + 1.1 branches 1.1.2.1; next; + 1.1.2.1 branches; next; + 1.2.2.1 branches; next; + deltatexts: + 1.2 + 1.2.2.1 + 1.1 + 1.1.2.1 + +Yes, the order seems to differ between the deltas and the deltatexts. +I have no idea how much of this should actually be considered part of +the RCS file format, and how much programs reading it should expect to +encounter any order. 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 @@ -62,6 +83,38 @@ rules. the current CVS death support, which uses a state "dead" rather than a "dead" newphrase. +CVS does use newphrases to implement the `PreservePermissions' +extension introduced in CVS 1.9.26. The following new keywords are +defined when PreservePermissions=yes: + + owner + group + permissions + special + symlink + hardlinks + +The contents of the `owner' and `group' field should be a numeric uid +and a numeric gid, respectively, representing the user and group who +own the file. The `permissions' field contains an octal integer, +representing the permissions that should be applied to the file. The +`special' field contains two words; the first must be either `block' +or `character', and the second is the file's device number. The +`symlink' field should be present only in files which are symbolic +links to other files, and absent on all regular files. The +`hardlinks' field contains a list of filenames to which the current +file is linked, in alphabetical order. Because files often contain +characters special to RCS, like `.' and sometimes even contain spaces +or eight-bit characters, the filenames in the hardlinks field will +usually be enclosed in RCS strings. For example: + + hardlinks README @install.txt@ @Installation Notes@; + +The hardlinks field should always include the name of the current +file. That is, in the repository file README,v, any hardlinks fields +in the delta nodes should include `README'; CVS will not operate +properly if this is not done. + The rules regarding keyword expansion are not documented along with the rest of the RCS file format; they are documented in the co(1) manpage in the RCS 5.7 distribution. See also the "Keyword diff --git a/contrib/cvs/doc/cvs.texinfo b/contrib/cvs/doc/cvs.texinfo index 5558538..5dd2f77 100644 --- a/contrib/cvs/doc/cvs.texinfo +++ b/contrib/cvs/doc/cvs.texinfo @@ -22,7 +22,7 @@ @c If one prints US letter on A4, reportedly there is @c some extra space at the top and/or bottom, and the side @c margins are a bit narrow, but no text is lost. -@c +@c @c See @c http://www.ft.uni-erlangen.de/~mskuhn/iso-paper.html @c for more on paper sizes. Insuring that margins are @@ -49,6 +49,14 @@ @c problems (as opposed to FIXCVS for CVS problems). @ifinfo +@format +START-INFO-DIR-ENTRY +* CVS: (cvs). Concurrent Versions System +END-INFO-DIR-ENTRY +@end format +@end ifinfo + +@ifinfo Copyright @copyright{} 1992, 1993 Signum Support AB Copyright @copyright{} 1993, 1994 Free Software Foundation, Inc. @@ -65,15 +73,13 @@ notice identical to this one except for the removal of this paragraph @end ignore Permission is granted to copy and distribute modified versions of this manual under the conditions for verbatim copying, provided also that the -section entitled ``GNU General Public License'' is included exactly as -in the original, and provided that the entire resulting derived work is -distributed under the terms of a permission notice identical to this one. +entire resulting derived work is distributed under the terms of a +permission notice identical to this one. Permission is granted to copy and distribute translations of this manual into another language, under the above conditions for modified versions, -except that the section entitled ``GNU General Public License'' and -this permission notice may be included in translations approved by the -Free Software Foundation instead of in the original English. +except that this permission notice may be stated in a translation +approved by the Free Software Foundation. @end ifinfo @comment The titlepage section does not appear in the Info file. @@ -103,15 +109,13 @@ are preserved on all copies. Permission is granted to copy and distribute modified versions of this manual under the conditions for verbatim copying, provided also that the -section entitled ``GNU General Public License'' is included exactly as -in the original, and provided that the entire resulting derived work is -distributed under the terms of a permission notice identical to this one. +entire resulting derived work is distributed under the terms of a +permission notice identical to this one. Permission is granted to copy and distribute translations of this manual into another language, under the above conditions for modified versions, -except that the section entitled ``GNU General Public License'' and -this permission notice may be included in translations approved by the -Free Software Foundation instead of in the original English. +except that this permission notice may be stated in a translation +approved by the Free Software Foundation. @end titlepage @comment ================================================================ @@ -121,7 +125,7 @@ Free Software Foundation instead of in the original English. @ifinfo @c --------------------------------------------------------------------- @node Top -@top +@top @c Note: there is a space after that @top command. @c The texinfo-format-buffer Emacs function and @c the makeinfo shell command disagree on what arguments @@ -164,7 +168,6 @@ References. * 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 @@ -257,20 +260,12 @@ http://www.loria.fr/~molli/cvs-index.html @cindex Mailing list @cindex List, mailing list @cindex Newsgroups -@c Be careful in editing this--it is worded so that -@c the long -request address is in the middle of a -@c line, thus avoiding overfull hboxes. There is a mailing list, known as @w{@code{info-cvs}}, devoted to @sc{cvs}. To subscribe or -unsubscribe -@c could add "to the mailing list," -send a message to -@c or "write to" -@w{@code{info-cvs-request@@prep.ai.mit.edu}}. Please -be specific about your email address. As of May 1996, -subscription requests are handled by a busy human -being, so you cannot expect to be added or removed -immediately. If you prefer a usenet group, the right +unsubscribe +write to +@w{@code{info-cvs-request@@gnu.org}}. +If you prefer a usenet group, the right group is @code{comp.software.config-mgmt} which is for @sc{cvs} discussions (along with other configuration management systems). In the future, it might be @@ -456,10 +451,10 @@ only once they have been proven. @c people who read in order get dumped right into all @c manner of hair regarding remote repositories, @c creating a repository, etc. -@c +@c @c The following was in the old Basic concepts node. I don't @c know how good a job it does at introducing modules, -@c or whether they need to be introduced so soon, but +@c or whether they need to be introduced so soon, but @c something of this sort might go into some @c introductory material somewhere. @ignore @@ -818,7 +813,7 @@ override the @code{$CVSROOT} environment variable. Once you've checked a working copy out from the repository, it will remember where its repository is (the information is recorded in the -@file{CVS/Root} file in the working copy). +@file{CVS/Root} file in the working copy). The @code{-d} option and the @file{CVS/Root} file both override the @code{$CVSROOT} environment variable. If @@ -862,7 +857,7 @@ the file permissions appropriate for 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 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 @@ -894,31 +889,31 @@ directories): +--@t{local} | | | +--@t{cvsroot} - | | | + | | | | | +--@t{CVSROOT} - | (administrative files) - | + | (administrative files) + | +--@t{gnu} - | | + | | | +--@t{diff} - | | (source code to @sc{gnu} diff) - | | + | | (source code to @sc{gnu} diff) + | | | +--@t{rcs} | | (source code to @sc{rcs}) - | | + | | | +--@t{cvs} - | (source code to @sc{cvs}) - | + | (source code to @sc{cvs}) + | +--@t{yoyodyne} - | + | +--@t{tc} | | | +--@t{man} | | | +--@t{testing} - | + | +--(other Yoyodyne software) -@end example +@end example With the directories are @dfn{history files} for each file under version control. The name of the history file is @@ -943,7 +938,7 @@ the @file{yoyodyne/tc} directory might look like: +--@t{man} | | | +--@t{tc.1,v} - | + | +--@t{testing} | +--@t{testpgm.t,v} @@ -1068,18 +1063,18 @@ 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 @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 @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 @c interact? -@c +@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 @@ -1194,6 +1189,10 @@ later; for details see @ref{Watches Compatibility}. @node Locks @subsection CVS locks in the repository +@cindex #cvs.rfl, technical details +@cindex #cvs.wfl, technical details +@cindex #cvs.lock, technical details +@cindex locks, cvs, technical details For an introduction to CVS locks focusing on user-visible behavior, see @ref{Concurrency}. The following section is aimed at people who are writing @@ -1204,6 +1203,7 @@ described here, like @dfn{read lock}, @dfn{write lock}, and @dfn{deadlock}, you might consult the literature on operating systems or databases. +@cindex #cvs.tfl 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 @@ -1277,10 +1277,10 @@ 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 +@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 +file, @sc{cvs} should print @example cvs commit: Rebuilding administrative file database @@ -1678,7 +1678,7 @@ It is possible to commit an erroneous administrative file. You can often fix the error and check in a new revision, but sometimes a particularly bad error in the administrative file makes it impossible to commit new -revisions. +revisions. @c @xref{Bad administrative files} for a hint @c about how to solve such situations. @c -- administrative file checking-- @@ -1793,6 +1793,8 @@ in the repository; for the most part it is possible to back them up just like any other files. However, there are a few issues to consider. +@cindex locks, cvs, and backups +@cindex #cvs.rfl, and backups The first is that to be paranoid, one should either not use @sc{cvs} during the backup, or have the backup program lock @sc{cvs} while doing the backup. To not @@ -1958,7 +1960,7 @@ directory, or two megabytes, whichever is larger. @c documenting the default configuration of CVS. If it @c is a "standard" thing to change that value, it @c should be some kind of run-time configuration. -@c +@c @c See cvsclient.texi for more on the design decision @c to not have locks in place while waiting for the @c client, which is what results in memory consumption @@ -2185,8 +2187,8 @@ to reread its initialization files. @c this. One strange situation I ran into recently @c was that if inetd.conf specifies a non-existent @c cvs (e.g. /usr/local/bin/cvs doesn't exist in -@c the above example), the client says -@c cvs-1.8 [login aborted]: unrecognized auth response from harvey: +@c the above example), the client says +@c cvs-1.8 [login aborted]: unrecognized auth response from harvey: @c which is a very unhelpful response (can it be @c improved? does inetd log somewhere?) @@ -2299,8 +2301,8 @@ argument or the @code{CVSROOT} environment variable. password: @example -cvs -d :pserver:bach@@chainsaw.yard.com:/usr/local/cvsroot login -CVS password: +cvs -d :pserver:bach@@chainsaw.yard.com:/usr/local/cvsroot login +CVS password: @end example The password is checked with the server; if it is @@ -2531,7 +2533,7 @@ other access methods do not have explicit support for read-only users because those methods all assume login access to the repository machine anyway, and therefore the user can do whatever local file permissions allow -her to do.) +her to do.) A user who has read-only access can do only those @sc{cvs} operations which do not modify the @@ -2613,7 +2615,7 @@ read-only access. @cindex server, temporary directories While running, the @sc{cvs} server creates temporary -directories. They are named +directories. They are named @example cvs-serv@var{pid} @@ -2848,7 +2850,7 @@ vary). See the comments in the script for details. @node From scratch @subsection Creating a directory tree from scratch -@c Also/instead should be documenting +@c Also/instead should be documenting @c $ cvs co -l . @c $ mkdir tc @c $ cvs add tc @@ -3106,7 +3108,7 @@ is expected that future names which are special to starting with @samp{.}, rather than being named analogously to @code{BASE} and @code{HEAD}, to avoid conflicts with actual tag names. -@c Including a character such as % or = has also been +@c Including a character such as % or = has also been @c suggested as the naming convention for future @c special tag names. Starting with . is nice because @c that is not a legal tag name as far as RCS is concerned. @@ -3147,7 +3149,7 @@ command in the directory where @file{backend.c} resides. @example -$ cvs tag release-0-4 backend.c +$ cvs tag rel-0-4 backend.c T backend.c $ cvs status -v backend.c =================================================================== @@ -3160,7 +3162,7 @@ File: backend.c Status: Up-to-date Sticky Options: (none) Existing Tags: - release-0-4 (revision: 1.4) + rel-0-4 (revision: 1.4) @end example @@ -3170,7 +3172,7 @@ strategic points in the development life-cycle, such as when a release is made. @example -$ cvs tag release-1-0 . +$ cvs tag rel-1-0 . cvs tag: Tagging . T Makefile T backend.c @@ -3191,7 +3193,7 @@ retrieve the sources that make up release 1.0 of the module @samp{tc} at any time in the future: @example -$ cvs checkout -r release-1-0 tc +$ cvs checkout -r rel-1-0 tc @end example @noindent @@ -3278,7 +3280,7 @@ 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 Tag: rel-1-0-patches (branch: 1.7.2) Sticky Date: (none) Sticky Options: (none) @@ -3340,7 +3342,7 @@ Checking in file1; /tmp/cvs-sanity/cvsroot/first-dir/file1,v <-- file1 new revision: 1.3; previous revision: 1.2 done -$ +$ @end example @c --------------------------------------------------------------------- @@ -3422,20 +3424,20 @@ 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 +$ cvs tag -b rel-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 "cvs tag rel-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 rel-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}. +@samp{rel-1-0-patches}. It is important to understand that branches get created in the repository, not in the working copy. Creating a @@ -3448,12 +3450,12 @@ 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 +$ cvs rtag -b -r rel-1-0 rel-1-0-patches tc @end example -@samp{-r release-1-0} says that this branch should be +@samp{-r rel-1-0} says that this branch should be rooted at the revision that -corresponds to the tag @samp{release-1-0}. It need not +corresponds to the tag @samp{rel-1-0}. It need not be the most recent revision -- it's often useful to split a branch off an old revision (for example, when fixing a bug in a past release otherwise known to be @@ -3462,13 +3464,13 @@ 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 +revision number that matches @samp{rel-1-0} will probably be different from file to file. So, the full effect of the command is to create a new -branch -- named @samp{release-1-0-patches} -- in module +branch -- named @samp{rel-1-0-patches} -- in module @samp{tc}, rooted in the revision tree at the point tagged -by @samp{release-1-0}. +by @samp{rel-1-0}. @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - @node Accessing branches @@ -3491,21 +3493,21 @@ To check out a branch from the repository, invoke the tag name of the branch (@pxref{Creating a branch}): @example -$ cvs checkout -r release-1-0-patches tc +$ cvs checkout -r rel-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 +$ cvs update -r rel-1-0-patches tc @end example or equivalently: @example $ cd tc -$ cvs update -r release-1-0-patches +$ cvs update -r rel-1-0-patches @end example It does not matter if the working copy was originally @@ -3535,34 +3537,34 @@ File: driver.c Status: Up-to-date Version: 1.7 Sat Dec 5 18:25:54 1992 RCS Version: 1.7 /u/cvsroot/yoyodyne/tc/driver.c,v - Sticky Tag: release-1-0-patches (branch: 1.7.2) + Sticky Tag: rel-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) + rel-1-0-patches (branch: 1.7.2) + rel-1-0 (revision: 1.7) =================================================================== File: backend.c Status: Up-to-date Version: 1.4 Tue Dec 1 14:39:01 1992 RCS Version: 1.4 /u/cvsroot/yoyodyne/tc/backend.c,v - Sticky Tag: release-1-0-patches (branch: 1.4.2) + Sticky Tag: rel-1-0-patches (branch: 1.4.2) Sticky Date: (none) Sticky Options: (none) Existing Tags: - release-1-0-patches (branch: 1.4.2) - release-1-0 (revision: 1.4) - release-0-4 (revision: 1.4) + rel-1-0-patches (branch: 1.4.2) + rel-1-0 (revision: 1.4) + rel-0-4 (revision: 1.4) @end example 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 +same, @samp{rel-1-0-patches}, and the files are indeed on the same branch. The numbers simply reflect the point in each file's revision history at which the branch was made. In the above example, one can deduce @@ -3592,7 +3594,7 @@ 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. +moved back to the main trunk. Each branch has a @dfn{branch number}, consisting of an odd number of period-separated decimal integers. The @@ -3933,7 +3935,7 @@ structure: | +--@t{CVS} | | (internal @sc{cvs} files) | +--@t{tc.1} - | + | +--@t{testing} | +--@t{CVS} @@ -3956,7 +3958,7 @@ cvs update testing/testpgm.t testing/test2.t @item @samp{cvs update testing man} updates all files in the -subdirectories +subdirectories @item @samp{cvs update .} or just @samp{cvs update} updates @@ -4038,7 +4040,7 @@ 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 no one has gotten around to fixing "cvs add -@c foo/bar". +@c foo/bar". @example $ cd foo @@ -4084,7 +4086,7 @@ For example, the following commands add the file @file{backend.c} to the repository: @c This example used to specify -@c -m "Optimizer and code generation passes." +@c -m "Optimizer and code generation passes." @c to the cvs add command, but that doesn't work @c client/server (see log2 in sanity.sh). Should fix CVS, @c but also seems strange to document things which @@ -4347,7 +4349,7 @@ to remove @var{old} from the repository, and add @example $ mv @var{old} @var{new} $ cvs remove @var{old} -$ cvs add @var{new} +$ cvs add @var{new} $ cvs commit -m "Renamed @var{old} to @var{new}" @var{old} @var{new} @end example @@ -4552,7 +4554,7 @@ source. You are not affected by modifications made by others until you decide to incorporate those changes (via the @code{update} command---@pxref{update}). -@item +@item Traceability---When something has changed, you can always see @emph{exactly} what changed. @end itemize @@ -4917,7 +4919,7 @@ 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 +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. @@ -4961,7 +4963,7 @@ considerably with the operating system. @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 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 @@ -5210,7 +5212,7 @@ resolve the conflict as described in @ref{Conflicts example}. @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 @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 @@ -5496,7 +5498,7 @@ 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 @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 @@ -5531,7 +5533,7 @@ newsgroup. @node Concurrency @section Several developers simultaneously attempting to run CVS -@cindex locks, cvs +@cindex locks, cvs, introduction @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 @@ -5541,6 +5543,9 @@ time, one may get the following message: [11:43:23] waiting for bach's lock in /usr/local/cvsroot/foo @end example +@cindex #cvs.rfl, removing +@cindex #cvs.wfl, removing +@cindex #cvs.lock, removing @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 @@ -5549,8 +5554,8 @@ 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}. +start with @file{#cvs.rfl}, +@file{#cvs.wfl}, or @file{#cvs.lock}. Note that these locks are to protect @sc{cvs}'s internal data structures and have no relationship to @@ -5857,7 +5862,7 @@ receive notifications, she should specify @code{-a none}. The @var{files} and options are processed as for the @code{cvs watch} commands. -@strong{Caution:} If the @var{PreservePermissions} +@strong{Caution:} If the @code{PreservePermissions} option is enabled in the repository (@pxref{config}), CVS will not change the permissions on any of the @var{files}. The reason for this change is to ensure @@ -6110,7 +6115,7 @@ a new revision of the file. @section Keyword List @cindex Keyword List -@c FIXME: need some kind of example here I think, +@c FIXME: need some kind of example here I think, @c perhaps in a @c "Keyword intro" node. The intro in the "Keyword @c substitution" node itself seems OK, but to launch @@ -6170,7 +6175,7 @@ file contains * $@asis{}Log: frob.c,v $ * Revision 1.1 1997/01/03 14:23:51 joe * Add the superfrobnicate option - * + * */ @end example @@ -6212,36 +6217,21 @@ relevant text string, such as @code{$@asis{Id}$}, inside the file, and commit the file. @sc{cvs} will automatically expand the string as part of the commit operation. -@need 800 -It is common to embed @code{$@asis{}Id$} string in the -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}} - @r{from issuing an "unused variable" warning}. */ -#if __GNUC__ == 2 -#define USE(var) static void * use_##var = (&use_##var, (void *) &var) -USE (rcsid); -#endif -@end example - -Even though a clever optimizing compiler could remove -the unused variable @code{rcsid}, most compilers tend -to include the string in the binary. Some compilers -have a @code{#pragma} directive to include literal text -in the binary. +It is common to embed the @code{$@asis{}Id$} string in +the source files so that it gets passed through to +generated files. For example, if you are managing +computer program source code, you might include a +variable which is initialized to contain that string. +Or some C compilers may provide a @code{#pragma ident} +directive. Or a document management system might +provide a way to pass a string through to generated +files. + +@c Would be nice to give an example, but doing this in +@c portable C is not possible and the problem with +@c picking any one language (VMS HELP files, Ada, +@c troff, whatever) is that people use CVS for all +@c kinds of files. @cindex Ident (shell command) The @code{ident} command (which is part of the @sc{rcs} @@ -6282,7 +6272,7 @@ Keyword substitution has its disadvantages. Sometimes you might want the literal text string @samp{$@asis{}Author$} to appear inside a file without @sc{cvs} interpreting it as a keyword and expanding it -into something like @samp{$@asis{}Author: ceder $}. +into something like @samp{$@asis{}Author: ceder $}. There is unfortunately no way to selectively turn off keyword substitution. You can use @samp{-ko} @@ -6453,7 +6443,7 @@ 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. When you import a new file, the vendor branch is made the `head' revision, so anyone that checks out a copy of the file gets that revision. When a local modification is committed it is @@ -6767,6 +6757,13 @@ is Odin (see @node Special Files @chapter Special Files +@cindex special files +@cindex device nodes +@cindex ownership, saving in CVS +@cindex permissions, saving in CVS +@cindex hard links +@cindex symbolic links + In normal circumstances, CVS works only with regular files. Every file in a project is assumed to be persistent; it must be possible to open, read and close @@ -6778,34 +6775,67 @@ if the device file cannot be opened, CVS will refuse to handle it. Files also lose their ownerships and permissions during repository transactions. -If the configuration variable @var{PreservePermissions} +If the configuration variable @code{PreservePermissions} (@pxref{config}) is set in the repository, CVS will -preserve file permissions and ownership across -repository transactions, and will permit checkin and -checkout of special files and symbolic links. - -Using this option affects the behavior of CVS in -several ways. First, some of the new operations -supported by CVS are not accessible to all users. In -particular, file ownership and special file -characteristics may only be changed by the superuser. -When the @var{PreservePermissions} configuration -variable is set, therefore, users will have to be -`root' in order to perform CVS operations. +save the following file characteristics in the +repository: + +@itemize @bullet +@item user and group ownership +@item permissions +@item major and minor device numbers +@item symbolic links +@item hard link structure +@end itemize + +Using the @code{PreservePermissions} option affects the +behavior of CVS in several ways. First, some of the +new operations supported by CVS are not accessible to +all users. In particular, file ownership and special +file characteristics may only be changed by the +superuser. When the @code{PreservePermissions} +configuration variable is set, therefore, users will +have to be `root' in order to perform CVS operations. + +When @code{PreservePermissions} is in use, some CVS +operations (such as @samp{cvs status}) will not +recognize a file's hard link structure, and so will +emit spurious warnings about mismatching hard links. +The reason is that CVS's internal structure does not +make it easy for these operations to collect all the +necessary data about hard links, so they check for file +conflicts with inaccurate data. A more subtle difference is that CVS considers a file to have changed only if its contents have changed (specifically, if the modification time of the working file does not match that of the repository's file). -Therefore, if only the permissions or ownership have -changed, or if a device's major or minor numbers have -changed, CVS will not notice. In order to commit such -a change to the repository, you must force the commit -with @samp{cvs commit -f}. This also means that if a -file's permissions have changed and the repository file -is newer than the working copy, performing @samp{cvs -update} will silently change the permissions on the -working copy. +Therefore, if only the permissions, ownership or hard +linkage have changed, or if a device's major or minor +numbers have changed, CVS will not notice. In order to +commit such a change to the repository, you must force +the commit with @samp{cvs commit -f}. This also means +that if a file's permissions have changed and the +repository file is newer than the working copy, +performing @samp{cvs update} will silently change the +permissions on the working copy. + +Changing hard links in a CVS repository is particularly +delicate. Suppose that file @file{foo} is linked to +file @file{old}, but is later relinked to file +@file{new}. You can wind up in the unusual situation +where, although @file{foo}, @file{old} and @file{new} +have all had their underlying link patterns changed, +only @file{foo} and @file{new} have been modified, so +@file{old} is not considered a candidate for checking +in. It can be very easy to produce inconsistent +results this way. Therefore, we recommend that when it +is important to save hard links in a repository, the +prudent course of action is to @code{touch} any file +whose linkage or status has changed since the last +checkin. Indeed, it may be wise to @code{touch *} +before each commit in a directory with complex hard +link structures. It is worth noting that only regular files may be merged, for reasons that hopefully are obvious. If @@ -6818,9 +6848,9 @@ differences between these files, since no meaningful textual comparisons can be made on files which contain no text. -The PreservePermissions features do not work with -client/server @sc{cvs}. Another limitation is that -hard links must be to other files within the same +The @code{PreservePermissions} features do not work +with client/server @sc{cvs}. Another limitation is +that hard links must be to other files within the same directory; hard links across directories are not supported. @@ -6976,7 +7006,7 @@ the file. So if this is the contents of the user's log -N diff -u update -P -co -P +checkout -P @end example @noindent @@ -7108,7 +7138,7 @@ suppressed. @cindex read-only files, and -r @item -r -Make new working files files read-only. Same effect +Make new working files read-only. Same effect as if the @code{$CVSREAD} environment variable is set (@pxref{Environment variables}). The default is to make working files writable, unless watches are on @@ -7200,7 +7230,7 @@ further updates in the same directory will use the same date @code{diff}, @code{export}, @code{history}, @code{rdiff}, @code{rtag}, and @code{update} commands. (The @code{history} command uses this option in a -slightly different way; @pxref{history options}). +slightly different way; @pxref{history options}). @c What other formats should we accept? I don't want @c to start accepting a whole mess of non-standard @@ -7218,19 +7248,19 @@ slightly different way; @pxref{history options}). @c VMS to support this format (and if we're going to do @c that, better to make CVS support it on all @c platforms. Maybe). -@c +@c @c NOTE: The tar manual has some documentation for @c getdate.y (just for our info; we don't want to @c attempt to document all the formats accepted by @c getdate.y). -@c +@c @c One more note: In output, CVS should consistently @c use one date format, and that format should be one that @c it accepts in input as well. The former isn't @c really true (see survey below), and I'm not @c sure that either of those formats is accepted in -@c input. -@c +@c input. +@c @c cvs log @c current 1996/01/02 13:45:31 @c Internet 02 Jan 1996 13:45:31 UT @@ -7279,7 +7309,7 @@ RFC1123). @c So I don't know.... @c A few specific issues: (1) Maybe should reassure @c people that years after 2000 -@c work (they are in the testsuite, so they do indeed +@c work (they are in the testsuite, so they do indeed @c work). (2) What do two digit years @c mean? Where do we accept them? (3) Local times can @c be ambiguous or nonexistent if they fall during the @@ -7337,7 +7367,7 @@ accept all of them. @c message from "cvs import" suggesting a merge @c command). What else? Probably some/all of the "3 @c weeks ago" family. -@c +@c @c Maybe at @c some point have CVS start give warnings on "unofficial" @c formats (many of which might be typos or user @@ -7366,7 +7396,7 @@ normally ignore files that do not contain the tag (or did not exist prior to the date) that you specified. Use the @samp{-f} option if you want files retrieved even when there is no match for the tag or date. (The most recent revision of the file -will be used). +will be used). @need 800 @samp{-f} is available with these commands: @@ -7396,7 +7426,7 @@ The @samp{-k} option is available with the @code{add}, @item -l Local; run only in current working directory, rather than -recursing through subdirectories. +recursing through subdirectories. @strong{Warning:} this is not the same as the overall @samp{cvs -l} option, which you can specify to the @@ -7420,7 +7450,7 @@ Available with the following commands: @code{add}, @item -n Do not run any checkout/commit/tag program. (A program can be specified to run on each of these activities, in the modules -database (@pxref{modules}); this option bypasses it). +database (@pxref{modules}); this option bypasses it). @strong{Warning:} this is not the same as the overall @samp{cvs -n} option, which you can specify to the left of a cvs command! @@ -7460,11 +7490,8 @@ revision you last checked out into the current working directory. @c for all cvs commands except diff. For diff, it @c seems to be (a) the head of the trunk (or the default @c branch?) if there is no sticky tag, (b) the head of the -@c branch if there is a branch sticky tag, and (c) the -@c same as BASE if there is a non-branch sticky tag. (c) -@c would appear to be strange, maybe accidental, and so there would -@c presumably be -@c little problem changing it. (b) is ugly as it differs +@c branch for the sticky tag, if there is a sticky tag. +@c (b) is ugly as it differs @c from what HEAD means for other commands, but people @c and/or scripts are quite possibly used to it. @c See "head" tests in sanity.sh. @@ -8400,37 +8427,56 @@ One or both @samp{-r} options can be replaced by a 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} -@code{-H} @code{-i} @code{-n} @code{-N} @code{-p} -@code{-s} @code{-t} @code{-u} @code{-U} @var{nlines} -@w{@code{-F} @var{regexp}} @w{@code{-I} @var{regexp}} -@w{@code{-L} @var{label}} @code{-T} @w{@code{-V} -@var{arg}} @w{@code{-W} @var{columns}} @code{-w} -@code{-y} @code{-0} @code{-1} @code{-2} @code{-3} -@code{-4} @code{-5} @code{-6} @code{-7} @code{-8} -@code{-9} @code{--binary} @code{--brief} -@code{--changed-group-format=@var{arg}} -@code{--context[=@var{lines}]} @code{--ed} -@code{--expand-tabs} @code{--forward-ed} -@code{--horizon-lines=@var{arg}} -@code{--ifdef=@var{arg}} -@code{--ignore-all-space} @code{--ignore-blank-lines} -@code{--ignore-case} -@code{--ignore-matching-lines=@var{regexp}} -@code{--ignore-space-change} @code{--initial-tab} -@code{--label=@var{label}} @code{--left-column} -@code{--minimal} @code{--new-file} -@code{--new-line-format=@var{arg}} -@code{--old-line-format=@var{arg}} @code{--paginate} -@code{--rcs} @code{--report-identical-files} -@code{--code-c-function} @code{--side-by-side} -@code{--show-function-line=@var{regexp}} -@code{--speed-large-files} -@code{--suppress-common-lines} @code{--text} -@code{--unchanged-group-format=@var{arg}} -@code{--unified[=@var{lines}]} -@code{--width=@var{columns}} +@example +-0 -1 -2 -3 -4 -5 -6 -7 -8 -9 +--binary +--brief +--changed-group-format=@var{arg} +-c + -C @var{nlines} + --context[=@var{lines}] +-e --ed +-t --expand-tabs +-f --forward-ed +--horizon-lines=@var{arg} +--ifdef=@var{arg} +-w --ignore-all-space +-B --ignore-blank-lines +-i --ignore-case +-I @var{regexp} + --ignore-matching-lines=@var{regexp} +-h +-b --ignore-space-change +-T --initial-tab +-L @var{label} + --label=@var{label} +--left-column +-d --minimal +-N --new-file +--new-line-format=@var{arg} +--old-line-format=@var{arg} +--paginate +-n --rcs +-s --report-identical-files +-p +--show-c-function +-y --side-by-side +-F @var{regexp} +--show-function-line=@var{regexp} +-H --speed-large-files +--suppress-common-lines +-a --text +--unchanged-group-format=@var{arg} +-u + -U @var{nlines} + --unified[=@var{lines}] +@c FIXCVS: This option is accepted by src/diff.c but +@c not diff/diff.c; it would appear that any attempt to +@c use it would get an error. +-V @var{arg} +-W @var{columns} + --width=@var{columns} +@end example @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . @node diff examples @@ -8608,7 +8654,7 @@ kind of report is generated: Report on each time commit was used (i.e., each time the repository was modified). -@item -e +@item -e Everything (all record types). Equivalent to specifying @samp{-x} with all record types. Of course, @samp{-e} will also include record types which are @@ -8629,9 +8675,9 @@ Report on all tags. @item -x @var{type} Extract a particular set of record types @var{type} from the @sc{cvs} history. The types are indicated by single letters, -which you may specify in combination. +which you may specify in combination. -Certain commands have a single record type: +Certain commands have a single record type: @table @code @item F @@ -8650,7 +8696,7 @@ One of four record types may result from an update: @table @code @item C A merge was necessary but collisions were -detected (requiring manual merging). +detected (requiring manual merging). @item G A merge was necessary and it succeeded. @item U @@ -8894,7 +8940,7 @@ be changed, but if there is a consensus on what it should be changed to, it doesn't seem to be apparent. (Various options in the @file{modules} file can be used to recreate symbolic links on checkout, update, etc.; -@pxref{modules}.) +@pxref{modules}.) @end table @c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . @@ -9018,7 +9064,7 @@ Do not print the list of tags for this file. This option can be very useful when your site uses a lot of tags, so rather than "more"'ing over 3 pages of tag information, the log information is presented without -tags at all. +tags at all. @item -R Print only the name of the @sc{rcs} file. @@ -9027,7 +9073,7 @@ Print only the name of the @sc{rcs} file. @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 (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. @@ -9056,7 +9102,7 @@ the same branch). Revisions from the beginning of the branch up to and including @var{rev}. -@item @var{rev}: +@item @var{rev}: Revisions starting with @var{rev} to the end of the branch containing @var{rev}. @@ -9303,7 +9349,7 @@ if it is non-empty! Before @code{release} releases your sources it will print a one-line message for any file that is not -up-to-date. +up-to-date. @strong{Warning:} Any new directories that you have created, but not added to the @sc{cvs} directory hierarchy @@ -9409,7 +9455,7 @@ Only useful with the @samp{-D @var{date}} or @samp{-r @var{tag}} flags. If no matching revision is found, use the most recent revision (instead of ignoring the file). -@item -F +@item -F Overwrite an existing tag of the same name on a different revision. @c FIXME: Needs an example, and/or more explanation. @@ -9550,7 +9596,7 @@ them): @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 +@item -F Overwrite an existing tag of the same name on a different revision. @c FIXME: See "rtag -F" for comments on this. @@ -9684,7 +9730,7 @@ See @ref{Sticky tags}, for more information on sticky tags/dates. Create any directories that exist in the repository if they're missing from the working directory. Normally, @code{update} acts only on directories and files that -were already enrolled in your working directory. +were already enrolled in your working directory. This is useful for updating directories that were created in the repository since the initial checkout; @@ -9876,13 +9922,13 @@ options}. Do not change any files. See @ref{Global options}. @item -Q -Cause the command to be really quiet. See @ref{Global options}. +Be really quiet. See @ref{Global options}. @item -q -Cause the command to be somewhat quiet. See @ref{Global options}. +Be somewhat quiet. See @ref{Global options}. @item -r -Make new working files files read-only. See @ref{Global options}. +Make new working files read-only. See @ref{Global options}. @item -s @var{variable}=@var{value} Set a user variable. See @ref{Variables}. @@ -9947,7 +9993,7 @@ Initial revision @c The idea behind this table is that we want each item @c to be a sentence or two at most. Preferably a @c single line. -@c +@c @c In some cases refs to "foo options" are just to get @c this thing written quickly, not because the "foo @c options" node is really the best place to point. @@ -10161,7 +10207,7 @@ Diff revision for @var{rev1} against working file. See @ref{diff options}. @item -r @var{rev2} -Diff rev1/date1 against rev2. See @ref{diff options}. +Diff @var{rev1}/@var{date1} against @var{rev2}. See @ref{diff options}. @end table @item edit [@var{options}] [@var{files}@dots{}] @@ -10351,7 +10397,7 @@ Do not list tags. See @ref{log options}. @item -R Only print name of RCS file. See @ref{log options}. -@item -r @var{revs} +@item -r@var{revs} Only list revisions @var{revs}. See @ref{log options}. @item -s @var{states} @@ -10361,7 +10407,7 @@ Only list revisions with specified states. See @ref{log options}. Only print header and descriptive text. See @ref{log options}. -@item -w @var{logins} +@item -w@var{logins} Only list revisions checked in by specified logins. See @ref{log options}. @end table @@ -10668,7 +10714,7 @@ file, which defines the modules inside the repository. * commit files:: The commit support files * commitinfo:: Pre-commit checking * verifymsg:: How are log messages evaluated? -* editinfo:: Specifying how log messages are created +* editinfo:: Specifying how log messages are created (obsolete) * loginfo:: Where should log messages be sent? * rcsinfo:: Templates for the log messages @@ -10897,12 +10943,16 @@ before the name of each directory to be excluded. For example, if the modules file contains: @example -exmodule -a first-dir !first-dir/sdir +exmodule -a !first-dir/sdir first-dir @end example then checking out the module @samp{exmodule} will check out everything in @samp{first-dir} except any files in the subdirectory @samp{first-dir/sdir}. +@c Note that the "!first-dir/sdir" sometimes must be listed +@c before "first-dir". That seems like a probable bug, in which +@c case perhaps it should be fixed (to allow either +@c order) rather than documented. See modules4 in testsuite. @node Module options @appendixsubsec Module options @@ -11024,11 +11074,13 @@ 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 +a non-binary file is updated. @code{MERGE} means the usual @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 +with @samp{-kb} (but if the file is specified as +binary, there is no need to specify @samp{-m 'COPY'}). +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. @strong{WARNING}: do not use @code{COPY} with @@ -11135,7 +11187,7 @@ cvs import -I ! -W "*.exe -k 'b'" first-dir vendortag reltag @c :::::::::::::::::: @c *.t12 -m 'COPY' @c *.t[0-9][0-9] -f 'gunzipcp %s' -t 'gzipcp %s %s' -m 'COPY' -@c +@c @c :::::::::::::::::: @c gunzipcp @c :::::::::::::::::: @@ -11335,8 +11387,8 @@ repositories}). @cindex verifymsg (admin file) @cindex log message, verifying -Once you have entered a log message, you can evaluate -that message to check for specific content, such as +Once you have entered a log message, you can evaluate +that message to check for specific content, such as a bug ID. Use the @file{verifymsg} file to specify a program that is used to verify the log message. This program could be a simple script that checks @@ -11385,7 +11437,7 @@ free text. The following template is found in the file @file{/usr/cvssupport/tc.template}. @example -BugId: +BugId: @end example The script @file{/usr/cvssupport/bugid.verify} is used to @@ -11396,7 +11448,7 @@ evaluate the log message. # # bugid.verify filename # -# Verify that the log message contains a valid bugid +# Verify that the log message contains a valid bugid # on the first line. # if head -1 < $1 | grep '^BugId:[ ]*[0-9][0-9]*$' > /dev/null; then @@ -11500,7 +11552,7 @@ free text. The following template is found in the file @file{/usr/cvssupport/tc.template}. @example -BugId: +BugId: @end example The script @file{/usr/cvssupport/bugid.edit} is used to @@ -11570,7 +11622,7 @@ matching regular expression or @samp{DEFAULT}. The first matching regular expression is used. @xref{commit files}, for a description of the syntax of -the @file{loginfo} file. +the @file{loginfo} file. The user may specify a format string as part of the filter. The string is composed of a @@ -11627,22 +11679,23 @@ repositories}). @appendixsubsec Loginfo example The following @file{loginfo} file, together with the -tiny shell-script below, appends all log messages +tiny shell-script below, appends all log messages to the file @file{$CVSROOT/CVSROOT/commitlog}, and any commits to the administrative files (inside the @file{CVSROOT} directory) are also logged in @file{/usr/adm/cvsroot-log}. -@c and mailed to @t{ceder}. +Commits to the @file{prog1} directory are mailed to @t{ceder}. @c FIXME: is it a CVS feature or bug that only the @c first matching line is used? It is documented -@c above, but is it useful? This example (with the -@c mail to ceder put back in) is awkward to write if +@c above, but is it useful? For example, if we wanted +@c to run both "cvs-log" and "Mail" for the CVSROOT +@c directory, it is kind of awkward if @c only the first matching line is used. @example -ALL /usr/local/bin/cvs-log $CVSROOT/CVSROOT/commitlog -@c ^CVSROOT Mail -s %s ceder +ALL /usr/local/bin/cvs-log $CVSROOT/CVSROOT/commitlog $USER ^CVSROOT /usr/local/bin/cvs-log /usr/adm/cvsroot-log +^prog1 Mail -s %s ceder @end example The shell-script @file{/usr/local/bin/cvs-log} looks @@ -11651,10 +11704,10 @@ like this: @example #!/bin/sh (echo "------------------------------------------------------"; - echo -n $USER" "; + echo -n $2" "; date; echo; - sed '1s+'$@{CVSROOT@}'++') >> $1 + cat) >> $1 @end example @node Keeping a checked out copy @@ -11808,7 +11861,7 @@ patterns is: *~ #* .#* ,* _$* *$ *.old *.bak *.BAK *.orig *.rej .del-* *.a *.olb *.o *.obj *.so *.exe - *.Z *.elc *.ln + *.Z *.elc *.ln core @end example @@ -12018,6 +12071,24 @@ symbolic links, file permissions and ownerships in the repository. The default value is @samp{no}. @xref{Special Files} for the full implications of using this keyword. + +@cindex TopLevelAdmin, in CVSROOT/config +@item TopLevelAdmin=@var{value} +Modify the @samp{checkout} command to create a +@samp{CVS} directory at the top level of the new +working directory, in addition to @samp{CVS} +directories created within checked-out directories. +The default value is @samp{no}. + +This option is useful if you find yourself performing +many commands at the top level of your working +directory, rather than in one of the checked out +subdirectories. The @samp{CVS} directory created there +will mean you don't have to specify @samp{CVSROOT} for +each command. It also provides a place for the +@samp{CVS/Template} file (@pxref{Working directory +storage}). + @end table @c --------------------------------------------------------------------- @@ -12062,7 +12133,7 @@ can supply it on the command line: @samp{cvs -d cvsroot cvs_command@dots{}} Once you have checked out a working directory, @sc{cvs} stores the appropriate root (in the file @file{CVS/Root}), so normally you only need to -worry about this when initially checking out a working +worry about this when initially checking out a working directory. @item $EDITOR @@ -12204,7 +12275,7 @@ to use the optional developer communication features. @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 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 @@ -12215,7 +12286,7 @@ to use the optional developer communication features. @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 @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 @@ -12320,6 +12391,17 @@ 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 cvs @var{command}: conflict: removed @var{file} was modified by second party +This message indicates that you removed a file, and +someone else modified it. To resolve the conflict, +first run @samp{cvs add @var{file}}. If desired, look +at the other party's modification to decide whether you +still want to remove it. If you don't want to remove +it, stop here. If you do want to remove it, proceed +with @samp{cvs remove @var{file}} and commit your +removal. +@c Tests conflicts2-142b* in sanity.sh test for this. + @item cannot change permissions on temporary directory @example Operation not permitted @@ -12839,401 +12921,6 @@ 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 - -@display -Copyright @copyright{} 1989, 1991 Free Software Foundation, Inc. -59 Temple Place - Suite 330, Boston, MA 02111-1307, USA - -Everyone is permitted to copy and distribute verbatim copies -of this license document, but changing it is not allowed. -@end display - -@unnumberedsec Preamble - - The licenses for most software are designed to take away your -freedom to share and change it. By contrast, the GNU General Public -License is intended to guarantee your freedom to share and change free -software---to make sure the software is free for all its users. This -General Public License applies to most of the Free Software -Foundation's software and to any other program whose authors commit to -using it. (Some other Free Software Foundation software is covered by -the GNU Library General Public License instead.) You can apply it to -your programs, too. - - When we speak of free software, we are referring to freedom, not -price. Our General Public Licenses are designed to make sure that you -have the freedom to distribute copies of free software (and charge for -this service if you wish), that you receive source code or can get it -if you want it, that you can change the software or use pieces of it -in new free programs; and that you know you can do these things. - - To protect your rights, we need to make restrictions that forbid -anyone to deny you these rights or to ask you to surrender the rights. -These restrictions translate to certain responsibilities for you if you -distribute copies of the software, or if you modify it. - - For example, if you distribute copies of such a program, whether -gratis or for a fee, you must give the recipients all the rights that -you have. You must make sure that they, too, receive or can get the -source code. And you must show them these terms so they know their -rights. - - We protect your rights with two steps: (1) copyright the software, and -(2) offer you this license which gives you legal permission to copy, -distribute and/or modify the software. - - Also, for each author's protection and ours, we want to make certain -that everyone understands that there is no warranty for this free -software. If the software is modified by someone else and passed on, we -want its recipients to know that what they have is not the original, so -that any problems introduced by others will not reflect on the original -authors' reputations. - - Finally, any free program is threatened constantly by software -patents. We wish to avoid the danger that redistributors of a free -program will individually obtain patent licenses, in effect making the -program proprietary. To prevent this, we have made it clear that any -patent must be licensed for everyone's free use or not licensed at all. - - The precise terms and conditions for copying, distribution and -modification follow. - -@iftex -@heading TERMS AND CONDITIONS FOR COPYING, -@heading DISTRIBUTION AND MODIFICATION -@end iftex -@ifinfo -@center TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION -@end ifinfo - -@enumerate 0 -@item -This License applies to any program or other work which contains -a notice placed by the copyright holder saying it may be distributed -under the terms of this General Public License. The ``Program'', below, -refers to any such program or work, and a ``work based on the Program'' -means either the Program or any derivative work under copyright law: -that is to say, a work containing the Program or a portion of it, -either verbatim or with modifications and/or translated into another -language. (Hereinafter, translation is included without limitation in -the term ``modification''.) Each licensee is addressed as ``you''. - -Activities other than copying, distribution and modification are not -covered by this License; they are outside its scope. The act of -running the Program is not restricted, and the output from the Program -is covered only if its contents constitute a work based on the -Program (independent of having been made by running the Program). -Whether that is true depends on what the Program does. - -@item -You may copy and distribute verbatim copies of the Program's -source code as you receive it, in any medium, provided that you -conspicuously and appropriately publish on each copy an appropriate -copyright notice and disclaimer of warranty; keep intact all the -notices that refer to this License and to the absence of any warranty; -and give any other recipients of the Program a copy of this License -along with the Program. - -You may charge a fee for the physical act of transferring a copy, and -you may at your option offer warranty protection in exchange for a fee. - -@item -You may modify your copy or copies of the Program or any portion -of it, thus forming a work based on the Program, and copy and -distribute such modifications or work under the terms of Section 1 -above, provided that you also meet all of these conditions: - -@enumerate a -@item -You must cause the modified files to carry prominent notices -stating that you changed the files and the date of any change. - -@item -You must cause any work that you distribute or publish, that in -whole or in part contains or is derived from the Program or any -part thereof, to be licensed as a whole at no charge to all third -parties under the terms of this License. - -@item -If the modified program normally reads commands interactively -when run, you must cause it, when started running for such -interactive use in the most ordinary way, to print or display an -announcement including an appropriate copyright notice and a -notice that there is no warranty (or else, saying that you provide -a warranty) and that users may redistribute the program under -these conditions, and telling the user how to view a copy of this -License. (Exception: if the Program itself is interactive but -does not normally print such an announcement, your work based on -the Program is not required to print an announcement.) -@end enumerate - -These requirements apply to the modified work as a whole. If -identifiable sections of that work are not derived from the Program, -and can be reasonably considered independent and separate works in -themselves, then this License, and its terms, do not apply to those -sections when you distribute them as separate works. But when you -distribute the same sections as part of a whole which is a work based -on the Program, the distribution of the whole must be on the terms of -this License, whose permissions for other licensees extend to the -entire whole, and thus to each and every part regardless of who wrote it. - -Thus, it is not the intent of this section to claim rights or contest -your rights to work written entirely by you; rather, the intent is to -exercise the right to control the distribution of derivative or -collective works based on the Program. - -In addition, mere aggregation of another work not based on the Program -with the Program (or with a work based on the Program) on a volume of -a storage or distribution medium does not bring the other work under -the scope of this License. - -@item -You may copy and distribute the Program (or a work based on it, -under Section 2) in object code or executable form under the terms of -Sections 1 and 2 above provided that you also do one of the following: - -@enumerate a -@item -Accompany it with the complete corresponding machine-readable -source code, which must be distributed under the terms of Sections -1 and 2 above on a medium customarily used for software interchange; or, - -@item -Accompany it with a written offer, valid for at least three -years, to give any third party, for a charge no more than your -cost of physically performing source distribution, a complete -machine-readable copy of the corresponding source code, to be -distributed under the terms of Sections 1 and 2 above on a medium -customarily used for software interchange; or, - -@item -Accompany it with the information you received as to the offer -to distribute corresponding source code. (This alternative is -allowed only for noncommercial distribution and only if you -received the program in object code or executable form with such -an offer, in accord with Subsection b above.) -@end enumerate - -The source code for a work means the preferred form of the work for -making modifications to it. For an executable work, complete source -code means all the source code for all modules it contains, plus any -associated interface definition files, plus the scripts used to -control compilation and installation of the executable. However, as a -special exception, the source code distributed need not include -anything that is normally distributed (in either source or binary -form) with the major components (compiler, kernel, and so on) of the -operating system on which the executable runs, unless that component -itself accompanies the executable. - -If distribution of executable or object code is made by offering -access to copy from a designated place, then offering equivalent -access to copy the source code from the same place counts as -distribution of the source code, even though third parties are not -compelled to copy the source along with the object code. - -@item -You may not copy, modify, sublicense, or distribute the Program -except as expressly provided under this License. Any attempt -otherwise to copy, modify, sublicense or distribute the Program is -void, and will automatically terminate your rights under this License. -However, parties who have received copies, or rights, from you under -this License will not have their licenses terminated so long as such -parties remain in full compliance. - -@item -You are not required to accept this License, since you have not -signed it. However, nothing else grants you permission to modify or -distribute the Program or its derivative works. These actions are -prohibited by law if you do not accept this License. Therefore, by -modifying or distributing the Program (or any work based on the -Program), you indicate your acceptance of this License to do so, and -all its terms and conditions for copying, distributing or modifying -the Program or works based on it. - -@item -Each time you redistribute the Program (or any work based on the -Program), the recipient automatically receives a license from the -original licensor to copy, distribute or modify the Program subject to -these terms and conditions. You may not impose any further -restrictions on the recipients' exercise of the rights granted herein. -You are not responsible for enforcing compliance by third parties to -this License. - -@item -If, as a consequence of a court judgment or allegation of patent -infringement or for any other reason (not limited to patent issues), -conditions are imposed on you (whether by court order, agreement or -otherwise) that contradict the conditions of this License, they do not -excuse you from the conditions of this License. If you cannot -distribute so as to satisfy simultaneously your obligations under this -License and any other pertinent obligations, then as a consequence you -may not distribute the Program at all. For example, if a patent -license would not permit royalty-free redistribution of the Program by -all those who receive copies directly or indirectly through you, then -the only way you could satisfy both it and this License would be to -refrain entirely from distribution of the Program. - -If any portion of this section is held invalid or unenforceable under -any particular circumstance, the balance of the section is intended to -apply and the section as a whole is intended to apply in other -circumstances. - -It is not the purpose of this section to induce you to infringe any -patents or other property right claims or to contest validity of any -such claims; this section has the sole purpose of protecting the -integrity of the free software distribution system, which is -implemented by public license practices. Many people have made -generous contributions to the wide range of software distributed -through that system in reliance on consistent application of that -system; it is up to the author/donor to decide if he or she is willing -to distribute software through any other system and a licensee cannot -impose that choice. - -This section is intended to make thoroughly clear what is believed to -be a consequence of the rest of this License. - -@item -If the distribution and/or use of the Program is restricted in -certain countries either by patents or by copyrighted interfaces, the -original copyright holder who places the Program under this License -may add an explicit geographical distribution limitation excluding -those countries, so that distribution is permitted only in or among -countries not thus excluded. In such case, this License incorporates -the limitation as if written in the body of this License. - -@item -The Free Software Foundation may publish revised and/or new versions -of the General Public License from time to time. Such new versions will -be similar in spirit to the present version, but may differ in detail to -address new problems or concerns. - -Each version is given a distinguishing version number. If the Program -specifies a version number of this License which applies to it and ``any -later version'', you have the option of following the terms and conditions -either of that version or of any later version published by the Free -Software Foundation. If the Program does not specify a version number of -this License, you may choose any version ever published by the Free Software -Foundation. - -@item -If you wish to incorporate parts of the Program into other free -programs whose distribution conditions are different, write to the author -to ask for permission. For software which is copyrighted by the Free -Software Foundation, write to the Free Software Foundation; we sometimes -make exceptions for this. Our decision will be guided by the two goals -of preserving the free status of all derivatives of our free software and -of promoting the sharing and reuse of software generally. - -@iftex -@heading NO WARRANTY -@end iftex -@ifinfo -@center NO WARRANTY -@end ifinfo - -@item -BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY -FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN -OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES -PROVIDE THE PROGRAM ``AS IS'' WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED -OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF -MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS -TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE -PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, -REPAIR OR CORRECTION. - -@item -IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING -WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR -REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, -INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING -OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED -TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY -YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER -PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE -POSSIBILITY OF SUCH DAMAGES. -@end enumerate - -@iftex -@heading END OF TERMS AND CONDITIONS -@end iftex -@ifinfo -@center END OF TERMS AND CONDITIONS -@end ifinfo - -@page -@unnumberedsec How to Apply These Terms to Your New Programs - - If you develop a new program, and you want it to be of the greatest -possible use to the public, the best way to achieve this is to make it -free software which everyone can redistribute and change under these terms. - - To do so, attach the following notices to the program. It is safest -to attach them to the start of each source file to most effectively -convey the exclusion of warranty; and each file should have at least -the ``copyright'' line and a pointer to where the full notice is found. - -@smallexample -@var{one line to give the program's name and a brief idea of what it does.} -Copyright (C) 19@var{yy} @var{name of author} - -This program is free software; you can redistribute it and/or modify -it under the terms of the GNU General Public License as published by -the Free Software Foundation; either version 2 of the License, or -(at your option) any later version. - -This program is distributed in the hope that it will be useful, -but WITHOUT ANY WARRANTY; without even the implied warranty of -MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -GNU General Public License for more details. - -You should have received a copy of the GNU General Public License -along with this program; if not, write to the Free Software -Foundation, Inc., 59 Temple Place - Suite 330, -Boston, MA 02111-1307, USA. -@end smallexample - -Also add information on how to contact you by electronic and paper mail. - -If the program is interactive, make it output a short notice like this -when it starts in an interactive mode: - -@smallexample -Gnomovision version 69, Copyright (C) 19@var{yy} @var{name of author} -Gnomovision comes with ABSOLUTELY NO WARRANTY; for details -type `show w'. -This is free software, and you are welcome to redistribute it -under certain conditions; type `show c' for details. -@end smallexample - -The hypothetical commands @samp{show w} and @samp{show c} should show -the appropriate parts of the General Public License. Of course, the -commands you use may be called something other than @samp{show w} and -@samp{show c}; they could even be mouse-clicks or menu items---whatever -suits your program. - -You should also get your employer (if you work as a programmer) or your -school, if any, to sign a ``copyright disclaimer'' for the program, if -necessary. Here is a sample; alter the names: - -@smallexample -Yoyodyne, Inc., hereby disclaims all copyright interest in the program -`Gnomovision' (which makes passes at compilers) written by James Hacker. - -@var{signature of Ty Coon}, 1 April 1989 -Ty Coon, President of Vice -@end smallexample - -This General Public License does not permit incorporating your program into -proprietary programs. If your program is a subroutine library, you may -consider it more useful to permit linking proprietary applications with the -library. If this is what you want to do, use the GNU Library General -Public License instead of this License. - -@c --------------------------------------------------------------------- @node Index @unnumbered Index @cindex Index diff --git a/contrib/cvs/doc/cvsclient.texi b/contrib/cvs/doc/cvsclient.texi index 56577c2..6f01399 100644 --- a/contrib/cvs/doc/cvsclient.texi +++ b/contrib/cvs/doc/cvsclient.texi @@ -320,6 +320,7 @@ General protocol conventions: * Filenames:: Conventions regarding filenames * File transmissions:: How file contents are transmitted * Strings:: Strings in various requests and responses +* Dates:: Times and dates The protocol itself: @@ -468,6 +469,32 @@ 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 Dates +@section Dates + +The protocol contains times and dates in various places. + +For the @samp{-D} option to the @code{annotate}, @code{co}, @code{diff}, +@code{export}, @code{history}, @code{rdiff}, @code{rtag}, @code{tag}, +and @code{update} requests, the server should support two formats: + +@example +26 May 1997 13:01:40 GMT ; @r{RFC 822 as modified by RFC 1123} +5/26/1997 13:01:40 GMT ; @r{traditional} +@end example + +The former format is preferred; the latter however is sent by the CVS +command line client (versions 1.5 through at least 1.9). + +For the @samp{-d} option to the @code{log} request, servers should at +least support RFC 822/1123 format. Clients are encouraged to use this +format too (traditionally the command line CVS client has just passed +along the date format specified by the user, however). + +For @code{Mod-time}, see the description of that response. + +For @code{Notify}, see the description of that request. + @node Request intro @section Request intro @@ -517,7 +544,7 @@ for the original directory, then the command. 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 +to indicate that top level, @samp{.} should be sent for @var{local-directory}. Here is an example of where a client gets @var{repository} and @@ -892,7 +919,6 @@ directory. @itemx tag \n @itemx status \n @itemx log \n -@itemx remove \n @itemx admin \n @itemx history \n @itemx watchers \n @@ -1034,6 +1060,23 @@ directories, as described above), use @samp{.} for @var{local-directory} may not get an error, but it will get you strange @code{Checked-in} responses from the buggy servers. +@item remove \n +Response expected: yes. Remove a file. This uses any +previous @code{Argument}, @code{Directory}, @code{Entry}, or +@code{Modified} requests, if they have been sent. The +last @code{Directory} sent specifies the working directory at the time +of the operation. + +Note that this request does not actually do anything to the repository; +the only effect of a successful @code{remove} request is to supply the +client with a new entries line containing @samp{-} to indicate a removed +file. In fact, the client probably could perform this operation without +contacting the server, although using @code{remove} may cause the server +to perform a few more checks. + +The client sends a subsequent @code{ci} request to actually record the +removal in the repository. + @item watch-on \n @itemx watch-off \n @itemx watch-add \n |
