Fri, 04 Jan 2013 19:05:20 +0100 destroyed: filter unknown before computing branchcache
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 04 Jan 2013 19:05:20 +0100] rev 18223
destroyed: filter unknown before computing branchcache Branchcache of filtered version need up to date phase data.
Wed, 02 Jan 2013 01:36:57 +0100 branchmap: disable fallback to unfiltered branchcache
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 02 Jan 2013 01:36:57 +0100] rev 18222
branchmap: disable fallback to unfiltered branchcache Disables this simple optimisation to allow coming more powerfull approach: cache collaboration. Our goal is to have branchcache collaborate. This means that unfiltered branchcache will fallback to some filtered branchcache if invalid. We can't have the filtered branchcache to use the unfiltered one. That would loop.
Fri, 21 Dec 2012 17:19:52 +0100 localrepo: filter unknown nodes from the phasecache on destroyed
Idan Kamara <idankk86@gmail.com> [Fri, 21 Dec 2012 17:19:52 +0100] rev 18221
localrepo: filter unknown nodes from the phasecache on destroyed When commit is followed by strip (qrefresh), phasecache contains nodes that were removed from the changelog. Since phasecache is filecached with .hg/store/phaseroots which doesn't change as a result of stripping, we have to filter it manually. If we don't write it immediately, the next time it is read from disk the nodes will be filtered again. That's what happened before, but there's no reason not to write it immediately. The change in test-keyword.t is caused by the above.
Fri, 04 Jan 2013 06:11:29 +0100 phases: make _filterunknown a member function of phasecache
Idan Kamara <idankk86@gmail.com> [Fri, 04 Jan 2013 06:11:29 +0100] rev 18220
phases: make _filterunknown a member function of phasecache We'd like the ability to call filterunknown on an existing phasecache instance after nodes are destroyed.
Fri, 04 Jan 2013 01:37:38 +0100 localrepo: drop `_cacheabletip` method
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 04 Jan 2013 01:37:38 +0100] rev 18219
localrepo: drop `_cacheabletip` method It iss dead code now.
Fri, 04 Jan 2013 01:25:55 +0100 branchmap: drop `_cacheabletip` usage in `updatecache`
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 04 Jan 2013 01:25:55 +0100] rev 18218
branchmap: drop `_cacheabletip` usage in `updatecache` Nobody overwrite the `_cacheabletip` any more. We always update the cache for the whole repo and write it to disk (or at list try to). The `updatecache` code is simplied to remove the double phase logic associated with _cacheabletip.
Fri, 28 Dec 2012 03:42:21 +0100 mq: drop `_cacheabletip` usage
Pierre-Yves David <pierre-yves.david@logilab.fr> [Fri, 28 Dec 2012 03:42:21 +0100] rev 18217
mq: drop `_cacheabletip` usage Strip have dedicated work around to solve the same problem, strip is even a fraction faster without that thanks to simpler update process of the branchcache.
Fri, 28 Dec 2012 02:34:32 +0100 bundlerepo: drop use of `_cacheabletip`
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 28 Dec 2012 02:34:32 +0100] rev 18216
bundlerepo: drop use of `_cacheabletip` Now that bundlerepo use a read only VFS, we do not worry about what part of the branchmap is written back to disk. Nothing is written at all.
Fri, 28 Dec 2012 02:32:47 +0100 bundlerepo: enforce reading from core repo only
Pierre-Yves David <pierre-yves.david@logilab.fr> [Fri, 28 Dec 2012 02:32:47 +0100] rev 18215
bundlerepo: enforce reading from core repo only We do not want anything computed with the bundle overlay to be written back in the repo. Such write will likely contains invalid data. The short terms goal of this change is to drop use of `_cacheabletip` in bundle repo.
Fri, 04 Jan 2013 04:52:57 +0100 branchmap: ignore Abort error while writing cache
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 04 Jan 2013 04:52:57 +0100] rev 18214
branchmap: ignore Abort error while writing cache Read only vfs can now raise Abort exception. Note that encoding.local are also a possible raiser.
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 +30000 tip