On 4/4/17 9:07 PM, Martin von Zweigbergk via Mercurial-devel wrote:
On Tue, Apr 4, 2017 at 12:06 PM, Jun Wu <qu...@fb.com> wrote:
Since most people want a separate hidden storage that handles wider cases, I
don't think this incomplete (internal-only) solution worths investment.
I can't say I've followed everything in this long discussion
(including the multiple threads), but my gut feeling is that I agree
with Jun. I really like the idea of separating hiddenness from
obsolescence and I feel like introducing that separation would be a
good first step. I'm sure there will be plenty of corner cases related
to just that piece (Pierre-Yves pointed out the case of pruning and
then re-pulling, for example), so getting that in (most likely hidden
behind an [experimental] option) and seeing how it works out would be
very useful. It does seem like most people agree on that separation
being the right thing to do. I'd prefer to get that reasonably done
before we spend too much time discussing the next step (unless the
next step seems to make the first step obsolete, but it hasn't seemed
that way so far).
Sorry for being late here, I was swamped with interviews at the
beginning of the week. Finally getting some space to catch up here.
I've managed to read the various threads and the back-and-forth here.
My overall thoughts are:
(1) I also agree that having a internal-core-hg hiding system that is
fast, scalable, and independent of all other concepts is highly
desirable. I imagine this being built on top of a bitmap-style system
because that's how I can see it being fast, but this is an
implementation detail.
(2) I think that new concepts like "internal-only", "extinct", and
"archived" will be able to interact with this internal hiddenness
concept however they wish -- and we can try new things without getting
wrapped up discussions about whether we're abusing one concept for one
of it's side effects (eg, abusing obsolescence markers because they
happen to hide things today). I think avoiding abusing obsmarkers this
way is also highly desirable, and having a distinct hiding mechanism
allows us to avoid this abuse.
As far as I can tell, everyone is okay with an internal-core-hg hiding
concept that their systems will choose how to interact with -- be it
obsolescence or arching or whatever else we come up with.
(3) Thanks to Pierre-Yves for the detailed analysis of verious
mechanisms for implementing internal-only changesets. This is super
valuable, especially the parts about why a changeset marker alone is
insufficient, and the analysis of the work involved to implement various
ideas. You went way above and beyond what my question was intended to
solicit. I was honestly just looking for something like "yeah, I've
thought about this and I think phases could work" or "I think phases
won't work because of this problem" -- but you wrote up a design doc!
Amazing.
(4) In response to the design proposal, I agree that it feels
over-complicated to me for what I would be trying to accomplish with the
feature. I agree with Jun that we can use "dynamic unhiding" for finding
the changesets we're interested in, so I don't think we need two new
phases, and I think that losing the strict ordering of phases would be
too much pain to introduce for this feature. So, my proposal would be a
single phase just above "secret" called "internal" that, like secret,
would never be exchanged, and would be hidden by default (unless
dynamically unhidden via being checked out or directly accessed, for
example). I'm against forbidding the user to do things with this
changeset -- I always opt to let the user do things, in general, that
they ask to do. If they want or run diff or update or whatever to it,
sure, let them. The nice thing about having a generic hiding mechanism
[item (2) above] is that we don't have to worry about the details of how
things are hidden. Overall, I think having a "default hidden phase that
doesn't get exchanged like secret" would get us everything we want, and
we don't need to introduce new flags or hard concepts into phases. It's
just another phase.
In conclusion, I propose that we shelve (heh) this discussion about
specific things that might use hiddenness until we something like #2
above, after which we can experiment much more easily in extensions with
the right ways to hide and unhide things, without abusing concepts like
obsolescence. That way, we can build these things in a clean and
composable manner instead of twisting things up like we've been doing
with inhibit at FB (painfully, I might add).
I think Durham recently sent out a new thread about something like
concept #2 above, so I'll go read that now and hope it's more or less
what I'm thinking :-)
~Ryan
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
