Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 11 May 2017 17:00:55 +0200] rev 2347
obsstore: also guard agains changing object in '_checkkey'
The 'upgradeneeded' function needs to be able to pass the object it fetched once.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 11 May 2017 16:58:43 +0200] rev 2346
obscache: guard from changing changelog or obsstore object
We access these object once to make sure they will never change through the
function (and their content will be fixed).
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 11 May 2017 16:45:13 +0200] rev 2345
obscache: return the new data along-side the upgrade needs (and cache key)
Having one function returning consistent data will help prevent race.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 11 May 2017 16:06:31 +0200] rev 2344
obscache: use the smaller scope function
This make the function simpler and allow larger update on the 'upgradeneeded'
one.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 11 May 2017 16:05:50 +0200] rev 2343
obscache: extract the cache key validation in its own function
This help keep the "up to date logic" simpler and prepare a more complex
version of the "upgradeneeded" logic that would return the full data needed for
the upgrade.
Boris Feld <boris.feld@octobus.net> [Wed, 10 May 2017 11:52:11 +0200] rev 2342
obshistory: use formatter instead of ui.write in the debugobshistory command
Replace ui.write with a formater to have template support and json output.
Update tests to assert json outputs.
Boris Feld <boris.feld@octobus.net> [Wed, 10 May 2017 09:55:22 +0200] rev 2341
ui: Fix hg stack json output
Previously 'hg stack -Tjson' generated invalid output
like:
[
{
"isentry": true,
"topic.stack.desc": "...",
"topic.stack.index": 1,
"topic.stack.state": "current",
"topic.stack.state.symbol": "@"
}
]
,
{
"isentry": true,
"topic.stack.desc": "...",
"topic.stack.index": 1,
"topic.stack.state": "current",
"topic.stack.state.symbol": "@"
},
{
"isentry": false,
"topic.stack.desc": "...",
"topic.stack.state": "base",
"topic.stack.state.symbol": "^"
}
]
I de-indented the fmt.end() to generate this output:
[
{
"isentry": true,
"topic.stack.desc": "...",
"topic.stack.index": 1,
"topic.stack.state": "current",
"topic.stack.state.symbol": "@"
},
{
"isentry": false,
"topic.stack.desc": "...",
"topic.stack.state": "base",
"topic.stack.state.symbol": "^"
}
]
I've also added a test case.
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.
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.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 03 May 2017 13:58:32 +0200] rev 2324
merge back with 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
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 03 May 2017 13:57:55 +0200] rev 2322
packaging: prepare version 6.1.0
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 03 May 2017 13:54:12 +0200] rev 2321
meta: update tested version to 4.1.2
We tested against the latest 4.1 too.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 03 May 2017 13:52:19 +0200] rev 2320
merge with future 6.1.0
No extra adjustment needed from hg-3.9 result
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 03 May 2017 13:23:36 +0200] rev 2319
merge with future 6.1.0
No extra adjustment needed from hg-4.0 result
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 03 May 2017 13:18:08 +0200] rev 2318
merge with future 6.1.0
In addition to the output reverted for 4.1, we also drop the "troubles:" entry
from the standard log.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 03 May 2017 13:12:39 +0200] rev 2317
merge with future 6.1.0
test pass fine except for the removal of the extra data when accessing hidden
revision. The better message are 4.2+ only.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 03 May 2017 13:27:26 +0200] rev 2316
compat: drop the context manager used to write the cache file
Mercurial 3.8 does not supports context manager on atomic temporary file.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 03 May 2017 12:54:11 +0200] rev 2315
compat: make obscache code compatible with Mercurial version prior to 4.2
the phasecache.getrevset method is new in 4.2.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 03 May 2017 12:41:54 +0200] rev 2314
evolve: record testing with 4.2
4.2 is now a things and tests pass fine.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 03 May 2017 12:31:40 +0200] rev 2313
merge with default for 6.1.0
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 03 May 2017 12:31:11 +0200] rev 2312
packaging first step toward 6.1.0
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 03 May 2017 12:25:53 +0200] rev 2311
auto-push: move config help in the extension help
That is a better spot than the extension itself.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Mon, 01 May 2017 06:17:44 +0200] rev 2310
opening mercurial 4.1 compat branch
This branch will receive test update implied by the 4.2 → 4.1 changes.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 02 May 2017 17:43:34 +0200] rev 2309
obscache: skip writing to disk if the data did not changed
This will avoid rewriting the cache for every single transaction.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 02 May 2017 16:19:05 +0200] rev 2308
obscache: skip writing if the cache is empty
if the cache is empty, we can just skip writing to disk.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 02 May 2017 16:17:03 +0200] rev 2307
obscache: set a valid "empty" cache key if the cache is missing
This avoid detecting bad cache when it just happens to be no cache.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 02 May 2017 16:10:14 +0200] rev 2306
obscache: have the obsstore fix empty file cachekey
Before this change, the missing file and empty file returned different value.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 02 May 2017 17:44:12 +0200] rev 2305
obscache: log case where the cache is not up to date
This will help track performance issue
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 02 May 2017 16:13:04 +0200] rev 2304
obscache: still update and use the cache during transaction
Other code might access the obsolete set in the middle of a transaction. It is
better to use the case in that case since the update will eventually be written
when the transaction is committed.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 02 May 2017 16:15:01 +0200] rev 2303
obscache: warm the cache in all cases
There are case when the obsstore have been invalidated, but we still need to
update the cache.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 02 May 2017 16:11:43 +0200] rev 2302
obscache: update the format to allow negative tiprev
If the changelog is empty (but the obsstore is not) the 'tiprev' will be -1.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 02 May 2017 16:09:03 +0200] rev 2301
obscache: load the disk data before checking is the cache is up to date
This is actually required since non-loaded cache will never be up to date...
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 02 May 2017 02:13:33 +0200] rev 2300
obscache: skip the cache entirely if not up to date
The current update code has some race condition windows around updating. But we
also ensure the cache are up to date with every transaction. So outdated cache
mean another client have been mudding the repository but things will get back
in place at the next transaction.
So we just skip using the cache when not up to date. This is not the best we
could do. But this is good enough for now.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Mon, 01 May 2017 15:49:36 +0200] rev 2299
readme: mention that some improvement are enabled for 4.2 only
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Mon, 01 May 2017 08:12:26 +0200] rev 2298
perf: use the cache to compute the obsolete set.
The official "obsolete" computation is switch to using the cache. This provide
noticable speed for operation that does not need to actually access the
obs markers. The part relating to obsolete changeset computation disappear from
the execution profile when it is used.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Mon, 01 May 2017 08:14:00 +0200] rev 2297
perf: warm the cache after all transactions
This is the simplest way to ensure the data are up to date.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Mon, 01 May 2017 08:13:24 +0200] rev 2296
perf: adds a cache to know if obsmarkers might affect a revision
Phase information still needs to be thrown in the mix to compute the final
information, but skipping reading the obsstore for most operation is a large
win.
Usage of this cache arrives in the next changeset.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Mon, 01 May 2017 08:07:05 +0200] rev 2295
perf: adds cachekey utility to validate changelog+obsstore content
We adds more helper about cache key to prepare the arrival of a cache that can
be updated iteratively (similar to branchmap cache)
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Mon, 01 May 2017 08:05:45 +0200] rev 2294
perf: adds some cache key helper on the obsstore class
This will be useful to allow validating cache depending on obsstore without
parsing the whole obsstore.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Mon, 01 May 2017 06:06:41 +0200] rev 2293
compat: only install the better filtered message for mercurial 4.2 and above
The helper function does not exist in earlier version.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Sat, 29 Apr 2017 05:35:01 +0200] rev 2292
evolve: update extension help
I'm pretty sure there are some missing bits, but this cannot be worse than
before.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Sat, 29 Apr 2017 05:44:07 +0200] rev 2291
merge with stable
Boris Feld <boris.feld@octobus.net> [Fri, 28 Apr 2017 16:56:09 +0200] rev 2290
ui: change the hidden revision error message
It now display the same details than the warning
when the working directory parent become obsolete
like:
$ hg update 0
abort: hidden revision '0' (successor: f301a99bd857)!
$ hg up 1
abort: hidden revision '1' (pruned)!
$ hg update 0
abort: hidden revision '0' (successors: 91311af6da10, 70653776ec4c)!
Boris Feld <boris.feld@octobus.net> [Fri, 28 Apr 2017 16:57:41 +0200] rev 2289
ui: add better messages when the working copy become obsolete.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 28 Apr 2017 15:29:32 +0200] rev 2288
topic: directly use "super" call
That is how one is supposed to do it.