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.
(0) -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 tip