Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 10 May 2017 13:04:31 +0200] rev 2340
topic: configure some default color for topic
This makes thg usable
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 10 May 2017 13:03:05 +0200] rev 2339
topic: automatically configure thg to display topic
If no other config is set, we configure Tortoise-hg to display topic. This
should helps usability.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 10 May 2017 13:08:45 +0200] rev 2338
readme: update readme to mention 'debugobshistory'
Boris Feld <boris.feld@octobus.net> [Tue, 09 May 2017 17:43:39 +0200] rev 2337
obshistory: add some color
Boris Feld <boris.feld@octobus.net> [Wed, 10 May 2017 12:26:33 +0200] rev 2336
obshistory: add a debugobshistory command to show obs history of a revs
Add the debugobshistory command that accept a revision range and display
the obsolescence containing each revision in the range.
For the moment, it only displays the predecessors.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 10 May 2017 12:16:01 +0200] rev 2335
tests: add the commit style checker from Mercurial
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 09 May 2017 19:13:12 +0200] rev 2334
obscache: update the cache key in place
Instead of computing the key in place, we update the existing one using the
data used for the incremental update of the content. This will help reaching
purely incremental cache eventually.
The 'getcachekey' function is dropped as it is no longer used.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 09 May 2017 19:02:04 +0200] rev 2333
obscache: distinct 'clear' and 'reset'
We make a difference between basic invalidatiton (or lack of loading) and
'reset' (current cache data are invalid).
We can now ensure a non-None key when we start the update. This will allow us
to "update" the existing key instead of recomputing one from scratch. This is
more efficient and less racy.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 04 May 2017 21:24:02 +0200] rev 2332
merge with stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 04 May 2017 21:21:59 +0200] rev 2331
serveronly: also enable the obscache for server only setting
The obscache is useful and speeds things up. So we also enable for server only
setting.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 04 May 2017 14:02:30 +0200] rev 2330
obscache: document a possible way forward to skipping obsstore parsing
We document a possibly viable idea for updating the cache on new revs without
having to fully parse the obsstore.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 03 May 2017 23:07:01 +0200] rev 2329
obscache: update some documentation
Update some data and do some proof reading.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 03 May 2017 21:47:06 +0200] rev 2328
obscache: Only access the new obsmarkers for marker update
Since we know what what is the part of the file with "new" markers we can just
access these.
If the cache was up to date before the transaction, we'll re-parse data we just
wrote. See the inline comment for details. This is good enough for now.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 03 May 2017 20:56:26 +0200] rev 2327
obscache: extract _updatemarkers code into its own function
This split the update logic from the bit retrieving markers. That cannot be bad.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 03 May 2017 18:46:48 +0200] rev 2326
obscache: extract code to update from new revision
Code cleanup and prepare upstreaming. The make the code more likely to work with
the key validation returning an iterator of revs to update the cache with.