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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 09:04:34 +0100] rev 2221
stablerange: small style fix
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.
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.
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.
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
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.
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.
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.
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.
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.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 03:33:36 +0100] rev 2211
minor simplification around rangelength
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 03:30:14 +0100] rev 2210
more explicite name in revsfromrange
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.
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.
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.
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.