Obsolete Terminology

[Greg Ward]

On 16 July 2012, Pierre-Yves David said:
> This email contains as sum-up of content and effect of the obsolete markerwhich is currently getting into core. And the current name for every concept
> that deserve one.
> 
> The main goal of this email is discuss the current naming scheme and to improveit until it is perfectly cool and consistent.

...and this is supposed to replace MQ by being *simpler* than MQ? Or
by attempting to conceptualize and nail down the entire universe of
mutable source control history?

If simpler: sorry, no. MQ certainly isn't perfect. It has a steep
learning curve and, like any powerful tool, sharp edges that you can
cut your fingers on. But it has a big advantage: its model is simple.
After someone has a couple of months' experience with Mercurial, and
has demonstrated a basic level of cluefulness, I can explain the
concept of MQ to them in 10 minutes.

I suspect, rather, that you are attempting to formally conceptualize
every possible case of mutable history. That is certainly ambitious,
and I wish you the best of luck.


> Possible changesets "type"
> ---------------------------------
> 
> 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.

This is where things start getting hairy. Am I expected to understand
and internalize the difference between (say) "unstable" and
"suspended" changesets in order to effectively mutate history? Yikes.
I'll have to print out your chart and tape it to my wall. Again, MQ's
simple and admittedly incomplete model starts to look pretty
attractive.

> |                     +--------------------------+-----------------------------+
> |                     |                          |                             |
> |                     | **troublesome**          | **unstable**                |
> |                     |                          |                             |
> |                     | *troublesome* has        | *unstable* is a changeset   |
> |                     | unresolved issue caused  | with obsolete ancestors.    |
> |                     | by *obsolete* relations. |                             |
> |                     |                          |                             |
> |                     | 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)                 |
> |                     | (a.k.a. conflicting and  |                             |
> |                     | unstable)                +-----------------------------+
> |                     |                          |                             |
> |                     | (possible alternative    | **latecomer**               |
> |                     | names: unsettled,        |                             |
> |                     | troubled)                | *latecomer* is a changeset  |
> |                     |                          | that tries to be successor  |
> |                     |                          | of  public changesets.      |
> |                     |                          |                             |
> |                     |                          | Public changeset can't      |
> |                     |                          | be deleted and replace      |
> |                     |                          | *latecomer*                 |
> |                     |                          | need to be converted into   |
> |                     |                          | an overlay to this public   |
> |                     |                          | changeset.                  |
> |                     |                          |                             |
> |                     |                          | (possible alternative names:|
> |                     |                          | mislead, naive, unaware,    |
> |                     |                          | mindless, disenchanting)    |
> |                     |                          |                             |
> |                     |                          +-----------------------------+

Instead of "troublesome", I kinda like "troubled". But I am less than
thrilled by the number and complexity of concepts being tossed around
here.

Re "latecomer": how is this possible? If a changeset A is public, how
can I create another changeset B that thinks that A is obsolete?

> |                     |                          | **conflicting**             |
> |                     |                          |                             |
> |                     |                          | *conflicting* is changeset  |
> |                     |                          | that appears when multiple  |
> |                     |                          | changesets are successors   |
> |                     |                          | of the same precursor.      |

Hmmm. I'm torn on this. I completely understand why these two
successors are considered "conflicting" (alternately, "in conflict").
But the word "conflict" is pretty much taken already: it's what
happens when I have to merge two revisions of a file with overlapping
changes. You know, back in boring old-fashioned *first* order version
control. ;-) I'm leery of using the same word for subtly related but
distinct concepts.

       Greg
-- 
Greg Ward                                http://www.gerg.ca/