[PATCH 2 of 5 filtering part 2 V2] clfilter: add actual repo filtering mechanism

[Idan Kamara]

On Sun, Dec 16, 2012 at 2:19 AM, Pierre-Yves David
<pierre-yves.david at ens-lyon.org> wrote:
>
>
> On 14 déc. 2012, at 19:43, Idan Kamara wrote:
>
> > On Mon, Dec 10, 2012 at 7:30 PM,  <pierre-yves.david at logilab.fr> wrote:
> >> # HG changeset patch
> >> # User Pierre-Yves David <pierre-yves.david at ens-lyon.org>
> >> # Date 1355157839 -3600
> >> # Node ID 5a3d1c83343b403cf1e1393cdf2dde4f8512309b
> >> # Parent  9280d7beadd6f38c8623ea3137f2028c57cc349c
> >> clfilter: add actual repo filtering mechanism
> >
> > How do you see other parts of the code hooking into this? For
> > example how would another feature such as stash add its commits
> > to the 'unserved' filter?
>
> Stash needs to extends the definition of "hidden" changeset. This means
> making a distinction between "hide-able" and "obsolete".

Ok, so basically every feature in core that wants to hide something
from the changelog (in a non-obsolete way), needs to add some logic to
localrepo.hiddenrevs?

>
> Then stashed changed will be properly hidden to the user eyes. Stash code
> will internally use unfiltered repo to operates its logic.
>
> A distinction between "hidden" and "disposable" will also be necessary.
>
> Regarding filtering mode themself, extension should be able to add they
> own filtering mode in by adding function to the `computefilter` mapping.

So they have to override the 'unserved' filter with their own
(probably calling the base one before adding).

Since other parts of the code refer to filters by name, adding completely
new ones seems to be useless.