Thu, 16 Aug 2018 22:45:36 +0200 obshashrange: add more validation output to tests stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 16 Aug 2018 22:45:36 +0200] rev 3957
obshashrange: add more validation output to tests We are about to update the logic and add more tests.
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.
Thu, 16 Aug 2018 20:22:19 +0200 stablerange: build closure a bit less inefficiently stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 16 Aug 2018 20:22:19 +0200] rev 3953
stablerange: build closure a bit less inefficiently The new way make me a bit less sad than the old one.
Thu, 16 Aug 2018 22:19:19 +0200 discovery: make sure repository wrapping happens in the right order stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 16 Aug 2018 22:19:19 +0200] rev 3952
discovery: make sure repository wrapping happens in the right order Otherwise we may end up in situation were cache are not warmed in the right order, crashing.
Thu, 16 Aug 2018 11:58:07 +0200 branching: merge with stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 16 Aug 2018 11:58:07 +0200] rev 3951
branching: merge with stable
Thu, 16 Aug 2018 11:54:30 +0200 changelog: add an entry about the next --evolve fix stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 16 Aug 2018 11:54:30 +0200] rev 3950
changelog: add an entry about the next --evolve fix
Thu, 16 Aug 2018 11:53:49 +0200 changelog: update 8.1.0 release date stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 16 Aug 2018 11:53:49 +0200] rev 3949
changelog: update 8.1.0 release date
Thu, 16 Aug 2018 11:44:32 +0200 next: fix topic constraint in the --evolve case stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 16 Aug 2018 11:44:32 +0200] rev 3948
next: fix topic constraint in the --evolve case We were using the wrong variable.
(0) -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 tip