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