revset: stop serializing node when using "%ln" Turning hundred of thousand of node from node to hex and back can be slow… what about we stop doing it? In many case were we are using node id we should be using revision id. However this is not a good reason to have a stupidly slow implementation of "%ln". This caught my attention again because the phase discovery during push make an extensive use of "%ln" or huge set. In absolute, that phase discovery probably should use "%ld" and need to improves its algorithmic complexity, but improving "%ln" seems simple and long overdue. This greatly speeds up `hg push` on repository with many drafts. Here are some relevant poulpe benchmarks: ### data-env-vars.name = mozilla-try-2023-03-22-zstd-sparse-revlog # benchmark.name = hg.command.push # bin-env-vars.hg.flavor = default # bin-env-vars.hg.py-re2-module = default # benchmark.variants.explicit-rev = all-out-heads # benchmark.variants.issue6528 = disabled # benchmark.variants.protocol = ssh # benchmark.variants.reuse-external-delta-parent = default ## benchmark.variants.revs = any-1-extra-rev before: 44.235070 after: 20.416329 (-53.85%, -23.82) ## benchmark.variants.revs = any-100-extra-rev before: 49.234697 after: 26.519829 (-46.14%, -22.71) ### benchmark.name = hg.command.bundle # bin-env-vars.hg.flavor = default # bin-env-vars.hg.py-re2-module = default # benchmark.variants.revs = all # benchmark.variants.type = none-streamv2 ## data-env-vars.name = heptapod-public-2024-03-25-zstd-sparse-revlog before: 10.138396 after: 7.750458 (-23.55%, -2.39) ## data-env-vars.name = mercurial-public-2024-03-22-zstd-sparse-revlog before: 1.263859 after: 0.700229 (-44.60%, -0.56) ## data-env-vars.name = mozilla-try-2023-03-22-zstd-sparse-revlog before: 399.484481 after: 346.5089 (-13.26%, -52.98) ## data-env-vars.name = pypy-2024-03-22-zstd-sparse-revlog before: 4.540080 after: 3.401700 (-25.07%, -1.14) ## data-env-vars.name = tryton-public-2024-03-22-zstd-sparse-revlog before: 2.975765 after: 1.870798 (-37.13%, -1.10)

     1

Checking how hg behaves when one side of a pull/push doesn't support

     2

some capability (because it's running an older hg version, usually).

     3

     4

  $ hg init repo1

     5

  $ cd repo1

     6

  $ echo a > a; hg add -q a; hg commit -q -m a

     7

  $ hg bookmark a

     8

  $ hg clone -q . ../repo2

     9

  $ cd ../repo2

    10

    11

  $ touch $TESTTMP/disable-lookup.py

    12

  $ disable_cap() {

    13

  >   rm -f $TESTTMP/disable-lookup.pyc # pyc caching is buggy

    14

  >   cat <<EOF > $TESTTMP/disable-lookup.py

    15

  > from mercurial import extensions, wireprotov1server

    16

  > def wcapabilities(orig, *args, **kwargs):

    17

  >   cap = orig(*args, **kwargs)

    18

  >   cap.remove(b'$1')

    19

  >   return cap

    20

  > extensions.wrapfunction(wireprotov1server, '_capabilities', wcapabilities)

    21

  > EOF

    22

  > }

    23

  $ cat >> ../repo1/.hg/hgrc <<EOF

    24

  > [extensions]

    25

  > disable-lookup = $TESTTMP/disable-lookup.py

    26

  > EOF

    27

    28

  $ hg pull ssh://user@dummy/repo1 -r tip -B a

    29

  pulling from ssh://user@dummy/repo1

    30

  no changes found

    31

    32

  $ disable_cap lookup

    33

  $ hg pull ssh://user@dummy/repo1 -r tip -B a

    34

  pulling from ssh://user@dummy/repo1

    35

  abort: other repository doesn't support revision lookup, so a rev cannot be specified.

    36

  [255]

    37

    38

  $ disable_cap pushkey

    39

  $ hg pull ssh://user@dummy/repo1 -r tip -B a

    40

  pulling from ssh://user@dummy/repo1

    41

  abort: remote bookmark a not found!

    42

  [10]