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
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.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 20 Dec 2017 12:27:17 +0100] rev 3318
stablesort: minor indent fix
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.
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
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.
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.
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.
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 18 Dec 2017 07:20:14 +0100] rev 3312
stablerange: use the filterparents utility
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 18 Dec 2017 07:10:43 +0100] rev 3311
stablesort: use the filtered parents utility
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 18 Dec 2017 06:50:57 +0100] rev 3310
depthcache: use parents filter in depth cache
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 18 Dec 2017 06:48:49 +0100] rev 3309
parents: add a utility to filter parents
There is various strange case of merge out there that needs to be handled. We
add an utility function to handle them all.
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 18 Dec 2017 01:53:20 +0100] rev 3308
stablerange: abstract the bit able to store cache into sql
The part about actually storing the range is independent of the algorithm, so we
should extract this before using it for the next iteration.
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 18 Dec 2017 00:40:07 +0100] rev 3307
stablerange: split pure algorithm part from the on disk cache
The stable cache file is getting long, we split the logic about keeping data on
disk into a dedicated file.
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 10 Dec 2017 05:17:04 +0100] rev 3306
stablerange: add an assert to detect buggy range
Nothing can be negative in there, we add an assert to make sure it is so.