Hidden Commits in 4.3

[Pierre-Yves David]

(important bit about how we -already- have a generic hiding API is at 
the end of the email).

On 04/05/2017 04:06 PM, Ryan McElroy wrote:
> On 4/5/17 12:06 PM, Pierre-Yves David wrote:
>> On 04/05/2017 03:11 AM, Durham Goode wrote:

>> I think we really needs to take a step back here. Before thinking
>> about unification, I think we needs a clean definition of what we are
>> doing here. As mentioned in another thread[2], they are at least three
>> identified categories of things we want to hide. obsolete, internal,
>> and some local only hiding. The first two are quite well defined now,
>> the last one less so.
>
> I disagree. I don't think we need to understand all the ways that things
> might be hidden before coming up with a good way to hide things that
> core hg and extensions can use in whatever way they wish.
> Generic hiding allows the deeply needed improvements to core hg the Greg described in
> the other thread, without waiting for evolve to be complete (which is
> still a ways off).

I agree, that non-user facing bits of the API do not needs to wait. And 
by chances we already have that reusable hiding ability. (I'm addressing 
this lower in this email). What we lack is the storage story for the 
local-only use-case. (that should not be quite easy to do)

>> I think we should currently refocus the discussion on the local-only
>> hiding. What are its usecases, what are the wished behavior. A large
>> part of what Durham just wrote can directly be re-used for that. But
>> re-centered on the local usecase, with the changes to evolution core
>> behavior.
>
> No, please let's not require solving a potential use case before
> building the mechanism that will allow us to build use cases we already
> know we want and need.

* UI to view and manipulate it (because we probably want one and Durham 
proposal includes one).

UI is the harder part and I think it is important to gather use-cases 
before designing the UI. We already know we want it to replace the 
current usage of strip. is there other known planned usage we should 
takes in account?

>> Once we have a clear view of the three concepts usecase, behavior and
>> constraint we can start looking for synergy between them.
>
> We already know the synergy -- we want ways to hide things. Let's build
> that and let each new concept use it in appropriate ways without trying
> to solve every potential problem first. Everybody wants hiding. So let's
> add generic hiding that can be exposed in various ways, including by
> evolve.

By chances, 4.25 years ago[1], I've already implemented a generic way to 
hide revision. As mentioned before, the current hiding mechanism is 
fully extensible and anything can plugs into it. All is controlled by 
this function here:

   https://www.mercurial-scm.org/repo/hg/file/tip/mercurial/repoview.py#l24

Currently only obsolescence related data are feed into this, but it is 
trivial to provides data from other mechanisms.

For example adding hiding from an "internal" phases is as simple as 
adding this line to the function:

    revs = revs | repo._phasecache._phasesets[phases.internal]

Enforcement of the current behavior we need around unhiding (working 
copy parents, non-hideable descendant, bookmark, etc) is made with some 
some small extra logic above this function. So we already have all the 
exception behavior we need for internal changesets.

Data from a local-hiding mechanism could also be fed directly into this 
function. We computes hidden revs from whatever storage we pick[2] and 
we adds that to the set and voila! We could have a proof of concept in 
an extension in a couple of hours and a full featured solution under a 
couple of days.

Conclusion
==========

Existing API is already fully extensible and usable by other mechanisms. 
We just need to define a storage for local-hiding. They are no needed 
for a full rework of the area. Touching evolution is also unnecessary to 
get local hiding feature.

Speed-wise, they are many easy optimization available around the hiding 
code waiting to happesn. So if they are any performance concerns with 
the current naive implementation, they should be trivial to lift.

-- 
Pierre-Yves David


[1] https://www.mercurial-scm.org/repo/hg/rev/1f35d6737ed8
[2] Currently I suspect a storing "root-head" ranges would be the best 
option we have.