[RFC] naming of obsolescence troubles

[Pierre-Yves David]

On 27 sept. 2012, at 21:15, Matt Mackall wrote:

> On Thu, 2012-09-27 at 17:22 +0200, Pierre-Yves David wrote:
>> I'm about to submit patches to compute the two remaining troubles related to
>> mutable history exchanges[1] (the first is "unstable" already in 2.3). But
>> their name are not fully hammered yet.
>> Please read the sentences below and discuss the *terms* used.
> 
> First, I still think the feature as a whole should be referred to as
> 'evolution'. Especially if the command to fix things is 'evolve'. I
> still haven't heard a good reason to change that. Obsolescence is also
> trickier to spell - I'm surprised you get it right so often.

1) I'll refer to the whole feature as changesets evolution. Obsolescence marker are a subpart of changeset evolution. I'll use "evolution" more when we'll put evolve logic in core.

>>    Second, a changeset may be a rewritten of a changeset now immutable. Such
>>    changeset are called *latecomer*.
> 
> Technically, it's only late from a local perspective. From the view of
> the global graph, the changeset became obsolete and public
> simultaneously. So calling it 'late' may be wrong as often as not in a
> global sense and we should probably avoid conflating the usual jargon of
> temporal ordering with Mercurial's less constrained notion of causality
> anyway.

That's a pretty good point

> The real issue is that we've created a paradox. But we know a priori
> that the public flag is going to trump the obsolete marker, so we should
> find a way to say "you made a successor, but it's not going to be
> honored as such, it's going to be turned into a new change". That could
> be something as simple as 'bumped' (in the sense familiar to air
> travelers).

I like this bumped idea. Its a bit too obscure to be perfect (you have to be a native speaker who take planes) to understand it. But it's better than latecomer.

>>    A changeset is called *troubled* when it is affected by at least one
>>    *troubles* (*unstable*, *latecomer* or *divergent*)
> 
> 'Troubled' is rather alarming from a user perspective. If the command to
> fix this stuff is going to be 'evolve', then I think we should instead
> refer to these as 'unevolved'. 

Meh, from my french speaker perspective troubled did not looked to bad.
But I'll trust your native speaker point of view.

But i'm not very convinced by "unevolved". I'm looking for something were both adjective and name are usable.
The name related to "unevolved" is "unevolution" it's both complicated and unclear.

We need the attribute for "boolean check" and revset

  >>> ctx.troubled()
  True
  $ hg log -r "troubled()"

And we need the names to transmits useful information to the user

  >>> ctx.troubles()
  ['unstable', 'bumped']
  $ hg log ---template '{rev} {troubles}\n'


> I think we're usually going to see the specific terms in the context of
> the sum command:
> 
> $ hg sum
> parent: 17639:d42cc3c880b6 tip
> templatefilters: add parameterized date method
> branch: default
> commit: 6 unknown (clean)
> update: (current)
> evolve: 5 unstable, 2 divergent, 1 bumped
> 
> Elsewhere (eg, on pull), we should probably just report an 'unevolved'
> count.

Yes. The evolve extension is displaying this kind of warning:

	1 new unstable changesets

This apply to: all history rewriting command, pull, push, bundle, phase, commit and some other.

This could turned into a more generic "1 new troubled changesets"

> These don't quite form a perfect set yet, as they'd ideally all either
> end in 'ed' or not. So we could perhaps consider unstable -> unsettled
> and divergent -> forked.

I really like unstable it really conveys the fact a changeset have weak base. I see unsettled as a bit weaker, but it sound like a valid replacement is necessary.

"Forked" have a too strong meaning for "I cloned you" in the DVCS community. I do not think it's a good idea to use it here.


Conclusion: I buy bumped for now, for the insightful arguments about the other names

-- 
Pierre-Yves David