Since most people want a separate hidden storage that handles wider cases, I don't think this incomplete (internal-only) solution worths investment.
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
