Next changeset evolution task: Low level filtering of revision

Pierre-Yves David pierre-yves.david at
Tue Nov 13 12:52:20 CST 2012

Low level filtering of revision is still very high on my priority list. Here is
a small summary of what I'm trying to do and how I plan to do it. I'll resume
sending patch shortly.


A repository can have different filter applied. A filter exclude some changeset
from the repository pretending they do not exists in the repository.  This way
code that use repository automatically apply filtering such as "secret phase"
and "hidden changeset" in applicable context.

Changelog object are already able to enforce such filtering. The question is how
do people use that repo side ?


The filtering must not alter the repo object itself.

- repository object may be used by multiple thread in hgweb
- repository object are for two purposes at the same time by some piece of code.
- altering the repo mean we must unsure we do not forget to restore it's state.

Filtered repo must use the same code than the original as most as possible,
extension may have wrapped some function or other logic.

We want to avoid expansible recopy or object creation to limit performance

Current implementation proposal

Repo filtering

localrepository object gains two methods:

    --> Return an unfiltered repository object

    --> Return a proxy object that read/write every attribute in the to the
    original unfiltered repo but access to changelog. It use a copy of the
    original changelog with filtering installed. The proxy class inherit from
    the same class than the repo it filter to make sure it reuse the very same

Possible filtering

These are now four planned modes:

    nothing is filterd (repo as we know it)

    Changeset hidden by log (usually obsolete one) are excluded

    changeset not shared with other repo are excluded
    - changeset in secret phase
    - hidden changeset.

    Change in non public phase are excluded.

Filtering strategy

When used as a server (for example in a Peer object) repo apply the 'served'
filter. It is also useful in for outgoing discovery.

By default, a repo receive the "visible" filtering for all commands. This is
necessary to ensure a consistent behavior from what the user see to what the
user do. See list archive for details. All commands receive an --hidden switch to
disable this filtering.

Several part of the code need to be explicitly unfiltered:

- rollback code in localrepo
- commit code in localrepo
- strip code in localrepo
- changegroup generation code
- addchangegroup code
- code that compute obsolescence relate set of changeset
- phases logic
- verify logic
- some part of MQ that check if .hg/patches/status have a valid content
- some part of the push/pull/clone logic
- some part of heads and bookmark checking logic

The localrepo class is very bloated. Now that we have a clear and clean peer
interface we way some of it's logic from (changegroup, addchangegroup, push,
pull, etc)

Branch cache logic

This new filtering will require a smarted branchcache that track a state for all
mode (unfiltered, visible, served). As visible and served are expected to be
very volatile, we'll keep a cache for 'public' changeset and recompute them from
there when needed. This is currently the only planned use of "public" filtering.

Pierre-Yves David

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <>

More information about the Mercurial-devel mailing list