A future patch will be reorganizing this section of the code into two paths, and
targetsubs complicates this by existing in the middle of one path, but not the
other. We fix that by moving it 200 lines down, to the only place it's used.
The primary goal is to make it easier for extensions to alter how bundle2
parts are laid out. They now can use the getbundle2partsgenerator decorator
to add new parts, or directly act on getbundle2partsmapping to wrap existing
part functions.
Note the 'request for bundle10 must include changegroup' error was kept
under the same conditions as before, although the logic changes don't make
it obvious.
This takes advantage of the `fullreposet` smartness with a nice
speedup. It's a similar speedup to `p1()` when a merge is in progress
(the non merge case is already lightning fast anyway.)
This takes advantage of the `fullreposet` smartness and yields a nice
speedup.
revset #0: p1()
0) wall 0.003256 comb 0.010000 user 0.010000 sys 0.000000 (best of 527)
1) wall 0.000066 comb 0.000000 user 0.000000 sys 0.000000 (best of 23224)
This takes advantage of the `fullreposet` smartness and yields a nice
speedup.
revset #0: rev(25)
0) wall 0.005480 comb 0.000000 user 0.000000 sys 0.000000 (best of 305)
1) wall 0.000052 comb 0.000000 user 0.000000 sys 0.000000 (best of 21891)
This takes advantage of the `fullreposet` smartness.
revset #0: origin(tip)
0) wall 0.005353 comb 0.000000 user 0.000000 sys 0.000000 (best of 354)
1) wall 0.003080 comb 0.000000 user 0.000000 sys 0.000000 (best of 446)
This takes advantage of the `fullreposet` smartness.
revset #0: follow(COPYING)
0) wall 0.002446 comb 0.000000 user 0.000000 sys 0.000000 (best of 735)
1) wall 0.000331 comb 0.000000 user 0.000000 sys 0.000000 (best of 5672)
This takes advantage of the `fullreposet` smartness.
revset #0: file(COPYING)
0) wall 3.179066 comb 3.180000 user 3.140000 sys 0.040000 (best of 3)
1) wall 2.723699 comb 2.730000 user 2.690000 sys 0.040000 (best of 4)
This takes advantage of the `fullreposet` smartness.
revset #0: divergent()
0) wall 0.002047 comb 0.000000 user 0.000000 sys 0.000000 (best of 813)
1) wall 0.000052 comb 0.000000 user 0.000000 sys 0.000000 (best of 22757)
This takes advantage of the `fullreposet` smartness.
revset #0: bisect(range)
0) wall 0.014007 comb 0.010000 user 0.010000 sys 0.000000 (best of 115)
1) wall 0.005556 comb 0.010000 user 0.010000 sys 0.000000 (best of 235)
This takes advantage of the `fullreposet` smartness.
revset #0: tip~25
0) wall 0.004800 comb 0.010000 user 0.010000 sys 0.000000 (best of 259)
1) wall 0.002475 comb 0.000000 user 0.000000 sys 0.000000 (best of 717)
This should give us the same benefit as elsewhere. Result is simpler (and
"faster").
Outgoing is dominated by the discovery so no benchmark is provided.
Python lookups are slow, so do all lookup outside of the for loop.
This provide a small but still significant speedup:
revset #0: 0::
0) wall 0.063258 comb 0.060000 user 0.060000 sys 0.000000 (best of 100)
1) wall 0.057776 comb 0.050000 user 0.050000 sys 0.000000 (best of 100)
Attribute lookup is slow in python. So this version is going to be a bit
faster. This does not have a visible impact since the rest of the stack is much
slower but this shaves the yak a few extra nanometers.
Moreover the new version is more readable so it worth doing this change for code
quality purpose.
This optimisation was approved by a core python dev.
In match.__init__(), we create the matchfn predicate by and-ing
together the individual predicates for includes, excludes (negated)
and patterns. Instead of the current set of nested if/else blocks, we
can simplify by adding the predicates to a list and defining the
overall predicate in a generic way based on the components. We can
still optimize it for the 0-length and 1-length cases. This way, there
is no combinatorial explosion to deal with if new component predicates
are added, and there is less risk of getting the overall predicate
wrong.
"And" operation with something that contains the whole repo should be super
cheap. Check method docstring for details.
This provide massive boost to simple revset that use `subset & xxx`
revset #0: p1(20000)
0) wall 0.002447 comb 0.010000 user 0.010000 sys 0.000000 (best of 767)
1) wall 0.000529 comb 0.000000 user 0.000000 sys 0.000000 (best of 3947)
revset #1: p2(10000)
0) wall 0.002464 comb 0.000000 user 0.000000 sys 0.000000 (best of 913)
1) wall 0.000530 comb 0.000000 user 0.000000 sys 0.000000 (best of 4226)
No other regression spotted.
More performance improvements are expected in the future as more
revset predicate are converted to use `subset & xxx`
The relaxed way `fullreposet` handles "&" operation may cause some trouble for
people comparing smartset from different filter levels. I'm not sure such people
exist and we can improve that aspect in later patches.
We rename the `spanset` class to `_spanset`. `spanset` is now a function that
builds either a `fullreposet` or a `_spanset` according to the argument passed.
At some point, we may force people to explicitly use the `fullreposet`
constructor, but the current approach makes it easier to ensure we use the new
class whenever possible and focus on the benefits of this class.
Every revset evaluation starts from `subset = spanset(repo)` and a lot of
revset predicates build a `spansetrepo` for their internal needs.
`spanset` is a generic class that can handle any situation. As a result a lot
of operation between spanset result in an `orderedlazyset`, a safe object but
suboptimal in may situation.
So we introduce a `fullreposet` class where some of the operation will be
overwritten to produce more interesting results.
When a set of revisions was empty, we were using an empty tuple. We now return an
empty frozenset to ensure the object could be used in an operation that requires a
set.
The old code relied on the subset contents to get rid of invalid values. We would
like to be able to rely more on the computation in parents() so we filter out
the invalid value.
Both paths are doing similar thing in the end. We refactor the function so that
the `ps` set is commonly used at the end.
This will end excluding `nullrev` from this set in a future patch
The old code relied on the subset contents to get rid of invalid values. We would
like to be able to rely more on the computation in p1() and p2() so we filter out
the invalid value
The baseset class is based on a python list. This means that base.__contains__
was absolutely as crappy as list.__contains__. We now rely on __contains__ from
the underlying set.
This will avoid having to explicitly convert the baseset to a set (using
baseset.set()) whenever one want fast membership test.
Apparently there is already code that forgot to do such conversions since we
observe a massive speedup in some test.
revset #25: roots((0::) - (0::tip))
0) wall 2.079454 comb 2.080000 user 2.080000 sys 0.000000 (best of 5)
1) wall 0.132970 comb 0.130000 user 0.130000 sys 0.000000 (best of 65)
No regression is observed in benchmarks.
This change improve the issue4371 back to acceptable situation (but are still
slower than manual substraction)
Before this patch, the shell alias causes failure when it takes its
specific (= unknown for "hg") options in the command line, because
"_parse()" can't accept them.
This is the regression introduced by 7849ac1dbc57.
It fixed the issue that ambiguity between shell aliases and commands
defined by extensions was ignored. But it also caused that ambiguous
shell alias is handled in "_parse()" even if it takes specific options
in the command line.
To avoid such failure, this patch checks shell alias again after
loading extensions.
All aliases and commands (including ones defined by extensions) are
completely defined before the 2nd (= newly added in this patch)
"_checkshellalias()" invocation, and "cmdutil.findcmd(strict=False)"
can detect ambiguity between them correctly.
For efficiency, this patch does:
- omit the 2nd "_checkshellalias()" invocation if "[ui] strict= True"
it causes "cmdutil.findcmd(strict=True)", of which result should
be equal to one of the 1st invocation before adding aliases
- avoid removing the 1st "_checkshellalias()" invocation
it causes "cmdutil.findcmd(strict=True)" invocation preventing
shell alias execution from loading extensions uselessly
To reduce changes in the subsequent patch fixing issue4355, this patch
makes "_checkshellalias" reusable regardless of adding aliases.
In this patch, alias definitions are added and restored, only when
"precheck=True".
`hg help -k` on my machine was aborting because the hg-prompt extension
was inserting a string and not a function into help.helptable and help
was blindly calling it.
This patch changes keyword searching to be more robust against
unexpected types.
Incidentally, this avoids the changelog cache being invalidated each time
it's accessed on a repoview.
On a filtering experiment on a repository the size of mozilla-central,
this makes a significant difference:
Before, running hg log -l 10 --time with about 8k changesets filtered out:
time: real 1.490 secs (user 1.450+0.000 sys 0.040+0.000)
After:
time: real 0.540 secs (user 0.530+0.000 sys 0.010+0.000)
Added + deleted file are files that need to be untracked from the dirstate but
that are already missing on disk. The current `_performrevert` code is handling
that with exception catching. We will be able to do better with a dedicated set.
The distinction between "remove" and "forget" used to be in special logic
checking for the state of the file in the dirstate. Now that we have dedicated
filtering, we can stop relying on this logic and have two distinct actions.
