Fwd: Hidden Commits in 4.3

[Martin von Zweigbergk]

*sigh* I was confused by the gmail/inbox default reply yet again. The
below was meant not just for Greg.

Doesn't really add much value at this point :-P


---------- Forwarded message ----------
From: Martin von Zweigbergk <martinvonz at google.com>
Date: Tue, Apr 4, 2017 at 9:20 PM
Subject: Re: Hidden Commits in 4.3
To: Gregory Szorc <gregory.szorc at gmail.com>


On Tue, Apr 4, 2017 at 8:58 PM, Gregory Szorc <gregory.szorc at gmail.com> wrote:
> On Tue, Apr 4, 2017 at 6:11 PM, Durham Goode <durham at fb.com> wrote:
>>
>> There's been a lot of discussion about how to hide and unhide commits
>> lately [0][1], and I feel the complexity of our current approach is hurting
>> our ability to reason about it, making it impossible to make progress.
>>
>> I would like to formally propose a new pattern for dealing with hidden
>> commits, along with the concrete steps to getting it enabled in core by
>> default by the August release.
>>
>> The proposal is quite concise, so check out this 1-page Google doc for the
>> details and to comment:
>>
>> https://goo.gl/7DJ9AI
>>
>> If people find this approach promising, I can commit to trying to get this
>> upstream by the August release. So if you have questions or concerns, please
>> let me know so I can address them.
>>
>>
>> [0] see: "obsolete: track node versions"
>> [1] see: "repo: add an ability to hide nodes in an appropriate way"
>
>
> I lost track of all the developments in the various ongoing threads about
> hidden changesets and obsolescence versioning. So thank you for taking the
> time to write a concise summary.
>
> I emphatically support your proposal of introducing a non-obsolescence
> mechanism for hiding changesets. It solves a very real and very painful
> deficiency in the storage model (strips required to rewrite history) without
> forcing complicated workflows and concepts onto users (evolve). As I said at
> the sprint, the horrible performance associated with history rewriting
> without obsolescence enabled is one of Mozilla's biggest pain points for
> large repos. I can't in good faith recommend evolve to all users because it
> is too complicated and can lead to unexpected behavior.
>
> I think this proposal for hidden changesets solves the performance problem
> while not preventing obsolescence/evolve from making progress in its problem
> space. It also doesn't seem to be as cognitively difficult on users.

I agree.

>
> There are some areas that need flushed out of course. Obviously storage. But
> I think the more important problems are the user-facing ones. e.g. what
> happens if a user updates to a hidden changeset and makes a commit? Do we
> allow that? I think there needs to be some kind of UX to discourage
> accidental usage of hidden changesets or at least warnings when things
> become unhidden because that may be unexpected.

Good question. Durham didn't say it explicitly, but I think you're
right that checking out a hidden commit probably unhides it (and its
ancestors).

> That's why things in the doc
> like `hg checkout HASH` automatically unhiding a changeset make me a little
> nervous.

I agree that some warning/note is probably appropriate to let the user
know that we unhid it.

> Same with `hg pull` automatic unhiding. It seems like it is almost
> too easy to create divergence without any helpful mechanism (obsolescence)
> to recover from it. What I'm still trying to contemplate are the workflows
> where this would most likely occur. If it is only rare scenarios or things
> we don't want users doing, I think it can be tolerable.

We need concrete uses cases to discuss this. The obvious ones seem
safe and correct to me (ex: I pull from Greg and hide a branch I don't
care about, then I pull again and it reappears -- seems right to me).

>
> I'm also curious if you intend to add a new repo requirement for this. If
> not, what's the story for a legacy client interacting with repos with the
> new hidden mechanism? IMO that experience is bad enough (legacy client would
> see a bunch of visible changesets that should be hidden) that I think it
> warrants locking out old clients.

Even though the hiddenness is not exchanged, it doesn't have to mean
that the hiddenness is not involved in exchange, does it? I would
think the repo would look like it didn't have the hidden nodes. I'm
sure it's trickier than that, but I'm not sure how.