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

[Kevin Bullock]

On 13 Dec 2012, at 8:22 PM, Pierre-Yves David wrote:

> After long discussion with Kevin Bullock:
> 
> - The code is structure is unchanged,
> - The class is now called `repoview` to better highlight the fact it manipulate the underlying repo almost directly.
> - The new documentation is:
> 
> class repoview(object):
>    """Provide a read/write view of a repo through a filtered changelog
> 
>    This object is used to access a filtered version of a repository without
>    altering the original repository object itself. We can not alter the
>    original object for two main reasons:
>    - It prevents the use of a repo with multiple filters at the same time. In
>      particular when multiple threads are involved.
>    - It makes scope of the filtering harder to control.
> 
>    This object behaves very closely to the original repository. All attribute
>    operations are done on the original repository:
>    - An access to `repoview.someattr` actually returns `repo.someattr`,
>    - A write to `repoview.someattr` actually sets value of `repo.someattr`,
>    - A deletion of `repoview.someattr` actually drops `someattr`
>      from `repo.__dict__`.
> 
>    The only exception is the `changelog` property. It is overridden to return
>    a (surface) copy of `repo.changelog` with some revisions filtered. The
>    `filtername` attribute of the view control the revisions that need to be
>    filtered.  (the fact the changelog is copied is an implementation detail).
> 
>    Unlike attributes, this object intercepts all method calls. This means that
>    all methods are run on the `repoview` object with the filtered `changelog`
>    property. For this purpose the simple `repoview` class must be mixed with
>    the actual class of the repository. This ensures that the resulting
>    `repoview` object have the very same methods than the repo object. This
>    leads to the property below.
> 
>        repoview.method() --> repo.__class__.method(repoview)
> 
>    The inheritance has to be done dynamically because `repo` can be of any
>    subclasses of `localrepo`. Eg: `bundlerepo` or `httprepo`.
>    """

The fact that such machinations are necessary, though, leads me to believe we need to take a hard look at localrepo and its interactions with the changelog.

I also recommended that the repoview class and all the new filtering functions to be added be put into a new module, particularly since we're also introducing a new module-level dispatch table.

pacem in terris / мир / शान्ति / ‎‫سَلاَم‬ / 平和
Kevin R. Bullock