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). > > Excerpts from Pierre-Yves David's message of 2017-04-04 20:26:29 +0200: >> TL;DR; having an internal changeset concept help building simpler UI. >> Implementation-wise, phases offer a fitting home for the concept while >> allow simpler implementation now and later. Moreover, this can be done >> sooner and independently from other discussions. >> >> On 04/03/2017 06:02 PM, Jun Wu wrote: >> > Excerpts from Pierre-Yves David's message of 2017-04-03 13:11:10 +0200: >> >> Local-hidding still needs its own solution. >> > >> > If we do have root-based hidden, and it's used for both "strip" and this >> > "local-only" thing. >> >> Let us make a small vocabulary point first (because I think it is >> important to be on the same pages here). >> >> * "strip" is the action of "physically" removing data from the >> repository. And this should remains so. The word is accurate and >> describe an operation that is sometimes useful and will stay around in >> the future. >> I know that Facebook use this word for something else but we should >> stick to strict semantic here to avoid confusion. >> >> * "root-based hidden" is a possible implementation for hiding. At that >> point of the discussion it would better to stay at the concept level >> "local-hiding" or "local-only-hiding" seems describe the concept you >> have in mind well. "root-based" is one of the many possible >> implementation. Until we have actually reviewed use-cases and option we >> are not sure we'll use that implementation for that concept, in practice >> a bitemap-based or ranged-based approach might turn out a better choice. >> In addition such description could match implementation for other >> concept. For example this internal phases is also "root-based" since >> phases are "root-based" >> >> > What problem will that cause? Worst case we add a bit >> > per root saying "whether this is by user or by system". But I don't think >> > they are fundamentally different that requires two different solutions. >> >> As mentioned in previous messages, we could use a generic local-hiding >> mechanism to hide internal changesets. I do not think this will create >> major problem. >> >> They are still multiple advantages to have handled by a new phases: >> >> * It fits well into the phases concept "public, draft, secret, internal" >> feel natural, >> >> * We already have all the visualization and manipulation we want for >> phases, so the "internal-changeset" comes at a very low overhead >> extension to an existing concept, >> >> * clear distinction between hidden internal-changeset and hidden >> real-changesets will help offer a clean UI around locally-hidden >> changesets. (To avoid internals polluting user output related to hidden-ess) >> >> * Adding extra bits related to internal in local-hiding will make >> local-hiding implementation and UI more complex. (while extending phases >> does not requires any changes) >> >> Implementation-wise, adding "internal" through phase should be quite >> trivial, we already have a solid phase implementation. Include fast C >> code to computes revision in each phases. And the hiding API support >> multiple source for feeding "internal" phase to it will be trivial. >> >> >> To conclude, having "internal-changeset" as an explicit concept will >> help building better/simpler UI. From my analysis, using phases for them >> provides us with a simpler implementation both -right- -now- and -later- >> even in the presence of a local hiding mechanism. >> >> What do you think ? >> >> Cheers, >> > _______________________________________________ > Mercurial-devel mailing list > Mercurial-devel@mercurial-scm.org > https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
