Hidden Commits in 4.3
pierre-yves.david at ens-lyon.org
Wed Apr 5 19:01:19 EDT 2017
(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, 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
> 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
By chances, 4.25 years ago, 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:
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 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.
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.
 Currently I suspect a storing "root-head" ranges would be the best
option we have.
More information about the Mercurial-devel