Wed, 03 May 2017 21:47:06 +0200 obscache: Only access the new obsmarkers for marker update
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.
Wed, 03 May 2017 20:56:26 +0200 obscache: extract _updatemarkers code into its own function
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.
Wed, 03 May 2017 18:46:48 +0200 obscache: extract code to update from new revision
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.
Wed, 03 May 2017 18:33:53 +0200 obscache: move assert earlier in the code
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 03 May 2017 18:33:53 +0200] rev 2325
obscache: move assert earlier in the code If we are to crash, let us crash earlier.
Wed, 03 May 2017 13:58:32 +0200 merge back with stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 03 May 2017 13:58:32 +0200] rev 2324
merge back with stable
Wed, 03 May 2017 13:58:06 +0200 Added tag 6.1.0 for changeset 8510d3fd7c3b stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 03 May 2017 13:58:06 +0200] rev 2323
Added tag 6.1.0 for changeset 8510d3fd7c3b
(0) -1000 -300 -100 -30 -10 -6 +6 +10 +30 +100 +300 +1000 +3000 tip