Mon, 08 Oct 2012 17:15:08 +0200 clfilter: prevent unwanted warning about filtered parents as unknown
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Mon, 08 Oct 2012 17:15:08 +0200] rev 18005
clfilter: prevent unwanted warning about filtered parents as unknown During changectx __init__ the dirstate's parents MAY be checked. If the repo is filtered, this check will complain "working directory has unknown parents" even if the parents are perfectly known. This may happen when the repo is used for serving and the dirstate has parents that are secret, as those secret changesets will be filtered.
Mon, 08 Oct 2012 17:12:09 +0200 clfilter: strip logic should be unfiltered
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Mon, 08 Oct 2012 17:12:09 +0200] rev 18004
clfilter: strip logic should be unfiltered Strip is a "write" operation that needs to be aware of the whole repo's content before destroying changesets. Only the low level function is altered. The top level command will still process its argument filtered (if any filtering is in place).
Mon, 08 Oct 2012 17:08:52 +0200 clfilter: verify logic should be unfiltered
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Mon, 08 Oct 2012 17:08:52 +0200] rev 18003
clfilter: verify logic should be unfiltered To verify a changelog obviously needs all of it. The verify logic now ensures it works on an unfiltered repository.
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.
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 +30000 tip