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