Tue, 02 May 2017 19:05:58 +0200 caches: call 'repo.updatecache()' in 'repo.destroyed()'
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 02 May 2017 19:05:58 +0200] rev 32304
caches: call 'repo.updatecache()' in 'repo.destroyed()' Regenerating the cache after a 'strip' or a 'rollback' is useful. So we call the generic cache warming function as other caches than just branchmap will be updated there in the future. To do so, we have to make 'repo.updatecache()' able to take no arguments. In such cases, we reload all caches.
Tue, 02 May 2017 21:39:43 +0200 caches: introduce a function to warm cache
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 02 May 2017 21:39:43 +0200] rev 32303
caches: introduce a function to warm cache We have multiple caches that gain from being kept up to date. For example in a server setup, we want to make sure the branchcache cache is hot for other read-only clients. Right now each cache tries to update themself in place where new data have been added. However the approach is error prone (we might miss some spot) and fragile. When nested transaction are involved, such cache updates might happen before a top level transaction is committed. Writing caches for uncommitted data on disk. Having a single entry point, run at the end of each successful transaction, helps to ensure the cache is up to date and refreshed at the right time. We start with updating the branchmap cache but other will come.
Tue, 02 May 2017 18:45:51 +0200 transaction: track newly introduced revisions
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 02 May 2017 18:45:51 +0200] rev 32302
transaction: track newly introduced revisions Tracking revisions is not the data that will unlock the most new capability. However, they are the simplest thing to track and still unlock some nice improvements in regard with caching. We plug ourself at the changelog level to make sure we do not miss any revision additions. The 'revs' set is configured at the repository level because the transaction itself does not needs to know that much about the business logic.
Tue, 02 May 2017 18:31:18 +0200 transaction: introduce "changes" dictionary to precisely track updates
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 02 May 2017 18:31:18 +0200] rev 32301
transaction: introduce "changes" dictionary to precisely track updates The transaction is already tracking some data intended for hooks (in 'hookargs'). However, that information is minimal as we optimise for passing data to other processes through environment variables. There are multiple places were we could use more complete and lower level information locally (eg: cache update, better report of changes to hooks, etc...). For this purpose we introduces a 'changes' dictionary on the transaction. It is intended to track every changes happening to the repository (eg: new revs, bookmarks move, phases move, obs-markers, etc). For now we just adds the 'changes' dictionary. We'll adds more tracking and usages over time.
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -4 +4 +10 +30 +100 +300 +1000 +3000 +10000 tip