[PATCH 00 of 17 RFC] Changelog level filtering (README)

pierre-yves.david at logilab.fr pierre-yves.david at logilab.fr
Mon Sep 3 07:58:24 CDT 2012

Hi all,

Here is a series that implements revisions filtering at the changelog level.
This feature is to be used by "hidden changesets" and "secret phase" to pretend
those changeset does not exist in a repository. This is done by making the 
changelog aware of the revisions we want to filter and overwrite a few key 
functions to behave as if they were not in the repo at all.

The full series is not yet ready but posted as an RFC to allow people to
comment and to comprehend the whole picture. Most changesets use the "clfilter"
topic for "changelog filter".

A few preliminary changesets do generic refactoring to get some issues out of
the way:

- clfilter: `updatebranchcache` during `addchangegroup` instead of after lock
- clfilter: introduce a `hassecret` function

Then we slightly alter the revlog code to reduce the number of methods that
must be overwritten by changelog. This also applies to other codes that assume
an unfiltered changelog:

- clfilter: make the revlog class responsible of all its iteration
- clfilter: handle non contiguous iteration in `revlov.headrevs`
- clfilter: split `revlog.headrevs` C call from python code
- clfilter: remove usage of `range` in favor of iteration over changelog
- clfilter: remove any explicit revision number from default cmdutil range

Only then can we introduce actual changelog filtering and necessary logic in
repo to
enable it. 

- clfilter: introduce `filteredrevs` attribute on changelog
- clfilter: do not use branchmap cache if there are filtered changesets
- clfilter: do not use tags cache if there are filtered changesets
- hidden: remove tags use in hidden computation
- clfilter: introduce a `revsfilter` class to control changelog filtering on


- The C version of headrevs is not yet compatible with filtering and disabled
  in this case.
- tags and branchmap cache are not used when filtering is enabled. We need
  to reinstall a clever cache mechanism later.
- we probably wants the changelog to raise specialized exception when a revision
  is filtered. This will allow smarter error message (hg up 4--> revision 4 is
  filtered. Do wyou want --hidden ?)

And finally use it for actual filtering: this part is not very finalized but
very important to understand what the filtering must be capable of.

- clfilter: use filtering in `visibleheads` and `visiblebranchmap`
- clfilter: disallow the use of localrepo in `addbranchrevs` XXX
- clfilter: set "unserved" filter on all repo used as server XXX
- clfilter: remove the last usage of `visibleheads`
- clfilter: enforce hidden changeset globally XXX

Pierre-Yves David


More information about the Mercurial-devel mailing list