Tue, 07 Jun 2016 11:57:11 +0200 crecord: drop unused "operation" parameter from filterpatch function
Denis Laxalde <denis.laxalde@logilab.fr> [Tue, 07 Jun 2016 11:57:11 +0200] rev 29327
crecord: drop unused "operation" parameter from filterpatch function
Tue, 07 Jun 2016 10:37:19 +0200 patch: define full messages for interactive record/revert
Denis Laxalde <denis.laxalde@logilab.fr> [Tue, 07 Jun 2016 10:37:19 +0200] rev 29326
patch: define full messages for interactive record/revert Followup 14eee72c8d52 to provide complete context for proper localization. Also update cmdutil.recordfilter docstring to remove recommendation that "operation" argument should be translated. Indeed, for record/revert, we either go to patch.filterpatch or crecord.filterpatch (in curses mode) ; the former now build the full ui message from the operation parameter and the latter does not use this parameter (removing in a followup patch). For shelve, operation is not specified and this thus falls back to "record".
Wed, 01 Jun 2016 15:16:38 +0200 hgweb: remove unused code in annotate web command
Denis Laxalde <denis.laxalde@logilab.fr> [Wed, 01 Jun 2016 15:16:38 +0200] rev 29325
hgweb: remove unused code in annotate web command
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.
(0) -10000 -3000 -1000 -300 -100 -30 -10 -6 +6 +10 +30 +100 +300 +1000 +3000 +10000 tip