Commits

Anonymous committed f348088

marmoute N+2 pass

Comments (0)

Files changed (1)

docs/obs-terms.rst

 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:
 .. :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*.
 ---------------------------------
 
 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.
 
 
 |                     | 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         |
 |                     |                          |                             |
 |                     |                          | 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.                  |
 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
 Fold
 ``````````
 
-Collapse multiple changesets into a uniq one.
+Collapse multiple changesets into a unique one.
 
 The *evolve* extension will have a `fold` command.
 
 
 - 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.
Tip: Filter by directory path e.g. /media app.js to search for public/media/app.js.
Tip: Use camelCasing e.g. ProjME to search for ProjectModifiedEvent.java.
Tip: Filter by extension type e.g. /repo .js to search for all .js files in the /repo directory.
Tip: Separate your search with spaces e.g. /ssh pom.xml to search for src/ssh/pom.xml.
Tip: Use ↑ and ↓ arrow keys to navigate and return to view the file.
Tip: You can also navigate files with Ctrl+j (next) and Ctrl+k (previous) and view the file with Ctrl+o.
Tip: You can also navigate files with Alt+j (next) and Alt+k (previous) and view the file with Alt+o.