SHA1 Hash:	4038525bc57ebf41442110e335b616d9df872c98
Date:	2007-09-10 02:21:46
User:	aku
Comment:	Slight editorial changes to sync documentation, fixing spelling errors.
Timelines:	ancestors | descendants | both | trunk
Other Links:	files | ZIP archive | manifest

• branch=trunk inherited from [a28c83647d]
• sym-trunk inherited from [a28c83647d]

Modified www/sync.html from [ca710f907d] to [e2578a4066].

@@ -102,21 +102,21 @@
 
 <h3>2.1 Line-oriented Format</h3>
 
 <p>The x-fossil content type consists of zero or more "cards".  Cards
 are separate by the newline character ("\n").  Leading and trailing
-whitespace on a card is ignore.  Blank cards are ignored.</p>
+whitespace on a card is ignored.  Blank cards are ignored.</p>
 
 <p>Each card is divided into zero or more space separated tokens.
 The first token on each card is the operator.  Subsequent tokens
 are arguments.  The set of operators understood by servers is slightly
 different from the operators understood by clients, though the two
 are very similar.</p>
 
 <h3>2.2 Login Cards</h3>
 
-<p>Every message from client to server begins with one more login
+<p>Every message from client to server begins with one or more login
 cards.  Each login card has the following format:</p>
 
 <blockquote>
 <b>login</b>  <i>userid  nonce  signature</i>
 </blockquote>
@@ -147,11 +147,11 @@
 <b>file</b> <i>uuid delta-uuid size</i> <b>\n</b> <i>content</i>
 </blockquote>
 
 <p>File cards are different from all other cards in that they
 followed by in-line "payload" data.  The content of the file
-or the file delta consists of first <i>size</i> bytes of the
+or the file delta consists of the first <i>size</i> bytes of the
 x-fossil content that immediately follow the newline that
 terminates the file card.  No other cards have this characteristic.
 </p>
 
 <p>The first argument of a file card is the UUID of the file that
@@ -294,38 +294,38 @@
 receives a file card that references a delta source that it does not
 hold.  When a server is generating its reply or when a client is
 generating a new request, it will usually send gimme cards for every
 phantom that it holds.</p>
 
-<p>A cluster is a special file that tells of the existance of other
+<p>A cluster is a special file that tells of the existence of other
 files.  Any file in the repository that follows the syntactic rules
 of a cluster is considered a cluster.</p>
 
-<p>A cluster consists is a line oriented file.  Each line of a cluster
+<p>A cluster is a line oriented file.  Each line of a cluster
 is a card.  The cards are separated by the newline ("\n") character.
 Each card consists of a single character card type, a space, and a
 single argument.  No extra whitespace and no trailing or leading
 whitespace is allowed.  All cards in the cluster must occur in
-strict lexigraphical order.</p>
+strict lexicographical order.</p>
 
 <p>A cluster consists of one or more "M" cards followed by a single
 "Z" card.  Each M card holds an argument which is a UUID for a file
 in the repository.  The Z card has a single argument which is the
 lower-case hexadecimal representation of the MD5 checksum of all
-preceeding M cards up to and included the newline character that
+preceding M cards up to and included the newline character that
 occurred just before the Z that starts the Z card.</p>
 
 <p>Any file that does not match the specifications of a cluster
 exactly is not a cluster.  There must be no extra whitespace in
 the file.  There must be one or more M cards.  There must be a
 single Z card with a correct MD5 checksum.  And all cards must
-be in strict lexigraphical order.</p>
+be in strict lexicographical order.</p>
 
 <h3>3.1 The Unclustered Table</h3>
 
 <p>Every repository maintains a table named "<b>unclustered</b>"
-which records the identify of every file and phantom it holds that is not
+which records the identity of every file and phantom it holds that is not
 mentioned in a cluster.  The entries in the unclustered table can
 be thought of as leaves on a tree of files.  Some of the unclustered
 files will be clusters.  Those clusters may contain other clusters,
 which might contain still more clusters, and so forth.  Beginning
 with the files in the unclustered table, one can follow the chain