Thu, 21 Dec 2017 02:13:19 +0100 stablesort: use on disk cache for test
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 21 Dec 2017 02:13:19 +0100] rev 3341
stablesort: use on disk cache for test
Thu, 21 Dec 2017 02:01:58 +0100 caches: factorise the cache warming check
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 21 Dec 2017 02:01:58 +0100] rev 3340
caches: factorise the cache warming check The old conditional was duplicated and hard to read. We factorise everything into the `utility` module.
Thu, 21 Dec 2017 00:06:07 +0100 stablerange: use repo-carried stablesortcache
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 21 Dec 2017 00:06:07 +0100] rev 3339
stablerange: use repo-carried stablesortcache That one is common to all and disk persisted
Thu, 21 Dec 2017 00:34:31 +0100 stablesort: expose the cache through the repository
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 21 Dec 2017 00:34:31 +0100] rev 3338
stablesort: expose the cache through the repository Let have a unique instance, keep it warm and accessible.
Wed, 29 Nov 2017 10:38:52 -0500 stablesort: implement an ondisk cache
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 29 Nov 2017 10:38:52 -0500] rev 3337
stablesort: implement an ondisk cache Persisting the cache on disk will be important for large repositories.
Wed, 20 Dec 2017 23:45:11 +0100 stablesort: realign a misaligned continue
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 20 Dec 2017 23:45:11 +0100] rev 3336
stablesort: realign a misaligned continue We should make a better use of the jump cache now.
Wed, 20 Dec 2017 23:42:28 +0100 stablesort: remove some dead code
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 20 Dec 2017 23:42:28 +0100] rev 3335
stablesort: remove some dead code This closure is no longer in use.
Wed, 20 Dec 2017 23:08:31 +0100 stablesort: abstract all cache access
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 20 Dec 2017 23:08:31 +0100] rev 3334
stablesort: abstract all cache access This prepare an on disk version of the cache
Mon, 18 Dec 2017 20:04:50 +0100 stablerange: use first merge cache to skip over linear section
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 18 Dec 2017 20:04:50 +0100] rev 3333
stablerange: use first merge cache to skip over linear section If we are to skip over a large section of the range, skipping everything until the first merge seems like a good idea.
Wed, 20 Dec 2017 20:46:10 +0100 stablerange: add a new 'firstmerge' cache
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 20 Dec 2017 20:46:10 +0100] rev 3332
stablerange: add a new 'firstmerge' cache This cache store the first merge ancestors of a changesets. This is useful to avoid iteration over the changelog when building stablerange.
Wed, 20 Dec 2017 20:17:11 +0100 stablerange: drop unused `until` utility
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 20 Dec 2017 20:17:11 +0100] rev 3331
stablerange: drop unused `until` utility We no longer needs this function.
Wed, 20 Dec 2017 19:47:19 +0100 stablerange: use cached size data instead of walking the graph
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 20 Dec 2017 19:47:19 +0100] rev 3330
stablerange: use cached size data instead of walking the graph Less iteration is better.
Wed, 20 Dec 2017 17:56:38 +0100 stablesort: record previous segment size in the jump
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 20 Dec 2017 17:56:38 +0100] rev 3329
stablesort: record previous segment size in the jump That was, we can skip over a full jump without walking it. We'll make use of this in the next changeset.
Wed, 20 Dec 2017 17:59:14 +0100 stablesort: move jump recording inside the exclusive function
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 20 Dec 2017 17:59:14 +0100] rev 3328
stablesort: move jump recording inside the exclusive function This will allow use to record to cache size of segment in a later changeset. If the exclusive set is empty, we need to record it outside that function.
Wed, 20 Dec 2017 17:49:41 +0100 stablerange: compute jump size after jump retrieval only
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 20 Dec 2017 17:49:41 +0100] rev 3327
stablerange: compute jump size after jump retrieval only This prepares the caching of jump sizes.
Sun, 10 Dec 2017 03:49:48 +0100 stablesort: warm jump cache more efficiently
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 10 Dec 2017 03:49:48 +0100] rev 3326
stablesort: warm jump cache more efficiently We no longer for a full depth iteration for all request: - we exit early for non-merge, - for merge, we only iterate over the exclusive area.
Sun, 10 Dec 2017 03:39:56 +0100 stablesort: use a regular dict for jumps
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 10 Dec 2017 03:39:56 +0100] rev 3325
stablesort: use a regular dict for jumps This will help knowing what revision we have already queried or not.
Wed, 20 Dec 2017 15:51:05 +0100 stablerange: use the jump information for faster iteration
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 20 Dec 2017 15:51:05 +0100] rev 3324
stablerange: use the jump information for faster iteration Instead of doing a full iteration over the exclusive set, we compare the jump information instead. This perform the same kind of logic than before but will allow for much faster iteration once all the caches are in place.
Sun, 10 Dec 2017 02:46:05 +0100 stablesort: expose the jumps sequence to other code
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 10 Dec 2017 02:46:05 +0100] rev 3323
stablesort: expose the jumps sequence to other code The stable range needs it to build exclusive subrange efficiently.
Wed, 20 Dec 2017 16:20:26 +0100 stablesort: use 'depth' in mergepoint tie breaker
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 20 Dec 2017 16:20:26 +0100] rev 3322
stablesort: use 'depth' in mergepoint tie breaker The parents with the most depth will is considered lower. It has a couple of advantages. 1) the more shallow parent probably have less exclusive revision, 2) it makes Oedipus merge behave like close to the linear case,
Wed, 20 Dec 2017 13:41:33 +0100 stablesort: rework jump gathering
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 20 Dec 2017 13:41:33 +0100] rev 3321
stablesort: rework jump gathering The old code was buggy in some case, the new code give the same result as the 'headstart' version.
Wed, 20 Dec 2017 12:36:45 +0100 stablesort: stop recording jump type
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 20 Dec 2017 12:36:45 +0100] rev 3320
stablesort: stop recording jump type There are no mature user of this "jump type" data and the current implementation is known to be buggy. So we drop the logic for now. This will make on disk storage simpler. The data will be reintroduced later
Wed, 20 Dec 2017 12:29:02 +0100 stablesort: pass a jump recording function instead of a list
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 20 Dec 2017 12:29:02 +0100] rev 3319
stablesort: pass a jump recording function instead of a list This seems cleaner to abstract the underlying storage to the lower level. This also makes use more flexible about jump detection.
Wed, 20 Dec 2017 12:27:17 +0100 stablesort: minor indent fix
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 20 Dec 2017 12:27:17 +0100] rev 3318
stablesort: minor indent fix
Wed, 20 Dec 2017 12:19:59 +0100 stablesort: clarify subcall to the exclusive side
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 20 Dec 2017 12:19:59 +0100] rev 3317
stablesort: clarify subcall to the exclusive side Before doing deeper rework of this logic, we tackle the simplest parts.
Wed, 20 Dec 2017 13:18:49 +0100 docgraph: update test output with new output
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 20 Dec 2017 13:18:49 +0100] rev 3316
docgraph: update test output with new output
Mon, 18 Dec 2017 09:04:16 +0100 stablesort: record, cache and reuse jump
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 18 Dec 2017 09:04:16 +0100] rev 3315
stablesort: record, cache and reuse jump Iterating below a merge means two things: 1) iterate over the part exclusive to the higher parents, 2) iterate from the lower parents. While iterating on the exclusive part, there will be case were we just go the next natural parent, and case were we'll have to "jump" to another revision. If we record all point this "jump" happens and their target, we can easily reproduce the iteration in the future. With that information we can iterate over the exclusive part of the merge without having to compute it entirely. In addition we store the reason of the jump. This will help the stable range processing later.
Mon, 18 Dec 2017 18:49:34 +0100 stablesort: fix head start computation
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 18 Dec 2017 18:49:34 +0100] rev 3314
stablesort: fix head start computation The recursion was wrong and provided wrong result. As a side effect, this seems to hint that `stablesort_mergepoint_bounded` is not giving the right result for complex set.
Mon, 18 Dec 2017 08:36:52 +0100 stablesort: avoid attempting to sort a tuple
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 18 Dec 2017 08:36:52 +0100] rev 3313
stablesort: avoid attempting to sort a tuple This seems silly.
Mon, 18 Dec 2017 07:20:14 +0100 stablerange: use the filterparents utility
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 18 Dec 2017 07:20:14 +0100] rev 3312
stablerange: use the filterparents utility
(0) -3000 -1000 -300 -100 -50 -30 +30 +50 +100 +300 +1000 tip