#
#
# patch "monotone.texi"
#  from [9dda37094f00c7ea80af646b4c4e6787dc019cdb]
#    to [c1fef42c317708808d7c8f32c9bf255a72528857]
#
============================================================
--- monotone.texi	9dda37094f00c7ea80af646b4c4e6787dc019cdb
+++ monotone.texi	c1fef42c317708808d7c8f32c9bf255a72528857
@@ -157,7 +157,7 @@ @section Versions of files
 bytes, which we will use to uniquely identify the address@hidden
 say @sc{sha1} values are ``unique'' here, when in fact there is a
 small probability of two different versions having the same @sc{sha1}
-value. This probability is very small, so we discount it.}. Now our
+value. This probability is very small, so we discount it.}.  Now our
 graph does not refer to some ``abstract'' parent and child, but rather
 to the exact edit we performed between a specific parent and a
 specific child.
@@ -310,8 +310,7 @@ @section Versions of trees
 file, or different contents for the same name.
 
 Other entries in the manifest format name directories or store file
-attributes, which we will cover address@hidden believe this sentence
-could be made more clear.}
+attributes, which we will cover later.
 
 @ifinfo
 @smallexample
@@ -399,7 +398,7 @@ @section Versions of trees
 As with versions of files, we may decide to store manifests in their
 entirety, or else we may store only a compact description of changes
 which occur between different versions of manifests. As with files,
-when possible, monotone stores compact descriptions of changes between
+when possible monotone stores compact descriptions of changes between
 manifests; when necessary it stores complete versions of manifests.
 
 @page
@@ -408,8 +407,8 @@ @section Historical records
 
 Suppose you sit down to edit some files. Before you start working, you
 may record a manifest of the files, for reference sake. When you
-finish working, you may record another manifest. These ``before'' and
-``after'' snapshots of the tree of files you worked on can serve as
+finish working, you may record another manifest. These ``before and
+after'' snapshots of the tree of files you worked on can serve as
 historical records of the set of changes, or @dfn{changeset}, that you
 made. In order to capture a ``complete'' view of history -- both the
 changes made and the state of your file tree on either side of those
@@ -455,7 +454,7 @@ @section Historical records
 The content of a revision includes one or more changesets.  These
 changesets make reference to file IDs, to describe how the tree changed.
 The revision also contains manifest IDs, as another way of describing
-the tree ``before'' and ``after'' the changeset --- storing this information
+the tree ``before and after'' the changeset --- storing this information
 in two forms allows monotone to detect any bugs or corrupted data before
 they can enter your history.  Finally and crucially, revisions also make
 reference to @i{other revision IDs}. This fact -- that revisions include
@@ -573,8 +572,8 @@ @section Certificates
 In an ideal world, these are all the parts of a statement we would
 need in order to go about our work. In the real world, however, there
 are sometimes malicious people who would make false or misleading
-statements, so we need a way to verify that a particular person made a
-particular statement about a revision. Therefore, we will add two more
+statements; so we need a way to verify that a particular person made a
+particular statement about a revision. We therefore will add two more
 pieces of information to our bundle:
 
 @itemize
@@ -621,19 +620,19 @@ @section Certificates
 trustworthiness you assign to those certs.
 
 The @sc{rsa} cryptography system --- and therefore monotone itself ---
-requires that you exchange special ``public'' numbers with your friends,
-before they will trust certificates signed by you. These numbers are
-called @dfn{public keys}. Giving someone your public key does not give
-them the power to @i{impersonate} you, but only ability to verify
+requires that you exchange special ``public'' numbers with your
+friends, before they will trust certificates signed by you. These
+numbers are called @dfn{public keys}. Giving someone your public key
+does not give them the power to @i{impersonate} you, only to verify
 signatures made by you. Exchanging public keys should be done over a
-trusted medium, in person, or via a trusted third party. Advanced secure
-key exchange techniques are beyond the scope of this document.
+trusted medium, in person, or via a trusted third party. Advanced
+secure key exchange techniques are beyond the scope of this document.
 
 @page
 @node    Storage and workflow, Forks and merges, Certificates, Concepts
 @section Storage and workflow
 
-Monotone moves information in and out of the four different types of
+Monotone moves information in and out of four different types of
 storage:
 
 @itemize
@@ -650,7 +649,7 @@ @section Storage and workflow
 The @dfn{keystore} is a directory @file{.monotone/keys} in your home directory
 which contains copies of all your private keys. Each key is stored in a file
 whose name is the key identifier with some characters converted to underscores.
-When you use a key to sign a cert, the public part of that key is copied into
+When you use a key to sign a cert, the public half of that key is copied into
 your local database along with the cert.
 
 All information passes @emph{through} your local database, en route to