Wed, 12 Dec 2012 02:38:14 +0100 debugdiscovery: report heads in sorted order
Mads Kiilerich <mads at kiilerich.com> [Wed, 12 Dec 2012 02:38:14 +0100] rev 18254
debugdiscovery: report heads in sorted order
Thu, 03 Jan 2013 18:52:59 +0100 hidden: drop of the repo.hiddenrevs property
Pierre-Yves David <pierre-yves.david@logilab.fr> [Thu, 03 Jan 2013 18:52:59 +0100] rev 18253
hidden: drop of the repo.hiddenrevs property It does not have any user left
Thu, 03 Jan 2013 18:51:16 +0100 context: retrieve hidden from filteredrevs
Pierre-Yves David <pierre-yves.david@logilab.fr> [Thu, 03 Jan 2013 18:51:16 +0100] rev 18252
context: retrieve hidden from filteredrevs This prepare the dropping of the repo.hiddenrevs property
Thu, 03 Jan 2013 18:48:14 +0100 revset: retrieve hidden from filteredrevs
Pierre-Yves David <pierre-yves.david@logilab.fr> [Thu, 03 Jan 2013 18:48:14 +0100] rev 18251
revset: retrieve hidden from filteredrevs This prepare the dropping of the `repo.hiddenrevs` property
Tue, 08 Jan 2013 17:31:00 +0100 hidden: use both parents of working directory
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 08 Jan 2013 17:31:00 +0100] rev 18250
hidden: use both parents of working directory If we are merging with and extinct revision, this extinct revision should not be hidden.
Tue, 08 Jan 2013 14:16:49 +0100 hidden: drop cache on hiddenrevs property
Pierre-Yves David <pierre-yves.david@logilab.fr> [Tue, 08 Jan 2013 14:16:49 +0100] rev 18249
hidden: drop cache on hiddenrevs property The `filteredrevs` function already have a cache mechanism. And this cache in invalidated at the same time than the current property cache. So we drop the cache on the property. The property itself is going to be dropped soon.
Tue, 08 Jan 2013 14:10:29 +0100 hidden: move computation in filter function
Pierre-Yves David <pierre-yves.david@logilab.fr> [Tue, 08 Jan 2013 14:10:29 +0100] rev 18248
hidden: move computation in filter function There is not good reason for this computation to be handle in a different way from the other. We are moving the computation of hidden revs in the filter function. In later changesets, code that access to `repo.hiddenrevs` will be updated and the property dropped.
Tue, 08 Jan 2013 12:41:51 +0100 branchcache: add note about cache invalidation to test-keyword.t
Pierre-Yves David <pierre-yves.david@logilab.fr> [Tue, 08 Jan 2013 12:41:51 +0100] rev 18247
branchcache: add note about cache invalidation to test-keyword.t [Should've been included in aff706b3a21c.] --Kevin Bullock <kbullock@ringworld.org>
Wed, 02 Jan 2013 02:02:41 +0100 clfilter: add impactable filter
Pierre-Yves David <pierre-yves.david@logilab.fr> [Wed, 02 Jan 2013 02:02:41 +0100] rev 18246
clfilter: add impactable filter The `mutable` filter still have some chance to get invalidated. This will happen when: - you garbage collect hidden changeset, - public phase is moved backward, - something is changed in the filtering (this could be fixed) So we introduce an even more stable filtering set: everything with a revision number egal or higher than the first mutable changeset is filtered. The only official use of this filter is for branchcache.
Wed, 02 Jan 2013 01:57:46 +0100 clfilter: add mutable filtering
Pierre-Yves David <pierre-yves.david@logilab.fr> [Wed, 02 Jan 2013 01:57:46 +0100] rev 18245
clfilter: add mutable filtering It filters all mutable changesets, leaving only public changeset unfiltered. This filtering set is expected to be much more stable that the previous one as public changeset are unlikely to disapear. The only official use of this filter is for branchcache.
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 +30000 tip