tests: descending empty dirs works in all hgweb styles, test them too The tested feature was added to multiple hgweb styles in c21d236ca897, but only paper was tested. Let's test everything now, including monoblue, which only got the feature some 6 years late in e50d8b21f4f4.

tests: actualize the comment in test-hgweb-descend-empties.t The comment came together with the whole test file and the feature (descend empty dirs in hgweb) in c21d236ca897, but for some reason wasn't exactly accurate. Namely, there isn't e1 directory in the test at all, it obviously should say d1; and b1 didn't terminate at level 3, but does now.

revset: add fast path for _list() of integer revisions This can greatly speed up chained 'or' of integer revisions. 1) reduce nesting of chained 'or' operations 2) optimize to a list 3) fast path for integer revisions (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) 3) wall 0.008371 comb 0.000000 user 0.000000 sys 0.000000 (best of 317) 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) 3) wall 0.008418 comb 0.000000 user 0.000000 sys 0.000000 (best of 322) 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) 3) wall 0.008423 comb 0.010000 user 0.010000 sys 0.000000 (best of 319) But I admit that it is still slower than the spanset. revset #3: 0:1000 3) wall 0.000132 comb 0.000000 user 0.000000 sys 0.000000 (best of 19010)

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.