Thu, 16 Aug 2018 21:12:57 +0200 obshashrange: correctly detect changeset directly affected by prune stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 16 Aug 2018 21:12:57 +0200] rev 3956
obshashrange: correctly detect changeset directly affected by prune Before this changesets, parent of standard obsmarkers were wrongly considered affected and pruned changeset were wrongly not considered affected.
Thu, 16 Aug 2018 21:18:18 +0200 obshashrange: do not search for affected ranges above the highest we have stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 16 Aug 2018 21:18:18 +0200] rev 3955
obshashrange: do not search for affected ranges above the highest we have It is a fast way to know we don't have an affected range for an affected revision.
Thu, 16 Aug 2018 20:49:55 +0200 obshashrange: do not search for affected stable range cache is unavailable stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 16 Aug 2018 20:49:55 +0200] rev 3954
obshashrange: do not search for affected stable range cache is unavailable Before this changeset we where resetting in all cases, and then looking for affected ranges. In addition is the stable range were not available, the functions silently returned no ranges affected. Now, do one or the other depending of the availability of the stable range cache. In practice we always do a broad reset because the code detecting affected changeset is currently buggy.
(0) -3000 -1000 -300 -100 -30 -10 -3 +3 +10 +30 +100 +300 +1000 tip