Fri, 14 Jul 2017 10:48:08 -0700 tests: fix an incorrect description in test-ignore.t
Martin von Zweigbergk <martinvonz@google.com> [Fri, 14 Jul 2017 10:48:08 -0700] rev 33477
tests: fix an incorrect description in test-ignore.t Differential Revision: https://phab.mercurial-scm.org/D82
Sat, 15 Jul 2017 00:38:57 +0900 templatekw: hide {peerpaths} keyword for 4.3
Yuya Nishihara <yuya@tcha.org> [Sat, 15 Jul 2017 00:38:57 +0900] rev 33476
templatekw: hide {peerpaths} keyword for 4.3 Thinking a bit further about list/dict subscript operation (proposed by issue 5534), I noticed the current data structure, a dict of dicts, might not be ideal. For example, if there were "'[' index ']'" and "'.' key" operators, "{parents[0]}" would return "{p1rev}:{p1node}", and we would probably want to write "{parents[0].desc}" to get the first element of "{parents % "{desc}"}". This will basically execute parents[0].makemap()['desc'] in Python. Given the rule above, "{peerpaths.default.pushurl}" will be translated to peerpaths['default'].makemap()['pushurl'], which means {peerpaths} should be a single-level dict and sub-options should be makemap()-ed. "{peerpaths % "{name} = {url}, {pushurl}, ..."}" (Well, it could be peerpaths['default']['pushurl'], but in which case, peerpaths['default'] should be a plain dict, not a hybrid object.) So, let's mark the current implementation experimental and revisit it later.
Fri, 14 Jul 2017 13:48:17 +0200 parsers: fix invariant bug in find_deepest (issue5623)
Sune Foldager <cryo@cyanite.org> [Fri, 14 Jul 2017 13:48:17 +0200] rev 33475
parsers: fix invariant bug in find_deepest (issue5623) find_deepest is used to find the "best" ancestors given a list. In the main loop it keeps an invariant called 'ninteresting' which is supposed to contain the number of non-zero entries in the 'interesting' array. This invariant is incorrectly maintained, however, which leads the the algorithm returning an empty result for certain graphs. This has been fixed. Also, the 'interesting' array is supposed to fit 2^ancestors values, but is incorrectly allocated to twice that size. This has been fixed as well. The tests in test-ancestor.py compare the Python and C versions of the code, and report the error correctly, since the Python version works correct. Even so, I have added an additional test against the expected result, in the event that both algorithms have an identical error in the future. This fixes issue5623.
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -3 +3 +10 +30 +100 +300 +1000 +3000 +10000 tip