[Cvs-cvs] ccvs/doc ChangeLog cvs.texinfo cvsclient.texi [cvs1-11-x-branch]

[Mark D. Baushke]

CVSROOT:        /cvsroot/cvs
Module name:    ccvs
Branch:         cvs1-11-x-branch
Changes by:     Mark D. Baushke <mdb>   06/08/12 03:02:36

Modified files:
        doc            : ChangeLog cvs.texinfo cvsclient.texi 

Log message:
        * cvs.texinfo, cvsclient.texi: Fix some typos.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/ccvs/doc/ChangeLog?cvsroot=cvs&only_with_tag=cvs1-11-x-branch&r1=1.721.2.123&r2=1.721.2.124
http://cvs.savannah.gnu.org/viewcvs/ccvs/doc/cvs.texinfo?cvsroot=cvs&only_with_tag=cvs1-11-x-branch&r1=1.545.2.67&r2=1.545.2.68
http://cvs.savannah.gnu.org/viewcvs/ccvs/doc/cvsclient.texi?cvsroot=cvs&only_with_tag=cvs1-11-x-branch&r1=1.130.6.6&r2=1.130.6.7

Patches:
Index: ChangeLog
===================================================================
RCS file: /cvsroot/cvs/ccvs/doc/ChangeLog,v
retrieving revision 1.721.2.123
retrieving revision 1.721.2.124
diff -u -b -r1.721.2.123 -r1.721.2.124
--- ChangeLog   16 Jul 2006 23:52:51 -0000      1.721.2.123
+++ ChangeLog   12 Aug 2006 03:02:36 -0000      1.721.2.124
@@ -1,3 +1,8 @@
+2006-08-11  Mark D. Baushke  <address@hidden>
+
+       * cvs.texinfo, cvsclient.texi: Fix some typos.
+       (inspired by Ralf Wildenhues <address@hidden>)
+
 2006-07-16  Derek Price  <address@hidden>
 
        * cvs.texinfo (File permissions): Correct punctuation.

Index: cvs.texinfo
===================================================================
RCS file: /cvsroot/cvs/ccvs/doc/cvs.texinfo,v
retrieving revision 1.545.2.67
retrieving revision 1.545.2.68
diff -u -b -r1.545.2.67 -r1.545.2.68
--- cvs.texinfo 16 Jul 2006 23:52:51 -0000      1.545.2.67
+++ cvs.texinfo 12 Aug 2006 03:02:36 -0000      1.545.2.68
@@ -338,7 +338,7 @@
 
 Of course, you should place the tools created to
 support such a build system (scripts, @file{Makefile}s,
-etc) under @sc{cvs}.
+etc.) under @sc{cvs}.
 
 Figuring out what files need to be rebuilt when
 something changes is, again, something to be handled
@@ -374,7 +374,7 @@
 files, will logically conflict with one another.  Its
 concept of a @dfn{conflict} is purely textual, arising
 when two changes to the same base file are near enough
-to spook the merge (i.e. @code{diff3}) command.
+to spook the merge (i.e., @code{diff3}) command.
 
 @sc{cvs} does not claim to help at all in figuring out
 non-textual or distributed conflicts in program logic.
@@ -394,7 +394,7 @@
 Change control refers to a number of things.  First of
 all it can mean @dfn{bug-tracking}, that is being able
 to keep a database of reported bugs and the status of
-each one (is it fixed?  in what release?  has the bug
+each one (Is it fixed?  In what release?  Has the bug
 submitter agreed that it is fixed?).  For interfacing
 @sc{cvs} to an external bug-tracking system, see the
 @file{rcsinfo} and @file{verifymsg} files
@@ -3541,7 +3541,7 @@
 
 When you tag more than one file with the same tag you
 can think about the tag as "a curve drawn through a
-matrix of filename vs. revision number."  Say we have 5
+matrix of filename vs.@: revision number."  Say we have 5
 files with the following revisions:
 
 @example
@@ -12242,7 +12242,7 @@
 @sc{cvs} will execute this program on the server from a temporary
 directory. The path is searched for this program.
 
-If using ``local access'' (on a local or remote NFS file system, i.e.
+If using ``local access'' (on a local or remote NFS file system, i.e.,
 repository set just to a path),
 the program will be executed from the newly checked-out tree, if
 found there, or alternatively searched for in the path if not.

Index: cvsclient.texi
===================================================================
RCS file: /cvsroot/cvs/ccvs/doc/cvsclient.texi,v
retrieving revision 1.130.6.6
retrieving revision 1.130.6.7
diff -u -b -r1.130.6.6 -r1.130.6.7
--- cvsclient.texi      9 Jun 2006 00:59:14 -0000       1.130.6.6
+++ cvsclient.texi      12 Aug 2006 03:02:36 -0000      1.130.6.7
@@ -205,7 +205,7 @@
 @samp{E} and/or @samp{error}.
 
 @item E @var{text}
-Provide a message for the user.  After this reponse, the authentication
+Provide a message for the user.  After this response, the authentication
 protocol continues with another response.  Typically the server will
 provide a series of @samp{E} responses followed by @samp{error}.
 Compatibility note: @sc{cvs} 1.9.10 and older clients will print
@@ -245,7 +245,7 @@
 The procedure here is to start with @samp{BEGIN
 GSSAPI REQUEST}.  GSSAPI authentication information is then exchanged
 between the client and the server.  Each packet of information consists
-of a two byte big endian length, followed by that many bytes of data.
+of a two byte big-endian length, followed by that many bytes of data.
 After the GSSAPI authentication is complete, the server continues with
 the responses described above (@samp{I LOVE YOU}, etc.).
 
@@ -569,7 +569,7 @@
 @code{Entry} or @code{Modified}, and then a final @code{Directory}
 for the original directory, then the command.
 The @var{local-directory} is relative to
-the top level at which the command is occurring (i.e. the last
+the top level at which the command is occurring (i.e., the last
 @code{Directory} which is sent before the command);
 to indicate that top level, @samp{.} should be sent for
 @var{local-directory}.
@@ -953,7 +953,7 @@
 situations where the user specifies a filename and the client does not
 know about that file).
 
-Though this request will be supported into the forseeable future, it has been
+Though this request will be supported into the foreseeable 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
@@ -1216,7 +1216,7 @@
 @code{Directory} request is ignored (it merely must point somewhere
 within the root).  The files to be imported are sent in @code{Modified}
 requests (files which the client knows should be ignored are not sent;
-the server must still process the CVSROOT/cvsignore file unless -I ! is
+the server must still process the CVSROOT/cvsignore file unless -I !@: is
 sent).  A log message must have been specified with a @code{-m}
 argument.
 
@@ -1393,7 +1393,7 @@
 @c lame terms (mostly because they are so awkward).  Any better ideas?
 The responses @code{Checked-in}, @code{New-entry}, @code{Updated},
 @code{Created}, @code{Update-existing}, @code{Merged}, and
address@hidden are refered to as @dfn{file updating} responses, because
address@hidden are referred to as @dfn{file updating} responses, because
 they change the status of a file in the working directory in some way.
 The responses @code{Mode}, @code{Mod-time}, and @code{Checksum} are
 referred to as @dfn{file update modifying} responses because they modify
@@ -1412,7 +1412,7 @@
 @c end in "/.".
 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
+relative to the directory in which the command was given (i.e., the last
 @code{Directory} before the command).  Then a linefeed and a repository
 name.  Then
 a slash and the filename (without a @samp{,v} ending).
@@ -1463,7 +1463,7 @@
 
 @item Checked-in @var{pathname} \n
 Additional data: New Entries line, \n.  This means a file @var{pathname}
-has been successfully operated on (checked in, added, etc.).  name in
+has been successfully operated on (checked in, added, etc.).  The name in
 the Entries line is the same as the last component of @var{pathname}.
 
 @item New-entry @var{pathname} \n
@@ -1857,7 +1857,7 @@
 @c line breaks.  Any better solutions?
 @c Other than that, this exchange is taken verbatim from the data
 @c exchanged by CVS (as of Nov 1996).  That is why some of the requests and
address@hidden reponses are not quite what you would pick for pedagogical 
purposes.
address@hidden responses are not quite what you would pick for pedagogical 
purposes.
 
 @example
 C: Root /u/cvsroot
@@ -2029,7 +2029,7 @@
 
 @itemize @bullet
 @item
-The @code{Modified} request could be speeded up by sending diffs rather
+The @code{Modified} request could be sped up by sending diffs rather
 than entire files.  The client would need some way to keep the version
 of the file which was originally checked out; probably requiring the use
 of "cvs edit" in this case is the most sensible course (the "cvs edit"