Sat, 04 Jun 2016 14:38:00 +0530 py3: conditionalize cPickle import by adding in util
Pulkit Goyal <7895pulkit@gmail.com> [Sat, 04 Jun 2016 14:38:00 +0530] rev 29324
py3: conditionalize cPickle import by adding in util The cPickle is renamed to _pickle in python3 and this C extension is available in pickle which was not included in earlier versions. So imports are conditionalized to import cPickle in py2 and pickle in py3. Moreover the use of pickle in py2 is switched to cPickle as the C extension is faster. The hack is added in util.py and the modules import util.pickle
Thu, 02 Jun 2016 17:11:32 -0500 bdiff: remove effectively dead code stable
Matt Mackall <mpm@selenic.com> [Thu, 02 Jun 2016 17:11:32 -0500] rev 29323
bdiff: remove effectively dead code Now that we extend matches backwards in the inner loop, the final adjustment has no effect. (A similar extension for the forward direction is trickier and has less benefit.)
Thu, 02 Jun 2016 17:09:06 -0500 bdiff: extend matches across popular lines stable
Matt Mackall <mpm@selenic.com> [Thu, 02 Jun 2016 17:09:06 -0500] rev 29322
bdiff: extend matches across popular lines For very large diffs that have large numbers of identical lines (JSON dumps) that also have large blocks of identical text, bdiff could become confused about which block matches which because it can only match very limited regions. The result is very large diffs for small sets of edits. The earlier recursion rebalancing fix made this behavior more frequent because it's now more prone to match block 1 to block 2. One frequent user of large JSON files reported being unable to pass the resulting diffs through their code review system. Prior to this change, bdiff would calculate the length of a match at (i, j) as 1 + length found at (i-1, j-1). With large number of popular (ignored) lines, this often meant matches couldn't be extended backwards at all and thus all matching regions were very small. Disabling the popularity threshold is not an option because it brings back quadratic behavior. Instead, we extend a match backwards until we either found a previously discovered match or we find a mismatching line. This thus successfully bridges over any popular lines inside and before a matching region. The larger regions then significant reduce the probability of confusion.
Fri, 03 Jun 2016 21:49:26 +0900 test-revset: fix test vector for ordering issue of matching()
Yuya Nishihara <yuya@tcha.org> [Fri, 03 Jun 2016 21:49:26 +0900] rev 29321
test-revset: fix test vector for ordering issue of matching() 592e0beee8b0 fixed matching() to preserve the order of the input set, but the test was incorrect. Given "A and B", "A" should be the input set to "B". But thanks to our optimizer, the test expression was rewritten as "(2 or 3 or 1) and matching(1 or 2 or 3)", therefore it was working well. Since I'm going to fix the overall ordering issue, the test needs to be adjusted to do the right thing.
(0) -10000 -3000 -1000 -300 -100 -30 -10 -4 +4 +10 +30 +100 +300 +1000 +3000 +10000 tip