Internal-changeset concept

[Pierre-Yves David]

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,

-- 
Pierre-Yves David