Hidden Commits in 4.3

Thu Apr 13 01:44:31 EDT 2017

On Fri, Apr 7, 2017 at 4:29 AM, Pierre-Yves David <
pierre-yves.david at ens-lyon.org> wrote:

> On 04/06/2017 12:02 AM, Durham Goode wrote:
>
>> On 4/5/17 4:06 AM, Pierre-Yves David wrote:
>>
>>> […]
>>> The change proposed to evolution is problematic. As explain in my reply
>>> to the other thread[1], at minimum, removing the link between
>>> obsolescence and visibility is destroying the "global-state" property we
>>> currently have. This put in disarray the whole ability to use evolution
>>> to exchange and collaborate on mutable history, the very thing evolution
>>> has been built for. I've not seen strong-enough rationals for derailing
>>> the current evolution plan and design.
>>>
>>
>> The simpler implementation model, the simpler mental model, the simpler
>> ability for commands to use hiding, and the lack of tie-in with other
>> more divisive features is the reason for this proposal. With this
>> proposal we can have the majority of the benefits quickly, without
>> notable changes to the existing core UI, and in a intuitive form for
>> users.
>>
>
> I agree that having a local-only hiding mechanism would be a win.
>
> However obsolescence and the hiding computed from it must stay fully
> independent from it. Changeset-evolution relies on building a global
> state[1] mixing it with local-only elements breaks this property.
>
> I believe these benefits outweigh the downside to evolve's current goal,
>> […]
>> I think other members of the community would have to weigh in on whether
>> this trade off is worth it, since it is a subjective decision.
>>
>
> This is not a "small downside" to evolution goal. This is a full stop to
> our ability to ship changeset-evolution.
>
> The founding goal of changeset-evolution is to allow exchange and
> collaboration around mutable history[2]. The local benefit are "just" a
> nice side effect, but the concept is fully design around distribution. This
> is a problem no other DVCS solves and we have a plan, on track, to complete
> the concept and solve it. That will give Mercurial clear edge over others.
>
> The current proposal is destroying at least one pillard currently holding
> the changeset-evolution plan (global state), without replacement. As of
> today, this kills our ability to complete and ship changeset-evolution to
> all Mercurial user in the next year or two.
>
> This is not a small subjective adjustment, this is a full discontinuation
> of concept critical to the future of Mercurial.
>

I just read this entire thread and am trying to wrap my head around
different sides of the argument. I clearly see where Durham, Ryan, and
others are coming from with "strip-based operations are bad." I think we
can all agree on that. I can also see how the new hiding mechanism is
effectively the same as strip-based operations in terms of behavior, but
without the poor performance and hacks. So it seems like a generally good
idea.

But I'm having difficulty comprehending Pierre-Yves's opposition to this
seemingly good proposal. Pierre-Yves has thought about evolution concepts
more than anyone, so when he raises an alarm, it is worth taking the time
to listen and understand his concerns so we don't jeopardize the future of
evolve. However, despite the vast amount of words written, it still isn't
clear to me exactly what the main objection is. But from seeing "global
state" and "monotonic" enough times and reading through
https://www.mercurial-scm.org/wiki/CEDConcept, I think I have an idea.
(Pierre-Yves: please confirm or correct what I'm about to say.)

I think most of Pierre-Yves's concerns are rooted at a *potential*
intrinsic incompatibility between a) a generic, non-versioned,
non-monotonic hiding mechanism (the proposal) and b) what is essentially
obsolescence markers of today. For example, if the new hiding mechanism
isn't designed with consideration for evolve, evolve/Mercurial would see an
instruction to hide a changeset but evolve would be powerless to make any
kind of reasonable judgement based on the "why" and "how" that changeset
became hidden because that data just isn't recorded. In other words,
generic hiding lacks the "global state" and "monotonic" properties of the
obsolescence store and its exchange, making evolve less effective. This
*would* undermine the ability to ship a high quality product: so
Pierre-Yves isn't using hyperbole when he says he fears that he could
deliver evolve depending on how this hiding feature is implemented.

Regardless of whether this is actually Pierre-Yves's fundamental concern,
there is a conflict here that needs addressed. And I /think/ that conflict
can be summarized as "how do we ensure that evolve is the sole source of
truth for hidden/obsolescence data?" Because if evolve isn't the sole
source of truth for hidden/obsolescence data, then evolve has to
essentially guess at what to do with changesets hidden for "unknown"
reasons and that severely undermines the ability of evolve to work well.

What I think this means is that we need writes to a generic hiding
mechanism and evolve/obsolescence markers to be mutually exclusive. I.e. if
obsolescence markers are active, we can't be hiding things via
not-obsolescence-markers because doing so would deprive evolve of critical
knowledge.

So, we can have a generic hiding mechanism in core Mercurial. We can lean
on that mechanism in the vanilla Mercurial configuration to hide changesets
so we don't have to strip. And, depending on how it is implemented,
obsolescence markers could potentially use that mechanism for efficient
hidden calculation (e.g. if it is a bitmap on disk computed from
obsolescence markers data). But what is extremely undesirable from the
perspective of evolve are writes to that hidden "store" coming from
not-evolve when evolve is active.

If my assessment is correct, I think I have a relatively simple solution to
this mess:

1) a unified API in core for "hiding" changesets. It writes directly to a
generic store or to obsolescence (if enabled). This is the only way to
"hide" a changeset.

2) clients refusing to write generic hidden data when obsolescence is used.
This will prevent evolve from encountering hidden changesets lacking
"global state" and "monotonic" properties.

3) any user-facing commands or behavior related to generic hiding (such as
`hg update <hidden>` unhiding a changeset) need to be disabled or changed
when obsolescence is enabled because they break the needs of evolve to have
"global state" and "monotonic" properties. (If #2 is implemented, anything
attempting to hide/unhide without obsolescence markers would break. So this
point follows as a consequence of #2.)

4) a mechanism to "upgrade" a repo using generic hiding data to use
obsolescence. This may involve some kind of special, local-only
obsolescence marker that basically says "obsoleted in local storage" so
when that changeset is pulled from a remote, it can be unhidden without the
the nasty implications of breaking "global state" and "monotonic"
properties (because these properties didn't exist in the first place).
Alternatively, we could just say "sorry, you can't use both at the same
time: run `hg debugupgraderepo --gc` to prune the store of pre-evolve data"
and then evolve can "own" all hidden data from what is effectively a fresh
clone.

#3 poses some interesting UX problems. You ideally want end-user facing
concepts and commands to remain similar for evolve and non-evolve users.
But if you want evolve to have its "global state" and "monotonic"
properties, that necessitates significant behavioral divergence from a
generic hiding mechanism (e.g. you have to use a new changeset to unhide
something to satisfy monotonic). We can mitigate the problem by limiting
the surface area of user-facing commands for hiding/unhiding things. And/or
we can just say "evolve changes everything" and not worry too much about
the user impact.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20170412/7009735a/attachment.html>