--- cvs-1.12.13+real.orig/doc/cvsclient.texi
+++ cvs-1.12.13+real/doc/cvsclient.texi
@@ -1,6 +1,18 @@
 \input texinfo @c -*- texinfo -*-
 
 @setfilename cvsclient.info
+@set MBSDPATCHLEVEL -MirOS-0AB8.4
+@tex
+ % set PA4 paper size (can print on both DIN ISO A4 and US Letter)
+ \globaldefs = 1%
+ \afourpaper%
+ \internalpagesizes{46\baselineskip}{160mm}%
+  {\voffset}{\hoffset}%
+  {\bindingoffset}{36pt}%
+  {28truecm}{21truecm}%
+ \globaldefs = 0%
+@end tex
+@comment $MirOS: src/gnu/usr.bin/cvs/doc/cvsclient.texi,v 1.11 2017/11/18 22:37:52 tg Exp $
 @include version-client.texi
 
 @dircategory Programming
@@ -12,10 +24,10 @@
 @top CVS Client/Server
 
 This document describes the client/server protocol used by CVS.  It does
-not describe how to use or administer client/server CVS; see the regular
-CVS manual for that.  This is version @value{VERSION} of the protocol
-specification---@xref{Introduction}, for more on what this version number
-means.
+not describe how to use or administer client/server CVS; for that,
+@pxref{Top, the regular CVS manual,, cvs, the regular CVS manual}.
+This specification applies to
+@sc{cvs} version @value{VERSION}@value{MBSDPATCHLEVEL} and up.
 
 @menu
 * Introduction::      What is CVS and what is the client/server protocol for?
@@ -53,7 +65,7 @@
 user documentation, @file{cvs.texinfo}, for that information.  The
 protocol is non-proprietary (anyone who wants to is encouraged to
 implement it) and an implementation, known as CVS, is available under
-the GNU Public License.  The CVS distribution, containing this
+the GNU General Public License.  The CVS distribution, containing this
 implementation, @file{cvs.texinfo}, and a copy (possibly more or less up
 to date than what you are reading now) of this document,
 @file{cvsclient.texi}, can be found at the usual GNU FTP sites, with a
@@ -149,7 +161,7 @@
 the client proceeds to start the cvs protocol.
 
 @item kserver
-The kerberized server listens on a port (in the current implementation,
+The kerberised server listens on a port (in the current implementation,
 by having inetd call "cvs kserver") which defaults to 1999.  The client
 connects, sends the usual kerberos authentication information, and then
 starts the cvs protocol.  Note: port 1999 is officially registered for
@@ -217,7 +229,7 @@
 close the connection.  The @var{code} is a code describing why it
 failed, intended for computer consumption.  The only code currently
 defined is @samp{0} which is nonspecific, but clients must silently
-treat any unrecognized codes as nonspecific.
+treat any unrecognised codes as nonspecific.
 The @var{text} should be supplied to the
 user.  Compatibility note: @sc{cvs} 1.9.10 and older clients will print
 @code{unrecognized auth response} and @var{text}, and then exit, upon
@@ -393,13 +405,13 @@
 @var{mode-type} is an identifier composed of alphanumeric characters.
 Currently specified: @samp{u} for user, @samp{g} for group, @samp{o}
 for other (see below for discussion of whether these have their POSIX
-meaning or are more loose).  Unrecognized values of @var{mode-type}
+meaning or are more loose).  Unrecognised values of @var{mode-type}
 are silently ignored.
 
 @var{data} consists of any data not containing @samp{,}, @samp{\0} or
 @samp{\n}.  For @samp{u}, @samp{g}, and @samp{o} mode types, data
 consists of alphanumeric characters, where @samp{r} means read, @samp{w}
-means write, @samp{x} means execute, and unrecognized letters are
+means write, @samp{x} means execute, and unrecognised letters are
 silently ignored.
 
 The two most obvious ways in which the mode matters are: (1) is it
@@ -471,12 +483,13 @@
 In various contexts, for example the @code{Argument} request and the
 @code{M} response, one transmits what is essentially an arbitrary
 string.  Often this will have been supplied by the user (for example,
-the @samp{-m} option to the @code{ci} request).  The protocol has no
-mechanism to specify the character set of such strings; it would be
-fairly safe to stick to the invariant ISO 646 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.
+the @samp{-m} option to the @code{ci} request will show up in the
+@code{LOGM} response).  The protocol has no mechanism to specify the
+character set of such strings; it would have been, initially, fairly
+safe to stick to the invariant ISO 646 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. In modern times, UTF-8 should be used.
 
 @node Dates
 @section Dates
@@ -513,7 +526,7 @@
 
 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 @samp{gzip-file-contents}.  Unrecognized requests will
+exception is @samp{gzip-file-contents}.  Unrecognised requests will
 always elicit a response from the server, even if that request begins
 with a capital letter.
 
@@ -568,7 +581,7 @@
 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.
+for reads to minimise races on any subsequent updates from the client.
 
 @item Directory @var{local-directory} \n
 @itemx Relative-directory @var{local-directory} \n
@@ -828,7 +841,7 @@
 @end example
 
 There is no requirement that the client and server clocks be
-synchronized.  The client just sends its recommendation for a timestamp
+synchronised.  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).
 
@@ -1227,6 +1240,13 @@
 directory and @emph{not} a fully qualified @code{CVSROOT} variable.
 The @code{Root} request need not have been previously sent.
 
+@item suck \n
+Response expected: yes.
+Actually do a @code{cvs suck} command.
+This uses a previous @code{Argument} request (only one, because the
+@code{cvs suck} CLI command takes only one).
+This is an extension specific to MirBSD, MirPorts and Debian.
+
 @item update \n
 Response expected: yes.  Actually do a @code{cvs update} command.  This
 uses any previous @code{Argument}, @code{Directory}, @code{Entry},
@@ -1268,7 +1288,7 @@
 C: Directory .
 C: 1dir
 C: add
-S: M Directory /u/cvsroot/1dir/nsdir added to the repository
+S: M Directory /u/cvsroot/1dir/nsdir put under version control
 S: ok
 @end example
 
@@ -1414,7 +1434,7 @@
 
 @item @var{other-request} @var{text} \n
 Response expected: yes.
-Any unrecognized request expects a response, and does not
+Any unrecognised request expects a response, and does not
 contain any additional data.  The response will normally be something like
 @samp{error  unrecognized request}, but it could be a different error if
 a previous request which doesn't expect a response produced an error.
@@ -1640,7 +1660,7 @@
 @end example
 
 There is no requirement that the client and server clocks be
-synchronized.  The server just sends its recommendation for a timestamp
+synchronised.  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).
 
@@ -1757,15 +1777,22 @@
 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 @samp{MT} response,
-and future versions of this document will hopefully standardize more of
+and future versions of this document will hopefully standardise more of
 the @samp{MT} tags; see @ref{Text tags}.
 
+@item LOGM @var{text} \n
+Exactly the same as @code{M} but only sent if the client indicates
+supporting it via @code{Valid-responses}, used exclusively for log
+message payload (that is, in @code{cvs log} and @code{cvs rlog},
+the text body the user originally has entered with the @samp{-m}
+option to the @code{ci} request).
+
 @item Mbinary \n
 Additional data: file transmission (note: compressed file transmissions
-are not supported).  This is like @samp{M}, except the contents of the
+are not supported).  This is like @code{M}, except the contents of the
 file transmission are binary and should be copied to standard output
 without translation to local text file conventions.  To transmit a text
-file to standard output, servers should use a series of @samp{M} requests.
+file to standard output, servers should use a series of @code{M} requests.
 
 @item E @var{text} \n
 Same as @code{M} but send to stderr not stdout.
@@ -1789,12 +1816,12 @@
 
 The @var{tagname} can have several forms.  If it starts with @samp{a}
 to @samp{z} or @samp{A} to @samp{Z}, then it represents tagged text.
-If the implementation recognizes @var{tagname}, then it may interpret
+If the implementation recognises @var{tagname}, then it may interpret
 @var{data} in some particular fashion.  If the implementation does not
-recognize @var{tagname}, then it should simply treat @var{data} as
-text to be sent to the user (similar to an @samp{M} response).  There
+recognise @var{tagname}, then it should simply treat @var{data} as
+text to be sent to the user (similar to an @code{M} response).  There
 are two tags which are general purpose.  The @samp{text} tag is
-similar to an unrecognized tag in that it provides text which will
+similar to an unrecognised tag in that it provides text which will
 ordinarily be sent to the user.  The @samp{newline} tag is used
 without @var{data} and indicates that a newline will ordinarily be
 sent to the user (there is no provision for embedding newlines in the
@@ -2133,13 +2160,13 @@
 The protocol uses an extra network turnaround for protocol negotiation
 (@code{valid-requests}).  It might be nice to avoid this by having the
 client be able to send requests and tell the server to ignore them if
-they are unrecognized (different requests could produce a fatal error if
-unrecognized).  To do this there should be a standard syntax for
+they are unrecognised (different requests could produce a fatal error if
+unrecognised).  To do this there should be a standard syntax for
 requests.  For example, perhaps all future requests should be a single
 line, with mechanisms analogous to @code{Argumentx}, or several requests
 working together, to provide greater amounts of information.  Or there
 might be a standard mechanism for counted data (analogous to that used
-by @code{Modified}) or continuation lines (like a generalized
+by @code{Modified}) or continuation lines (like a generalised
 @code{Argumentx}).  It would be useful to compare what HTTP is planning
 in this area; last I looked they were contemplating something called
 Protocol Extension Protocol but I haven't looked at the relevant IETF
