[RFC] naming of obsolescence troubles

Pierre-Yves David pierre-yves.david at ens-lyon.org
Sun Sep 30 17:55:17 CDT 2012

On 28 sept. 2012, at 04:15, Matt Harbison wrote:

> Pierre-Yves David <pierre-yves.david <at> logilab.fr> writes:
>> 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.
>>    Exchange mutable history can bring different kind of *troubles*.
>>    First, ancestors of a changeset may becomes obsoletes. Such changeset are
>>    called *unstable*.
> 'Unstable' seems good, but what if 'unstable' was used in place of 'troubled',
> and this case was called an 'orphan'?  I realize it's still connected in the
> DAG, so not truly an orphan, but with obsolete csets generally being hidden, it
> might better convey the concept.

They are not really orphan. Their parent evolve in some other changeset not that far away. They need to be rewritten to stay with their parents.

(and calling them orphan mean that you have to "kill" the orphans too solve the situation…)

> This might work better if the command to resolve all of these cases is
> 'stabilize'.  (FWIW, the command 'evolve' conjures an image of the thing that
> would place obsolete markers and cause a cset to evolve into another, not
> necessarily the command to fix these problems.  IDK if the plan was to have an
> all in one command or not.)

The evolve command was actually named "stabilize" some months ago. But case 2 and 3 (latecomer/bumped and diverged) does not really fit in "unstable". So I moved to "evolve". "evolve" is a good name because you use it so say "Please follow the evolution of other part of the history". "solve" was an option too (please "solve" my troubles) but it's near resolve.

>>    Second, a changeset may be a rewritten of a changeset now immutable. Such
>>    changeset are called *latecomer*.
> 'Mutant'?  Given that it applies to a cset that is attempting to replace
> something that is immutable, I think that also gives more clarity to the
> particular scenario (i.e. there's a mutant of something that is immutable).

Muh, (tan), not sure what to think about that. It does not conveys very well the idea of something we can't not accept as a whole but with good part in it (the mutation actually).

Pierre-Yves David

More information about the Mercurial-devel mailing list