Wed, 21 Nov 2012 00:53:45 +0100 clfilter: phases logic should be unfiltered
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 21 Nov 2012 00:53:45 +0100] rev 18002
clfilter: phases logic should be unfiltered Phase computations and boundary movements need to be aware of all revisions that exist in the repository to return correct results.
Mon, 08 Oct 2012 16:55:00 +0200 clfilter: unfilter computation of obsolescence related computation
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Mon, 08 Oct 2012 16:55:00 +0200] rev 18001
clfilter: unfilter computation of obsolescence related computation All obsolescence related sets need to be computed on the full unfiltered version of the repository, in particular because several of them (obsolete, extinct) are used to compute the hidden revisions. On a filtered repo, revset predicates related to these sets will be properly filtered because of revset's own pre-filtering.
Mon, 26 Nov 2012 19:24:11 +0100 clfilter: ensure changeset creation in the repo is run unfiltered
Pierre-Yves David <pierre-yves.david@logilab.fr> [Mon, 26 Nov 2012 19:24:11 +0100] rev 18000
clfilter: ensure changeset creation in the repo is run unfiltered This applies to both creation of new commits and application of changegroups.
Mon, 26 Nov 2012 19:23:25 +0100 clfilter: ensure changegroup generation is run unfiltered
Pierre-Yves David <pierre-yves.david@logilab.fr> [Mon, 26 Nov 2012 19:23:25 +0100] rev 17999
clfilter: ensure changegroup generation is run unfiltered Changegroup generation logic needs to be aware of the whole repository to work properly.
Mon, 26 Nov 2012 19:21:24 +0100 clfilter: ensure `rollback` is run unfiltered
Pierre-Yves David <pierre-yves.david@logilab.fr> [Mon, 26 Nov 2012 19:21:24 +0100] rev 17998
clfilter: ensure `rollback` is run unfiltered Rollback logic needs to be aware of the whole repository to work properly.
Mon, 26 Nov 2012 19:22:12 +0100 clfilter: ensure cache invalidation is done on the main unfiltered repo
Pierre-Yves David <pierre-yves.david@logilab.fr> [Mon, 26 Nov 2012 19:22:12 +0100] rev 17997
clfilter: ensure cache invalidation is done on the main unfiltered repo The proxy version will not hold any cache for now. But we have to ensure all cache operations are done on the unfiltered version.
Mon, 26 Nov 2012 19:26:24 +0100 clfilter: ensure that tag logic runs unfiltered
Pierre-Yves David <pierre-yves.david@logilab.fr> [Mon, 26 Nov 2012 19:26:24 +0100] rev 17996
clfilter: ensure that tag logic runs unfiltered The current tag logic is not aware of filtering. We keep the status quo, ensuring that the tag cache is computed as before: without any filtering.
Mon, 26 Nov 2012 19:25:44 +0100 clfilter: ensure `branchcache` logic runs unfiltered
Pierre-Yves David <pierre-yves.david@logilab.fr> [Mon, 26 Nov 2012 19:25:44 +0100] rev 17995
clfilter: ensure `branchcache` logic runs unfiltered The current branchcache construction is not aware of filtering. We keep the status quo, ensuring that the branch cache logic is computed as before: without any filtering.
Mon, 26 Nov 2012 19:11:13 +0100 clfilter: introduce an `unfilteredmethod` decorator
Pierre-Yves David <pierre-yves.david@logilab.fr> [Mon, 26 Nov 2012 19:11:13 +0100] rev 17994
clfilter: introduce an `unfilteredmethod` decorator This decorator ensure the method in run on an unfiltered version of the repository. See follow-up commit for details. This decorator is not named `unfiltered` because it would clash with the `unfilteredmethod` on `localrepo` itself.
Wed, 21 Nov 2012 00:36:29 +0100 clfilter: introduce an "unfiltered" method on localrepo
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 21 Nov 2012 00:36:29 +0100] rev 17993
clfilter: introduce an "unfiltered" method on localrepo This commit is part of the changelog level filtering effort. It returns the main "unfiltered" version of a repo-like object. For localrepo this means the same localrepo object. But this method will be overwritten by the filtered versions of a repository to return the core unfiltered version of the repo. Introducing this simple method first allows later commits to prepare for the use of a filtered version of a repository. A new repo method is added because a lot of users may call it. At the end of this series of commits, about 40 calls exist in core and hgext.
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 +30000 tip