tests/test-remotefilelog-pull-noshallow.t

setdiscovery: stop limiting the number of local head we initially send

In our testing this limitation provides now real gain and instead triggers
pathological discovery timing for some repository with many heads.

See inline documentation for details.

Some timing below:

Mozilla try repository, (~1M revs, ~35K heads), discovery between 2 clones with
100 head missing on each side

before:
! wall 1.492111 comb 1.490000 user 1.450000 sys 0.040000 (best of 20)
! wall 1.813992 comb 1.820000 user 1.700000 sys 0.120000 (max of 20)
! wall 1.574326 comb 1.573500 user 1.522000 sys 0.051500 (avg of 20)
! wall 1.572583 comb 1.570000 user 1.520000 sys 0.050000 (median of 20)

after:
! wall 1.147834 comb 1.150000 user 1.090000 sys 0.060000 (best of 20)
! wall 1.449144 comb 1.450000 user 1.330000 sys 0.120000 (max of 20)
! wall 1.204618 comb 1.202500 user 1.146500 sys 0.056000 (avg of 20)
! wall 1.194407 comb 1.190000 user 1.140000 sys 0.050000 (median of 20)


pypy (~100 heads, 317 heads) discovery between clones with only 42 common heads

before:
! wall 0.031653 comb 0.030000 user 0.030000 sys 0.000000 (best of 25)
! wall 0.055719 comb 0.050000 user 0.040000 sys 0.010000 (max of 25)
! wall 0.038939 comb 0.039600 user 0.038400 sys 0.001200 (avg of 25)
! wall 0.038660 comb 0.050000 user 0.040000 sys 0.010000 (median of 25)

after:
! wall 0.018754 comb 0.020000 user 0.020000 sys 0.000000 (best of 49)
! wall 0.034505 comb 0.040000 user 0.030000 sys 0.010000 (max of 49)
! wall 0.019631 comb 0.019796 user 0.018367 sys 0.001429 (avg of 49)
! wall 0.019132 comb 0.020000 user 0.020000 sys 0.000000 (median of 49)


Private repository (~1M revs, ~3K heads), discovery from a strip subset, about
100 changesets to be pulled.

before:
! wall 1.837729 comb 1.840000 user 1.790000 sys 0.050000 (best of 20)
! wall 2.203468 comb 2.200000 user 2.100000 sys 0.100000 (max of 20)
! wall 2.049355 comb 2.048500 user 2.002500 sys 0.046000 (avg of 20)
! wall 2.035315 comb 2.040000 user 2.000000 sys 0.040000 (median of 20)

after:
! wall 0.136598 comb 0.130000 user 0.110000 sys 0.020000 (best of 20)
! wall 0.330519 comb 0.330000 user 0.260000 sys 0.070000 (max of 20)
! wall 0.157254 comb 0.155500 user 0.123000 sys 0.032500 (avg of 20)
! wall 0.149870 comb 0.140000 user 0.110000 sys 0.030000 (median of 20)


Same private repo, discovery between two clone with 500 different heads on each
side:

before:
! wall 2.372919 comb 2.370000 user 2.320000 sys 0.050000 (best of 20)
! wall 2.622422 comb 2.610000 user 2.510000 sys 0.100000 (max of 20)
! wall 2.450135 comb 2.450000 user 2.402000 sys 0.048000 (avg of 20)
! wall 2.443896 comb 2.450000 user 2.410000 sys 0.040000 (median of 20)

after:
! wall 0.625497 comb 0.620000 user 0.570000 sys 0.050000 (best of 20)
! wall 0.834723 comb 0.820000 user 0.730000 sys 0.090000 (max of 20)
! wall 0.675725 comb 0.675500 user 0.628000 sys 0.047500 (avg of 20)
! wall 0.671614 comb 0.680000 user 0.640000 sys 0.040000 (median of 20)

#require no-windows

  $ . "$TESTDIR/remotefilelog-library.sh"

Set up an extension to make sure remotefilelog clientsetup() runs
unconditionally even if we have never used a local shallow repo.
This mimics behavior when using remotefilelog with chg.  clientsetup() can be
triggered due to a shallow repo, and then the code can later interact with
non-shallow repositories.

  $ cat > setupremotefilelog.py << EOF
  > from mercurial import extensions
  > def extsetup(ui):
  >     remotefilelog = extensions.find(b'remotefilelog')
  >     remotefilelog.onetimeclientsetup(ui)
  > EOF

Set up the master repository to pull from.

  $ hg init master
  $ cd master
  $ cat >> .hg/hgrc <<EOF
  > [remotefilelog]
  > server=True
  > EOF
  $ echo x > x
  $ hg commit -qAm x

  $ cd ..

  $ hg clone ssh://user@dummy/master child -q

We should see the remotefilelog capability here, which advertises that
the server supports our custom getfiles method.

  $ cd master
  $ echo 'hello' | hg -R . serve --stdio | grep capa | identifyrflcaps
  exp-remotefilelog-ssh-getfiles-1
  x_rfl_getfile
  x_rfl_getflogheads
  $ echo 'capabilities' | hg -R . serve --stdio | identifyrflcaps ; echo
  exp-remotefilelog-ssh-getfiles-1
  x_rfl_getfile
  x_rfl_getflogheads
  

Pull to the child repository.  Use our custom setupremotefilelog extension
to ensure that remotefilelog.onetimeclientsetup() gets triggered.  (Without
using chg it normally would not be run in this case since the local repository
is not shallow.)

  $ echo y > y
  $ hg commit -qAm y

  $ cd ../child
  $ hg pull --config extensions.setuprfl=$TESTTMP/setupremotefilelog.py
  pulling from ssh://user@dummy/master
  searching for changes
  adding changesets
  adding manifests
  adding file changes
  added 1 changesets with 1 changes to 1 files
  new changesets d34c38483be9
  (run 'hg update' to get a working copy)

  $ hg up
  1 files updated, 0 files merged, 0 files removed, 0 files unresolved

  $ cat y
  y

Test that bundle works in a non-remotefilelog repo w/ remotefilelog loaded

  $ echo y >> y
  $ hg commit -qAm "modify y"
  $ hg bundle --base ".^" --rev . mybundle.hg --config extensions.setuprfl=$TESTTMP/setupremotefilelog.py
  1 changesets found

  $ cd ..