Import cvs-1.9.10

4 files changed, 256 insertions, 12 deletions

diff --git a/contrib/cvs/doc/ChangeLog b/contrib/cvs/doc/ChangeLog
index a8cb3e2..c56c253 100644
--- a/contrib/cvs/doc/ChangeLog
+++ b/contrib/cvs/doc/ChangeLog
@@ -1,3 +1,61 @@
+Wed Jun 18 00:03:25 1997  Jim Kingdon  <kingdon@harvey.cyclic.com>
+
+	* cvs.texinfo (Password authentication server): Document
+	--allow-root.
+
+Tue Jun 17 09:58:03 1997  Jim Kingdon  <kingdon@harvey.cyclic.com>
+
+	* cvs.texinfo (Error messages): Add "unknown option" from RCS.
+
+Fri Jun 13 12:11:09 1997  Jim Kingdon  <kingdon@harvey.cyclic.com>
+
+	* cvs.texinfo (Global options): Add note about how -n might affect
+	CVS's output.
+
+Thu Jun 12 09:33:40 1997  Jim Kingdon  <kingdon@harvey.cyclic.com>
+
+	* cvs.texinfo (Other problems): New node.  Add discussion of
+	problem with old rcsmerge.
+
+	* cvs.texinfo (Environment variables): Add CVSUMASK.
+
+Mon Jun  2 18:39:57 1997  Jim Kingdon  <kingdon@harvey.cyclic.com>
+
+	* cvs.texinfo (Moving a repository): New node.
+
+Tue May 27 18:27:57 1997  Jim Kingdon  <kingdon@harvey.cyclic.com>
+
+	* cvs.texinfo (Working directory storage): Add comment about
+	timestamps.
+	* cvsclient.texi (Responses): Add Mod-time.
+
+Mon May 26 10:04:32 1997  Jim Kingdon  <kingdon@harvey.cyclic.com>
+
+	* cvs.texinfo (Wrappers): Add comment concerning -t/-f and
+	client/server.
+
+Sun May 25 00:08:39 1997  Jim Kingdon  <kingdon@harvey.cyclic.com>
+
+	* cvs.texinfo (Multiple vendor branches): New node.
+	(First import, import options, Invoking CVS): xref to it.
+
+Sat May 24 23:47:47 1997  Jim Kingdon  <kingdon@harvey.cyclic.com>
+
+	* cvs.texinfo (File permissions): Add comment about group
+	ownership in repository and setgid bit on directories.
+
+Fri May 23 17:14:05 1997  Jim Kingdon  <kingdon@harvey.cyclic.com>
+
+	* RCSFILES: Fix typo in dead newphrase description ("an" -> "a").
+
+Fri May 23 16:33:38 1997  Ian Lance Taylor  <ian@cygnus.com>
+
+	* RCSFILES: Mention dead as a newphrase.
+
+Fri May 23 09:45:39 1997  Jim Kingdon  <kingdon@harvey.cyclic.com>
+
+	* cvs.texinfo (Builds): In comment, update URL of mk.
+
 Thu May 22 09:25:56 1997  Jim Kingdon  <kingdon@harvey.cyclic.com>
 
 	* cvs.texinfo (Error messages): Add comment about yet another way
diff --git a/contrib/cvs/doc/RCSFILES b/contrib/cvs/doc/RCSFILES
index 90a023f..5d9c7f7 100644
--- a/contrib/cvs/doc/RCSFILES
+++ b/contrib/cvs/doc/RCSFILES
@@ -53,6 +53,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.
 
 The rules regarding keyword expansion are not documented along with
 the rest of the RCS file format; they are documented in the co(1)
diff --git a/contrib/cvs/doc/cvs.texinfo b/contrib/cvs/doc/cvs.texinfo
index 43f6606..b087f3f 100644
--- a/contrib/cvs/doc/cvs.texinfo
+++ b/contrib/cvs/doc/cvs.texinfo
@@ -980,6 +980,7 @@ user-defined modules.
 * Multiple repositories::       Multiple repositories
 * Creating a repository::       Creating a repository
 * Backing up::                  Backing up a repository
+* Moving a repository::         Moving a repository
 * Remote repositories::         Accessing repositories on remote machines
 * Read-only access::            Granting read-only access to the repository
 * Server temporary directory::  The server creates temporary directories
@@ -1224,6 +1225,18 @@ 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 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
+@c repository.  Need to talk about group ownership of
+@c newly-created directories/files (on some unices,
+@c such as SunOS4, setting the setgid bit on the
+@c directories will make files inherit the directory's
+@c group.  On other unices, your mileage may vary.  I
+@c can't remember what POSIX says about this, if
+@c anything).
 
 Note that using the client/server @sc{cvs}
 (@pxref{Remote repositories}), there is no good way to
@@ -1292,6 +1305,13 @@ non-@code{dead} state.
 @node Working directory storage
 @section How data is stored in the working directory
 
+@c FIXME: Somewhere we should discuss timestamps (test
+@c case "stamps" in sanity.sh).  But not here.  Maybe
+@c in some kind of "working directory" chapter which
+@c would encompass the "Builds" one?  But I'm not sure
+@c whether that is a good organization (is it based on
+@c what the user wants to do?).
+
 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
@@ -1756,6 +1776,41 @@ what has changed, and then when you are ready, commit
 the changes into the repository.
 @end itemize
 
+@node Moving a repository
+@section Moving a repository
+@cindex repository, moving
+@cindex moving a repository
+@cindex copying a repository
+
+Just as backing up the files in the repository is
+pretty much like backing up any other files, if you
+need to move a repository from one place to another it
+is also pretty much like just moving any other
+collection of files.
+
+The main thing to consider is that working directories
+point to the repository.  The simplest way to deal with
+a moved repository is to just get a fresh working
+directory after the move.  Of course, you'll want to
+make sure that the old working directory had been
+checked in before the move, or you figured out some
+other way to make sure that you don't lose any
+changes.  If you really do want to reuse the existing
+working directory, it should be possible with manual
+surgery on the @file{CVS/Repository} files.  You can
+see @ref{Working directory storage}, for information on
+the @file{CVS/Repository} and @file{CVS/Root} files, but
+unless you are sure you want to bother, it probably
+isn't worth it.
+@c FIXME: This should be made unnecessary by:
+@c 1) a new -d should affect CVS/Root files throughout
+@c the tree, not just at the top level.
+@c 2) the RELATIVE_REPOS code should be fixed and made the
+@c default.  I think that CVS already reads
+@c CVS/Repository files which are absolute or
+@c relative.  FIXME: needs more investigation and
+@c documentation in "Working directory storage".
+
 @c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 @node Remote repositories
 @section Remote repositories
@@ -1993,13 +2048,19 @@ single line in @file{inetd.conf}) should be sufficient:
 
 @example
 2401  stream  tcp  nowait  root  /usr/local/bin/cvs
-cvs -b /usr/local/bin pserver
+cvs -b /usr/local/bin --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
 @samp{-T} option to specify a temporary directory.
 
+The @samp{--allow-root} option specifies the allowable
+@sc{cvsroot} directory.  Clients which attempt to use a
+different @sc{cvsroot} directory will not be allowed to
+connect.  If there is more than one @sc{cvsroot}
+directory which you want to allow, repeat the option.
+
         If your @code{inetd} wants a symbolic service
 name instead of a raw port number, then put this in
 @file{/etc/services}:
@@ -2108,6 +2169,8 @@ passwd} command.
 @c would open up a can of worms in that the users next
 @c questions are likely to be "where do I get it?" and
 @c "how do I use it?"
+@c Also note that htpasswd, at least the version I had,
+@c likes to clobber the third field.
 
 @node Password authentication client
 @subsubsection Using the client with password authentication
@@ -4938,6 +5001,7 @@ revision.
 * 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 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@@ -4953,7 +5017,7 @@ command to track third-party sources, the @dfn{vendor
 tag} and @dfn{release tags} are useful.  The
 @dfn{vendor tag} is a symbolic name for the branch
 (which is always 1.1.1, unless you use the @samp{-b
-@var{branch}} flag---@xref{import options}.).  The
+@var{branch}} flag---@xref{Multiple vendor branches}.).  The
 @dfn{release tags} are symbolic names for a particular
 release, such as @samp{FSF_0_04}.
 
@@ -5085,6 +5149,58 @@ and use the @samp{-k} option to @code{cvs update} or
 @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
@@ -6062,8 +6178,11 @@ is Odin (see
 @c Of course, many non-CVS systems have this kind of
 @c functionality, for example OSF's ODE
 @c (http://www.osf.org/ode/) or mk
-@c (http://www.io.org/~pzi/heading.html;
-@c ftp://ftp.interlog.com/pub/unix/mk is out of date).  But I'm not sure
+@c (http://www.grin.net/~pzi/mk-3.18.4.docs/mk_toc.html
+@c He has changed providers in the past; a search engine search
+@c for "Peter Ziobrzynski" probably won't get too many
+@c spurious hits :-).  A more stable URL might be
+@c ftp://ftp.uu.net/pub/cmvc/mk).  But I'm not sure
 @c there is any point in mentioning them here unless they
 @c can work with CVS.
 
@@ -6380,6 +6499,10 @@ The available @samp{cvs_options} (that are given to the
 left of @samp{cvs_command}) are:
 
 @table @code
+@item --allow-root=@var{rootdir}
+Specify legal @sc{cvsroot} directory.  See
+@ref{Password authentication server}.
+
 @cindex RCSBIN, overriding
 @cindex Overriding RCSBIN
 @item -b @var{bindir}
@@ -6442,6 +6565,12 @@ Do not change any files.  Attempt to execute the
 @samp{cvs_command}, but only to issue reports; do not remove,
 update, or merge any existing files, or create any new files.
 
+Note that @sc{cvs} will not necessarily produce exactly
+the same output as without @samp{-n}.  In some cases
+the output will be the same, but in other cases
+@sc{cvs} will skip some of the processing that would
+have been required to produce the exact same output.
+
 @item -Q
 Cause the command to be really quiet; the command will only
 generate output for serious problems.
@@ -8068,13 +8197,7 @@ There are three additional special options.
 
 @table @code
 @item -b @var{branch}
-Specify a first-level branch other than 1.1.1.  Unless
-the @samp{-b @var{branch}} flag is given, revisions will
-@emph{always} be made to the branch 1.1.1---even if a
-@var{vendortag} that matches another branch is given!
-What happens in that case, is that the tag will be
-reset to 1.1.1.  Warning: This behavior might change
-in the future.
+See @ref{Multiple vendor branches}.
 
 @item -k @var{subst}
 Indicate the RCS keyword expansion mode desired.  This
@@ -9400,7 +9523,7 @@ Import files into CVS, using vendor branches.  See
 @table @code
 @item -b @var{bra}
 Import to vendor branch @var{bra}.  See
-@ref{import options}.
+@ref{Multiple vendor branches}.
 
 @item -d
 Use the file's modification time as the time of
@@ -9957,6 +10080,10 @@ with the @code{-t} flag) and the other when the file is
 checked out of the repository (this is denoted with the
 @code{-f} flag).  The @samp{-t}/@samp{-f} feature does
 not work with client/server @sc{cvs}.
+@c I think maybe -t/-f works client/server if a single
+@c file converts to/from a single file, as opposed to
+@c the file<->directory case.  Could use more
+@c investigation...
 
 The @file{cvswrappers} also has a @samp{-m} option to
 specify the merge methodology that should be used when
@@ -10902,6 +11029,10 @@ try hard to make the files in your working directory
 read-only.  When this is not set, the default behavior
 is to permit modification of your working files.
 
+@item $CVSUMASK
+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}
@@ -11057,8 +11188,16 @@ argument lists of most @sc{rcs} commands.
 @node Troubleshooting
 @appendix Troubleshooting
 
+If you are having trouble with @sc{cvs}, this appendix
+may help.  If there is a particular error message which
+you are seeing, then you can look up the message
+alphabetically.  If not, you can look through the
+section on other problems to see if your problem is
+mentioned there.
+
 @menu
 * Error messages::              Partial list of CVS errors
+* Other problems::              Problems not readily listed by error message
 @end menu
 
 @ignore
@@ -11185,6 +11324,16 @@ every place it appears in your @code{modules}
 file.  For more information on the @code{modules} file,
 see @ref{modules}.
 
+@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
+@sc{rcs} (probably supplied with your operating
+system).  CVS only works with @sc{rcs} version 5 and
+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).
+
 @item cvs [server aborted]: received broken pipe signal
 This message seems to be caused by a hard-to-track-down
 bug in @sc{cvs} or the systems it runs on (we don't
@@ -11244,6 +11393,23 @@ exit 0
 @c potentially confusing for the new user.
 @end table
 
+@node Other problems
+@appendixsec Other common problems
+
+Here is a list of problems which cannot be readily
+looked up based on an error message.  They are in no
+particular order.
+
+@itemize @bullet
+@item
+If @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.
+@end itemize
+
 @c ---------------------------------------------------------------------
 @node Copying
 @appendix GNU GENERAL PUBLIC LICENSE
diff --git a/contrib/cvs/doc/cvsclient.texi b/contrib/cvs/doc/cvsclient.texi
index 0d80788..d0aac35 100644
--- a/contrib/cvs/doc/cvsclient.texi
+++ b/contrib/cvs/doc/cvsclient.texi
@@ -1100,6 +1100,23 @@ This @var{mode} applies to the next file mentioned in
 @code{Checked-in}, @code{New-entry}, @code{Updated}, @code{Merged}, or
 @code{Patched} response.
 
+@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
+@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
+format is:
+
+@example
+26 May 1997 13:01:40 -0400
+@end example
+
+There is no requirement that the client and server clocks be
+synchronized.  The server just sends its recommendation for a timestamp
+(based on its own clock, presumably), and the client should just believe
+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