# HG changeset patch
# User Pierre-Yves.David@ens-lyon.org
# Date 1342403979 -7200
# Node ID f348088d3b3fb64c01592ba942e9b53f20afb06b
# Parent  c2f3cdd5a2a21f650b49bca80faa311ef8f83357
marmoute N+2 pass

diff -r c2f3cdd5a2a2 -r f348088d3b3f docs/obs-terms.rst
--- a/docs/obs-terms.rst	Sun Jul 15 16:19:02 2012 +0200
+++ b/docs/obs-terms.rst	Mon Jul 16 03:59:39 2012 +0200
@@ -10,11 +10,11 @@
 version.
 
 Old changesets are called **precursors** while their new versions are called
-**successors**. A marker always registers a single *precursor* to:
+**successors**. A marker always registers a single *precursor* and:
 
 - no *successor*: the *precursor* is just discarded.
 - one *successor*: the *precursor* has been rewritten
-- multiple *successors*: the *precursor* has been splitted in multiple
+- multiple *successors*: the *precursor* were splits in multiple
   changesets.
 
 .. The *precursors* and *successors* terms can be used on changeset directy:
@@ -25,27 +25,27 @@
 .. :successors: of a changeset `B` are changesets used as *successors* by
 ..              obsolete marker using changeset `B` as *precursors*
 
-Chainning obsolete markers is allowed to rewrite a changeset that is already a
+Chaining obsolete markers is allowed to rewrite a changeset that is already a
 *successor*. This is a kind of *second order version control*.
-To clarify ambiguous situtations one can use **direct precursors** or
+To clarify ambiguous situations one can use **direct precursors** or
 **direct successors** to name changesets that are directly related.
 
-The set of all **bsolete markers* forms a direct acyclic graph the same way
+The set of all *obsolete markers* forms a direct acyclic graph the same way
 standard *parents*/*children* relation does. In this graph we have:
 
 :any precursors: are transitive precursors of a changeset: *direct precursors*
                  and *precursors* of *precursors*.
 
 :any successors: are transitive successors of a changeset: *direct successors*
-                 and *precursors*  of *precursors*)
+                 and *successors*  of *successors*)
 
 Obsolete markers may refer changesets that are not known locally.
 So, *direct precursors* of a changeset may be unknown locally.
 This is why we usually focus on the **first known precursors**  of the rewritten
 changeset. The same apply for *successors*.
 
-Changeset in *any successors* which are not **precursor**[#] are called
-**newest successors**.
+Changeset in *any successors* which are not **Obsolete** are called
+**newest successors**..
 
 .. note:: I'm not very happy with this naming scheme and I'm looking for a
           better distinction between *direct successors* and **any successors*.
@@ -54,7 +54,7 @@
 ---------------------------------
 
 The following table describes names and behaviors of changesets affected by
-obsolete markers. Thge left column describes generic categories and the right
+obsolete markers. The left column describes generic categories and the right
 columns are about sub-categories.
 
 
@@ -68,8 +68,8 @@
 |                     | A changeset is used as   | They can safely be:         |
 |                     | a *precursor* when at    |                             |
 |                     | least one obsolete       | - hidden in the UI,         |
-|                     | marker refers to it.     | - silently excluded from    |
-|                     |                          |   pull and push operations  |
+|                     | marker refers to it      | - silently excluded from    |
+|                     | as precursors.           |   pull and push operations  |
 |                     |                          | - mostly ignored            |
 |                     |                          | - garbage collected         |
 |                     |                          |                             |
@@ -111,7 +111,8 @@
 |                     |                          | of  public changesets.      |
 |                     |                          |                             |
 |                     |                          | Public changeset can't      |
-|                     |                          | be *precursor*. *latecomer* |
+|                     |                          | be deleted and replace      |. *latecomer* |
+|                     |                          | *latecomer*                 |
 |                     |                          | need to be converted into   |
 |                     |                          | an overlay to this public   |
 |                     |                          | changeset.                  |
@@ -187,7 +188,7 @@
 Existing terms
 ``````````````
 
-Mercurial already uses the following terms:
+Mercurial core already uses the following terms:
 
 :amend: to rewrite a changeset
 :graft: to copy a changeset
@@ -205,7 +206,7 @@
 Fold
 ``````````
 
-Collapse multiple changesets into a uniq one.
+Collapse multiple changesets into a unique one.
 
 The *evolve* extension will have a `fold` command.
 
@@ -236,13 +237,3 @@
 
 - solve (too generic ?)
 - evolve (too vague)
-
-
-
-.. note:: I'm not very happy with the naming of:
-
-          - "ok" changeset
-          - latecomer
-          - troublesome
-
-          Any better idea are welcome.