merge with 0.5
authorPierre-Yves David <pierre-yves.david@logilab.fr>
Tue, 17 Jul 2012 19:49:08 +0200
changeset 372 de3d112db51b
parent 367 5bc3e5dc2637 (current diff)
parent 371 381ce7036d6d (diff)
child 377 1d6cc8c22cd9
merge with 0.5
--- a/.hgtags	Sun Jul 15 14:51:52 2012 +0200
+++ b/.hgtags	Tue Jul 17 19:49:08 2012 +0200
@@ -3,3 +3,4 @@
 c046b083a5e0b21af69027f31cee141800cf894b 0.3.0
 9bbcd274689829d9239978236e16610688978233 0.4.0
 4ecbaec1d664b1e6f8ebc78292e1ced77a8e69c0 0.4.1
+7ef8ab8c6feadb8a9d9e13af144a17cb23e9a38d 0.5
--- a/docs/obs-terms.rst	Sun Jul 15 14:51:52 2012 +0200
+++ b/docs/obs-terms.rst	Tue Jul 17 19:49:08 2012 +0200
@@ -2,83 +2,83 @@
 Terminology of the obsolete concept
 -----------------------------------------------------------
 
-Obsolete marker them self
+Obsolete markers
 ---------------------------------
 
-The mutable concept is based on the creation of **obsolete marker**. An obsolete
-marker register a relation between the old obsoleted changeset and its newer
+The mutable concept is based on **obsolete markers**. Creating an obsolete
+marker registers a relation between an old obsoleted changeset and its newer
 version.
 
-The old changesets is called **precursors**. Its newer version are called
-*successors*. A marker always register a single *precursors* but can refer
-to:
+Old changesets are called **precursors** while their new versions are called
+**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* were splits in multiple
+  changesets.
 
-- No *successors* at all if the *precursors* if just discarded.
-- One *successor* at all if the *precursors* have been rewritten
-- Multiple *successors* if the *precursors* have been splitted in myltiple
-  changeset.
+.. The *precursors* and *successors* terms can be used on changeset directy:
 
-The **precursors** and **successors** terms can be used on changeset directy:
+.. :precursors: of a changeset `A` are changesets used as *precursors* by
+..              obsolete marker using changeset `A` as *successors*
 
-:precursors: of a changeset `A` are changesets used as *precursors* by
-             obsolete marker using changeset `A` as *successors*
-
-:successors: of a changeset `B` are changesets used as *successors* by
-             obsolete marker using changeset `B` as *precursors*
+.. :successors: of a changeset `B` are changesets used as *successors* by
+..              obsolete marker using changeset `B` as *precursors*
 
-*Precursors* and *successors* directly related within the same marker are called
-**direct precursors** and **direct successors** in ambiguous situation.
+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 situations one can use **direct precursors** or
+**direct successors** to name changesets that are directly related.
 
-The set of all *obsolete markers* create a direct acyclic graph the same way
-standard *parent* and *children* relation do. In this graph we have:
+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: of a `A` are transitive precursors of `A`. (*direct
-                 precursors* of `A` and *precursors*  of *precursors*)
+:any precursors: are transitive precursors of a changeset: *direct precursors*
+                 and *precursors* of *precursors*.
 
-:any successors: of a `A` are transitive successors of `A`. (*direct
-                 successors* of `A` and *precursors*  of *precursors*)
+:any successors: are transitive successors of a changeset: *direct successors*
+                 and *successors*  of *successors*)
 
-Obsolete markers may revert to changesets that are not known locally. *Direct
-precursors* of a changeset may be unknown locally. This is why we usually focus
-on the **first known precursors**  of changeset
+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*.
 
-(The same apply for successors)
-
-Item in *Any successors* which are not *obsolete* 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, any-successors.
+          better distinction between *direct successors* and **any successors*.
 
 Possible changesets "type"
 ---------------------------------
 
-The following table describe name and behavior of changesets affected by
-obsolete marker. Left column describe generic category and right column are
-about sub-category.
+The following table describes names and behaviors of changesets affected by
+obsolete markers. The left column describes generic categories and the right
+columns are about sub-categories.
 
 
 +---------------------+--------------------------+-----------------------------+
 | **mutable**         | **obsolete**             | **extinct**                 |
 |                     |                          |                             |
-| Changeset in either | Obsolete changesets are  | Extinct changesets are      |
-| *draft* or *secret* | mutable changeset used   | obsolete one with obsolete  |
-| phases.             | as a precursors.         | only descendants.           |
+| Changeset in either | Obsolete changeset is    | *extinct* changeset is      |
+| *draft* or *secret* | *mutable* used as a      | *obsolete* which has only   |
+| phase.              | *precursor*.             | *obsolete* descendants.     |
 |                     |                          |                             |
-|                     | A changeset is used as   | They can be safely:         |
-|                     | a precursors when at     |                             |
+|                     | A changeset is used as   | They can safely be:         |
+|                     | a *precursor* when at    |                             |
 |                     | least one obsolete       | - hidden in the UI,         |
-|                     | refer to it in the       | - silently excluded from pp |
-|                     | precursors field.        |   pull and push,t operation |
-|                     |                          | - ignored by most operation |
-|                     |                          | - garbage collected.        |
+|                     | marker refers to it      | - silently excluded from    |
+|                     | as precursors.           |   pull and push operations  |
+|                     |                          | - mostly ignored            |
+|                     |                          | - garbage collected         |
 |                     |                          |                             |
 |                     |                          +-----------------------------+
 |                     |                          |                             |
 |                     |                          | **suspended**               |
 |                     |                          |                             |
-|                     |                          | Suspended changesets are    |
-|                     |                          | obsolete one with at least  |
+|                     |                          | *suspended* changeset is    |
+|                     |                          | *obsolete* with at least    |
 |                     |                          | one non-obsolete descendant |
 |                     |                          |                             |
 |                     |                          | Thoses descendants prevent  |
@@ -91,54 +91,53 @@
 |                     |                          |                             |
 |                     | **troublesome**          | **unstable**                |
 |                     |                          |                             |
-|                     | Troublesome commit have  | Unstable changesets are     |
-|                     | unresolved issue caused  | changesets with obsolete    |
-|                     | by obsolete relations.   | ancestors.                  |
+|                     | *troublesome* has        | *unstable* is a changeset   |
+|                     | unresolved issue caused  | with obsolete ancestors.    |
+|                     | by *obsolete* relations. |                             |
 |                     |                          |                             |
-|                     | Possible issues are      | They must be rebased on a   |
-|                     | listed in the next       | better base to solve the    |
-|                     | column. It is possible   | situation.                  |
-|                     | for troublesome          |                             |
+|                     | Possible issues are      | It must be rebased on a     |
+|                     | listed in the next       | non *troublesome* base to   |
+|                     | column. It is possible   | solve the problem.          |
+|                     | for *troublesome*        |                             |
 |                     | changeset to combine     | (possible alternative name: |
 |                     | multiple issue at once.  | precarious)                 |
-|                     | (eg: conflicting and     |                             |
+|                     | (a.k.a. conflicting and  |                             |
 |                     | unstable)                +-----------------------------+
 |                     |                          |                             |
 |                     | (possible alternative    | **latecomer**               |
-|                     | name: unsettled,         |                             |
-|                     | troubled)                | Latecomer changesets are    |
-|                     |                          | changesets that try to      |
-|                     |                          | be successors of public     |
-|                     |                          | changesets.                 |
+|                     | names: unsettled,        |                             |
+|                     | troubled)                | *latecomer* is a changeset  |
+|                     |                          | that tries to be successor  |
+|                     |                          | of  public changesets.      |
 |                     |                          |                             |
 |                     |                          | Public changeset can't      |
-|                     |                          | be obsolete. Latecomer      |
-|                     |                          | changeset need to be        |
-|                     |                          | rewritten as an overlay     |
-|                     |                          | to this public changeset.   |
+|                     |                          | be deleted and replace      |
+|                     |                          | *latecomer*                 |
+|                     |                          | need to be converted into   |
+|                     |                          | an overlay to this public   |
+|                     |                          | changeset.                  |
 |                     |                          |                             |
-|                     |                          | (possible alternative names |
+|                     |                          | (possible alternative names:|
 |                     |                          | mislead, naive, unaware,    |
 |                     |                          | mindless, disenchanting)    |
 |                     |                          |                             |
 |                     |                          +-----------------------------+
 |                     |                          | **conflicting**             |
 |                     |                          |                             |
-|                     |                          | Conflicting changesets      |
-|                     |                          | happen when multiple        |
+|                     |                          | *conflicting* is changeset  |
+|                     |                          | that appears when multiple  |
 |                     |                          | changesets are successors   |
-|                     |                          | of the same obsolete        |
-|                     |                          | changeset.                  |
+|                     |                          | of the same precursor.      |
 |                     |                          |                             |
-|                     |                          | Conflicting changesets are  |
-|                     |                          | resolve through a three     |
-|                     |                          | ways merging between the    |
-|                     |                          | two conflicting changesets, |
+|                     |                          | *conflicting* are solved    |
+|                     |                          | through a three ways merge  |
+|                     |                          | between the two             |
+|                     |                          | *conflictings*,             |
 |                     |                          | using the last "obsolete-   |
 |                     |                          | -common-ancestor" as the    |
 |                     |                          | base.                       |
 |                     |                          |                             |
-|                     |                          | (Changeset splitting is     |
+|                     |                          | (*splitting* is             |
 |                     |                          | properly not detected as a  |
 |                     |                          | conflict)                   |
 |                     |                          |                             |
@@ -163,14 +162,13 @@
 | Rewriting operation refuse to work on immutable changeset.                   |
 |                                                                              |
 | Obsolete markers that refer an immutable changeset as precursors have        |
-| no effect on the precussors changeset (but may have effect on the            |
-| successors)                                                                  |
+| no effect on the precussors but may have effect on the successors.           |
 |                                                                              |
-| When a mutable changeset becomes immutable its is just *immutable* and loose |
-| any property of it's former state.                                           |
+| When a *mutable* changeset becomes *immutable* (changing its phase from draft|
+| to public) it is just *immutable* and loose any property of it's former      |
+| state.                                                                       |
 |                                                                              |
-| By phase property, once a changeset becomes a public immutable changeset,    |
-| you can expect it to remain as such forever.                                 |
+| The phase properties says that public changesets stay as *immutable* forever.|
 |                                                                              |
 +------------------------------------------------------------------------------+
 
@@ -190,64 +188,52 @@
 Existing terms
 ``````````````
 
-Mercurial already use the following terms:
+Mercurial core already uses the following terms:
 
-:amend: rewrite a changeset
-:graft: copy a changeset
-:rebase: move a changeset
+:amend: to rewrite a changeset
+:graft: to copy a changeset
+:rebase: to move a changeset
 
 
 Uncommit
 `````````````
 
-remove files from a commit (and leave them as dirty in the working directory)
+Remove files from a commit (and leave them as dirty in the working directory)
 
-The evolve extension have an `uncommit` command that aims to replace most
+The *evolve* extension have an `uncommit` command that aims to replace most
 `rollback` usage.
 
 Fold
 ``````````
 
-Collapse multiple changeset into one
+Collapse multiple changesets into a unique one.
 
-The evolve extensions *will* have a `fold` commands
+The *evolve* extension will have a `fold` command.
 
 Prune
 ``````````
 
 Make a changeset obsolete without successors.
 
-This an important operation as it should replace strip in 95% of the case.
+This an important operation as it should mostly replace *strip*.
 
-alternative name:
+Alternative names:
 
-- kill: nice name for effect when you forget the "hg" in front on "hg kill".
-- obsolete: too vague, long and generic.
+- kill: shall has funny effects when you forget "hg" in front of ``hg kill``.
+- obsolete: too vague, too long and too generic.
 
 Stabilize
 ```````````````
 
-Automatically resolve troublesome changesets
-(unstable, latecomer and conflicting)
+Automatically resolve *troublesome* changesets
+(*unstable*, *latecomer* and *conflicting*)
 
-This is an important name as hg pull/pussh will suggest it the same way it
+This is an important name as hg pull/push will suggest it the same way it
 suggest merging when you add heads.
 
 I do not like stabilize much.
 
-alternative name:
+alternative names:
 
 - 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.