On 4/5/17 9:58 AM, Martin von Zweigbergk wrote:
*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 <martinv...@google.com>
Date: Tue, Apr 4, 2017 at 9:20 PM
Subject: Re: Hidden Commits in 4.3
To: Gregory Szorc <gregory.sz...@gmail.com>
On Tue, Apr 4, 2017 at 8:58 PM, Gregory Szorc <gregory.sz...@gmail.com> wrote:
On Tue, Apr 4, 2017 at 6:11 PM, Durham Goode <dur...@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://urldefense.proofpoint.com/v2/url?u=https-3A__goo.gl_7DJ9AI&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=nuarHzhP1wi1T9iURRCj1A&m=9ujoyPVTKANNXyeB-TWto89n1J_Wgrj9nn1gn38N_xE&s=Dol8nY676yUOBn4FDWvmMdPgoxALSIH2aLElSDOA760&e=
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).
The doc mentions 'hg checkout hash' unhides it. Along with bookmark
placement and the explicit 'hg unhide' command.
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).
This is mainly there for backwards compatibility reasons. If people have
automation that is stripping commits and then potentially reapplying the
commits (via unbundle or pull), then not having those commits be visible
after the pull/unbundle in this new world would be a breaking change.
This let's us enable the feature by default with less risk to existing
deployments.
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.
Exchange would work exactly the same as today. If the commit is
stripped today, it is not exchanged. If the commit is hidden in the
world of tomorrow, it is not exchanged.
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
