Internal-changeset concept

Jun Wu quark at fb.com
Tue Apr 4 15:06:42 EDT 2017


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,
> 


More information about the Mercurial-devel mailing list