Mon, 14 Jan 2019 22:19:43 -0500 histedit: fix call to _getgoal() by adding a byteskwargs() wrapper
Augie Fackler <augie@google.com> [Mon, 14 Jan 2019 22:19:43 -0500] rev 41223
histedit: fix call to _getgoal() by adding a byteskwargs() wrapper I also added some b-prefixes while I was here because I got confused and it seems silly to not just add them since it clarifies the whole change. Differential Revision: https://phab.mercurial-scm.org/D5585
Fri, 04 Jan 2019 13:41:21 +0100 revset: introduce an API that avoids `formatspec` input serialization
Boris Feld <boris.feld@octobus.net> [Fri, 04 Jan 2019 13:41:21 +0100] rev 41222
revset: introduce an API that avoids `formatspec` input serialization Instead of having the data fully serialized, the input can be directly inserted in the tree at a later stage. Just using it for simple "%ld" case provide a significant boost. For example here are the impact on a sample discovery run between two pypy repositories with arbitrary differences (using hg perfdiscovery). $ hg perfdiscovery before: ! wall 0.700435 comb 0.710000 user 0.700000 sys 0.010000 (median of 15) after: ! wall 0.501305 comb 0.510000 user 0.490000 sys 0.020000 (median of 20)
Fri, 04 Jan 2019 05:26:13 +0100 revset: detect integer list on parsing
Boris Feld <boris.feld@octobus.net> [Fri, 04 Jan 2019 05:26:13 +0100] rev 41221
revset: detect integer list on parsing Right now, using "%ld" with `repo.revs("…%ld…", somerevs)` is very inefficient, all items in `somerevs` will be serialized to ascii and then reparsed as integers. If `somerevs` contains just an handful of entry this is fine, however, when you get to thousands or hundreds of thousands of revisions this becomes very slow. To avoid this serialization we need to first detect this situation. The code involved in the whole process is quite complex so we start simple and focus on some "simple" but widespread cases. So far we only detect the situation and don't do anything special about it. The singled out will be serialized in `formatspec` in the same way as before.
Fri, 04 Jan 2019 05:16:57 +0100 revert: extract "%ld" formatting in a _formatintlist function
Boris Feld <boris.feld@octobus.net> [Fri, 04 Jan 2019 05:16:57 +0100] rev 41220
revert: extract "%ld" formatting in a _formatintlist function We'll have to reuse this logic in different places.
Fri, 04 Jan 2019 02:29:04 +0100 revset: extract parsing logic out of formatspec
Boris Feld <boris.feld@octobus.net> [Fri, 04 Jan 2019 02:29:04 +0100] rev 41219
revset: extract parsing logic out of formatspec We want to be able to perform better handling of some input when running revset (eg: `repo.revs("%ld", somerevs)`). The first step is to be able to access some of the parsed content before it gets substituted. There are many possible different substitutions, we'll add support for them gradually. In this changeset we support none, we just split some logic in a sub function as a preparatory step.
Thu, 10 Jan 2019 15:23:58 +0100 revset: enforce "%d" to be interpreted as literal revision number (API) (BC)
Boris Feld <boris.feld@octobus.net> [Thu, 10 Jan 2019 15:23:58 +0100] rev 41218
revset: enforce "%d" to be interpreted as literal revision number (API) (BC) Before this change, `formatspec("%d", x)` results in `"%d" % int(x)`. This seems simple and correct until you consider `nullrev`. In revset, a direct "-1" symbol is equivalent to `tip` not `nullrev`. This is a subtle error that went undetected for a while. Wrapping the revision number inside 'rev()' remove the ambiguity, preserving nullrev value passed to formatspec. It got caught by the rebase code, were the following wrongly returned `[1]`: repo.revs("children(%d) and ancestors(%ld)", 0, [nullrev]) This is flagged as API, because `%d` can be used for non-revision integer argument of revset function. We probably need to introduce a new '%…' substitution to allow literal integer (maybe `%i`). However, the `%d` usage is currently widespread for revision number so it is important to fix this issue for `%d`. This choice is reinforced by the fact _intlist is implemented as revisions only. Restricting `%d` to revision only makes things more consistent. This bug can become especially tricky since `_intlist` recognize `nullrev` right. So `revs('%ld', [-1, 0])` → select `[nullrev, 0]` but `revs('%ld', [-1])` is simplified and treated as `%d` selecting `[tip]`. Another side effect is that "%d" of an unknown revision simply match nothing. It was previously raising and error. This is consistent with what "%ld" (and `_intlist`) is doing, so it seems like a good move.
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -6 +6 +10 +30 +100 +300 +1000 +3000 +10000 tip