Hello! I'm brand new user of Monotone which I like very much (along with the darcs which is my No. 1).
However, I believe that when Indefero get mtn support, we'll switch fully. Atm, I'm still learning about mtn by playing with it a bit and reading the docs. Please, excuse me for dare to 'fix' and/or suggest something to the present docs, especially considering I'm non-native English 'speaker'. However, I won't be offended at all if none of the fixes/suggestions are going to be applied. :-) In the attachment, there is patch for chapter-1 of the docs. Sincerely, Gour p.s. I tried to create public pullable repo on mtn-host.prjke.net, but syncs stalled/failed and now I'm stuck - cannot resume nor re-create the project from the scratch (until admin cleans the mess). -- Gour | Hlapicina, Croatia | GPG key: F96FF5F6 ----------------------------------------------------------------
#
#
# 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 vers...@footnote{we
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 lat...@footnote{i 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
signature.asc
Description: PGP signature
_______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
