revset: optimize 'or' operation of trivial revisions to a list
As seen in
issue4565 and
issue4624, GUI wrappers and automated scripts are
likely to generate a long query that just has numeric revisions joined by 'or'.
One reason why is that they allows users to choose arbitrary revisions from
a list. Because this use case isn't handled well by smartset, let's optimize
it to a plain old list.
Benchmarks:
1) reduce nesting of chained 'or' operations
2) optimize to a list (this patch)
revset #0: 0 + 1 + 2 + ... + 1000
1) wall 0.483341 comb 0.480000 user 0.480000 sys 0.000000 (best of 20)
2) wall 0.025393 comb 0.020000 user 0.020000 sys 0.000000 (best of 107)
revset #1: sort(0 + 1 + 2 + ... + 1000)
1) wall 0.035240 comb 0.040000 user 0.040000 sys 0.000000 (best of 100)
2) wall 0.026432 comb 0.030000 user 0.030000 sys 0.000000 (best of 102)
revset #2: first(0 + 1 + 2 + ... + 1000)
1) wall 0.028949 comb 0.030000 user 0.030000 sys 0.000000 (best of 100)
2) wall 0.025503 comb 0.030000 user 0.030000 sys 0.000000 (best of 106)
revset: make "null" able to appear in internal _list() expression
This is the same workaround introduced at
e16456831516. Without this patch,
"null or x" can't be optimized to _list(null x).
Test case will be added by the next patch.
revset: make internal _list() expression remove duplicated revisions
This allows us to optimize chained 'or' operations to _list() expression.
Unlike _intlist() or _hexlist(), it's difficult to remove duplicates by the
caller of _list() because different symbols can point to the same revision.
If the caller knows all symbols are unique, that probably means revisions or
nodes are known, therefore, _intlist() or _hexlist() should be used instead.
So, it makes sense to check duplicates by _list() function.
'%ls' is no longer used in core, this won't cause performance regression.
repair: use _hexlist() to build revset expression from binary nodes
_hexlist() should be efficient than _list().
listkey: display the size of the listkey payload in a debug message
This is a useful information to have in general and we already have debug
output related to listkeys. I'm planning to play around with massive amount of
phases roots and bookmarks so having this data in debug will be very useful.
This already got me to spot that one of the Logilab's review repo is exchanging
65KB of phases data during each exchanges.
ssh: test some no-op pull through ssh with --debug
It appears that we are never running any wireprotocol operation with a --debug
flag. So we are adding some basic testing into 'test-ssh.t'
subrepo: detect
issue3781 case earlier so it apply to bundle2
We are doing some strange special casing of phase push when:
- the source is a subrepo
- the destination is publishing
- some changeset are still draft on the destination
In that case we do not push phases information (to publish the draft changesets)
because it could break simple cycle of 'clone/pull/push' of subrepos. We have to
detect this case earlier to have bundle2 respecting it.
We change the test to check the behavior for both bundle1 and bundle2.
bundle2: hide bundle2 stream debug under a config flag
The old output is very verbose and unsuitable for general debug level. It is
however very useful for debugging bundle2 generation or consumption issues. All
this verbose ouput is hidden under a 'devel.bundle2.debug' flag.
bundle2: add generic debug output regarding processed interruption
If we are about to hide the detailed debug output, we need some generic debug
message to replace it in a concise way.
bundle2: add generic debug output regarding processed part payload
If we are about to hide the detailed debug output, we need some generic debug
message to replace it in a concise way.