--- 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.