[RFC] naming of obsolescence troubles
Matt Mackall
mpm at selenic.com
Thu Sep 27 14:15:54 CDT 2012
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.
> Exchange mutable history can bring different kind of *troubles*.
>
> First, ancestors of a changeset may becomes obsoletes. Such changeset are
> called *unstable*.
Fine.
> 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.
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).
> Third, multiple change may try to rewrite the same changeset. Such
> changeset are called *divergent*.
Fine.
> 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'.
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.
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.
$ hg sum
parent: 17639:d42cc3c880b6 tip
templatefilters: add parameterized date method
branch: default
commit: 6 unknown (clean)
update: (current)
evolve: 5 unsettled, 2 forked, 1 bumped
--
Mathematics is the supreme nostalgia of our time.
More information about the Mercurial-devel
mailing list