Mercurial > evolve
changeset 369:f348088d3b3f stable
marmoute N+2 pass
| author | Pierre-Yves.David@ens-lyon.org |
|---|---|
| date | Mon, 16 Jul 2012 03:59:39 +0200 |
| parents | c2f3cdd5a2a2 |
| children | 7ef8ab8c6fea |
| files | docs/obs-terms.rst |
| diffstat | 1 files changed, 15 insertions(+), 24 deletions(-) [+] |
line wrap: on
line diff
--- 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.