Hidden Commits in 4.3

[Gregory Szorc]

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.

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. That's why things in the
doc like `hg checkout HASH` automatically unhiding a changeset make me a
little nervous. 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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20170404/b8f1b104/attachment.html>