Thu, 18 May 2017 11:29:27 +0200 obshistory: add a graph option on the debugobshistory command
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 18 May 2017 11:29:27 +0200] rev 2407
obshistory: add a graph option on the debugobshistory command Add a graph option (--graph) to the debugobshistory. The output is like the 'hg log -G' output. The option is activated by default but can be deactivated with '--no-graph' option. There are various issue with the current implementation (multiple cycles handling, N² complexity) but this can be fixed later.
Thu, 18 May 2017 11:29:23 +0200 obshistory: import 'node' as 'nodemod'
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 18 May 2017 11:29:23 +0200] rev 2406
obshistory: import 'node' as 'nodemod' This simplify the next changeset.
Thu, 18 May 2017 11:00:06 +0200 label: add a label for the node in the "wc now at" message
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 18 May 2017 11:00:06 +0200] rev 2405
label: add a label for the node in the "wc now at" message MOAR COLOR FOR THE COLOR GOAD!
Thu, 18 May 2017 10:56:08 +0200 label: rename 'evolve.short_node' to 'evolve.node'
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 18 May 2017 10:56:08 +0200] rev 2404
label: rename 'evolve.short_node' to 'evolve.node' A wider labelk will helps compatibility.
Wed, 17 May 2017 19:20:43 +0200 obshistory: refactor debugobshistory
Boris Feld <boris.feld@octobus.net> [Wed, 17 May 2017 19:20:43 +0200] rev 2403
obshistory: refactor debugobshistory Rename the function and extract the heavy work of the command in a separate module named obshistory.py
Wed, 17 May 2017 18:54:48 +0200 test: adapt to change in cache warming in core
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 17 May 2017 18:54:48 +0200] rev 2402
test: adapt to change in cache warming in core Core Mercurial has a more rational cache warming strategy now. 24f55686a63d stopped warming of the cache after every changegroup application (in favor of end of transaction warming). This reflect in the blackbox test output.
Wed, 17 May 2017 18:38:13 +0200 test: adapt to change in cache warming in core
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 17 May 2017 18:38:13 +0200] rev 2401
test: adapt to change in cache warming in core Core Mercurial has a more rational cache warming strategy now. 2b6692df1bdf stopped warming of the cache after every commit (in favor of end of transaction warming). This reflect in the blackbox test output.
Wed, 17 May 2017 18:47:22 +0200 stablerangecache: avoid crash when 'cache/' directory is missing
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 17 May 2017 18:47:22 +0200] rev 2400
stablerangecache: avoid crash when 'cache/' directory is missing If the directory is missing, we create it.
Wed, 17 May 2017 18:40:48 +0200 obshashrange: avoid crash when 'cache/' directory is missing
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 17 May 2017 18:40:48 +0200] rev 2399
obshashrange: avoid crash when 'cache/' directory is missing If the directory is missing, we create it.
Wed, 17 May 2017 17:16:59 +0200 tests: apply output changes from core fix
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 17 May 2017 17:16:59 +0200] rev 2398
tests: apply output changes from core fix Mercurial core fixed a bug were the obsolete set (and all depending data) stayed invalid after markers were merged. Fixing this bug is fixing some bad output on the evolve side so we apply the output change.
Wed, 17 May 2017 15:49:21 +0200 packaging: mention 'dev' status in the version number
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 17 May 2017 15:49:21 +0200] rev 2397
packaging: mention 'dev' status in the version number
Wed, 17 May 2017 09:28:10 +0200 color: update the shorttemplate to use colors
Boris Feld <boris.feld@octobus.net> [Wed, 17 May 2017 09:28:10 +0200] rev 2396
color: update the shorttemplate to use colors
Wed, 17 May 2017 14:49:02 +0200 merge with stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 17 May 2017 14:49:02 +0200] rev 2395
merge with stable
Wed, 17 May 2017 14:40:18 +0200 obshashrange: cleanup 'valid' life cycle
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 17 May 2017 14:40:18 +0200] rev 2394
obshashrange: cleanup 'valid' life cycle - reset is only called when we detect a strip, the on disk data are invalid, - after a reset, we should not keep using the data base connection, - after a write, the on disk data are valid.
Wed, 17 May 2017 12:27:13 +0200 obsrangecache: raise programming error when using an unwarmed cache
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 17 May 2017 12:27:13 +0200] rev 2393
obsrangecache: raise programming error when using an unwarmed cache This will provide a better experience for developer using this the cache.
Wed, 17 May 2017 13:27:29 +0200 obshashrange: stop marking on-disk data as invalid on clear
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 17 May 2017 13:27:29 +0200] rev 2392
obshashrange: stop marking on-disk data as invalid on clear This was abusing and prevent proper use of the on disk cache.
Wed, 17 May 2017 13:16:18 +0200 obshashcache: purge the meta line before writing a new one
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 17 May 2017 13:16:18 +0200] rev 2391
obshashcache: purge the meta line before writing a new one Otherwise we get multiple lines and this gets messy.
Wed, 17 May 2017 13:14:50 +0200 obshashrange: drop spurious whitespace
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 17 May 2017 13:14:50 +0200] rev 2390
obshashrange: drop spurious whitespace
Wed, 17 May 2017 12:25:56 +0200 obshashcache: invalidate affected cache entries on side
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 17 May 2017 12:25:56 +0200] rev 2389
obshashcache: invalidate affected cache entries on side Calling reset during upgrade is screwing up the cache key update.
Wed, 17 May 2017 12:26:15 +0200 obshashcache: properly break out of all loops
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 17 May 2017 12:26:15 +0200] rev 2388
obshashcache: properly break out of all loops
Wed, 17 May 2017 12:23:10 +0200 dualsourcecache: simplify cachekey.clear
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 17 May 2017 12:23:10 +0200] rev 2387
dualsourcecache: simplify cachekey.clear We do not needs the super call anymore and we can make the reset case more explicit. So we do.
Wed, 17 May 2017 11:58:48 +0200 tests: small test update
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 17 May 2017 11:58:48 +0200] rev 2386
tests: small test update This is a bit clearer.
Wed, 17 May 2017 11:23:33 +0200 dualsourcecache: fix obskey return by _checkkey
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 17 May 2017 11:23:33 +0200] rev 2385
dualsourcecache: fix obskey return by _checkkey The function was returning the old key instead of the new one. This is now fixed.
Wed, 17 May 2017 11:47:14 +0200 test: update test-obsolete.t to use common.sh stable
Boris Feld <boris.feld@octobus.net> [Wed, 17 May 2017 11:47:14 +0200] rev 2384
test: update test-obsolete.t to use common.sh The definition of getid() in the test file was wrong, use the one from common.sh instead
Tue, 16 May 2017 12:23:31 +0200 obshashrange: log reset from new markers
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 16 May 2017 12:23:31 +0200] rev 2383
obshashrange: log reset from new markers This will help tracking performance impact from current limitation.
Tue, 16 May 2017 12:18:46 +0200 dualsourcecache: log cache reset
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 16 May 2017 12:18:46 +0200] rev 2382
dualsourcecache: log cache reset
Tue, 16 May 2017 17:03:34 +0200 stablerange: log time spent updating the stable range
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 16 May 2017 17:03:34 +0200] rev 2381
stablerange: log time spent updating the stable range
Tue, 16 May 2017 16:56:37 +0200 cache: track time spend updating various cache
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 16 May 2017 16:56:37 +0200] rev 2380
cache: track time spend updating various cache This produce more useful blackbox log.
Tue, 16 May 2017 15:20:53 +0200 obshashrange: adds blackbox usage in tests
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 16 May 2017 15:20:53 +0200] rev 2379
obshashrange: adds blackbox usage in tests This will help track the validation of the cache.
Tue, 16 May 2017 12:45:08 +0200 obshashrange: test behavior in case of rollback
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 16 May 2017 12:45:08 +0200] rev 2378
obshashrange: test behavior in case of rollback The cache should be properly invalidated.
Tue, 16 May 2017 12:42:50 +0200 obshashrange: extend tests
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 16 May 2017 12:42:50 +0200] rev 2377
obshashrange: extend tests We test more situations.
Tue, 16 May 2017 12:18:30 +0200 dualsourcecache: add a cache name
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 16 May 2017 12:18:30 +0200] rev 2376
dualsourcecache: add a cache name This will be used to automatically log message for blackbox
Tue, 16 May 2017 12:17:13 +0200 obscache: stop definition of the empty key
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 16 May 2017 12:17:13 +0200] rev 2375
obscache: stop definition of the empty key
Tue, 16 May 2017 11:41:36 +0200 obshashrange: keep value fetched from sql in memory
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 16 May 2017 11:41:36 +0200] rev 2374
obshashrange: keep value fetched from sql in memory This will reduce the number of roundtrip to the data base we need.
Tue, 16 May 2017 11:37:45 +0200 obshashrange: stop inheriting from 'dict'
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 16 May 2017 11:37:45 +0200] rev 2373
obshashrange: stop inheriting from 'dict' A simple dictionary attribute seems more simpler.
Wed, 17 May 2017 09:52:06 +0200 merge with stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 17 May 2017 09:52:06 +0200] rev 2372
merge with stable
Wed, 17 May 2017 00:23:19 +0200 obshashrange: to not overwrite the list with the set
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 17 May 2017 00:23:19 +0200] rev 2371
obshashrange: to not overwrite the list with the set We reusing the list variable lower in the code.
Wed, 17 May 2017 00:22:24 +0200 obshashrange: properly break out of the two loops
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 17 May 2017 00:22:24 +0200] rev 2370
obshashrange: properly break out of the two loops Otherwise we would continue to iterate even after we reseted the cache.
Wed, 17 May 2017 00:21:30 +0200 obshashrange: fix reset conditional
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 17 May 2017 00:21:30 +0200] rev 2369
obshashrange: fix reset conditional If the revision is in "revs" we should not reset the cache. The old code was wrong (Thanks goes to new tests for catching this).
Tue, 16 May 2017 11:21:41 +0200 cache: ensure we warm stablerange cache before the obshashrange cache
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 16 May 2017 11:21:41 +0200] rev 2368
cache: ensure we warm stablerange cache before the obshashrange cache I've been seeing traceback that seems to be happening because of issues in this area.
Tue, 16 May 2017 23:37:10 -0700 evolve: fixing obscache invalidation stable
Rodrigo Damazio Bovendorp <rdamazio@google.com> [Tue, 16 May 2017 23:37:10 -0700] rev 2367
evolve: fixing obscache invalidation This was missing a call to the parent's destroyed(), such that any transaction after stripping some nodes would result in a crash (by attempting to read nodes which were stripped).
Fri, 12 May 2017 21:21:31 +0200 obshashrange: warm the cache at the end of each transaction
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 12 May 2017 21:21:31 +0200] rev 2366
obshashrange: warm the cache at the end of each transaction This will help having warmed cache for read only client. The warming is still imperfect in case of markers that trigger a reset, but we are in a better place than what we used to be.
Fri, 12 May 2017 21:00:39 +0200 obshashrange: warm cache outside of loops
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 12 May 2017 21:00:39 +0200] rev 2365
obshashrange: warm cache outside of loops The performance impact will be lower
Fri, 12 May 2017 21:20:02 +0200 obshashrange: "update" the cache on each transaction close
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 12 May 2017 21:20:02 +0200] rev 2364
obshashrange: "update" the cache on each transaction close Right now the "update" does not really file the cache, but it will detect invalid situation and clean them.
Fri, 12 May 2017 20:52:19 +0200 obshashrange: properly invalidate the cache on destroyed
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 12 May 2017 20:52:19 +0200] rev 2363
obshashrange: properly invalidate the cache on destroyed Copy paste is the scurge of code source.
Fri, 12 May 2017 20:49:27 +0200 obshashrange: properly drop the current connection on clear
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 12 May 2017 20:49:27 +0200] rev 2362
obshashrange: properly drop the current connection on clear
Fri, 12 May 2017 20:40:00 +0200 obshashrange: exit early if nothing to write
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 12 May 2017 20:40:00 +0200] rev 2361
obshashrange: exit early if nothing to write
Fri, 12 May 2017 20:29:54 +0200 obshashrange: use the dualsourcecache as a base for the cache
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 12 May 2017 20:29:54 +0200] rev 2360
obshashrange: use the dualsourcecache as a base for the cache This will easily open the way to incrementally updated obshashrange cache. Small update are needed to the data base schema so be bump the version Currently the update function is not warming the cache (but details case where it is invalidated).
Fri, 12 May 2017 20:28:09 +0200 obscache: makes dualsourcecache compatible with obshashrange cache needs
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 12 May 2017 20:28:09 +0200] rev 2359
obscache: makes dualsourcecache compatible with obshashrange cache needs The goal of the abstract method is to be reusable. So we make sure it is reusable.
Fri, 12 May 2017 21:20:40 +0200 readme: add a changelog entry about the more efficient obscache
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 12 May 2017 21:20:40 +0200] rev 2358
readme: add a changelog entry about the more efficient obscache
Fri, 12 May 2017 19:18:49 +0200 obscache: extract a data agnostic class
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 12 May 2017 19:18:49 +0200] rev 2357
obscache: extract a data agnostic class We now have an independent class that we can reuse for other purpose (eg: obshashrange cache)
Fri, 12 May 2017 19:07:14 +0200 obscache: extract the actual data update in a dedicated function
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 12 May 2017 19:07:14 +0200] rev 2356
obscache: extract the actual data update in a dedicated function This will help extract a data agnostic class.
Fri, 12 May 2017 19:05:46 +0200 obscache: move an assert to a lower level
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 12 May 2017 19:05:46 +0200] rev 2355
obscache: move an assert to a lower level
Fri, 12 May 2017 19:04:13 +0200 obscache: use 'nullid' as the hash of an empty obsstore
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 12 May 2017 19:04:13 +0200] rev 2354
obscache: use 'nullid' as the hash of an empty obsstore This align this result with what we use for 'emptykey'
Fri, 12 May 2017 18:56:56 +0200 obcache: move empty on the class
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 12 May 2017 18:56:56 +0200] rev 2353
obcache: move empty on the class We'll extract a smaller data agnostic class but we need to gather all method on it first.
Fri, 12 May 2017 18:56:42 +0200 obcache: move _checkkey on the class
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 12 May 2017 18:56:42 +0200] rev 2352
obcache: move _checkkey on the class We'll extract a smaller data agnostic class but we need to gather all method on it first.
Fri, 12 May 2017 18:52:59 +0200 obcache: move updateneeded on the class
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 12 May 2017 18:52:59 +0200] rev 2351
obcache: move updateneeded on the class We'll extract a smaller data agnostic class but we need to gather all method on it first.
Fri, 12 May 2017 18:34:37 +0200 obshistory: only display each revision once in debugobshistory
Boris Feld <boris.feld@octobus.net> [Fri, 12 May 2017 18:34:37 +0200] rev 2350
obshistory: only display each revision once in debugobshistory When using a revision range, the same precursor could have been displayed more than once. Use a cache to display each revision only once. It's a fix until we found the nicest way to display obs history.
Fri, 12 May 2017 11:39:41 +0200 obshistory: display a message when one marker node has no change ctx
Boris Feld <boris.feld@octobus.net> [Fri, 12 May 2017 11:39:41 +0200] rev 2349
obshistory: display a message when one marker node has no change ctx When exchanging obs markers, there is some change contexts referencing change contexts that are not available locally. As we cannot display informations about them, instead print a message saying so.
Wed, 10 May 2017 14:46:01 +0200 ui: hg topic now display if current revision is in bad state (issue5533) stable
Boris Feld <boris.feld@octobus.net> [Wed, 10 May 2017 14:46:01 +0200] rev 2348
ui: hg topic now display if current revision is in bad state (issue5533) Previously, hg topic didn't showed the state of the current revision. Now if show both informations.
Thu, 11 May 2017 17:00:55 +0200 obsstore: also guard agains changing object in '_checkkey'
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.
Thu, 11 May 2017 16:58:43 +0200 obscache: guard from changing changelog or obsstore object
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).
Thu, 11 May 2017 16:45:13 +0200 obscache: return the new data along-side the upgrade needs (and cache key)
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.
Thu, 11 May 2017 16:06:31 +0200 obscache: use the smaller scope function
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.
Thu, 11 May 2017 16:05:50 +0200 obscache: extract the cache key validation in its own function
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.
Wed, 10 May 2017 11:52:11 +0200 obshistory: use formatter instead of ui.write in the debugobshistory command
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.
Wed, 10 May 2017 09:55:22 +0200 ui: Fix hg stack json output stable
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.
Wed, 10 May 2017 13:04:31 +0200 topic: configure some default color for topic
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
Wed, 10 May 2017 13:03:05 +0200 topic: automatically configure thg to display topic
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.
Wed, 10 May 2017 13:08:45 +0200 readme: update readme to mention 'debugobshistory'
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 10 May 2017 13:08:45 +0200] rev 2338
readme: update readme to mention 'debugobshistory'
Tue, 09 May 2017 17:43:39 +0200 obshistory: add some color
Boris Feld <boris.feld@octobus.net> [Tue, 09 May 2017 17:43:39 +0200] rev 2337
obshistory: add some color
Wed, 10 May 2017 12:26:33 +0200 obshistory: add a debugobshistory command to show obs history of a revs
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.
Wed, 10 May 2017 12:16:01 +0200 tests: add the commit style checker from Mercurial
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
Tue, 09 May 2017 19:13:12 +0200 obscache: update the cache key in place
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.
Tue, 09 May 2017 19:02:04 +0200 obscache: distinct 'clear' and 'reset'
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.
Thu, 04 May 2017 21:24:02 +0200 merge with stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 04 May 2017 21:24:02 +0200] rev 2332
merge with stable
Thu, 04 May 2017 21:21:59 +0200 serveronly: also enable the obscache for server only setting 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.
Thu, 04 May 2017 14:02:30 +0200 obscache: document a possible way forward to skipping obsstore parsing
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.
Wed, 03 May 2017 23:07:01 +0200 obscache: update some documentation
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.
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
Wed, 03 May 2017 13:57:55 +0200 packaging: prepare version 6.1.0 stable 6.1.0
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 03 May 2017 13:57:55 +0200] rev 2322
packaging: prepare version 6.1.0
Wed, 03 May 2017 13:54:12 +0200 meta: update tested version to 4.1.2 stable
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.
Wed, 03 May 2017 13:52:19 +0200 merge with future 6.1.0 mercurial-3.8
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
Wed, 03 May 2017 13:23:36 +0200 merge with future 6.1.0 mercurial-3.9
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
Wed, 03 May 2017 13:18:08 +0200 merge with future 6.1.0 mercurial-4.0
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.
Wed, 03 May 2017 13:12:39 +0200 merge with future 6.1.0 mercurial-4.1
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.
Wed, 03 May 2017 13:27:26 +0200 compat: drop the context manager used to write the cache file stable
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.
Wed, 03 May 2017 12:54:11 +0200 compat: make obscache code compatible with Mercurial version prior to 4.2 stable
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.
Wed, 03 May 2017 12:41:54 +0200 evolve: record testing with 4.2 stable
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.
Wed, 03 May 2017 12:31:40 +0200 merge with default for 6.1.0 stable
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
Wed, 03 May 2017 12:31:11 +0200 packaging first step toward 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
Wed, 03 May 2017 12:25:53 +0200 auto-push: move config help in the extension help
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.
Mon, 01 May 2017 06:17:44 +0200 opening mercurial 4.1 compat branch mercurial-4.1
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.
Tue, 02 May 2017 17:43:34 +0200 obscache: skip writing to disk if the data did not changed
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.
Tue, 02 May 2017 16:19:05 +0200 obscache: skip writing if the cache is empty
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.
Tue, 02 May 2017 16:17:03 +0200 obscache: set a valid "empty" cache key if the cache is missing
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.
Tue, 02 May 2017 16:10:14 +0200 obscache: have the obsstore fix empty file cachekey
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.
Tue, 02 May 2017 17:44:12 +0200 obscache: log case where the cache is not up to date
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
Tue, 02 May 2017 16:13:04 +0200 obscache: still update and use the cache during transaction
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.
Tue, 02 May 2017 16:15:01 +0200 obscache: warm the cache in all cases
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.
Tue, 02 May 2017 16:11:43 +0200 obscache: update the format to allow negative tiprev
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.
Tue, 02 May 2017 16:09:03 +0200 obscache: load the disk data before checking is the cache is up to date
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...
Tue, 02 May 2017 02:13:33 +0200 obscache: skip the cache entirely if not 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.
Mon, 01 May 2017 15:49:36 +0200 readme: mention that some improvement are enabled for 4.2 only
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
Mon, 01 May 2017 08:12:26 +0200 perf: use the cache to compute the obsolete set.
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.
Mon, 01 May 2017 08:14:00 +0200 perf: warm the cache after all transactions
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.
Mon, 01 May 2017 08:13:24 +0200 perf: adds a cache to know if obsmarkers might affect a revision
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.
Mon, 01 May 2017 08:07:05 +0200 perf: adds cachekey utility to validate changelog+obsstore content
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)
Mon, 01 May 2017 08:05:45 +0200 perf: adds some cache key helper on the obsstore class
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.
Mon, 01 May 2017 06:06:41 +0200 compat: only install the better filtered message for mercurial 4.2 and above
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.
Sat, 29 Apr 2017 05:35:01 +0200 evolve: update extension help
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.
Sat, 29 Apr 2017 05:44:07 +0200 merge with stable
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Sat, 29 Apr 2017 05:44:07 +0200] rev 2291
merge with stable
Fri, 28 Apr 2017 16:56:09 +0200 ui: change the hidden revision error message
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)!
Fri, 28 Apr 2017 16:57:41 +0200 ui: add better messages when the working copy become obsolete.
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.
Fri, 28 Apr 2017 15:29:32 +0200 topic: directly use "super" call
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.
Thu, 27 Apr 2017 20:52:09 +0200 repo: properly progate "destroyed" call to super class stable
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 27 Apr 2017 20:52:09 +0200] rev 2287
repo: properly progate "destroyed" call to super class The propagation of the 'destroyed' call was dropped. I'm not certain of the consequences of having a partially broken "destroyed" call, but this can't be good.
Tue, 25 Apr 2017 10:56:55 +0200 safeguard: add an option to disable automatic publishing
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 25 Apr 2017 10:56:55 +0200] rev 2286
safeguard: add an option to disable automatic publishing Pushing to publishing server by mistake is a bit too common in the current state of evolve. Especially when the lack of good feature branch story make the use of -f a bit too common. So we add a very simple experimental option to allow warning (or abort) when changeset are pushed to a publishing server. This is unlikely to survive as is, but this is useful now.
Thu, 20 Apr 2017 13:05:45 +0200 merge back with stable
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 20 Apr 2017 13:05:45 +0200] rev 2285
merge back with stable
Thu, 20 Apr 2017 13:04:31 +0200 Added tag 6.0.1 for changeset 5ef112a6eb87 stable
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 20 Apr 2017 13:04:31 +0200] rev 2284
Added tag 6.0.1 for changeset 5ef112a6eb87
Thu, 20 Apr 2017 12:59:19 +0200 pkg: prepare release 6.0.1 stable 6.0.1
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 20 Apr 2017 12:59:19 +0200] rev 2283
pkg: prepare release 6.0.1
Thu, 20 Apr 2017 12:58:27 +0200 debian: finalize 6.0.0 entry stable
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 20 Apr 2017 12:58:27 +0200] rev 2282
debian: finalize 6.0.0 entry
Thu, 20 Apr 2017 12:54:57 +0200 readme: fix 6.0.0 release date stable
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 20 Apr 2017 12:54:57 +0200] rev 2281
readme: fix 6.0.0 release date It was March, not February.
Thu, 20 Apr 2017 12:50:22 +0200 merge with future 6.0.1 mercurial-3.8
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 20 Apr 2017 12:50:22 +0200] rev 2280
merge with future 6.0.1 Nothing special to report
Thu, 20 Apr 2017 12:48:31 +0200 merge with future 6.0.1 mercurial-3.9
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 20 Apr 2017 12:48:31 +0200] rev 2279
merge with future 6.0.1 Nothing special to report
Thu, 20 Apr 2017 12:45:02 +0200 merge with future 6.0.1 mercurial-4.0
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 20 Apr 2017 12:45:02 +0200] rev 2278
merge with future 6.0.1 Nothing special to report
Thu, 20 Apr 2017 12:24:43 +0200 checkheads: update tests to match the one in core stable
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 20 Apr 2017 12:24:43 +0200] rev 2277
checkheads: update tests to match the one in core These test now exists in core, so we update the evolve version.
Thu, 20 Apr 2017 11:43:57 +0200 serveronly: fix reposetup stable
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 20 Apr 2017 11:43:57 +0200] rev 2276
serveronly: fix reposetup The local 'reposetup' function was shadowing the extension helper one. We add a test for obshashrange using 'serveronly' since this is the item that made use discover the issue.
Thu, 20 Apr 2017 11:41:20 +0200 extension: simplify the extensions helper hierarchy stable
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 20 Apr 2017 11:41:20 +0200] rev 2275
extension: simplify the extensions helper hierarchy If one mode depends on the other, its extensions helper is merged.
Thu, 20 Apr 2017 11:40:08 +0200 checkheads: do not overwrite code for Mercurial 4.2 and above stable
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 20 Apr 2017 11:40:08 +0200] rev 2274
checkheads: do not overwrite code for Mercurial 4.2 and above The fix has been ported to Mercurial core as c6cb21ddf74a.
Thu, 20 Apr 2017 00:21:13 +0900 legacy: fix debugrecordpruneparents to call obsstore.create() with keywords stable
Yuya Nishihara <yuya@tcha.org> [Thu, 20 Apr 2017 00:21:13 +0900] rev 2273
legacy: fix debugrecordpruneparents to call obsstore.create() with keywords It appears the API was changed twice in Mercurial at - 570f87422f54 "obsstore: add an explicit `date` argument to obsstore.create" - adb3798dce49 "obsstore: add a `parents` argument to obsstore.create" and metadata would be changed to a list of (key, value) pairs. Convert it back to a dict as expected by create().
Wed, 19 Apr 2017 21:17:43 +0900 template: adapt to new showlist() API introduced by hg e5eab0fe69ee stable
Yuya Nishihara <yuya@tcha.org> [Wed, 19 Apr 2017 21:17:43 +0900] rev 2272
template: adapt to new showlist() API introduced by hg e5eab0fe69ee
Wed, 19 Apr 2017 21:12:09 +0900 template: pass all mapping data to showlist() stable
Yuya Nishihara <yuya@tcha.org> [Wed, 19 Apr 2017 21:12:09 +0900] rev 2271
template: pass all mapping data to showlist() Otherwise a keyword depending on repo or ctx couldn't be rendered.
Wed, 19 Apr 2017 21:37:28 +0900 make: merge recipes for help stable
Yuya Nishihara <yuya@tcha.org> [Wed, 19 Apr 2017 21:37:28 +0900] rev 2270
make: merge recipes for help
Wed, 19 Apr 2017 21:34:03 +0900 make: fix indent of ifeq-endif stable
Yuya Nishihara <yuya@tcha.org> [Wed, 19 Apr 2017 21:34:03 +0900] rev 2269
make: fix indent of ifeq-endif ifeq() can't be a recipe.
Sat, 08 Apr 2017 12:48:20 +0200 tests: update test to match upstreamable version stable
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Sat, 08 Apr 2017 12:48:20 +0200] rev 2268
tests: update test to match upstreamable version Name have been clarified, documentation has been updated and some test-case have been updated to match the intended test.
Sat, 08 Apr 2017 12:45:39 +0200 tests: fix directory names in exchange-D4 test stable
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Sat, 08 Apr 2017 12:45:39 +0200] rev 2267
tests: fix directory names in exchange-D4 test The test is based on another one and the directory name had not been updated.
Sat, 08 Apr 2017 12:43:36 +0200 tests: fix directory names in exchange-D3 test stable
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Sat, 08 Apr 2017 12:43:36 +0200] rev 2266
tests: fix directory names in exchange-D3 test The test is based on another one and the directory name had not been updated.
Sat, 01 Apr 2017 12:45:18 +0200 merge back with default
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Sat, 01 Apr 2017 12:45:18 +0200] rev 2265
merge back with default
Fri, 31 Mar 2017 15:51:58 +0200 Added tag 6.0.0 for changeset 165ad227993d stable
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 31 Mar 2017 15:51:58 +0200] rev 2264
Added tag 6.0.0 for changeset 165ad227993d
Fri, 31 Mar 2017 15:51:27 +0200 packaging: prepare version 6.0.0 stable 6.0.0
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 31 Mar 2017 15:51:27 +0200] rev 2263
packaging: prepare version 6.0.0
Fri, 31 Mar 2017 15:47:31 +0200 merged with future 6.0 mercurial-3.8
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 31 Mar 2017 15:47:31 +0200] rev 2262
merged with future 6.0 No output changed.
Fri, 31 Mar 2017 15:44:10 +0200 test-compat-hg-3.9: merge with future 6.0 mercurial-3.9
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 31 Mar 2017 15:44:10 +0200] rev 2261
test-compat-hg-3.9: merge with future 6.0
Fri, 31 Mar 2017 15:39:20 +0200 merge with future 6.0.0 mercurial-4.0
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 31 Mar 2017 15:39:20 +0200] rev 2260
merge with future 6.0.0
Fri, 31 Mar 2017 15:33:59 +0200 merge with default stable
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 31 Mar 2017 15:33:59 +0200] rev 2259
merge with default We are getting close to cutting a 6.0.0
Fri, 31 Mar 2017 14:50:50 +0200 readme: mention the fix for issue4354
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 31 Mar 2017 14:50:50 +0200] rev 2258
readme: mention the fix for issue4354
Fri, 31 Mar 2017 15:02:39 +0200 checkheads: add a small debug message in case were we give up fast
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 31 Mar 2017 15:02:39 +0200] rev 2257
checkheads: add a small debug message in case were we give up fast When node is unknown we assume it will stay. Yet, we might have markers to it that are going to be pushed. However, we do not have branch (ancestors) information unless we are very lucky an all of them are pruned. So for now we do not do anything assuming this will be rare. We still add a small debug message to help detecting such situation in the future.
Fri, 31 Mar 2017 13:46:51 +0200 checkheahds: switch algorithm to use pushed markers instead
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 31 Mar 2017 13:46:51 +0200] rev 2256
checkheahds: switch algorithm to use pushed markers instead We now checks if markers involved in the push are relevant to nodes in the branch we try to replace. The approach is simpler and more robust. A test showing the limitation of the previous approach is added.
Fri, 31 Mar 2017 13:47:14 +0200 checkheads: add test where the rewrite of the other branch is not direct
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 31 Mar 2017 13:47:14 +0200] rev 2255
checkheads: add test where the rewrite of the other branch is not direct This will help testing that our logic is properly transitive.
Fri, 31 Mar 2017 13:45:26 +0200 check-heads: add tests about old heads indirectly pruned
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 31 Mar 2017 13:45:26 +0200] rev 2254
check-heads: add tests about old heads indirectly pruned
Wed, 29 Mar 2017 17:50:33 +0200 checkheads: add more complexe case where a branch is split on multiple ones
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 29 Mar 2017 17:50:33 +0200] rev 2253
checkheads: add more complexe case where a branch is split on multiple ones We extend case A-6 and A-7 with partial counterpart. These case are interesting because some of the partial pushing will (rightfully) works and some other won't.
Wed, 29 Mar 2017 17:35:55 +0200 checkheads: add a test of partially pushing a branch spread on multiple other
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 29 Mar 2017 17:35:55 +0200] rev 2252
checkheads: add a test of partially pushing a branch spread on multiple other If a branch is fully obsolete but is result are spread on multiple branch, pushing only one of them should detect we create new branches.
Fri, 31 Mar 2017 13:42:28 +0200 checkheads-tests: add missing parents recording for prune markers
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 31 Mar 2017 13:42:28 +0200] rev 2251
checkheads-tests: add missing parents recording for prune markers It is a bit too easy to forget about theses :/ If they are missing, the markers are not going to be exchanged on push.
Wed, 29 Mar 2017 14:02:46 +0200 checkheads: add some extra tests about "partial push"
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 29 Mar 2017 14:02:46 +0200] rev 2250
checkheads: add some extra tests about "partial push" This adds a couple of test that checks that the head replacement code is properly ignored replacement not relevant to the push.
Wed, 29 Mar 2017 15:48:27 +0200 checkheads: handle partial obsolescence
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 29 Mar 2017 15:48:27 +0200] rev 2249
checkheads: handle partial obsolescence We now properly detects situations were only parts of the remote branch is obsoleted. To do so, we process children in the branch recursively to see if they will be obsolete. The current code has some trouble when the remote branch in unknown locally, or when the prune happened on a successors that is not relevant to the push. These case will be handled later. The processing code is becoming more and more complex, a lighter approach would be to check for the obsolescence markers that are relevant to the pushed set, but I prefer to stick with the current approach until more test cases are written.
Wed, 29 Mar 2017 16:41:42 +0200 test: force a push in inhibit's test
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 29 Mar 2017 16:41:42 +0200] rev 2248
test: force a push in inhibit's test Our checkheads detection code is becoming better and will prevent that push. As we do not care about this for inhibit, we simply force the push.
Tue, 21 Mar 2017 12:30:53 +0100 checkheads: basic handling of pruned heads (and associated tests)
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 21 Mar 2017 12:30:53 +0100] rev 2247
checkheads: basic handling of pruned heads (and associated tests) We now detect that heads was pruned and stop warning about it. Note that this has the same shortcoming as the existing code and only looks at the heads.
Wed, 29 Mar 2017 16:28:15 +0200 checkheads: give up on processing locally unknown changeset
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 29 Mar 2017 16:28:15 +0200] rev 2246
checkheads: give up on processing locally unknown changeset There are too many issue with locally unknown changesets, we ignore them for now while we get the core feature of the detection working.
Tue, 21 Mar 2017 23:44:30 +0100 checkheads: import our own copy of the checkheads code
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 21 Mar 2017 23:44:30 +0100] rev 2245
checkheads: import our own copy of the checkheads code I expect enough change and experimental will be made that is it worthwhile having them done in evolution close to the rest of the exchange tests make sense.
Sun, 26 Mar 2017 04:59:36 +0200 compat: work around some filecache bug in 3.8
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Sun, 26 Mar 2017 04:59:36 +0200] rev 2244
compat: work around some filecache bug in 3.8 We are still compatible with this version.
Fri, 24 Mar 2017 18:21:48 +0100 obshashrange: have an half descent wireprotocol command
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 18:21:48 +0100] rev 2243
obshashrange: have an half descent wireprotocol command The previous implementation was extremely hacky. The new version is based on the other discovery function and work!
Fri, 24 Mar 2017 18:37:03 +0100 obshashrange: improve message issued during discovery
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 18:37:03 +0100] rev 2242
obshashrange: improve message issued during discovery This is a minor new message that help to understand what is going on.
Fri, 24 Mar 2017 18:28:01 +0100 obshashrange: introduce basic sqlite caching
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 18:28:01 +0100] rev 2241
obshashrange: introduce basic sqlite caching Same as for stablerange, this is far from perfect but already a win. The cache is currently extremely volatile, but that will still be a win when doing multiple consecutive request during discovery. Better cache invalidation will happens "in the future".
Fri, 24 Mar 2017 15:57:54 +0100 stablerange: warm cache before using it server side
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 15:57:54 +0100] rev 2240
stablerange: warm cache before using it server side We make sure the cache is fully up to date before starting to use it. Updating all value is more efficient and this give us a single point where we update and write on disk. Hopefully the cache have been kept up to date as we go anyway.
Fri, 24 Mar 2017 15:57:08 +0100 stablerange: warm cache before using it in findrangemissing
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 15:57:08 +0100] rev 2239
stablerange: warm cache before using it in findrangemissing We make sure the cache is fully up to date before starting to use it. Updating all value is more efficient and this give us a single point where we update and write on disk. Hopefully the cache have been kept up to date as we go anyway.
Fri, 24 Mar 2017 15:56:57 +0100 stablerange: warm cache on transaction (if obshashrange is enabled)
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 15:56:57 +0100] rev 2238
stablerange: warm cache on transaction (if obshashrange is enabled) If we plan to use it (obshashrange is enabled) we better keep it up to date. If a transaction adds node, we update the cache (this should also update the on disk version).
Fri, 24 Mar 2017 16:05:28 +0100 stablerange: introduce ondisk caching through sqlite
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 16:05:28 +0100] rev 2237
stablerange: introduce ondisk caching through sqlite There is many short cut and limitation with this first version of a cache but this allow use to envision some actual usage of the stablerange thingy so let us got for it.
Fri, 24 Mar 2017 18:41:55 +0100 stablerange: drop the cache on 'destroyed'
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 18:41:55 +0100] rev 2236
stablerange: drop the cache on 'destroyed' if the repository have been strip, the cache is not usable as is. We could be smarter in the invalidation but that is a prototype anyway. G: changed hgext3rd/evolve/stablerange.py
Fri, 24 Mar 2017 11:27:56 +0100 stablerange: support loading the cache iteratively
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 11:27:56 +0100] rev 2235
stablerange: support loading the cache iteratively We record how far we loaded so that we can resume from this point.
Fri, 24 Mar 2017 11:20:42 +0100 stablerange: add some basic documentation about the cache
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 11:20:42 +0100] rev 2234
stablerange: add some basic documentation about the cache
Fri, 24 Mar 2017 11:18:01 +0100 stablerange: warmup all upto a revision
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 11:18:01 +0100] rev 2233
stablerange: warmup all upto a revision Let us start doing more systemic warming of the cache before we start writing things out. This prepare on disk caching.
Fri, 24 Mar 2017 10:22:38 +0100 debugstablerange: add a --verify flag to the command
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 10:22:38 +0100] rev 2232
debugstablerange: add a --verify flag to the command This should help us finding bugs.
Fri, 24 Mar 2017 10:12:02 +0100 stablerange: add a proper debugstablerange commands
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 10:12:02 +0100] rev 2231
stablerange: add a proper debugstablerange commands This commands allows to inspect the standard stable range of a range. That should come handy.
Fri, 24 Mar 2017 09:49:03 +0100 debugobshashrange: add a --subranges option
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 09:49:03 +0100] rev 2230
debugobshashrange: add a --subranges option We stop displaying -everything- by default, since is is usually very large. This will help getting better timing when measuring cache effect too, since we won't need to dig out deep cache value that real life usage would not touch.
Fri, 24 Mar 2017 09:42:39 +0100 debug: rename 'debugstablerange' to 'debugobshashrange'
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 09:42:39 +0100] rev 2229
debug: rename 'debugstablerange' to 'debugobshashrange' The command is more about the 'obshashrange' computation.
Fri, 24 Mar 2017 09:40:50 +0100 debugstablerange: improve output spacing
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 09:40:50 +0100] rev 2228
debugstablerange: improve output spacing On repo with a descent amount of changeset the number where overflowing in all directions. We give use more room now.
Fri, 24 Mar 2017 09:21:05 +0100 subranges: add a utility function to set the cache
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 09:21:05 +0100] rev 2227
subranges: add a utility function to set the cache This is preparing on disk persistence for the value in this cache.
Fri, 24 Mar 2017 09:18:50 +0100 subranges: add a utility function to access the cache
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 09:18:50 +0100] rev 2226
subranges: add a utility function to access the cache This is preparing on disk persistence for the value in this cache.
Fri, 24 Mar 2017 09:15:18 +0100 depth: add a utility function to set the cache
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 09:15:18 +0100] rev 2225
depth: add a utility function to set the cache This is preparing on disk persistence for the value in this cache.
Fri, 24 Mar 2017 09:01:25 +0100 depth: add a utility function to access the cache
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 09:01:25 +0100] rev 2224
depth: add a utility function to access the cache This is preparing on disk persistence for the value in this cache.
Fri, 24 Mar 2017 03:20:29 +0100 stablerange: add warming of the subrange
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 03:20:29 +0100] rev 2223
stablerange: add warming of the subrange Note that this means we build standard stable subrange for all changesets in the repository this is significantly more than what we were computing before and result is significantly more ranges being computed.
Fri, 24 Mar 2017 11:04:38 +0100 stablerange: fix merge slicing when range has multiple roots
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 11:04:38 +0100] rev 2222
stablerange: fix merge slicing when range has multiple roots The first element in the bottom set is not necessarly the one with the lowest revision. We now properly compute and use the minimum value.
Fri, 24 Mar 2017 09:04:34 +0100 stablerange: small style fix
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 09:04:34 +0100] rev 2221
stablerange: small style fix
Fri, 24 Mar 2017 08:16:00 +0100 merge-slicing: introduce and use "inheritance point" for merge
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 08:16:00 +0100] rev 2220
merge-slicing: introduce and use "inheritance point" for merge The first part of the stable sorted list of revision of a merge will shared with the one of others. This means we can reuse subranges computed from that point to compute some of the subranges from the merge. That point is latest point in the stable sorted list where the depth of the revisions match its index (that means all revision earlier in the stable sorted list are its ancestors, no dangling unrelated branches exists). This is a bit expensive to find since we have to walk all the revision, but being able to reuse subranges in all case (not just regular changesets) provide a massive speedup so the cost is worth it.
Fri, 24 Mar 2017 08:31:10 +0100 stablerange: rearrange the code picking subrange to warm
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 08:31:10 +0100] rev 2219
stablerange: rearrange the code picking subrange to warm Same logic, as the previous changesets, we prepare the code before adding merge support.
Fri, 24 Mar 2017 08:20:36 +0100 stablerange: rearrange the reusing logic to prepare to merge
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 08:20:36 +0100] rev 2218
stablerange: rearrange the reusing logic to prepare to merge We'll soon be able to reuse some lower range when dealing with merge too. So we prepare the code for this in advance for clarity.
Fri, 24 Mar 2017 06:24:02 +0100 merge-slicing: explain an alternative implementation in a comments
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 06:24:02 +0100] rev 2217
merge-slicing: explain an alternative implementation in a comments It has a better time complexity so a C implementation would likely out perform the current implementation
Fri, 24 Mar 2017 06:36:12 +0100 merge-slicing: use reachable roots to filter the various branches
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 06:36:12 +0100] rev 2216
merge-slicing: use reachable roots to filter the various branches Reachable roots does what we want and have a quite fast C implementation.
Fri, 24 Mar 2017 05:51:20 +0100 merge-slicing: simplify various aspect of the code
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 05:51:20 +0100] rev 2215
merge-slicing: simplify various aspect of the code Especially the case were the bottom have single heads is not more efficiently handled.
Thu, 23 Mar 2017 14:17:15 +0100 stablerange: soon it will not provide any benefit and it gets in the way
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 23 Mar 2017 14:17:15 +0100] rev 2214
stablerange: soon it will not provide any benefit and it gets in the way This was a bit strange and memory consuming anyway.
Fri, 24 Mar 2017 06:31:32 +0100 revsfromrange: reuse information from the stablesort
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 06:31:32 +0100] rev 2213
revsfromrange: reuse information from the stablesort We collaborate with the stablesort to store the order that led to a merge. That way, when we needs to retrieve revision from that merge we can reuse that order. We might need to filter to only retains ancestors of the merge we care about but skipping the stablesort safe a large amount of time.
Fri, 24 Mar 2017 03:22:56 +0100 stablesort: allow a callback to be triggered on merge
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 03:22:56 +0100] rev 2212
stablesort: allow a callback to be triggered on merge Storing some information as we sort is going to be useful to avoid performing multiple sort while computing the stablerange.
Fri, 24 Mar 2017 03:33:36 +0100 minor simplification around rangelength
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 03:33:36 +0100] rev 2211
minor simplification around rangelength
Fri, 24 Mar 2017 03:30:14 +0100 more explicite name in revsfromrange
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 03:30:14 +0100] rev 2210
more explicite name in revsfromrange
Fri, 24 Mar 2017 05:15:25 +0100 stablerange: cache parents
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 05:15:25 +0100] rev 2209
stablerange: cache parents We happens to be doing and awful amount of parent call. We cache them locally for efficiency.
Thu, 23 Mar 2017 12:53:39 +0100 merge-slicing: avoid doing the same work twice
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 23 Mar 2017 12:53:39 +0100] rev 2208
merge-slicing: avoid doing the same work twice We have already computed the list of revision in that bottom slice as 'hrevs' so we do not need to compute it a second time.
Thu, 23 Mar 2017 14:16:43 +0100 stablerange: fix a bug when a top slice ended on a merge
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 23 Mar 2017 14:16:43 +0100] rev 2207
stablerange: fix a bug when a top slice ended on a merge Our "smart" detection of merge was buggy if the top slice ended on a merge. This is not fixed and tested.
Thu, 23 Mar 2017 10:49:03 +0100 slicesrangeat: stop double setting the revsinranges cache
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 23 Mar 2017 10:49:03 +0100] rev 2206
slicesrangeat: stop double setting the revsinranges cache The cache should have already been filled by the logic warming the cache for the parent.
Thu, 23 Mar 2017 10:44:12 +0100 subranges: remove the recursivity of the call to isubranges(parentrange)
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 23 Mar 2017 10:44:12 +0100] rev 2205
subranges: remove the recursivity of the call to isubranges(parentrange) We add some logic to ensure we'll have hot cache for the parent ranges when that matters, the cache is filled from ancestors to descendant to ensure this. The range are still 'created from descendant to ancestors to fill the revsfromrange cache since it important.
Thu, 23 Mar 2017 10:19:59 +0100 subranges: detach cache logic from computation logic
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 23 Mar 2017 10:19:59 +0100] rev 2204
subranges: detach cache logic from computation logic Having both the logic around cache checking and setting makes is a bit harder to follow. In addition, this allow to gather the computation logic next to the other related function.
Thu, 23 Mar 2017 10:07:21 +0100 findmissingrange: properly queue new subrange for slicing
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 23 Mar 2017 10:07:21 +0100] rev 2203
findmissingrange: properly queue new subrange for slicing The previous code was buggy and used the wrong variable leading to no extra slicing being performed to file the sample at the requested size.
Thu, 23 Mar 2017 10:06:20 +0100 findmissingrange: fix reversed value in debug output
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 23 Mar 2017 10:06:20 +0100] rev 2202
findmissingrange: fix reversed value in debug output "oops"
Wed, 22 Mar 2017 22:05:30 +0100 stablecache: warmup on unfiltered repository
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 22 Mar 2017 22:05:30 +0100] rev 2201
stablecache: warmup on unfiltered repository We only looks at ancestors revision so filtering will not have any effect. This reduce overhead from the filtering.
Wed, 22 Mar 2017 21:11:35 +0100 stablerange: rename the class
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 22 Mar 2017 21:11:35 +0100] rev 2200
stablerange: rename the class This is much more than just a cache now.
Thu, 23 Mar 2017 09:40:04 +0100 stablerange: do not inherit from dict
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 23 Mar 2017 09:40:04 +0100] rev 2199
stablerange: do not inherit from dict This seems like and old cargo cult that when unnoticed.
Wed, 22 Mar 2017 21:10:01 +0100 stablerange: move a utility function around
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 22 Mar 2017 21:10:01 +0100] rev 2198
stablerange: move a utility function around It make more sense to have this small function earlier in the series
Wed, 22 Mar 2017 21:09:28 +0100 stablerange: remove the now unused individual range class
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 22 Mar 2017 21:09:28 +0100] rev 2197
stablerange: remove the now unused individual range class That class is now longer necessary, we dropped its usage for performance reason.
Wed, 22 Mar 2017 21:08:58 +0100 stablerange: directly use tuple to refer to a stable range
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 22 Mar 2017 21:08:58 +0100] rev 2196
stablerange: directly use tuple to refer to a stable range Now that all advance logic lives in the unified class we no longer needs the individual class. Creating and operating on this cache introduce a significant overhead that we can not stop having. From now on, a range a is pair tuple '(headrev, index)'. Long live the tuple.
Wed, 22 Mar 2017 21:28:18 +0100 obshash: properly cache obshash value
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 22 Mar 2017 21:28:18 +0100] rev 2195
obshash: properly cache obshash value The code was buggy and only cached non-nullid/non-inherited value. This was previous hidden because we were using a 'propertycache' to cache the value on the range object. This fixes it and restore a lot of performance.
Wed, 22 Mar 2017 20:59:42 +0100 stablerange: directly use 'self' when possible
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 22 Mar 2017 20:59:42 +0100] rev 2194
stablerange: directly use 'self' when possible Code movement introduced multiple silly case were we where accessing 'self' though 'repo.stablerange' for no good reasons.
Wed, 22 Mar 2017 20:56:17 +0100 revsfromrange: set the cache for the multiple bottom ranges in merge slicing
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 22 Mar 2017 20:56:17 +0100] rev 2193
revsfromrange: set the cache for the multiple bottom ranges in merge slicing We no longer rely on the object magic here.
Wed, 22 Mar 2017 20:55:43 +0100 revsfromrange: set the cache for the single bottom range in merge slicing
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 22 Mar 2017 20:55:43 +0100] rev 2192
revsfromrange: set the cache for the single bottom range in merge slicing We no longer rely on the object magic here.
Wed, 22 Mar 2017 20:55:23 +0100 revsfromrange: set the cache for the top range in merge slicing
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 22 Mar 2017 20:55:23 +0100] rev 2191
revsfromrange: set the cache for the top range in merge slicing We no longer rely on the object magic here.
Wed, 22 Mar 2017 20:44:29 +0100 revsfromrange: remove reference to '_revs' in merge slicing
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 22 Mar 2017 20:44:29 +0100] rev 2190
revsfromrange: remove reference to '_revs' in merge slicing Given '_revs' is a property from the cache, we use the official method of the object we are on instead. That method should be using the same cache than the property if available.
Wed, 22 Mar 2017 20:37:27 +0100 revsfromcache: update cache for the top slice if possible
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 22 Mar 2017 20:37:27 +0100] rev 2189
revsfromcache: update cache for the top slice if possible Same logic, we update the cache if have the data.
Wed, 22 Mar 2017 20:37:03 +0100 revsfromrange: skip setting the cache for length-1 top entry
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 22 Mar 2017 20:37:03 +0100] rev 2188
revsfromrange: skip setting the cache for length-1 top entry The content of the range is trivial to compute.
Wed, 22 Mar 2017 20:36:19 +0100 revsfromrange: update cache for parentrange directly in the code
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 22 Mar 2017 20:36:19 +0100] rev 2187
revsfromrange: update cache for parentrange directly in the code We update it where it matters if we detect that we have the data.
Wed, 22 Mar 2017 20:34:07 +0100 revsfromramge: hard code the single changeset range case
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 22 Mar 2017 20:34:07 +0100] rev 2186
revsfromramge: hard code the single changeset range case That case is trivial and triggering and full stable sort for it seems a bit silly.
Wed, 22 Mar 2017 20:18:01 +0100 stablerange: introduce caching for the full revision in a set
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 22 Mar 2017 20:18:01 +0100] rev 2185
stablerange: introduce caching for the full revision in a set Such cache proved handy in the "per-range" class so we carry it along to the unified class. cf documentation for details.
Wed, 22 Mar 2017 20:11:19 +0100 stablerange: add a cache for stablesort ordering
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 22 Mar 2017 20:11:19 +0100] rev 2184
stablerange: add a cache for stablesort ordering This will be very handy for merge, cf inline documentation for details.
Wed, 22 Mar 2017 20:05:21 +0100 stablerange: move revs computation within the main class
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 22 Mar 2017 20:05:21 +0100] rev 2183
stablerange: move revs computation within the main class We still need to compute the revision withing a range when we slice a merge. This is the last large logic that remains in the individual class and we migrate is on the main class.
Wed, 22 Mar 2017 19:42:37 +0100 stablerange: minor method reorders on the main class
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 22 Mar 2017 19:42:37 +0100] rev 2182
stablerange: minor method reorders on the main class We put the public method first for clarify.
Wed, 22 Mar 2017 19:30:23 +0100 stablerange: drop "key" and "id" logic form the class
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 22 Mar 2017 19:30:23 +0100] rev 2181
stablerange: drop "key" and "id" logic form the class We can restrict to the bare minimun for equality and hashing now.
Wed, 22 Mar 2017 19:28:14 +0100 stablerange: drop length from the class
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 22 Mar 2017 19:28:14 +0100] rev 2180
stablerange: drop length from the class There is not remaining user.
Wed, 22 Mar 2017 19:26:40 +0100 stablerange: drop _depth
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 22 Mar 2017 19:26:40 +0100] rev 2179
stablerange: drop _depth Nothing uses it anymore.
Wed, 22 Mar 2017 19:25:12 +0100 stablerange: drop __repr__
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 22 Mar 2017 19:25:12 +0100] rev 2178
stablerange: drop __repr__ IT was used for debug and the class is on it way out.
Wed, 22 Mar 2017 19:23:32 +0100 stablerange: drop the subranges method on the small class
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 22 Mar 2017 19:23:32 +0100] rev 2177
stablerange: drop the subranges method on the small class Nobody use it anymore.
Wed, 22 Mar 2017 19:21:41 +0100 stablerange: use subranges from the main class in subrangesclosure
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 22 Mar 2017 19:21:41 +0100] rev 2176
stablerange: use subranges from the main class in subrangesclosure This is the last method used on the class.
Wed, 22 Mar 2017 19:21:18 +0100 stablerange: use subranges from the main class in _obshashrange
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 22 Mar 2017 19:21:18 +0100] rev 2175
stablerange: use subranges from the main class in _obshashrange This is the last method used on the class.
Wed, 22 Mar 2017 19:20:30 +0100 stablerange: use subranges from the main class in findrangemissing
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 22 Mar 2017 19:20:30 +0100] rev 2174
stablerange: use subranges from the main class in findrangemissing This is the last method used on the class.
Wed, 22 Mar 2017 18:55:26 +0100 stablerange: make sure nobody use '.depth' anymore
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 22 Mar 2017 18:55:26 +0100] rev 2173
stablerange: make sure nobody use '.depth' anymore
Wed, 22 Mar 2017 18:54:45 +0100 stablerange: use depthrevs in range slicing
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 22 Mar 2017 18:54:45 +0100] rev 2172
stablerange: use depthrevs in range slicing We stop using the property from the class to get us closer to tuple.
Wed, 22 Mar 2017 18:53:25 +0100 stablerange: use depthrevs in debugstablerange
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 22 Mar 2017 18:53:25 +0100] rev 2171
stablerange: use depthrevs in debugstablerange We stop using the property from the class to get us closer to tuple.
Wed, 22 Mar 2017 18:41:26 +0100 stablerange: use rangelength inside the class itself
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 22 Mar 2017 18:41:26 +0100] rev 2170
stablerange: use rangelength inside the class itself We stop using the building '__len__' this get use closer to be able to use a tuple.
Wed, 22 Mar 2017 18:40:54 +0100 stablerange: use rangelength in '_slicesatrange'
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 22 Mar 2017 18:40:54 +0100] rev 2169
stablerange: use rangelength in '_slicesatrange' We stop using the building '__len__' this get use closer to be able to use a tuple.
Wed, 22 Mar 2017 18:40:19 +0100 stablerange: use rangelength in '_slicepoint'
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 22 Mar 2017 18:40:19 +0100] rev 2168
stablerange: use rangelength in '_slicepoint' We stop using the building '__len__' this get use closer to be able to use a tuple.
(0) -1000 -240 +240 +1000 tip