cvs: Remove info pages (one converted to man page)
authorJohn Marino <draco@marino.st>
Fri, 3 Apr 2015 07:30:58 +0000 (09:30 +0200)
committerJohn Marino <draco@marino.st>
Fri, 3 Apr 2015 08:53:19 +0000 (10:53 +0200)
As the start of an effort to remove info pages and texinfo from the
system, the cvsclient info page has been converted to a man page.
The cvs info page was not converted since it appears to be equivalent
to the already existing man page.

Entries were added to Makefile_upgrade.inc, but when all the info pages
are gone, those entries will be replaced by a single directory line -
to remove /usr/share/info

Makefile_upgrade.inc
gnu/usr.bin/cvs/Makefile
gnu/usr.bin/cvs/cvs/Makefile
gnu/usr.bin/cvs/cvs/cvsclient.7 [new file with mode: 0644]
gnu/usr.bin/cvs/doc/Makefile [deleted file]

index 8b98323..aed1b7c 100644 (file)
@@ -3016,6 +3016,8 @@ TO_REMOVE+=/usr/share/nls/zh_HK.Big5HKSCS
 TO_REMOVE+=/usr/share/nls/zh_HK.UTF-8
 TO_REMOVE+=/usr/share/nls/zh_TW.Big5
 TO_REMOVE+=/usr/share/nls/zh_TW.UTF-8
+TO_REMOVE+=/usr/share/info/cvs.info.gz
+TO_REMOVE+=/usr/share/info/cvsclient.info.gz
 
 .if ${MACHINE_ARCH} == "x86_64"
 TO_REMOVE+=/usr/sbin/stlstats
index 8150a9f..6387bea 100644 (file)
@@ -1,6 +1,5 @@
 # $FreeBSD: src/gnu/usr.bin/cvs/Makefile,v 1.13.2.3 2002/12/19 21:18:01 peter Exp $
-# $DragonFly: src/gnu/usr.bin/cvs/Makefile,v 1.4 2005/09/10 11:55:42 asmodai Exp $
 
-SUBDIR = lib libdiff cvs contrib doc
+SUBDIR = lib libdiff cvs contrib
 
 .include <bsd.subdir.mk>
index 700a1d2..f2238e9 100644 (file)
@@ -9,7 +9,7 @@
 .PATH: ${CVSDIR}
 
 PROG=  cvs
-MAN=   cvs.1 cvs.5
+MAN=   cvs.1 cvs.5 cvsclient.7
 
 SRCS=  add.c admin.c annotate.c buffer.c \
        checkin.c checkout.c classify.c client.c \
diff --git a/gnu/usr.bin/cvs/cvs/cvsclient.7 b/gnu/usr.bin/cvs/cvs/cvsclient.7
new file mode 100644 (file)
index 0000000..2e86f45
--- /dev/null
@@ -0,0 +1,2146 @@
+.\" Automatically generated by Pod::Man 2.27 (Pod::Simple 3.28)
+.\"
+.\" Standard preamble:
+.\" ========================================================================
+.de Sp \" Vertical space (when we can't use .PP)
+.if t .sp .5v
+.if n .sp
+..
+.de Vb \" Begin verbatim text
+.ft CW
+.nf
+.ne \\$1
+..
+.de Ve \" End verbatim text
+.ft R
+.fi
+..
+.\" Set up some character translations and predefined strings.  \*(-- will
+.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
+.\" double quote, and \*(R" will give a right double quote.  \*(C+ will
+.\" give a nicer C++.  Capital omega is used to do unbreakable dashes and
+.\" therefore won't be available.  \*(C` and \*(C' expand to `' in nroff,
+.\" nothing in troff, for use with C<>.
+.tr \(*W-
+.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
+.ie n \{\
+.    ds -- \(*W-
+.    ds PI pi
+.    if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
+.    if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\"  diablo 12 pitch
+.    ds L" ""
+.    ds R" ""
+.    ds C` ""
+.    ds C' ""
+'br\}
+.el\{\
+.    ds -- \|\(em\|
+.    ds PI \(*p
+.    ds L" ``
+.    ds R" ''
+.    ds C`
+.    ds C'
+'br\}
+.\"
+.\" Escape single quotes in literal strings from groff's Unicode transform.
+.ie \n(.g .ds Aq \(aq
+.el       .ds Aq '
+.\"
+.\" If the F register is turned on, we'll generate index entries on stderr for
+.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
+.\" entries marked with X<> in POD.  Of course, you'll have to process the
+.\" output yourself in some meaningful fashion.
+.\"
+.\" Avoid warning from groff about undefined register 'F'.
+.de IX
+..
+.nr rF 0
+.if \n(.g .if rF .nr rF 1
+.if (\n(rF:(\n(.g==0)) \{
+.    if \nF \{
+.        de IX
+.        tm Index:\\$1\t\\n%\t"\\$2"
+..
+.        if !\nF==2 \{
+.            nr % 0
+.            nr F 2
+.        \}
+.    \}
+.\}
+.rr rF
+.\"
+.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
+.\" Fear.  Run.  Save yourself.  No user-serviceable parts.
+.    \" fudge factors for nroff and troff
+.if n \{\
+.    ds #H 0
+.    ds #V .8m
+.    ds #F .3m
+.    ds #[ \f1
+.    ds #] \fP
+.\}
+.if t \{\
+.    ds #H ((1u-(\\\\n(.fu%2u))*.13m)
+.    ds #V .6m
+.    ds #F 0
+.    ds #[ \&
+.    ds #] \&
+.\}
+.    \" simple accents for nroff and troff
+.if n \{\
+.    ds ' \&
+.    ds ` \&
+.    ds ^ \&
+.    ds , \&
+.    ds ~ ~
+.    ds /
+.\}
+.if t \{\
+.    ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
+.    ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
+.    ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
+.    ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
+.    ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
+.    ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
+.\}
+.    \" troff and (daisy-wheel) nroff accents
+.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
+.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
+.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
+.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
+.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
+.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
+.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
+.ds ae a\h'-(\w'a'u*4/10)'e
+.ds Ae A\h'-(\w'A'u*4/10)'E
+.    \" corrections for vroff
+.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
+.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
+.    \" for low resolution devices (crt and lpr)
+.if \n(.H>23 .if \n(.V>19 \
+\{\
+.    ds : e
+.    ds 8 ss
+.    ds o a
+.    ds d- d\h'-1'\(ga
+.    ds D- D\h'-1'\(hy
+.    ds th \o'bp'
+.    ds Th \o'LP'
+.    ds ae ae
+.    ds Ae AE
+.\}
+.rm #[ #] #H #V #F C
+.\" ========================================================================
+.\"
+.IX Title "CVSCLIENT 7"
+.TH CVSCLIENT 7 "2015-04-03" "perl v5.18.4" "DragonFly Miscellaneous Information Manual"
+.\" For nroff, turn off justification.  Always turn off hyphenation; it makes
+.\" way too many mistakes in technical documents.
+.if n .ad l
+.nh
+.SH "NAME"
+CVS Client/Server Reference Manual \- Conversion of cvsclient.info
+.SH "CVS Client/Server"
+.IX Header "CVS Client/Server"
+This document describes the client/server protocol used by \s-1CVS. \s0 It does
+not describe how to use or administer client/server \s-1CVS\s0; see the regular
+\&\s-1CVS\s0 manual for that.  This is version 1.12.13 of the protocol
+specification\*(--see \*(L"Introduction\*(R", for more on what this version
+number means.
+.PP
+* Menu:
+.PP
+What is \s-1CVS\s0 and what is the client/server protocol for?: see \*(L"Introduction\*(R"
+.PP
+Basic design decisions, requirements, scope, etc.: see \*(L"Goals\*(R"
+.PP
+Various ways to connect to the server: see \*(L"Connection and Authentication\*(R"
+.PP
+Scrambling used by pserver: see \*(L"Password scrambling\*(R"
+.PP
+Complete description of the protocol: see \*(L"Protocol\*(R"
+.PP
+Possible enhancements, limitations, etc. of the protocol: see \*(L"Protocol Notes\*(R"
+.SS "1 Introduction"
+.IX Subsection "1 Introduction"
+\&\s-1CVS\s0 is a version control system (with some additional configuration
+management functionality).  It maintains a central \*(L"repository\*(R" which
+stores files (often source code), including past versions, information
+about who modified them and when, and so on.  People who wish to look
+at or modify those files, known as \*(L"developers\*(R", use \s-1CVS\s0 to \*(L"check out\*(R"
+a \*(L"working directory\*(R" from the repository, to \*(L"check in\*(R" new versions
+of files to the repository, and other operations such as viewing the
+modification history of a file.  If developers are connected to the
+repository by a network, particularly a slow or flaky one, the most
+efficient way to use the network is with the CVS-specific protocol
+described in this document.
+.PP
+Developers, using the machine on which they store their working
+directory, run the \s-1CVS \s0\*(L"client\*(R" program.  To perform operations which
+cannot be done locally, it connects to the \s-1CVS \s0\*(L"server\*(R" program, which
+maintains the repository.  For more information on how to connect see
+see \*(L"Connection and Authentication\*(R".
+.PP
+This document describes the \s-1CVS\s0 protocol.  Unfortunately, it does not
+yet completely document one aspect of the protocol\*(--the detailed
+operation of each \s-1CVS\s0 command and option\*(--and one must look at the \s-1CVS\s0
+user documentation, `\fBcvs.texinfo\fR', for that information.  The protocol
+is non-proprietary (anyone who wants to is encouraged to implement it)
+and an implementation, known as \s-1CVS,\s0 is available under the \s-1GNU\s0 Public
+License.  The \s-1CVS\s0 distribution, containing this implementation,
+`\fBcvs.texinfo\fR', and a copy (possibly more or less up to date than what
+you are reading now) of this document, `\fBcvsclient.texi\fR', can be found
+at the usual \s-1GNU FTP\s0 sites, with a filename such as
+`\fBcvs\-VERSION.tar.gz\fR'.
+.PP
+This is version 1.12.13 of the protocol specification.  This version
+number is intended only to aid in distinguishing different versions of
+this specification.  Although the specification is currently maintained
+in conjunction with the \s-1CVS\s0 implementation, and carries the same
+version number, it also intends to document what is involved with
+interoperating with other implementations (such as other versions of
+\&\s-1CVS\s0); see see \*(L"Requirements\*(R".  This version number should not be used
+by clients or servers to determine what variant of the protocol to
+speak; they should instead use the `\fBvalid-requests\fR' and
+`\fBValid-responses\fR' mechanism (see \*(L"Protocol\*(R"), which is more flexible.
+.SS "2 Goals"
+.IX Subsection "2 Goals"
+* Do not assume any access to the repository other than via this
+protocol.  It does not depend on \s-1NFS,\s0 rdist, etc.
+.PP
+* Providing a reliable transport is outside this protocol.  The
+protocol expects a reliable transport that is transparent (that
+is, there is no translation of characters, including characters
+such as linefeeds or carriage returns), and can transmit all 256
+octets (for example for proper handling of binary files,
+compression, and encryption).  The encoding of characters
+specified by the protocol (the names of requests and so on) is the
+invariant \s-1ISO 646\s0 character set (a subset of most popular
+character sets including \s-1ASCII\s0 and others).  For more details on
+running the protocol over the \s-1TCP\s0 reliable transport, see *note
+Connection and Authentication::.
+.PP
+* Security and authentication are handled outside this protocol (but
+see below about `\fBcvs kserver\fR' and `\fBcvs pserver\fR').
+.PP
+* The protocol makes it possible for updates to be atomic with
+respect to checkins; that is if someone commits changes to several
+files in one cvs command, then an update by someone else would
+either get all the changes, or none of them.  The current \s-1CVS\s0
+server can't do this, but that isn't the protocol's fault.
+.PP
+* The protocol is, with a few exceptions, transaction-based.  That
+is, the client sends all its requests (without waiting for server
+responses), and then waits for the server to send back all
+responses (without waiting for further client requests).  This has
+the advantage of minimizing network turnarounds and the
+disadvantage of sometimes transferring more data than would be
+necessary if there were a richer interaction.  Another, more
+subtle, advantage is that there is no need for the protocol to
+provide locking for features such as making checkins atomic with
+respect to updates.  Any such locking can be handled entirely by
+the server.  A good server implementation (such as the current \s-1CVS\s0
+server) will make sure that it does not have any such locks in
+place whenever it is waiting for communication with the client;
+this prevents one client on a slow or flaky network from
+interfering with the work of others.
+.PP
+* It is a general design goal to provide only one way to do a given
+operation (where possible).  For example, implementations have no
+choice about whether to terminate lines with linefeeds or some
+other character(s), and request and response names are
+case-sensitive.  This is to enhance interoperability.  If a
+protocol allows more than one way to do something, it is all too
+easy for some implementations to support only some of them
+(perhaps accidentally).
+.SS "3 How to Connect to and Authenticate Oneself to the \s-1CVS\s0 server"
+.IX Subsection "3 How to Connect to and Authenticate Oneself to the CVS server"
+Connection and authentication occurs before the \s-1CVS\s0 protocol itself is
+started.  There are several ways to connect.
+.PP
+server
+If the client has a way to execute commands on the server, and
+provide input to the commands and output from them, then it can
+connect that way.  This could be the usual rsh (port 514)
+protocol, Kerberos rsh, \s-1SSH,\s0 or any similar mechanism.  The client
+may allow the user to specify the name of the server program; the
+default is `\fBcvs\fR'.  It is invoked with one argument, `\fBserver\fR'.
+Once it invokes the server, the client proceeds to start the cvs
+protocol.
+.PP
+kserver
+The kerberized server listens on a port (in the current
+implementation, by having inetd call \*(L"cvs kserver\*(R") which defaults
+to 1999.  The client connects, sends the usual kerberos
+authentication information, and then starts the cvs protocol.
+Note: port 1999 is officially registered for another use, and in
+any event one cannot register more than one port for \s-1CVS,\s0 so
+GSS-API (see below) is recommended instead of kserver as a way to
+support kerberos.
+.PP
+pserver
+The name \*(L"pserver\*(R" is somewhat confusing.  It refers to both a
+generic framework which allows the \s-1CVS\s0 protocol to support several
+authentication mechanisms, and a name for a specific mechanism
+which transfers a username and a cleartext password.  Servers need
+not support all mechanisms, and in fact servers will typically
+want to support only those mechanisms which meet the relevant
+security needs.
+.PP
+The pserver server listens on a port (in the current
+implementation, by having inetd call \*(L"cvs pserver\*(R") which defaults
+to 2401 (this port is officially registered).  The client
+connects, and sends the following:
+.PP
+* the string `\fB\s-1BEGIN AUTH REQUEST\s0\fR', a linefeed,
+.PP
+* the cvs root, a linefeed,
+.PP
+* the username, a linefeed,
+.PP
+* the password trivially encoded (see *note Password
+scrambling::), a linefeed,
+.PP
+* the string `\fB\s-1END AUTH REQUEST\s0\fR', and a linefeed.
+.PP
+The client must send the identical string for cvs root both here
+and later in the `\fBRoot\fR' request of the cvs protocol itself.
+Servers are encouraged to enforce this restriction.  The possible
+server responses (each of which is followed by a linefeed) are the
+following.  Note that although there is a small similarity between
+this authentication protocol and the cvs protocol, they are
+separate.
+.PP
+`\fBI \s-1LOVE YOU\s0\fR'
+The authentication is successful.  The client proceeds with
+the cvs protocol itself.
+.PP
+`\fBI \s-1HATE YOU\s0\fR'
+The authentication fails.  After sending this response, the
+server may close the connection.  It is up to the server to
+decide whether to give this response, which is generic, or a
+more specific response using `\fBE\fR' and/or `\fBerror\fR'.
+.PP
+`\fBE \s-1TEXT\s0\fR'
+Provide a message for the user.  After this reponse, the
+authentication protocol continues with another response.
+Typically the server will provide a series of `\fBE\fR' responses
+followed by `\fBerror\fR'.  Compatibility note: \s-1CVS 1.9.10\s0 and
+older clients will print `\fBunrecognized auth response\fR' and
+\&\s-1TEXT,\s0 and then exit, upon receiving this response.
+.PP
+`\fBerror \s-1CODE TEXT\s0\fR'
+The authentication fails.  After sending this response, the
+server may close the connection.  The \s-1CODE\s0 is a code
+describing why it failed, intended for computer consumption.
+The only code currently defined is `\fB0\fR' which is nonspecific,
+but clients must silently treat any unrecognized codes as
+nonspecific.  The \s-1TEXT\s0 should be supplied to the user.
+Compatibility note: \s-1CVS 1.9.10\s0 and older clients will print
+`\fBunrecognized auth response\fR' and \s-1TEXT,\s0 and then exit, upon
+receiving this response.  Note that \s-1TEXT\s0 for this response,
+or the \s-1TEXT\s0 in an `\fBE\fR' response, is not designed for machine
+parsing.  More vigorous use of \s-1CODE,\s0 or future extensions,
+will be needed to prove a cleaner machine-parseable
+indication of what the error was.
+.PP
+If the client wishes to merely authenticate without starting the
+cvs protocol, the procedure is the same, except \s-1BEGIN AUTH REQUEST\s0
+is replaced with \s-1BEGIN VERIFICATION REQUEST, END AUTH REQUEST\s0 is
+replaced with \s-1END VERIFICATION REQUEST,\s0 and upon receipt of I \s-1LOVE
+YOU\s0 the connection is closed rather than continuing.
+.PP
+Another mechanism is \s-1GSSAPI\s0 authentication.  \s-1GSSAPI\s0 is a generic
+interface to security services such as kerberos.  \s-1GSSAPI\s0 is
+specified in \s-1RFC2078 \s0(\s-1GSSAPI\s0 version 2) and \s-1RFC1508 \s0(\s-1GSSAPI\s0
+version 1); we are not aware of differences between the two which
+affect the protocol in incompatible ways, so we make no attempt to
+specify one version or the other.  The procedure here is to start
+with `\fB\s-1BEGIN GSSAPI REQUEST\s0\fR'.  \s-1GSSAPI\s0 authentication information is
+then exchanged between the client and the server.  Each packet of
+information consists of a two byte big endian length, followed by
+that many bytes of data.  After the \s-1GSSAPI\s0 authentication is
+complete, the server continues with the responses described above
+(`\fBI \s-1LOVE YOU\s0\fR', etc.).
+.PP
+future possibilities
+There are a nearly unlimited number of ways to connect and
+authenticate.  One might want to allow access based on \s-1IP\s0 address
+(similar to the usual rsh protocol but with different/no
+restrictions on ports < 1024), to adopt mechanisms such as
+Pluggable Authentication Modules (\s-1PAM\s0), to allow users to run
+their own servers under their own usernames without root access,
+or any number of other possibilities.  The way to add future
+mechanisms, for the most part, should be to continue to use port
+2401, but to use different strings in place of `\s-1BEGIN AUTH
+REQUEST\s0'.
+.SS "4 Password scrambling algorithm"
+.IX Subsection "4 Password scrambling algorithm"
+The pserver authentication protocol, as described in *note Connection
+and Authentication::, trivially encodes the passwords.  This is only to
+prevent inadvertent compromise; it provides no protection against even a
+relatively unsophisticated attacker.  For comparison, \s-1HTTP\s0 Basic
+Authentication (as described in \s-1RFC2068\s0) uses \s-1BASE64\s0 for a similar
+purpose.  \s-1CVS\s0 uses its own algorithm, described here.
+.PP
+The scrambled password starts with `\fBA\fR', which serves to identify the
+scrambling algorithm in use.  After that follows a single octet for
+each character in the password, according to a fixed encoding.  The
+values are shown here, with the encoded values in decimal.  Control
+characters, space, and characters outside the invariant \s-1ISO 646\s0
+character set are not shown; such characters are not recommended for use
+in passwords.  There is a long discussion of character set issues in
+see \*(L"Protocol Notes\*(R".
+.PP
+0 111           P 125           p  58
+! 120   1  52   A  57   Q  55   a 121   q 113
+"  53   2  75   B  83   R  54   b 117   r  32
+3 119   C  43   S  66   c 104   s  90
+4  49   D  46   T 124   d 101   t  44
+% 109   5  34   E 102   U 126   e 100   u  98
+&  72   6  82   F  40   V  59   f  69   v  60
+\&' 108   7  81   G  89   W  47   g  73   w  51
+(  70   8  95   H  38   X  92   h  99   x  33
+)  64   9  65   I 103   Y  71   i  63   y  97
+76   : see \*(L"112   J  45   Z 115   j  94   z  62\*(R"
+.PP
++  67   ;  86   K  50           k  93
+, 116   < 118   L  42           l  39
+\&\-  74   = 110   M 123           m  37
+\&.  68   > 122   N  91           n  61
+/  87   ? 105   O  35   _  56   o  48
+.SS "5 The \s-1CVS\s0 client/server protocol"
+.IX Subsection "5 The CVS client/server protocol"
+In the following, `\fB\en\fR' refers to a linefeed and `\fB\et\fR' refers to a
+horizontal tab; \*(L"requests\*(R" are what the client sends and \*(L"responses\*(R"
+are what the server sends.  In general, the connection is governed by
+the client\*(--the server does not send responses without first receiving
+requests to do so; see see \*(L"Response intro\*(R" for more details of this
+convention.
+.PP
+It is typical, early in the connection, for the client to transmit a
+`\fBValid-responses\fR' request, containing all the responses it supports,
+followed by a `\fBvalid-requests\fR' request, which elicits from the server a
+`\fBValid-requests\fR' response containing all the requests it understands.
+In this way, the client and server each find out what the other
+supports before exchanging large amounts of data (such as file
+contents).
+.PP
+* Menu:
+.PP
+General protocol conventions:
+.PP
+Transmitting \s-1RCS\s0 data: see \*(L"Entries Lines\*(R"
+.PP
+Read, write, execute, and possibly more...: see \*(L"File Modes\*(R"
+.PP
+Conventions regarding filenames: see \*(L"Filenames\*(R"
+.PP
+How file contents are transmitted: see \*(L"File transmissions\*(R"
+.PP
+Strings in various requests and responses: see \*(L"Strings\*(R"
+.PP
+Times and dates: see \*(L"Dates\*(R"
+.PP
+The protocol itself:
+.PP
+General conventions relating to requests: see \*(L"Request intro\*(R"
+.PP
+List of requests: see \*(L"Requests\*(R"
+.PP
+General conventions relating to responses: see \*(L"Response intro\*(R"
+.PP
+The \*(L"pathname\*(R" in responses: see \*(L"Response pathnames\*(R"
+.PP
+List of responses: see \*(L"Responses\*(R"
+.PP
+More details about the \s-1MT\s0 response: see \*(L"Text tags\*(R"
+.PP
+An example session, and some further observations:
+.PP
+A conversation between client and server: see \*(L"Example\*(R"
+.PP
+Things not to omit from an implementation: see \*(L"Requirements\*(R"
+.PP
+Former protocol features: see \*(L"Obsolete\*(R"
+.PP
+\&\fB5.1 Entries Lines\fR
+.PP
+Entries lines are transmitted as:
+.PP
+/ \s-1NAME / VERSION / CONFLICT / OPTIONS / TAG_OR_DATE\s0
+.PP
+\&\s-1TAG_OR_DATE\s0 is either `\fBT\fR' \s-1TAG\s0 or `\fBD\fR' \s-1DATE\s0 or empty.  If it is
+followed by a slash, anything after the slash shall be silently ignored.
+.PP
+\&\s-1VERSION\s0 can be empty, or start with `\fB0\fR' or `\fB\-\fR', for no user file,
+new user file, or user file to be removed, respectively.
+.PP
+\&\s-1CONFLICT,\s0 if it starts with `\fB+\fR', indicates that the file had
+conflicts in it.  The rest of \s-1CONFLICT\s0 is `\fB=\fR' if the timestamp matches
+the file, or anything else if it doesn't.  If \s-1CONFLICT\s0 does not start
+with a `\fB+\fR', it is silently ignored.
+.PP
+\&\s-1OPTIONS\s0 signifies the keyword expansion options (for example `\fB\-ko\fR').
+In an `\fBEntry\fR' request, this indicates the options that were specified
+with the file from the previous file updating response (*note Response
+intro::, for a list of file updating responses); if the client is
+specifying the `\fB\-k\fR' or `\fB\-A\fR' option to `\fBupdate\fR', then it is the server
+which figures out what overrides what.
+.PP
+\&\fB5.2 File Modes\fR
+.PP
+A mode is any number of repetitions of
+.PP
+MODE-TYPE = \s-1DATA\s0
+.PP
+separated by `\fB,\fR'.
+.PP
+MODE-TYPE is an identifier composed of alphanumeric characters.
+Currently specified: `\fBu\fR' for user, `\fBg\fR' for group, `\fBo\fR' for other (see
+below for discussion of whether these have their \s-1POSIX\s0 meaning or are
+more loose).  Unrecognized values of MODE-TYPE are silently ignored.
+.PP
+\&\s-1DATA\s0 consists of any data not containing `\fB,\fR', `\fB\e0\fR' or `\fB\en\fR'.  For
+`\fBu\fR', `\fBg\fR', and `\fBo\fR' mode types, data consists of alphanumeric characters,
+where `\fBr\fR' means read, `\fBw\fR' means write, `\fBx\fR' means execute, and
+unrecognized letters are silently ignored.
+.PP
+The two most obvious ways in which the mode matters are: (1) is it
+writeable?  This is used by the developer communication features, and
+is implemented even on \s-1OS/2 \s0(and could be implemented on \s-1DOS\s0), whose
+notion of mode is limited to a readonly bit. (2) is it executable?
+Unix \s-1CVS\s0 users need \s-1CVS\s0 to store this setting (for shell scripts and
+the like).  The current \s-1CVS\s0 implementation on unix does a little bit
+more than just maintain these two settings, but it doesn't really have
+a nice general facility to store or version control the mode, even on
+unix, much less across operating systems with diverse protection
+features.  So all the ins and outs of what the mode means across
+operating systems haven't really been worked out (e.g. should the \s-1VMS\s0
+port use ACLs to get \s-1POSIX\s0 semantics for groups?).
+.PP
+\&\fB5.3 Conventions regarding transmission of file names\fR
+.PP
+In most contexts, `\fB/\fR' is used to separate directory and file names in
+filenames, and any use of other conventions (for example, that the user
+might type on the command line) is converted to that form.  The only
+exceptions might be a few cases in which the server provides a magic
+cookie which the client then repeats verbatim, but as the server has
+not yet been ported beyond unix, the two rules provide the same answer
+(and what to do if future server ports are operating on a repository
+like e:/foo or CVS_ROOT:[\s-1FOO.BAR\s0] has not been carefully thought out).
+.PP
+Characters outside the invariant \s-1ISO 646\s0 character set should be
+avoided in filenames.  This restriction may need to be relaxed to allow
+for characters such as `\fB[\fR' and `\fB]\fR' (see above about non-unix servers);
+this has not been carefully considered (and currently implementations
+probably use whatever character sets that the operating systems they
+are running on allow, and/or that users specify).  Of course the most
+portable practice is to restrict oneself further, to the \s-1POSIX\s0 portable
+filename character set as specified in \s-1POSIX.1.\s0
+.PP
+\&\fB5.4 File transmissions\fR
+.PP
+File contents (noted below as \s-1FILE TRANSMISSION\s0) can be sent in one of
+two forms.  The simpler form is a number of bytes, followed by a
+linefeed, followed by the specified number of bytes of file contents.
+These are the entire contents of the specified file.  Second, if both
+client and server support `\fBgzip-file-contents\fR', a `\fBz\fR' may precede the
+length, and the `\fBfile contents\fR' sent are actually compressed with
+`\fBgzip\fR' (\s-1RFC1952/1951\s0) compression.  The length specified is that of the
+compressed version of the file.
+.PP
+In neither case are the file content followed by any additional data.
+The transmission of a file will end with a linefeed iff that file (or
+its compressed form) ends with a linefeed.
+.PP
+The encoding of file contents depends on the value for the `\fB\-k\fR'
+option.  If the file is binary (as specified by the `\fB\-kb\fR' option in the
+appropriate place), then it is just a certain number of octets, and the
+protocol contributes nothing towards determining the encoding (using
+the file name is one widespread, if not universally popular, mechanism).
+If the file is text (not binary), then the file is sent as a series of
+lines, separated by linefeeds.  If the keyword expansion is set to
+something other than `\fB\-ko\fR', then it is expected that the file conform
+to the \s-1RCS\s0 expectations regarding keyword expansion\*(--in particular,
+that it is in a character set such as \s-1ASCII\s0 in which 0x24 is a dollar
+sign (`\fB$\fR').
+.PP
+\&\fB5.5 Strings\fR
+.PP
+In various contexts, for example the `\fBArgument\fR' request and the `\fBM\fR'
+response, one transmits what is essentially an arbitrary string.  Often
+this will have been supplied by the user (for example, the `\fB\-m\fR' option
+to the `\fBci\fR' request).  The protocol has no mechanism to specify the
+character set of such strings; it would be fairly safe to stick to the
+invariant \s-1ISO 646\s0 character set but the 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.
+.PP
+\&\fB5.6 Dates\fR
+.PP
+The protocol contains times and dates in various places.
+.PP
+For the `\fB\-D\fR' option to the `\fBannotate\fR', `\fBco\fR', `\fBdiff\fR', `\fBexport\fR',
+`\fBhistory\fR', `\fBrannotate\fR', `\fBrdiff\fR', `\fBrtag\fR', `\fBtag\fR', and `\fBupdate\fR' requests,
+the server should support two formats:
+.PP
+26 May 1997 13:01:40 \-0000  ; \s-1RFC 822\s0 as modified by \s-1RFC 1123
+5/26/1997 13:01:40 GMT    \s0; traditional
+.PP
+The former format is preferred; the latter however is sent by the \s-1CVS\s0
+command line client (versions 1.5 through at least 1.9).
+.PP
+For the `\fB\-d\fR' option to the `\fBlog\fR' and `\fBrlog\fR' requests, servers should
+at least support \s-1RFC 822/1123\s0 format.  Clients are encouraged to use
+this format too (the command line \s-1CVS\s0 client, version 1.10 and older,
+just passed along the date format specified by the user, however).
+.PP
+The `\fBMod-time\fR' response and `\fBCheckin-time\fR' request use \s-1RFC 822/1123\s0
+format (see the descriptions of that response and request for details).
+.PP
+For `\fBNotify\fR', see the description of that request.
+.PP
+\&\fB5.7 Request intro\fR
+.PP
+By convention, requests which begin with a capital letter do not elicit
+a response from the server, while all others do \- save one.  The
+exception is `\fBgzip-file-contents\fR'.  Unrecognized requests will always
+elicit a response from the server, even if that request begins with a
+capital letter.
+.PP
+The term \*(L"command\*(R" means a request which expects a response (except
+`\fBvalid-requests\fR').  The general model is that the client transmits a
+great number of requests, but nothing happens until the very end when
+the client transmits a command.  Although the intention is that
+transmitting several commands in one connection should be legal,
+existing servers probably have some bugs with some combinations of more
+than one command, and so clients may find it necessary to make several
+connections in some cases.  This should be thought of as a workaround
+rather than a desired attribute of the protocol.
+.PP
+\&\fB5.8 Requests\fR
+.PP
+Here are the requests:
+.PP
+`\fBRoot \s-1PATHNAME\s0 \en\fR'
+Response expected: no.  Tell the server which `\fB\s-1CVSROOT\s0\fR' to use.
+Note that \s-1PATHNAME\s0 is a local directory and _not_ a fully
+qualified `\fB\s-1CVSROOT\s0\fR' variable.  \s-1PATHNAME\s0 must already exist; if
+creating a new root, use the `\fBinit\fR' request, not `\fBRoot\fR'.  \s-1PATHNAME\s0
+does not include the hostname of the server, how to access the
+server, etc.; by the time the \s-1CVS\s0 protocol is in use, connection,
+authentication, etc., are already taken care of.
+.PP
+The `\fBRoot\fR' request must be sent only once, and it must be sent
+before any requests other than `\fBValid-responses\fR',
+`\fBvalid-requests\fR', `\fBUseUnchanged\fR', `\fBSet\fR', `\fBGlobal_option\fR', `\fBinit\fR',
+`\fBnoop\fR', or `\fBversion\fR'.
+.PP
+`\fBValid-responses REQUEST-LIST \en\fR'
+Response expected: no.  Tell the server what responses the client
+will accept.  request-list is a space separated list of tokens.
+The `\fBRoot\fR' request need not have been previously sent.
+.PP
+`\fBvalid-requests \en\fR'
+Response expected: yes.  Ask the server to send back a
+`\fBValid-requests\fR' response.  The `\fBRoot\fR' request need not have been
+previously sent.
+.PP
+`\fBCommand-prep \s-1COMMAND\s0 \en\fR'
+Response expected: yes.  Notify the server of the command that we
+are leading up to.  Intended to allow the server to send a
+redirect for write operations.  Requires either an `\fBok\fR' or
+`\fBRedirect\fR' respnose.
+.PP
+`\fBReferrer \s-1CVSROOT\s0 \en\fR'
+Response expected: no.  Notify a primary server of a server which
+referred us.  Intended to allow a primary (write) server to update
+the read-only mirror a client is using for reads to minimize races
+on any subsequent updates from the client.
+.PP
+`\fBDirectory LOCAL-DIRECTORY \en\fR'
+`\fBRelative-directory LOCAL-DIRECTORY \en\fR'
+Additional data: \s-1REPOSITORY\s0 \en.  Response expected: no.  Tell the
+server what directory to use.
+.PP
+The \s-1REPOSITORY\s0 should be a directory name from a previous server
+response and may be specified either relative to the \s-1PATHNAME\s0
+provided with the `\fBRoot\fR' request or absolute.  Relative or
+absolute, it must specify a path within \s-1PATHNAME.\s0
+.PP
+Prior to \s-1CVS\s0 version *FIXME \- release number 1.12.10?*, \s-1REPOSITORY\s0
+had to be absolute and `\fBRelative-directory\fR' was not a valid
+request.  The `\fBRelative-directory\fR' request is synonymous with
+`\fBDirectory\fR' and is provided to alert modern clients that a relative
+\&\s-1REPOSITORY\s0 is acceptable.
+.PP
+Note that this both gives a default for `\fBEntry\fR' and `\fBModified\fR' and
+also for `\fBci\fR' and the other commands; normal usage is to send
+`\fBDirectory\fR' for each directory in which there will be an `\fBEntry\fR'
+or `\fBModified\fR', and then a final `\fBDirectory\fR' for the original
+directory, then the command.  The LOCAL-DIRECTORY is relative to
+the top level at which the command is occurring (i.e. the last
+`\fBDirectory\fR' which is sent before the command); to indicate that
+top level, `\fB.\fR' should be sent for LOCAL-DIRECTORY.
+.PP
+Here is an example of where a client gets \s-1REPOSITORY\s0 and
+LOCAL-DIRECTORY.  Suppose that there is a module defined by
+.PP
+moddir 1dir
+.PP
+That is, one can check out `\fBmoddir\fR' and it will take `\fB1dir\fR' in the
+repository and check it out to `\fBmoddir\fR' in the working directory.
+Then an initial check out could proceed like this:
+.PP
+C: Root /home/kingdon/zwork/cvsroot
+\&. . .
+C: Argument moddir
+C: Directory .
+C: .
+C: co
+S: Clear-sticky moddir/
+S: 1dir/
+\&. . .
+S: ok
+.PP
+In this example the response shown is `\fBClear-sticky\fR', but it could
+be another response instead.  Note that it returns two pathnames.
+The first one, `\fBmoddir/\fR', indicates the working directory to check
+out into.  The second one, ending in `\fB1dir/\fR', indicates the
+directory to pass back to the server in a subsequent `\fBDirectory\fR'
+request.  For example, a subsequent `\fBupdate\fR' request might look
+like:
+.PP
+C: Directory moddir
+C: 1dir
+\&. . .
+C: update
+.PP
+For a given LOCAL-DIRECTORY, the repository will be the same for
+each of the responses, so one can use the repository from whichever
+response is most convenient.  Typically a client will store the
+repository along with the sources for each LOCAL-DIRECTORY, use
+that same setting whenever operating on that LOCAL-DIRECTORY, and
+not update the setting as long as the LOCAL-DIRECTORY exists.
+.PP
+A client is free to rename a LOCAL-DIRECTORY at any time (for
+example, in response to an explicit user request).  While it is
+true that the server supplies a LOCAL-DIRECTORY to the client, as
+noted above, this is only the default place to put the directory.
+Of course, the various `\fBDirectory\fR' requests for a single command
+(for example, `\fBupdate\fR' or `\fBci\fR' request) should name a particular
+directory with the same LOCAL-DIRECTORY.
+.PP
+Each `\fBDirectory\fR' request specifies a brand-new LOCAL-DIRECTORY and
+\&\s-1REPOSITORY\s0; that is, LOCAL-DIRECTORY and \s-1REPOSITORY\s0 are never
+relative to paths specified in any previous `\fBDirectory\fR' request.
+.PP
+Here's a more complex example, in which we request an update of a
+working directory which has been checked out from multiple places
+in the repository.
+.PP
+C: Argument dir1
+C: Directory dir1
+C: mod1
+\&. . .
+C: Argument dir2
+C: Directory dir2
+C: mod2
+\&. . .
+C: Argument dir3
+C: Directory dir3/subdir3
+C: mod3
+\&. . .
+C: update
+.PP
+While directories `\fBdir1\fR' and `\fBdir2\fR' will be handled in similar
+fashion to the other examples given above, `\fBdir3\fR' is slightly
+different from the server's standpoint.  Notice that module `\fBmod3\fR'
+is actually checked out into `\fBdir3/subdir3\fR', meaning that directory
+`\fBdir3\fR' is either empty or does not contain data checked out from
+this repository.
+.PP
+The above example will work correctly in \s-1CVS 1.10.1\s0 and later.  The
+server will descend the tree starting from all directories
+mentioned in `\fBArgument\fR' requests and update those directories
+specifically mentioned in `\fBDirectory\fR' requests.
+.PP
+Previous versions of \s-1CVS \s0(1.10 and earlier) do not behave the same
+way.  While the descent of the tree begins at all directories
+mentioned in `\fBArgument\fR' requests, descent into subdirectories only
+occurs if a directory has been mentioned in a `\fBDirectory\fR' request.
+Therefore, the above example would succeed in updating `\fBdir1\fR' and
+`\fBdir2\fR', but would skip `\fBdir3\fR' because that directory was not
+specifically mentioned in a `\fBDirectory\fR' request.  A functional
+version of the above that would run on a 1.10 or earlier server is
+as follows:
+.PP
+C: Argument dir1
+C: Directory dir1
+C: mod1
+\&. . .
+C: Argument dir2
+C: Directory dir2
+C: mod2
+\&. . .
+C: Argument dir3
+C: Directory dir3
+C: .
+\&. . .
+C: Directory dir3/subdir3
+C: mod3
+\&. . .
+C: update
+.PP
+Note the extra `\fBDirectory dir3\fR' request.  It might be better to use
+`\fBEmptydir\fR' as the repository for the `\fBdir3\fR' directory, but the
+above will certainly work.
+.PP
+One more peculiarity of the 1.10 and earlier protocol is the
+ordering of `\fBDirectory\fR' arguments.  In order for a subdirectory to
+be registered correctly for descent by the recursion processor,
+its parent must be sent first.  For example, the following would
+not work to update `\fBdir3/subdir3\fR':
+.PP
+\&. . .
+C: Argument dir3
+C: Directory dir3/subdir3
+C: mod3
+\&. . .
+C: Directory dir3
+C: .
+\&. . .
+C: update
+.PP
+The implementation of the server in 1.10 and earlier writes the
+administration files for a given directory at the time of the
+`\fBDirectory\fR' request.  It also tries to register the directory with
+its parent to mark it for recursion.  In the above example, at the
+time `\fBdir3/subdir3\fR' is created, the physical directory for `\fBdir3\fR'
+will be created on disk, but the administration files will not
+have been created.  Therefore, when the server tries to register
+`\fBdir3/subdir3\fR' for recursion, the operation will silently fail
+because the administration files do not yet exist for `\fBdir3\fR'.
+.PP
+`\fBMax-dotdot \s-1LEVEL\s0 \en\fR'
+Response expected: no.  Tell the server that \s-1LEVEL\s0 levels of
+directories above the directory which `\fBDirectory\fR' requests are
+relative to will be needed.  For example, if the client is
+planning to use a `\fBDirectory\fR' request for `\fB../../foo\fR', it must
+send a `\fBMax-dotdot\fR' request with a \s-1LEVEL\s0 of at least 2.
+`\fBMax-dotdot\fR' must be sent before the first `\fBDirectory\fR' request.
+.PP
+`\fBStatic-directory \en\fR'
+Response expected: no.  Tell the server that the directory most
+recently specified with `\fBDirectory\fR' should not have additional
+files checked out unless explicitly requested.  The client sends
+this if the `\fBEntries.Static\fR' flag is set, which is controlled by
+the `\fBSet-static-directory\fR' and `\fBClear-static-directory\fR' responses.
+.PP
+`\fBSticky \s-1TAGSPEC\s0 \en\fR'
+Response expected: no.  Tell the server that the directory most
+recently specified with `\fBDirectory\fR' has a sticky tag or date
+\&\s-1TAGSPEC. \s0 The first character of \s-1TAGSPEC\s0 is `\fBT\fR' for a tag, `\fBD\fR' for
+a date, or some other character supplied by a Set-sticky response
+from a previous request to the server.  The remainder of \s-1TAGSPEC\s0
+contains the actual tag or date, again as supplied by Set-sticky.
+.PP
+The server should remember `\fBStatic-directory\fR' and `\fBSticky\fR'
+requests for a particular directory; the client need not resend
+them each time it sends a `\fBDirectory\fR' request for a given
+directory.  However, the server is not obliged to remember them
+beyond the context of a single command.
+.PP
+`\fBCheckin-prog \s-1PROGRAM\s0 \en\fR'
+Response expected: no.  Tell the server that the directory most
+recently specified with `\fBDirectory\fR' has a checkin program \s-1PROGRAM.\s0
+Such a program would have been previously set with the
+`\fBSet-checkin-prog\fR' response.
+.PP
+`\fBUpdate-prog \s-1PROGRAM\s0 \en\fR'
+Response expected: no.  Tell the server that the directory most
+recently specified with `\fBDirectory\fR' has an update program \s-1PROGRAM.\s0
+Such a program would have been previously set with the
+`\fBSet-update-prog\fR' response.
+.PP
+`\fBEntry ENTRY-LINE \en\fR'
+Response expected: no.  Tell the server what version of a file is
+on the local machine.  The name in ENTRY-LINE is a name relative
+to the directory most recently specified with `\fBDirectory\fR'.  If the
+user is operating on only some files in a directory, `\fBEntry\fR'
+requests for only those files need be included.  If an `\fBEntry\fR'
+request is sent without `\fBModified\fR', `\fBIs-modified\fR', or `\fBUnchanged\fR',
+it means the file is lost (does not exist in the working
+directory).  If both `\fBEntry\fR' and one of `\fBModified\fR', `\fBIs-modified\fR',
+or `\fBUnchanged\fR' are sent for the same file, `\fBEntry\fR' must be sent
+first.  For a given file, one can send `\fBModified\fR', `\fBIs-modified\fR',
+or `\fBUnchanged\fR', but not more than one of these three.
+.PP
+`\fBKopt \s-1OPTION\s0 \en\fR'
+This indicates to the server which keyword expansion options to
+use for the file specified by the next `\fBModified\fR' or `\fBIs-modified\fR'
+request (for example `\fB\-kb\fR' for a binary file).  This is similar to
+`\fBEntry\fR', but is used for a file for which there is no entries line.
+Typically this will be a file being added via an `\fBadd\fR' or `\fBimport\fR'
+request.  The client may not send both `\fBKopt\fR' and `\fBEntry\fR' for the
+same file.
+.PP
+`\fBCheckin-time \s-1TIME\s0 \en\fR'
+For the file specified by the next `\fBModified\fR' request, use \s-1TIME\s0 as
+the time of the checkin.  The \s-1TIME\s0 is in the format specified by
+\&\s-1RFC822\s0 as modified by \s-1RFC1123. \s0 The client may specify any
+timezone it chooses; servers will want to convert that to their own
+timezone as appropriate.  An example of this format is:
+.PP
+26 May 1997 13:01:40 \-0400
+.PP
+There is no requirement that the client and server clocks be
+synchronized.  The client just sends its recommendation for a
+timestamp (based on file timestamps or whatever), and the server
+should just believe it (this means that the time might be in the
+future, for example).
+.PP
+Note that this is not a general-purpose way to tell the server
+about the timestamp of a file; that would be a separate request
+(if there are servers which can maintain timestamp and time of
+checkin separately).
+.PP
+This request should affect the `\fBimport\fR' request, and may optionally
+affect the `\fBci\fR' request or other relevant requests if any.
+.PP
+`\fBModified \s-1FILENAME\s0 \en\fR'
+Response expected: no.  Additional data: mode, \en, file
+transmission.  Send the server a copy of one locally modified
+file.  \s-1FILENAME\s0 is a file within the most recent directory sent
+with `\fBDirectory\fR'; it must not contain `\fB/\fR'.  If the user is
+operating on only some files in a directory, only those files need
+to be included.  This can also be sent without `\fBEntry\fR', if there
+is no entry for the file.
+.PP
+`\fBIs-modified \s-1FILENAME\s0 \en\fR'
+Response expected: no.  Additional data: none.  Like `\fBModified\fR',
+but used if the server only needs to know whether the file is
+modified, not the contents.
+.PP
+The commands which can take `\fBIs-modified\fR' instead of `\fBModified\fR'
+with no known change in behavior are: `\fBadmin\fR', `\fBdiff\fR' (if and only
+if two `\fB\-r\fR' or `\fB\-D\fR' options are specified), `\fBwatch-on\fR',
+`\fBwatch-off\fR', `\fBwatch-add\fR', `\fBwatch-remove\fR', `\fBwatchers\fR', `\fBeditors\fR',
+`\fBlog\fR', and `\fBannotate\fR'.
+.PP
+For the `\fBstatus\fR' command, one can send `\fBIs-modified\fR' but if the
+client is using imperfect mechanisms such as timestamps to
+determine whether to consider a file modified, then the behavior
+will be different.  That is, if one sends `\fBModified\fR', then the
+server will actually compare the contents of the file sent and the
+one it derives from to determine whether the file is genuinely
+modified.  But if one sends `\fBIs-modified\fR', then the server takes
+the client's word for it.  A similar situation exists for `\fBtag\fR',
+if the `\fB\-c\fR' option is specified.
+.PP
+Commands for which `\fBModified\fR' is necessary are `\fBco\fR', `\fBci\fR',
+`\fBupdate\fR', and `\fBimport\fR'.
+.PP
+Commands which do not need to inform the server about a working
+directory, and thus should not be sending either `\fBModified\fR' or
+`\fBIs-modified\fR': `\fBrdiff\fR', `\fBrtag\fR', `\fBhistory\fR', `\fBinit\fR', and `\fBrelease\fR'.
+.PP
+Commands for which further investigation is warranted are:
+`\fBremove\fR', `\fBadd\fR', and `\fBexport\fR'.  Pending such investigation, the
+more conservative course of action is to stick to `\fBModified\fR'.
+.PP
+`\fBUnchanged \s-1FILENAME\s0 \en\fR'
+Response expected: no.  Tell the server that \s-1FILENAME\s0 has not been
+modified in the checked out directory.  The \s-1FILENAME\s0 is a file
+within the most recent directory sent with `\fBDirectory\fR'; it must
+not contain `\fB/\fR'.
+.PP
+`\fBUseUnchanged \en\fR'
+Response expected: no.  To specify the version of the protocol
+described in this document, servers must support this request
+(although it need not do anything) and clients must issue it.  The
+`\fBRoot\fR' request need not have been previously sent.
+.PP
+`\fBNotify \s-1FILENAME\s0 \en\fR'
+Response expected: no.  Tell the server that an `\fBedit\fR' or `\fBunedit\fR'
+command has taken place.  The server needs to send a `\fBNotified\fR'
+response, but such response is deferred until the next time that
+the server is sending responses.  The \s-1FILENAME\s0 is a file within
+the most recent directory sent with `\fBDirectory\fR'; it must not
+contain `\fB/\fR'.  Additional data:
+NOTIFICATION-TYPE \et \s-1TIME\s0 \et \s-1CLIENTHOST\s0 \et
+WORKING-DIR \et \s-1WATCHES\s0 \en
+where NOTIFICATION-TYPE is `\fBE\fR' for edit, `\fBU\fR' for unedit, undefined
+behavior if `\fBC\fR', and all other letters should be silently ignored
+for future expansion.  \s-1TIME\s0 is the time at which the edit or
+unedit took place, in a user-readable format of the client's
+choice (the server should treat the time as an opaque string
+rather than interpreting it).  \s-1CLIENTHOST\s0 is the name of the host
+on which the edit or unedit took place, and WORKING-DIR is the
+pathname of the working directory where the edit or unedit took
+place.  \s-1WATCHES\s0 are the temporary watches, zero or more of the
+following characters in the following order: `\fBE\fR' for edit, `\fBU\fR' for
+unedit, `\fBC\fR' for commit, and all other letters should be silently
+ignored for future expansion.  If NOTIFICATION-TYPE is `\fBE\fR' the
+temporary watches are set; if it is `\fBU\fR' they are cleared.  If
+\&\s-1WATCHES\s0 is followed by \et then the \et and the rest of the line
+should be ignored, for future expansion.
+.PP
+The \s-1TIME, CLIENTHOST,\s0 and WORKING-DIR fields may not contain the
+characters `\fB+\fR', `\fB,\fR', `\fB>\fR', `\fB;\fR', or `\fB=\fR'.
+.PP
+Note that a client may be capable of performing an `\fBedit\fR' or
+`\fBunedit\fR' operation without connecting to the server at that time,
+and instead connecting to the server when it is convenient (for
+example, when a laptop is on the net again) to send the `\fBNotify\fR'
+requests.  Even if a client is capable of deferring notifications,
+it should attempt to send them immediately (one can send `\fBNotify\fR'
+requests together with a `\fBnoop\fR' request, for example), unless
+perhaps if it can know that a connection would be impossible.
+.PP
+`\fBQuestionable \s-1FILENAME\s0 \en\fR'
+Response expected: no.  Additional data: no.  Tell the server to
+check whether \s-1FILENAME\s0 should be ignored, and if not, next time the
+server sends responses, send (in a `\fBM\fR' response) `\fB?\fR' followed by
+the directory and filename.  \s-1FILENAME\s0 must not contain `\fB/\fR'; it
+needs to be a file in the directory named by the most recent
+`\fBDirectory\fR' request.
+.PP
+`\fBCase \en\fR'
+Response expected: no.  Tell the server that filenames should be
+matched in a case-insensitive fashion.  Note that this is not the
+primary mechanism for achieving case-insensitivity; for the most
+part the client keeps track of the case which the server wants to
+use and takes care to always use that case regardless of what the
+user specifies.  For example the filenames given in `\fBEntry\fR' and
+`\fBModified\fR' requests for the same file must match in case
+regardless of whether the `\fBCase\fR' request is sent.  The latter
+mechanism is more general (it could also be used for 8.3
+filenames, \s-1VMS\s0 filenames with more than one `\fB.\fR', and any other
+situation in which there is a predictable mapping between
+filenames in the working directory and filenames in the protocol),
+but there are some situations it cannot handle (ignore patterns, or
+situations where the user specifies a filename and the client does
+not know about that file).
+.PP
+Though this request will be supported into the forseeable future,
+it has been the source of numerous bug reports in the past due to
+the complexity of testing this functionality via the test suite
+and client developers are encouraged not to use it.  Instead,
+please consider munging conflicting names and maintaining a map
+for communicating with the server.  For example, suppose the
+server sends files `\fBcase\fR', `\fB\s-1CASE\s0\fR', and `\fBCaSe\fR'.  The client could
+write all three files to names such as, `\fBcase\fR',
+`\fBcase_prefix_case\fR', and `\fBcase_prefix_2_case\fR' and maintain a
+mapping between the file names in, for instance a new `\fBCVS/Map\fR'
+file.
+.PP
+`\fBArgument \s-1TEXT\s0 \en\fR'
+Response expected: no.  Save argument for use in a subsequent
+command.  Arguments accumulate until an argument-using command is
+given, at which point they are forgotten.
+.PP
+`\fBArgumentx \s-1TEXT\s0 \en\fR'
+Response expected: no.  Append \en followed by text to the current
+argument being saved.
+.PP
+`\fBGlobal_option \s-1OPTION\s0 \en\fR'
+Response expected: no.  Transmit one of the global options `\fB\-q\fR',
+`\fB\-Q\fR', `\fB\-l\fR', `\fB\-t\fR', `\fB\-r\fR', or `\fB\-n\fR'.  \s-1OPTION\s0 must be one of those
+strings, no variations (such as combining of options) are allowed.
+For graceful handling of `\fBvalid-requests\fR', it is probably better to
+make new global options separate requests, rather than trying to
+add them to this request.  The `\fBRoot\fR' request need not have been
+previously sent.
+.PP
+`\fBGzip-stream \s-1LEVEL\s0 \en\fR'
+Response expected: no.  Use zlib (\s-1RFC 1950/1951\s0) compression to
+compress all further communication between the client and the
+server.  As of \s-1CVS 1.12.13,\s0 this request needs to be sent as the
+first non-rootless request if the server is configured with
+compression level restrictions and \s-1LEVEL\s0 is outside the restricted
+range.  After this request is sent, all further communication must
+be compressed.  All further data received from the server will
+also be compressed.  The \s-1LEVEL\s0 argument suggests to the server the
+level of compression that it should apply; it should be an integer
+between 0 and 9, inclusive, where `\fB0\fR' means no compression and
+higher numbers indicate more compression.
+.PP
+`\fBKerberos-encrypt \en\fR'
+Response expected: no.  Use Kerberos encryption to encrypt all
+further communication between the client and the server.  This
+will only work if the connection was made over Kerberos in the
+first place.  If both the `\fBGzip-stream\fR' and the `\fBKerberos-encrypt\fR'
+requests are used, the `\fBKerberos-encrypt\fR' request should be used
+first.  This will make the client and server encrypt the
+compressed data, as opposed to compressing the encrypted data.
+Encrypted data is generally incompressible.
+.PP
+Note that this request does not fully prevent an attacker from
+hijacking the connection, in the sense that it does not prevent
+hijacking the connection between the initial authentication and the
+`\fBKerberos-encrypt\fR' request.
+.PP
+`\fBGssapi-encrypt \en\fR'
+Response expected: no.  Use \s-1GSSAPI\s0 encryption to encrypt all
+further communication between the client and the server.  This
+will only work if the connection was made over \s-1GSSAPI\s0 in the first
+place.  See `\fBKerberos-encrypt\fR', above, for the relation between
+`\fBGssapi-encrypt\fR' and `\fBGzip-stream\fR'.
+.PP
+Note that this request does not fully prevent an attacker from
+hijacking the connection, in the sense that it does not prevent
+hijacking the connection between the initial authentication and the
+`\fBGssapi-encrypt\fR' request.
+.PP
+`\fBGssapi-authenticate \en\fR'
+Response expected: no.  Use \s-1GSSAPI\s0 authentication to authenticate
+all further communication between the client and the server.  This
+will only work if the connection was made over \s-1GSSAPI\s0 in the first
+place.  Encrypted data is automatically authenticated, so using
+both `\fBGssapi-authenticate\fR' and `\fBGssapi-encrypt\fR' has no effect
+beyond that of `\fBGssapi-encrypt\fR'.  Unlike encrypted data, it is
+reasonable to compress authenticated data.
+.PP
+Note that this request does not fully prevent an attacker from
+hijacking the connection, in the sense that it does not prevent
+hijacking the connection between the initial authentication and the
+`\fBGssapi-authenticate\fR' request.
+.PP
+`\fBSet VARIABLE=VALUE \en\fR'
+Response expected: no.  Set a user variable \s-1VARIABLE\s0 to \s-1VALUE.\s0
+The `\fBRoot\fR' request need not have been previously sent.
+.PP
+`\fBHostname \s-1HOSTNAME\s0 \en\fR'
+Response expected: no.  Set the client hostname for an upcoming
+`\fBedit\fR' request.
+.PP
+`\fBLocalDir \s-1HOSTNAME\s0 \en\fR'
+Response expected: no.  Set the local client directory name for an
+upcoming `\fBedit\fR' request.
+.PP
+`\fBexpand-modules \en\fR'
+Response expected: yes.  Expand the modules which are specified in
+the arguments.  Returns the data in `\fBModule-expansion\fR' responses.
+Note that the server can assume that this is checkout or export,
+not rtag or rdiff; the latter do not access the working directory
+and thus have no need to expand modules on the client side.
+.PP
+Expand may not be the best word for what this request does.  It
+does not necessarily tell you all the files contained in a module,
+for example.  Basically it is a way of telling you which working
+directories the server needs to know about in order to handle a
+checkout of the specified modules.
+.PP
+For example, suppose that the server has a module defined by
+.PP
+aliasmodule \-a 1dir
+.PP
+That is, one can check out `\fBaliasmodule\fR' and it will take `\fB1dir\fR'
+in the repository and check it out to `\fB1dir\fR' in the working
+directory.  Now suppose the client already has this module checked
+out and is planning on using the `\fBco\fR' request to update it.
+Without using `\fBexpand-modules\fR', the client would have two bad
+choices: it could either send information about _all_ working
+directories under the current directory, which could be
+unnecessarily slow, or it could be ignorant of the fact that
+`\fBaliasmodule\fR' stands for `\fB1dir\fR', and neglect to send information
+for `\fB1dir\fR', which would lead to incorrect operation.
+.PP
+With `\fBexpand-modules\fR', the client would first ask for the module to
+be expanded:
+.PP
+C: Root /home/kingdon/zwork/cvsroot
+\&. . .
+C: Argument aliasmodule
+C: Directory .
+C: .
+C: expand-modules
+S: Module-expansion 1dir
+S: ok
+.PP
+and then it knows to check the `\fB1dir\fR' directory and send requests
+such as `\fBEntry\fR' and `\fBModified\fR' for the files in that directory.
+.PP
+`\fBci \en\fR'
+`\fBdiff \en\fR'
+`\fBlist \en\fR'
+`\fBtag \en\fR'
+`\fBstatus \en\fR'
+`\fBadmin \en\fR'
+`\fBhistory \en\fR'
+`\fBwatchers \en\fR'
+`\fBeditors \en\fR'
+`\fBannotate \en\fR'
+Response expected: yes.  Actually do a cvs command.  This uses any
+previous `\fBArgument\fR', `\fBDirectory\fR', `\fBEntry\fR', or `\fBModified\fR' requests,
+if they have been sent.  The last `\fBDirectory\fR' sent specifies the
+working directory at the time of the operation.  No provision is
+made for any input from the user.  This means that `\fBci\fR' must use a
+`\fB\-m\fR' argument if it wants to specify a log message.
+.PP
+`\fBlog \en\fR'
+Response expected: yes.  Show information for past revisions.
+This uses any previous `\fBDirectory\fR', `\fBEntry\fR', or `\fBModified\fR'
+requests, if they have been sent.  The last `\fBDirectory\fR' sent
+specifies the working directory at the time of the operation.
+Also uses previous `\fBArgument\fR''s of which the canonical forms are
+the following (\s-1CVS 1.10\s0 and older clients sent what the user
+specified, but clients are encouraged to use the canonical forms
+and other forms are deprecated):
+.PP
+`\fB\-b, \-h, \-l, \-N, \-R, \-t\fR'
+These options go by themselves, one option per `\fBArgument\fR'
+request.
+.PP
+`\fB\-d DATE1<\s-1DATE2\s0\fR'
+Select revisions between \s-1DATE1\s0 and \s-1DATE2. \s0 Either date may be
+omitted in which case there is no date limit at that end of
+the range (clients may specify dates such as 1 Jan 1970 or 1
+Jan 2038 for similar purposes but this is problematic as it
+makes assumptions about what dates the server supports).
+Dates are in \s-1RFC822/1123\s0 format.  The `\fB\-d\fR' is one `\fBArgument\fR'
+request and the date range is a second one.
+.PP
+`\fB\-d DATE1<=DATE2\fR'
+Likewise but compare dates for equality.
+.PP
+`\fB\-d \s-1SINGLEDATE\s0\fR'
+Select the single, latest revision dated \s-1SINGLEDATE\s0 or
+earlier.
+.PP
+To include several date ranges and/or singledates, repeat the
+`\fB\-d\fR' option as many times as necessary.
+.PP
+`\fB\-rREV1:REV2\fR'
+`\fB\-rBRANCH\fR'
+`\fB\-rBRANCH.\fR'
+`\fB\-r\fR'
+Specify revisions (note that \s-1REV1\s0 or \s-1REV2\s0 can be omitted, or
+can refer to branches).  Send both the `\fB\-r\fR' and the revision
+information in a single `\fBArgument\fR' request.  To include
+several revision selections, repeat the `\fB\-r\fR' option.
+.PP
+`\fB\-s \s-1STATE\s0\fR'
+`\fB\-w\fR'
+`\fB\-wLOGIN\fR'
+Select on states or users.  To include more than one state or
+user, repeat the option.  Send the `\fB\-s\fR' option as a separate
+argument from the state being selected.  Send the `\fB\-w\fR' option
+as part of the same argument as the user being selected.
+.PP
+`\fBco \en\fR'
+Response expected: yes.  Get files from the repository.  This uses
+any previous `\fBArgument\fR', `\fBDirectory\fR', `\fBEntry\fR', or `\fBModified\fR'
+requests, if they have been sent.  Arguments to this command are
+module names; the client cannot know what directories they
+correspond to except by (1) just sending the `\fBco\fR' request, and then
+seeing what directory names the server sends back in its
+responses, and (2) the `\fBexpand-modules\fR' request.
+.PP
+`\fBexport \en\fR'
+Response expected: yes.  Get files from the repository.  This uses
+any previous `\fBArgument\fR', `\fBDirectory\fR', `\fBEntry\fR', or `\fBModified\fR'
+requests, if they have been sent.  Arguments to this command are
+module names, as described for the `\fBco\fR' request.  The intention
+behind this command is that a client can get sources from a server
+without storing \s-1CVS\s0 information about those sources.  That is, a
+client probably should not count on being able to take the entries
+line returned in the `\fBCreated\fR' response from an `\fBexport\fR' request
+and send it in a future `\fBEntry\fR' request.  Note that the entries
+line in the `\fBCreated\fR' response must indicate whether the file is
+binary or text, so the client can create it correctly.
+.PP
+`\fBls \en\fR'
+`\fBrannotate \en\fR'
+`\fBrdiff \en\fR'
+`\fBrlist \en\fR'
+`\fBrlog \en\fR'
+`\fBrtag \en\fR'
+Response expected: yes.  Actually do a cvs command.  This uses any
+previous `\fBArgument\fR' requests, if they have been sent.  The client
+should not send `\fBDirectory\fR', `\fBEntry\fR', or `\fBModified\fR' requests for
+these commands; they are not used.  Arguments to these commands
+are module names, as described for `\fBco\fR'.  `\fBls\fR' is a synonym for
+`\fBrlist\fR', for compatibility with \s-1CVSNT.\s0
+.PP
+`\fBinit ROOT-NAME \en\fR'
+Response expected: yes.  If it doesn't already exist, create a \s-1CVS\s0
+repository ROOT-NAME.  Note that ROOT-NAME is a local directory
+and _not_ a fully qualified `\fB\s-1CVSROOT\s0\fR' variable.  The `\fBRoot\fR'
+request need not have been previously sent.
+.PP
+`\fBupdate \en\fR'
+Response expected: yes.  Actually do a `\fBcvs update\fR' command.  This
+uses any previous `\fBArgument\fR', `\fBDirectory\fR', `\fBEntry\fR', or `\fBModified\fR'
+requests, if they have been sent.  The last `\fBDirectory\fR' sent
+specifies the working directory at the time of the operation.  The
+`\fB\-I\fR' option is not used-files which the client can decide whether
+to ignore are not mentioned and the client sends the
+`\fBQuestionable\fR' request for others.
+.PP
+`\fBimport \en\fR'
+Response expected: yes.  Actually do a `\fBcvs import\fR' command.  This
+uses any previous `\fBArgument\fR', `\fBDirectory\fR', `\fBEntry\fR', or `\fBModified\fR'
+requests, if they have been sent.  The last `\fBDirectory\fR' sent
+specifies the working directory at the time of the operation \-
+unlike most commands, the repository field of each `\fBDirectory\fR'
+request is ignored (it merely must point somewhere within the
+root).  The files to be imported are sent in `\fBModified\fR' requests
+(files which the client knows should be ignored are not sent; the
+server must still process the CVSROOT/cvsignore file unless \-I ! is
+sent).  A log message must have been specified with a `\fB\-m\fR'
+argument.
+.PP
+`\fBadd \en\fR'
+Response expected: yes.  Add a file or directory.  This uses any
+previous `\fBArgument\fR', `\fBDirectory\fR', `\fBEntry\fR', or `\fBModified\fR' requests,
+if they have been sent.  The last `\fBDirectory\fR' sent specifies the
+working directory at the time of the operation.
+.PP
+To add a directory, send the directory to be added using
+`\fBDirectory\fR' and `\fBArgument\fR' requests.  For example:
+.PP
+C: Root /u/cvsroot
+\&. . .
+C: Argument nsdir
+C: Directory nsdir
+C: 1dir/nsdir
+C: Directory .
+C: 1dir
+C: add
+S: M Directory /u/cvsroot/1dir/nsdir added to the repository
+S: ok
+.PP
+You will notice that the server does not signal to the client in
+any particular way that the directory has been successfully added.
+The client is supposed to just assume that the directory has been
+added and update its records accordingly.  Note also that adding a
+directory is immediate; it does not wait until a `\fBci\fR' request as
+files do.
+.PP
+To add a file, send the file to be added using a `\fBModified\fR'
+request.  For example:
+.PP
+C: Argument nfile
+C: Directory .
+C: 1dir
+C: Modified nfile
+C: u=rw,g=r,o=r
+C: 6
+C: hello
+C: add
+S: E cvs server: scheduling file `\fBnfile\fR' for addition
+S: Mode u=rw,g=r,o=r
+S: Checked-in ./
+S: /u/cvsroot/1dir/nfile
+S: /nfile/0///
+S: E cvs server: use 'cvs commit' to add this file permanently
+S: ok
+.PP
+Note that the file has not been added to the repository; the only
+effect of a successful `\fBadd\fR' request, for a file, is to supply the
+client with a new entries line containing `\fB0\fR' to indicate an added
+file.  In fact, the client probably could perform this operation
+without contacting the server, although using `\fBadd\fR' does cause the
+server to perform a few more checks.
+.PP
+The client sends a subsequent `\fBci\fR' to actually add the file to the
+repository.
+.PP
+Another quirk of the `\fBadd\fR' request is that with \s-1CVS 1.9\s0 and older,
+a pathname specified in an `\fBArgument\fR' request cannot contain `\fB/\fR'.
+There is no good reason for this restriction, and in fact more
+recent \s-1CVS\s0 servers don't have it.  But the way to interoperate
+with the older servers is to ensure that all `\fBDirectory\fR' requests
+for `\fBadd\fR' (except those used to add directories, as described
+above), use `\fB.\fR' for LOCAL-DIRECTORY.  Specifying another string for
+LOCAL-DIRECTORY may not get an error, but it will get you strange
+`\fBChecked-in\fR' responses from the buggy servers.
+.PP
+`\fBremove \en\fR'
+Response expected: yes.  Remove a file.  This uses any previous
+`\fBArgument\fR', `\fBDirectory\fR', `\fBEntry\fR', or `\fBModified\fR' requests, if they
+have been sent.  The last `\fBDirectory\fR' sent specifies the working
+directory at the time of the operation.
+.PP
+Note that this request does not actually do anything to the
+repository; the only effect of a successful `\fBremove\fR' request is to
+supply the client with a new entries line containing `\fB\-\fR' to
+indicate a removed file.  In fact, the client probably could
+perform this operation without contacting the server, although
+using `\fBremove\fR' may cause the server to perform a few more checks.
+.PP
+The client sends a subsequent `\fBci\fR' request to actually record the
+removal in the repository.
+.PP
+`\fBedit \en\fR'
+Response expected: yes.  Actually do the `\fBcvs edit\fR' command.  This
+uses any previous `\fBArgument\fR', `\fBDirectory\fR', `\fBEntry\fR', `\fBLocalDir\fR', or
+`\fBHostname\fR' requests, if they have been sent.  Unless the user has
+requested that edits not be granted unless no one else is editing
+a file, a local edit followed by an attempt to send `\fBNotify\fR'
+requests to the server is preferred.
+.PP
+`\fBwatch-on \en\fR'
+`\fBwatch-off \en\fR'
+`\fBwatch-add \en\fR'
+`\fBwatch-remove \en\fR'
+Response expected: yes.  Actually do the `\fBcvs watch on\fR', `cvs
+watch off', `\fBcvs watch add\fR', and `\fBcvs watch remove\fR' commands,
+respectively.  This uses any previous `\fBArgument\fR', `\fBDirectory\fR',
+`\fBEntry\fR', or `\fBModified\fR' requests, if they have been sent.  The last
+`\fBDirectory\fR' sent specifies the working directory at the time of
+the operation.
+.PP
+`\fBrelease \en\fR'
+Response expected: yes.  Note that a `\fBcvs release\fR' command has
+taken place and update the history file accordingly.
+.PP
+`\fBglobal-list-quiet \en\fR'
+Response expected: yes.  This request is a synonym for noop, but
+its existance notifies the client that a `\fB\-q\fR' option to `\fBlist\fR' and
+`\fBrlist\fR' will be rejected.  This, in a reverse-logic sort of way,
+is here so that when it _isn't_ received, as for instance from
+\&\s-1CVSNT,\s0 the client will know that the quiet option has to be sent
+as a command option rather than a global option.
+.PP
+`\fBnoop \en\fR'
+Response expected: yes.  This request is a null command in the
+sense that it doesn't do anything, but merely (as with any other
+requests expecting a response) sends back any responses pertaining
+to pending errors, pending `\fBNotified\fR' responses, etc.  The `\fBRoot\fR'
+request need not have been previously sent.
+.PP
+`\fBupdate-patches \en\fR'
+Response expected: yes.  This request does not actually do
+anything.  It is used as a signal that the server is able to
+generate patches when given an `\fBupdate\fR' request.  The client must
+issue the `\fB\-u\fR' argument to `\fBupdate\fR' in order to receive patches.
+.PP
+`\fBgzip-file-contents \s-1LEVEL\s0 \en\fR'
+Response expected: no.  Note that this request does not follow the
+response convention stated above.  `\fBGzip-stream\fR' is suggested
+instead of `\fBgzip-file-contents\fR' as it gives better compression; the
+only reason to implement the latter is to provide compression with
+\&\s-1CVS 1.8\s0 and earlier.  The `\fBgzip-file-contents\fR' request asks the
+server to compress files it sends to the client using `\fBgzip\fR'
+(\s-1RFC1952/1951\s0) compression, using the specified level of
+compression.  If this request is not made, the server must not
+compress files.
+.PP
+This is only a hint to the server.  It may still decide (for
+example, in the case of very small files, or files that already
+appear to be compressed) not to do the compression.  Compression
+is indicated by a `\fBz\fR' preceding the file length.
+.PP
+Availability of this request in the server indicates to the client
+that it may compress files sent to the server, regardless of
+whether the client actually uses this request.
+.PP
+`\fBwrapper-sendme-rcsOptions \en\fR'
+Response expected: yes.  Request that the server transmit mappings
+from filenames to keyword expansion modes in `\fBWrapper-rcsOption\fR'
+responses.
+.PP
+`\fBversion \en\fR'
+Response expected: yes.  Request that the server transmit its
+version message.  The `\fBRoot\fR' request need not have been previously
+sent.
+.PP
+`\fBOTHER-REQUEST \s-1TEXT\s0 \en\fR'
+Response expected: yes.  Any unrecognized request expects a
+response, and does not contain any additional data.  The response
+will normally be something like `\fBerror  unrecognized request\fR', but
+it could be a different error if a previous request which doesn't
+expect a response produced an error.
+.PP
+When the client is done, it drops the connection.
+.PP
+\&\fB5.9 Introduction to Responses\fR
+.PP
+After a command which expects a response, the server sends however many
+of the following responses are appropriate.  The server should not send
+data at other times (the current implementation may violate this
+principle in a few minor places, where the server is printing an error
+message and exiting\*(--this should be investigated further).
+.PP
+Any set of responses always ends with `\fBerror\fR' or `\fBok\fR'.  This
+indicates that the response is over.
+.PP
+The responses `\fBChecked-in\fR', `\fBNew-entry\fR', `\fBUpdated\fR', `\fBCreated\fR',
+`\fBUpdate-existing\fR', `\fBMerged\fR', and `\fBPatched\fR' are refered to as \*(L"file
+updating\*(R" responses, because they change the status of a file in the
+working directory in some way.  The responses `\fBMode\fR', `\fBMod-time\fR', and
+`\fBChecksum\fR' are referred to as \*(L"file update modifying\*(R" responses because
+they modify the next file updating response.  In no case shall a file
+update modifying response apply to a file updating response other than
+the next one.  Nor can the same file update modifying response occur
+twice for a given file updating response (if servers diagnose this
+problem, it may aid in detecting the case where clients send an update
+modifying response without following it by a file updating response).
+.PP
+\&\fB5.10 The \*(L"pathname\*(R" in responses\fR
+.PP
+Many of the responses contain something called \s-1PATHNAME. \s0 The name is
+somewhat misleading; it actually indicates a pair of pathnames.  First,
+a local directory name relative to the directory in which the command
+was given (i.e. the last `\fBDirectory\fR' before the command).  Then a
+linefeed and a repository name.  Then a slash and the filename (without
+a `\fB,v\fR' ending).
+.PP
+The repository name may be absolute or relative to the \s-1PATHNAME\s0 sent
+with the `\fBRoot\fR' request.  If absolute, the repository name must begin
+with the \s-1PATHNAME\s0 sent with the `\fBRoot\fR' request.  Relative or absolute,
+the repository name must specify a path underneath the `\fBRoot\fR' \s-1PATHNAME.\s0
+.PP
+For example, for a file `\fBi386.mh\fR' which is in the local directory
+`\fBgas.clean/config\fR' and for which the repository name is
+`\fBdevo/gas/config\fR':
+.PP
+gas.clean/config/
+devo/gas/config/i386.mh
+.PP
+If the server wants to tell the client to create a directory, then it
+merely uses the directory in any response, as described above, and the
+client should create the directory if it does not exist.  Note that this
+should only be done one directory at a time, in order to permit the
+client to correctly store the repository for each directory.  Servers
+can use requests such as `\fBClear-sticky\fR', `\fBClear-static-directory\fR', or
+any other requests, to create directories.
+.PP
+Some server implementations may poorly distinguish between a
+directory which should not exist and a directory which contains no
+files; in order to refrain from creating empty directories a client
+should both send the `\fB\-P\fR' option to `\fBupdate\fR' or `\fBco\fR', and should also
+detect the case in which the server asks to create a directory but not
+any files within it (in that case the client should remove the
+directory or refrain from creating it in the first place).  Note that
+servers could clean this up greatly by only telling the client to
+create directories if the directory in question should exist, but until
+servers do this, clients will need to offer the `\fB\-P\fR' behavior described
+above.
+.PP
+\&\fB5.11 Responses\fR
+.PP
+Here are the responses:
+.PP
+`\fBValid-requests REQUEST-LIST \en\fR'
+Indicate what requests the server will accept.  REQUEST-LIST is a
+space separated list of tokens.  If the server supports sending
+patches, it will include `\fBupdate-patches\fR' in this list.  The
+`\fBupdate-patches\fR' request does not actually do anything.
+.PP
+`\fBForce-gzip \en\fR'
+Response expected: no.  Indicates that the server requires
+compression.  The client must send a `\fBGzip-stream\fR' request, though
+the requested \s-1LEVEL\s0 may be `\fB0\fR'.
+.PP
+`\fBReferrer \s-1CVSROOT\s0\fR'
+Request that the client store \s-1CVSROOT\s0 as the name of this server
+and that this name be passed via a `\fBReferrer\fR' _request_ to any
+subsequent servers contacted as a result of a `\fBRedirect\fR' response.
+This can be useful to allow the secondary administrator to
+configure the `\fB\s-1CVSROOT\s0\fR' the primary should use to update the
+secondary in case the client uses a non-standard name or even a
+name that is unique to the client for some reason.
+.PP
+`\fBRedirect \s-1CVSROOT\s0\fR'
+Request that the client redirect its connection to \s-1CVSROOT\s0 and
+begin again.  This response is only valid in response to a
+`\fBCommand-prep\fR' request.  If a client receives this response, it is
+expected to notify the write server it subsequently contacts of
+the \s-1CVSROOT\s0 of the server which redirected it using the `\fBReferrer\fR'
+request.  This information makes it possible for primary servers
+to update the client's mirror first, hopefully minimizing race
+conditions on subsequent updates from the same client.
+.PP
+`\fBChecked-in \s-1PATHNAME\s0 \en\fR'
+Additional data: New Entries line, \en.  This means a file \s-1PATHNAME\s0
+has been successfully operated on (checked in, added, etc.).  name
+in the Entries line is the same as the last component of \s-1PATHNAME.\s0
+.PP
+`\fBNew-entry \s-1PATHNAME\s0 \en\fR'
+Additional data: New Entries line, \en.  Like `\fBChecked-in\fR', but the
+file is not up to date.
+.PP
+`\fBUpdated \s-1PATHNAME\s0 \en\fR'
+Additional data: New Entries line, \en, mode, \en, file
+transmission.  A new copy of the file is enclosed.  This is used
+for a new revision of an existing file, or for a new file, or for
+any other case in which the local (client-side) copy of the file
+needs to be updated, and after being updated it will be up to
+date.  If any directory in pathname does not exist, create it.
+This response is not used if `\fBCreated\fR' and `\fBUpdate-existing\fR' are
+supported.
+.PP
+`\fBCreated \s-1PATHNAME\s0 \en\fR'
+This is just like `\fBUpdated\fR' and takes the same additional data, but
+is used only if no `\fBEntry\fR', `\fBModified\fR', or `\fBUnchanged\fR' request has
+been sent for the file in question.  The distinction between
+`\fBCreated\fR' and `\fBUpdate-existing\fR' is so that the client can give an
+error message in several cases: (1) there is a file in the working
+directory, but not one for which `\fBEntry\fR', `\fBModified\fR', or
+`\fBUnchanged\fR' was sent (for example, a file which was ignored, or a
+file for which `\fBQuestionable\fR' was sent), (2) there is a file in
+the working directory whose name differs from the one mentioned in
+`\fBCreated\fR' in ways that the client is unable to use to distinguish
+files.  For example, the client is case-insensitive and the names
+differ only in case.
+.PP
+`\fBUpdate-existing \s-1PATHNAME\s0 \en\fR'
+This is just like `\fBUpdated\fR' and takes the same additional data, but
+is used only if a `\fBEntry\fR', `\fBModified\fR', or `\fBUnchanged\fR' request has
+been sent for the file in question.
+.PP
+This response, or `\fBMerged\fR', indicates that the server has
+determined that it is \s-1OK\s0 to overwrite the previous contents of the
+file specified by \s-1PATHNAME. \s0 Provided that the client has correctly
+sent `\fBModified\fR' or `\fBIs-modified\fR' requests for a modified file, and
+the file was not modified while \s-1CVS\s0 was running, the server can
+ensure that a user's modifications are not lost.
+.PP
+`\fBMerged \s-1PATHNAME\s0 \en\fR'
+This is just like `\fBUpdated\fR' and takes the same additional data,
+with the one difference that after the new copy of the file is
+enclosed, it will still not be up to date.  Used for the results
+of a merge, with or without conflicts.
+.PP
+It is useful to preserve an copy of what the file looked like
+before the merge.  This is basically handled by the server; before
+sending `\fBMerged\fR' it will send a `\fBCopy-file\fR' response.  For
+example, if the file is `\fBaa\fR' and it derives from revision 1.3, the
+`\fBCopy-file\fR' response will tell the client to copy `\fBaa\fR' to
+`\fB.#aa.1.3\fR'.  It is up to the client to decide how long to keep this
+file around; traditionally clients have left it around forever,
+thus letting the user clean it up as desired.  But another answer,
+such as until the next commit, might be preferable.
+.PP
+`\fBRcs-diff \s-1PATHNAME\s0 \en\fR'
+This is just like `\fBUpdated\fR' and takes the same additional data,
+with the one difference that instead of sending a new copy of the
+file, the server sends an \s-1RCS\s0 change text.  This change text is
+produced by `\fBdiff \-n\fR' (the \s-1GNU\s0 diff `\fB\-a\fR' option may also be used).
+The client must apply this change text to the existing file.  This
+will only be used when the client has an exact copy of an earlier
+revision of a file.  This response is only used if the `\fBupdate\fR'
+command is given the `\fB\-u\fR' argument.
+.PP
+`\fBPatched \s-1PATHNAME\s0 \en\fR'
+This is just like `\fBRcs-diff\fR' and takes the same additional data,
+except that it sends a standard patch rather than an \s-1RCS\s0 change
+text.  The patch is produced by `\fBdiff \-c\fR' for \s-1CVS 1.6\s0 and later
+(see \s-1POSIX.2\s0 for a description of this format), or `\fBdiff \-u\fR' for
+previous versions of \s-1CVS\s0; clients are encouraged to accept either
+format.  Like `\fBRcs-diff\fR', this response is only used if the
+`\fBupdate\fR' command is given the `\fB\-u\fR' argument.
+.PP
+The `\fBPatched\fR' response is deprecated in favor of the `\fBRcs-diff\fR'
+response.  However, older clients (\s-1CVS 1.9\s0 and earlier) only
+support `\fBPatched\fR'.
+.PP
+`\fBEdit-file \s-1PATHNAME\s0 \en\fR'
+Do the client-side portion of editing a file.
+.PP
+`\fBMode \s-1MODE\s0 \en\fR'
+This \s-1MODE\s0 applies to the next file mentioned in `\fBChecked-in\fR'.
+`\fBMode\fR' is a file update modifying response as described in *note
+Response intro::.
+.PP
+`\fBMod-time \s-1TIME\s0 \en\fR'
+Set the modification time of the next file sent to \s-1TIME.\s0
+`\fBMod-time\fR' is a file update modifying response as described in
+see \*(L"Response intro\*(R".  The \s-1TIME\s0 is in the format specified by
+\&\s-1RFC822\s0 as modified by \s-1RFC1123. \s0 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:
+.PP
+26 May 1997 13:01:40 \-0400
+.PP
+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).
+.PP
+If the server does not send `\fBMod-time\fR' for a given file, the client
+should pick a modification time in the usual way (usually, just
+let the operating system set the modification time to the time
+that the \s-1CVS\s0 command is running).
+.PP
+`\fBChecksum CHECKSUM\en\fR'
+The \s-1CHECKSUM\s0 applies to the next file sent (that is, `\fBChecksum\fR' is
+a file update modifying response as described in *note Response
+intro::).  In the case of `\fBPatched\fR', the checksum applies to the
+file after being patched, not to the patch itself.  The client
+should compute the checksum itself, after receiving the file or
+patch, and signal an error if the checksums do not match.  The
+checksum is the 128 bit \s-1MD5\s0 checksum represented as 32 hex digits
+(\s-1MD5\s0 is described in \s-1RFC1321\s0).  This response is optional, and is
+only used if the client supports it (as judged by the
+`\fBValid-responses\fR' request).
+.PP
+`\fBCopy-file \s-1PATHNAME\s0 \en\fR'
+Additional data: \s-1NEWNAME\s0 \en.  Copy file \s-1PATHNAME\s0 to \s-1NEWNAME\s0 in the
+same directory where it already is.  This does not affect
+`\fBCVS/Entries\fR'.
+.PP
+This can optionally be implemented as a rename instead of a copy.
+The only use for it which currently has been identified is prior
+to a `\fBMerged\fR' response as described under `\fBMerged\fR'.  Clients can
+probably assume that is how it is being used, if they want to worry
+about things like how long to keep the \s-1NEWNAME\s0 file around.
+.PP
+`\fBRemoved \s-1PATHNAME\s0 \en\fR'
+The file has been removed from the repository (this is the case
+where cvs prints `\fBfile foobar.c is no longer pertinent\fR').
+.PP
+`\fBRemove-entry \s-1PATHNAME\s0 \en\fR'
+The file needs its entry removed from `\fBCVS/Entries\fR', but the file
+itself is already gone (this happens in response to a `\fBci\fR' request
+which involves committing the removal of a file).
+.PP
+`\fBSet-static-directory \s-1PATHNAME\s0 \en\fR'
+This instructs the client to set the `\fBEntries.Static\fR' flag, which
+it should then send back to the server in a `\fBStatic-directory\fR'
+request whenever the directory is operated on.  \s-1PATHNAME\s0 ends in a
+slash; its purpose is to specify a directory, not a file within a
+directory.
+.PP
+`\fBClear-static-directory \s-1PATHNAME\s0 \en\fR'
+Like `\fBSet-static-directory\fR', but clear, not set, the flag.
+.PP
+`\fBSet-sticky \s-1PATHNAME\s0 \en\fR'
+Additional data: \s-1TAGSPEC\s0 \en.  Tell the client to set a sticky tag
+or date, which should be supplied with the `\fBSticky\fR' request for
+future operations.  \s-1PATHNAME\s0 ends in a slash; its purpose is to
+specify a directory, not a file within a directory.  The client
+should store \s-1TAGSPEC\s0 and pass it back to the server as-is, to
+allow for future expansion.  The first character of \s-1TAGSPEC\s0 is `\fBT\fR'
+for a tag, `\fBD\fR' for a date, or something else for future expansion.
+The remainder of \s-1TAGSPEC\s0 contains the actual tag or date.
+.PP
+`\fBClear-sticky \s-1PATHNAME\s0 \en\fR'
+Clear any sticky tag or date set by `\fBSet-sticky\fR'.
+.PP
+`\fBTemplate \s-1PATHNAME\s0 \en\fR'
+Additional data: file transmission (note: compressed file
+transmissions are not supported).  \s-1PATHNAME\s0 ends in a slash; its
+purpose is to specify a directory, not a file within a directory.
+Tell the client to store the file transmission as the template log
+message, and then use that template in the future when prompting
+the user for a log message.
+.PP
+`\fBSet-checkin-prog \s-1DIR\s0 \en\fR'
+Additional data: \s-1PROG\s0 \en.  Tell the client to set a checkin
+program, which should be supplied with the `\fBCheckin-prog\fR' request
+for future operations.
+.PP
+`\fBSet-update-prog \s-1DIR\s0 \en\fR'
+Additional data: \s-1PROG\s0 \en.  Tell the client to set an update
+program, which should be supplied with the `\fBUpdate-prog\fR' request
+for future operations.
+.PP
+`\fBNotified \s-1PATHNAME\s0 \en\fR'
+Indicate to the client that the notification for \s-1PATHNAME\s0 has been
+done.  There should be one such response for every `\fBNotify\fR'
+request; if there are several `\fBNotify\fR' requests for a single file,
+the requests should be processed in order; the first `\fBNotified\fR'
+response pertains to the first `\fBNotify\fR' request, etc.
+.PP
+`\fBModule-expansion \s-1PATHNAME\s0 \en\fR'
+Return a file or directory which is included in a particular
+module.  \s-1PATHNAME\s0 is relative to cvsroot, unlike most pathnames in
+responses.  \s-1PATHNAME\s0 should be used to look and see whether some
+or all of the module exists on the client side; it is not
+necessarily suitable for passing as an argument to a `\fBco\fR' request
+(for example, if the modules file contains the `\fB\-d\fR' option, it
+will be the directory specified with `\fB\-d\fR', not the name of the
+module).
+.PP
+`\fBWrapper-rcsOption \s-1PATTERN\s0 \-k \fR'\s-1OPTION\s0' \en'
+Transmit to the client a filename pattern which implies a certain
+keyword expansion mode.  The \s-1PATTERN\s0 is a wildcard pattern (for
+example, `\fB*.exe\fR'.  The \s-1OPTION\s0 is `\fBb\fR' for binary, and so on.  Note
+that although the syntax happens to resemble the syntax in certain
+\&\s-1CVS\s0 configuration files, it is more constrained; there must be
+exactly one space between \s-1PATTERN\s0 and `\fB\-k\fR' and exactly one space
+between `\fB\-k\fR' and `'', and no string is permitted in place of `\fB\-k\fR'
+(extensions should be done with new responses, not by extending
+this one, for graceful handling of `\fBValid-responses\fR').
+.PP
+`\fBM \s-1TEXT\s0 \en\fR'
+A one-line message for the user.  Note that the format of \s-1TEXT\s0 is
+not designed for machine parsing.  Although sometimes scripts and
+clients will have little choice, the exact text which is output is
+subject to vary at the discretion of the server and the example
+output given in this document is just that, example output.
+Servers are encouraged to use the `\fB\s-1MT\s0\fR' response, and future
+versions of this document will hopefully standardize more of the
+`\fB\s-1MT\s0\fR' tags; see see \*(L"Text tags\*(R".
+.PP
+`\fBMbinary \en\fR'
+Additional data: file transmission (note: compressed file
+transmissions are not supported).  This is like `\fBM\fR', except the
+contents of the file transmission are binary and should be copied
+to standard output without translation to local text file
+conventions.  To transmit a text file to standard output, servers
+should use a series of `\fBM\fR' requests.
+.PP
+`\fBE \s-1TEXT\s0 \en\fR'
+Same as `\fBM\fR' but send to stderr not stdout.
+.PP
+`\fBF \en\fR'
+Flush stderr.  That is, make it possible for the user to see what
+has been written to stderr (it is up to the implementation to
+decide exactly how far it should go to ensure this).
+.PP
+`\fB\s-1MT TAGNAME DATA\s0 \en\fR'
+This response provides for tagged text.  It is similar to
+\&\s-1SGML/HTML/XML\s0 in that the data is structured and a naive
+application can also make some sense of it without understanding
+the structure.  The syntax is not SGML-like, however, in order to
+fit into the \s-1CVS\s0 protocol better and (more importantly) to make it
+easier to parse, especially in a language like perl or awk.
+.PP
+The \s-1TAGNAME\s0 can have several forms.  If it starts with `\fBa\fR' to `\fBz\fR'
+or `\fBA\fR' to `\fBZ\fR', then it represents tagged text.  If the
+implementation recognizes \s-1TAGNAME,\s0 then it may interpret \s-1DATA\s0 in
+some particular fashion.  If the implementation does not recognize
+\&\s-1TAGNAME,\s0 then it should simply treat \s-1DATA\s0 as text to be sent to
+the user (similar to an `\fBM\fR' response).  There are two tags which
+are general purpose.  The `\fBtext\fR' tag is similar to an unrecognized
+tag in that it provides text which will ordinarily be sent to the
+user.  The `\fBnewline\fR' tag is used without \s-1DATA\s0 and indicates that a
+newline will ordinarily be sent to the user (there is no provision
+for embedding newlines in the \s-1DATA\s0 of other tagged text responses).
+.PP
+If \s-1TAGNAME\s0 starts with `\fB+\fR' it indicates a start tag and if it
+starts with `\fB\-\fR' it indicates an end tag.  The remainder of \s-1TAGNAME\s0
+should be the same for matching start and end tags, and tags
+should be nested (for example one could have tags in the following
+order `\fB+bold\fR' `\fB+italic\fR' `\fBtext\fR' `\fB\-italic\fR' `\fB\-bold\fR' but not `\fB+bold\fR'
+`\fB+italic\fR' `\fBtext\fR' `\fB\-bold\fR' `\fB\-italic\fR').  A particular start and end
+tag may be documented to constrain the tagged text responses which
+are valid between them.
+.PP
+Note that if \s-1DATA\s0 is present there will always be exactly one
+space between \s-1TAGNAME\s0 and \s-1DATA\s0; if there is more than one space,
+then the spaces beyond the first are part of \s-1DATA.\s0
+.PP
+Here is an example of some tagged text responses.  Note that there
+is a trailing space after `\fBChecking in\fR' and `\fBinitial revision:\fR'
+and there are two trailing spaces after `\fB<\-\-\fR'.  Such trailing
+spaces are, of course, part of \s-1DATA.\s0
+.PP
+\&\s-1MT\s0 +checking\-in
+\&\s-1MT\s0 text Checking in
+\&\s-1MT\s0 fname gz.tst
+\&\s-1MT\s0 text ;
+\&\s-1MT\s0 newline
+\&\s-1MT\s0 rcsfile /home/kingdon/zwork/cvsroot/foo/gz.tst,v
+\&\s-1MT\s0 text   <\-\-
+\&\s-1MT\s0 fname gz.tst
+\&\s-1MT\s0 newline
+\&\s-1MT\s0 text initial revision:
+\&\s-1MT\s0 init-rev 1.1
+\&\s-1MT\s0 newline
+\&\s-1MT\s0 text done
+\&\s-1MT\s0 newline
+\&\s-1MT\s0 \-checking\-in
+.PP
+If the client does not support the `\fB\s-1MT\s0\fR' response, the same
+responses might be sent as:
+.PP
+M Checking in gz.tst;
+M /home/kingdon/zwork/cvsroot/foo/gz.tst,v  <\-\-  gz.tst
+M initial revision: 1.1
+M done
+.PP
+For a list of specific tags, see see \*(L"Text tags\*(R".
+.PP
+`error ERRNO-CODE `\fB \fR' \s-1TEXT\s0 \en'
+The command completed with an error.  ERRNO-CODE is a symbolic
+error code (e.g. `\fB\s-1ENOENT\s0\fR'); if the server doesn't support this
+feature, or if it's not appropriate for this particular message,
+it just omits the errno-code (in that case there are two spaces
+after `\fBerror\fR').  Text is an error message such as that provided by
+\&\fIstrerror()\fR, or any other message the server wants to use.  The
+\&\s-1TEXT\s0 is like the `\fBM\fR' response, in the sense that it is not
+particularly intended to be machine-parsed; servers may wish to
+print an error message with `\fB\s-1MT\s0\fR' responses, and then issue a
+`\fBerror\fR' response without \s-1TEXT \s0(although it should be noted that
+`\fB\s-1MT\s0\fR' currently has no way of flagging the output as intended for
+standard error, the way that the `\fBE\fR' response does).
+.PP
+`\fBok \en\fR'
+The command completed successfully.
+.PP
+\&\fB5.12 Tags for the \s-1MT\s0 tagged text response\fR
+.PP
+The `\fB\s-1MT\s0\fR' response, as described in see \*(L"Responses\*(R", offers a way for
+the server to send tagged text to the client.  This section describes
+specific tags.  The intention is to update this section as servers add
+new tags.
+.PP
+In the following descriptions, `\fBtext\fR' and `\fBnewline\fR' tags are
+omitted.  Such tags contain information which is intended for users (or
+to be discarded), and are subject to change at the whim of the server.
+To avoid being vulnerable to such whim, clients should look for the tags
+listed here, not `\fBtext\fR', `\fBnewline\fR', or other tags.
+.PP
+The following tag means to indicate to the user that a file has been
+updated.  It is more or less redundant with the `\fBCreated\fR' and
+`\fBUpdate-existing\fR' responses, but we don't try to specify here whether
+it occurs in exactly the same circumstances as `\fBCreated\fR' and
+`\fBUpdate-existing\fR'.  The \s-1NAME\s0 is the pathname of the file being updated
+relative to the directory in which the command is occurring (that is,
+the last `\fBDirectory\fR' request which is sent before the command).
+.PP
+\&\s-1MT\s0 +updated
+\&\s-1MT\s0 fname \s-1NAME
+MT\s0 \-updated
+.PP
+The `\fBimportmergecmd\fR' tag is used when doing an import which has
+conflicts, or when doing an import with the `\fB\-X\fR' flag.  The client can
+use it to report how to merge in the newly imported changes.  The \s-1COUNT\s0
+is the number of conflicts, or the string `\fBNo\fR' if no conflicts
+occurred.  (The latter will only be sent for imports run with the `\fB\-X\fR'
+flag.)  The newly imported changes can be merged by running the
+following command:
+cvs checkout \-j \s-1TAG1\s0 \-j \s-1TAG2 REPOSITORY\s0
+.PP
+\&\s-1MT\s0 +importmergecmd
+\&\s-1MT\s0 conflicts \s-1COUNT
+MT\s0 mergetag1 \s-1TAG1
+MT\s0 mergetag2 \s-1TAG2
+MT\s0 repository \s-1REPOSITORY
+MT\s0 \-importmergecmd
+.PP
+\&\fB5.13 Example\fR
+.PP
+Here is an example; lines are prefixed by `\fBC: \fR' to indicate the client
+sends them or `\fBS: \fR' to indicate the server sends them.
+.PP
+The client starts by connecting, sending the root, and completing the
+protocol negotiation.  In actual practice the lists of valid responses
+and requests would be longer.
+.PP
+C: Root /u/cvsroot
+C: Valid-responses ok error Checked-in M E
+C: valid-requests
+S: Valid-requests Root Directory Entry Modified Argument Argumentx ci co
+S: ok
+C: UseUnchanged
+.PP
+The client wants to check out the `\fBsupermunger\fR' module into a fresh
+working directory.  Therefore it first expands the `\fBsupermunger\fR'
+module; this step would be omitted if the client was operating on a
+directory rather than a module.
+.PP
+C: Argument supermunger
+C: Directory .
+C: .
+C: expand-modules
+.PP
+The server replies that the `\fBsupermunger\fR' module expands to the
+directory `\fBsupermunger\fR' (the simplest case):
+.PP
+S: Module-expansion supermunger
+S: ok
+.PP
+The client then proceeds to check out the directory.  The fact that
+it sends only a single `\fBDirectory\fR' request which specifies `\fB.\fR' for the
+working directory means that there is not already a `\fBsupermunger\fR'
+directory on the client.
+.PP
+C: Argument \-N
+C: Argument supermunger
+C: Directory .
+C: .
+C: co
+.PP
+The server replies with the requested files.  In this example, there
+is only one file, `\fBmungeall.c\fR'.  The `\fBClear-sticky\fR' and
+`\fBClear-static-directory\fR' requests are sent by the current
+implementation but they have no effect because the default is for those
+settings to be clear when a directory is newly created.
+.PP
+S: Clear-sticky supermunger/
+S: /u/cvsroot/supermunger/
+S: Clear-static-directory supermunger/
+S: /u/cvsroot/supermunger/
+S: E cvs server: Updating supermunger
+S: M U supermunger/mungeall.c
+S: Created supermunger/
+S: /u/cvsroot/supermunger/mungeall.c
+S: /mungeall.c/1.1///
+S: u=rw,g=r,o=r
+S: 26
+S: int mein () { abort (); }
+S: ok
+.PP
+The current client implementation would break the connection here
+and make a new connection for the next command.  However, the protocol
+allows it to keep the connection open and continue, which is what we
+show here.
+.PP
+After the user modifies the file and instructs the client to check it
+back in.  The client sends arguments to specify the log message and file
+to check in:
+.PP
+C: Argument \-m
+C: Argument Well, you see, it took me hours and hours to find
+C: Argumentx this typo and I searched and searched and eventually
+C: Argumentx had to ask John for help.
+C: Argument mungeall.c
+.PP
+It also sends information about the contents of the working
+directory, including the new contents of the modified file.  Note that
+the user has changed into the `\fBsupermunger\fR' directory before executing
+this command; the top level directory is a user-visible concept because
+the server should print filenames in `\fBM\fR' and `\fBE\fR' responses relative to
+that directory.
+.PP
+C: Directory .
+C: supermunger
+C: Entry /mungeall.c/1.1///
+C: Modified mungeall.c
+C: u=rw,g=r,o=r
+C: 26
+C: int main () { abort (); }
+.PP
+And finally, the client issues the checkin command (which makes use
+of the data just sent):
+.PP
+C: ci
+.PP
+And the server tells the client that the checkin succeeded:
+.PP
+S: M Checking in mungeall.c;
+S: E /u/cvsroot/supermunger/mungeall.c,v  <\-\-  mungeall.c
+S: E new revision: 1.2; previous revision: 1.1
+S: E done
+S: Mode u=rw,g=r,o=r
+S: Checked-in ./
+S: /u/cvsroot/supermunger/mungeall.c
+S: /mungeall.c/1.2///
+S: ok
+.PP
+\&\fB5.14 Required versus optional parts of the protocol\fR
+.PP
+The following are part of every known implementation of the \s-1CVS\s0 protocol
+(except obsolete, pre\-1.5, versions of \s-1CVS\s0) and it is considered
+reasonable behavior to completely fail to work if you are connected with
+an implementation which attempts to not support them.  Requests:
+`\fBRoot\fR', `\fBValid-responses\fR', `\fBvalid-requests\fR', `\fBDirectory\fR', `\fBEntry\fR',
+`\fBModified\fR', `\fBUnchanged\fR', `\fBArgument\fR', `\fBArgumentx\fR', `\fBci\fR', `\fBco\fR', `\fBupdate\fR'.
+Responses: `\fBok\fR', `\fBerror\fR', `\fBValid-requests\fR', `\fBChecked-in\fR', `\fBUpdated\fR',
+`\fBMerged\fR', `\fBRemoved\fR', `\fBM\fR', `\fBE\fR'.
+.PP
+A server need not implement `\fBRepository\fR', but in order to
+interoperate with \s-1CVS 1.5\s0 through 1.9 it must claim to implement it (in
+`\fBValid-requests\fR').  The client will not actually send the request.
+.PP
+\&\fB5.15 Obsolete protocol elements\fR
+.PP
+This section briefly describes protocol elements which are obsolete.
+There is no attempt to document them in full detail.
+.PP
+There was a `\fBRepository\fR' request which was like `\fBDirectory\fR' except
+it only provided \s-1REPOSITORY,\s0 and the local directory was assumed to be
+similarly named.
+.PP
+If the `\fBUseUnchanged\fR' request was not sent, there was a `\fBLost\fR'
+request which was sent to indicate that a file did not exist in the
+working directory, and the meaning of sending `\fBEntries\fR' without `\fBLost\fR'
+or `\fBModified\fR' was different.  All current clients (\s-1CVS 1.5\s0 and later)
+will send `\fBUseUnchanged\fR' if it is supported.
+.SS "6 Notes on the Protocol"
+.IX Subsection "6 Notes on the Protocol"
+A number of enhancements are possible.  Also see the file \s-1TODO\s0 in the
+\&\s-1CVS\s0 source distribution, which has further ideas concerning various
+aspects of \s-1CVS,\s0 some of which impact the protocol.  Similarly, the
+`\fBhttp://www.nongnu.org/cvs/\fR' site, in particular the `\fBDevelopment\fR'
+pages.
+.PP
+* The `\fBModified\fR' request could be speeded up by sending diffs rather
+than entire files.  The client would need some way to keep the
+version of the file which was originally checked out; probably
+requiring the use of \*(L"cvs edit\*(R" in this case is the most sensible
+course (the \*(L"cvs edit\*(R" could be handled by a package like \s-1VC\s0 for
+emacs).  This would also allow local operation of `\fBcvs diff\fR'
+without arguments.
+.PP
+* The fact that `\fBpserver\fR' requires an extra network turnaround in
+order to perform authentication would be nice to avoid.  This
+relates to the issue of reporting errors; probably the clean
+solution is to defer the error until the client has issued a
+request which expects a response.  To some extent this might
+relate to the next item (in terms of how easy it is to skip a
+whole bunch of requests until we get to one that expects a
+response).  I know that the kerberos code doesn't wait in this
+fashion, but that probably can cause network deadlocks and perhaps
+future problems running over a transport which is more transaction
+oriented than \s-1TCP. \s0 On the other hand I'm not sure it is wise to
+make the client conduct a lengthy upload only to find there is an
+authentication failure.
+.PP
+* The protocol uses an extra network turnaround for protocol
+negotiation (`\fBvalid-requests\fR').  It might be nice to avoid this by
+having the client be able to send requests and tell the server to
+ignore them if they are unrecognized (different requests could
+produce a fatal error if unrecognized).  To do this there should
+be a standard syntax for requests.  For example, perhaps all
+future requests should be a single line, with mechanisms analogous
+to `\fBArgumentx\fR', or several requests working together, to provide
+greater amounts of information.  Or there might be a standard
+mechanism for counted data (analogous to that used by `\fBModified\fR')
+or continuation lines (like a generalized `\fBArgumentx\fR').  It would
+be useful to compare what \s-1HTTP\s0 is planning in this area; last I
+looked they were contemplating something called Protocol Extension
+Protocol but I haven't looked at the relevant \s-1IETF\s0 documents in
+any detail.  Obviously, we want something as simple as possible
+(but no simpler).
+.PP
+* The scrambling algorithm in the \s-1CVS\s0 client and server actually
+support more characters than those documented in *note Password
+scrambling::.  Someday we are going to either have to document
+them all (but this is not as easy as it may look, see below), or
+(gradually and with adequate process) phase out the support for
+other characters in the \s-1CVS\s0 implementation.  This business of
+having the feature partly undocumented isn't a desirable state
+long-term.
+.PP
+The problem with documenting other characters is that unless we
+know what character set is in use, there is no way to make a
+password portable from one system to another.  For example, a with
+a circle on top might have different encodings in different
+character sets.
+.PP
+It _almost_ works to say that the client picks an arbitrary,
+unknown character set (indeed, having the \s-1CVS\s0 client know what
+character set the user has in mind is a hard problem otherwise),
+and scrambles according to a certain octet<\->octet mapping.  There
+are two problems with this.  One is that the protocol has no way
+to transmit character 10 decimal (linefeed), and the current
+server and clients have no way to handle 0 decimal (\s-1NUL\s0).  This
+may cause problems with certain multibyte character sets, in which
+octets 10 and 0 will appear in the middle of other characters.
+The other problem, which is more minor and possibly not worth
+worrying about, is that someone can type a password on one system
+and then go to another system which uses a different encoding for
+the same characters, and have their password not work.
+.PP
+The restriction to the \s-1ISO646\s0 invariant subset is the best
+approach for strings which are not particularly significant to
+users.  Passwords are visible enough that this is somewhat
+doubtful as applied here.  \s-1ISO646\s0 does, however, have the virtue
+(!?) of offending everyone.  It is easy to say \*(L"But the $ is right
+on people's keyboards!  Surely we can't forbid that\*(R".  From a
+human factors point of view, that makes quite a bit of sense.  The
+contrary argument, of course, is that a with a circle on top, or
+some of the characters poorly handled by Unicode, are on
+_someone_'s keyboard.
diff --git a/gnu/usr.bin/cvs/doc/Makefile b/gnu/usr.bin/cvs/doc/Makefile
deleted file mode 100644 (file)
index dde2419..0000000
+++ /dev/null
@@ -1,25 +0,0 @@
-# $FreeBSD: src/gnu/usr.bin/cvs/doc/Makefile,v 1.12.2.3 2002/12/19 21:18:01 peter Exp $
-
-.include "${.CURDIR}/../Makefile.inc"
-
-SRCDIR= ${CVSDIR}/doc
-
-INFO=  cvs cvsclient
-INFOSECTION= "Programming & development tools."
-INFOENTRY_cvs= "* CVS: (cvs).                  CVS Reference Manual."
-INFOENTRY_cvsclient= "* CVS-CLIENT: (cvsclient).       CVS client/server Reference Manual."
-MAKEINFOFLAGS+=        --no-warn
-
-CLEANFILES+=   getdate-cvs.texi cvs.texinfo
-
-cvs.info: getdate-cvs.texi
-
-cvs.texinfo: ${SRCDIR}/${.TARGET}
-       cp ${.ALLSRC} ${.TARGET}
-
-getdate-cvs.texi: getdate.texi
-       sed -e "s/^@chapter /@appendixsec /" \
-           -e "s/^@section /@appendixsubsec /" \
-           < ${.ALLSRC} > ${.TARGET}
-
-.include <bsd.info.mk>