tests/test-treediscovery-legacy.t
author Gregory Szorc <gregory.szorc@gmail.com>
Fri, 13 Jan 2017 20:16:56 -0800
changeset 30818 4c0a5a256ae8
parent 25474 8c14f87bd0ae
child 34661 eb586ed5d8ce
permissions -rw-r--r--
localrepo: experimental support for non-zlib revlog compression The final part of integrating the compression manager APIs into revlog storage is the plumbing for repositories to advertise they are using non-zlib storage and for revlogs to instantiate a non-zlib compression engine. The main intent of the compression manager work was to zstd all of the things. Adding zstd to revlogs has proved to be more involved than other places because revlogs are... special. Very small inputs and the use of delta chains (which are themselves a form of compression) are a completely different use case from streaming compression, which bundles and the wire protocol employ. I've conducted numerous experiments with zstd in revlogs and have yet to formalize compression settings and a storage architecture that I'm confident I won't regret later. In other words, I'm not yet ready to commit to a new mechanism for using zstd - or any other compression format - in revlogs. That being said, having some support for zstd (and other compression formats) in revlogs in core is beneficial. It can allow others to conduct experiments. This patch introduces *highly experimental* support for non-zlib compression formats in revlogs. Introduced is a config option to control which compression engine to use. Also introduced is a namespace of "exp-compression-*" requirements to denote support for non-zlib compression in revlogs. I've prefixed the namespace with "exp-" (short for "experimental") because I'm not confident of the requirements "schema" and in no way want to give the illusion of supporting these requirements in the future. I fully intend to drop support for these requirements once we figure out what we're doing with zstd in revlogs. A good portion of the patch is teaching the requirements system about registered compression engines and passing the requested compression engine as an opener option so revlogs can instantiate the proper compression engine for new operations. That's a verbose way of saying "we can now use zstd in revlogs!" On an `hg pull` conversion of the mozilla-unified repo with no extra redelta settings (like aggressivemergedeltas), we can see the impact of zstd vs zlib in revlogs: $ hg perfrevlogchunks -c ! chunk ! wall 2.032052 comb 2.040000 user 1.990000 sys 0.050000 (best of 5) ! wall 1.866360 comb 1.860000 user 1.820000 sys 0.040000 (best of 6) ! chunk batch ! wall 1.877261 comb 1.870000 user 1.860000 sys 0.010000 (best of 6) ! wall 1.705410 comb 1.710000 user 1.690000 sys 0.020000 (best of 6) $ hg perfrevlogchunks -m ! chunk ! wall 2.721427 comb 2.720000 user 2.640000 sys 0.080000 (best of 4) ! wall 2.035076 comb 2.030000 user 1.950000 sys 0.080000 (best of 5) ! chunk batch ! wall 2.614561 comb 2.620000 user 2.580000 sys 0.040000 (best of 4) ! wall 1.910252 comb 1.910000 user 1.880000 sys 0.030000 (best of 6) $ hg perfrevlog -c -d 1 ! wall 4.812885 comb 4.820000 user 4.800000 sys 0.020000 (best of 3) ! wall 4.699621 comb 4.710000 user 4.700000 sys 0.010000 (best of 3) $ hg perfrevlog -m -d 1000 ! wall 34.252800 comb 34.250000 user 33.730000 sys 0.520000 (best of 3) ! wall 24.094999 comb 24.090000 user 23.320000 sys 0.770000 (best of 3) Only modest wins for the changelog. But manifest reading is significantly faster. What's going on? One reason might be data volume. zstd decompresses faster. So given more bytes, it will put more distance between it and zlib. Another reason is size. In the current design, zstd revlogs are *larger*: debugcreatestreamclonebundle (size in bytes) zlib: 1,638,852,492 zstd: 1,680,601,332 I haven't investigated this fully, but I reckon a significant cause of larger revlogs is that the zstd frame/header has more bytes than zlib's. For very small inputs or data that doesn't compress well, we'll tend to store more uncompressed chunks than with zlib (because the compressed size isn't smaller than original). This will make revlog reading faster because it is doing less decompression. Moving on to bundle performance: $ hg bundle -a -t none-v2 (total CPU time) zlib: 102.79s zstd: 97.75s So, marginal CPU decrease for reading all chunks in all revlogs (this is somewhat disappointing). $ hg bundle -a -t <engine>-v2 (total CPU time) zlib: 191.59s zstd: 115.36s This last test effectively measures the difference between zlib->zlib and zstd->zstd for revlogs to bundle. This is a rough approximation of what a server does during `hg clone`. There are some promising results for zstd. But not enough for me to feel comfortable advertising it to users. We'll get there...

#require killdaemons

Tests discovery against servers without getbundle support:

  $ cat >> $HGRCPATH <<EOF
  > [ui]
  > logtemplate="{rev} {node|short}: {desc} {branches}\n"
  > EOF
  $ cp $HGRCPATH $HGRCPATH-withcap

  $ CAP="getbundle known changegroupsubset bundle2"
  $ . "$TESTDIR/notcapable"
  $ cp $HGRCPATH $HGRCPATH-nocap
  $ cp $HGRCPATH-withcap $HGRCPATH

Prep for test server without branchmap support

  $ CAP="branchmap"
  $ . "$TESTDIR/notcapable"
  $ cp $HGRCPATH $HGRCPATH-nocap-branchmap
  $ cp $HGRCPATH-withcap $HGRCPATH

Setup HTTP server control:

  $ remote=http://localhost:$HGPORT/
  $ export remote
  $ tstart() {
  >   echo '[web]' > $1/.hg/hgrc
  >   echo 'push_ssl = false' >> $1/.hg/hgrc
  >   echo 'allow_push = *' >> $1/.hg/hgrc
  >   cp $HGRCPATH-nocap $HGRCPATH
  >   hg serve -R $1 -p $HGPORT -d --pid-file=hg.pid -E errors.log
  >   cat hg.pid >> $DAEMON_PIDS
  > }
  $ tstop() {
  >   killdaemons.py
  >   cp $HGRCPATH-withcap $HGRCPATH
  > }

Both are empty:

  $ hg init empty1
  $ hg init empty2
  $ tstart empty2
  $ hg incoming -R empty1 $remote
  comparing with http://localhost:$HGPORT/
  no changes found
  [1]
  $ hg outgoing -R empty1 $remote
  comparing with http://localhost:$HGPORT/
  no changes found
  [1]
  $ hg pull -R empty1 $remote
  pulling from http://localhost:$HGPORT/
  no changes found
  $ hg push -R empty1 $remote
  pushing to http://localhost:$HGPORT/
  no changes found
  [1]
  $ tstop

Base repo:

  $ hg init main
  $ cd main
  $ hg debugbuilddag -mo '+2:tbase @name1 +3:thead1 <tbase @name2 +4:thead2 @both /thead1 +2:tmaintip'
  $ hg log -G
  o  11 a19bfa7e7328: r11 both
  |
  o  10 8b6bad1512e1: r10 both
  |
  o    9 025829e08038: r9 both
  |\
  | o  8 d8f638ac69e9: r8 name2
  | |
  | o  7 b6b4d315a2ac: r7 name2
  | |
  | o  6 6c6f5d5f3c11: r6 name2
  | |
  | o  5 70314b29987d: r5 name2
  | |
  o |  4 e71dbbc70e03: r4 name1
  | |
  o |  3 2c8d5d5ec612: r3 name1
  | |
  o |  2 a7892891da29: r2 name1
  |/
  o  1 0019a3b924fd: r1
  |
  o  0 d57206cc072a: r0
  
  $ cd ..
  $ tstart main

Full clone:

  $ hg clone main full
  updating to branch default
  2 files updated, 0 files merged, 0 files removed, 0 files unresolved
  $ cd full
  $ hg incoming $remote
  comparing with http://localhost:$HGPORT/
  searching for changes
  no changes found
  [1]
  $ hg outgoing $remote
  comparing with http://localhost:$HGPORT/
  searching for changes
  no changes found
  [1]
  $ hg pull $remote
  pulling from http://localhost:$HGPORT/
  searching for changes
  no changes found
  $ hg push $remote
  pushing to http://localhost:$HGPORT/
  searching for changes
  no changes found
  [1]
  $ cd ..

Local is empty:

  $ cd empty1
  $ hg incoming $remote --rev name1
  comparing with http://localhost:$HGPORT/
  abort: cannot look up remote changes; remote repository does not support the 'changegroupsubset' capability!
  [255]
  $ hg incoming $remote
  comparing with http://localhost:$HGPORT/
  0 d57206cc072a: r0 
  1 0019a3b924fd: r1 
  2 a7892891da29: r2 name1
  3 2c8d5d5ec612: r3 name1
  4 e71dbbc70e03: r4 name1
  5 70314b29987d: r5 name2
  6 6c6f5d5f3c11: r6 name2
  7 b6b4d315a2ac: r7 name2
  8 d8f638ac69e9: r8 name2
  9 025829e08038: r9 both
  10 8b6bad1512e1: r10 both
  11 a19bfa7e7328: r11 both
  $ hg outgoing $remote
  comparing with http://localhost:$HGPORT/
  no changes found
  [1]
  $ hg push $remote
  pushing to http://localhost:$HGPORT/
  no changes found
  [1]
  $ hg pull $remote
  pulling from http://localhost:$HGPORT/
  requesting all changes
  adding changesets
  adding manifests
  adding file changes
  added 12 changesets with 24 changes to 2 files
  (run 'hg update' to get a working copy)
  $ hg incoming $remote
  comparing with http://localhost:$HGPORT/
  searching for changes
  no changes found
  [1]
  $ cd ..

Local is subset:

  $ cp $HGRCPATH-withcap $HGRCPATH
  $ hg clone main subset --rev name2 ; cd subset
  adding changesets
  adding manifests
  adding file changes
  added 6 changesets with 12 changes to 2 files
  updating to branch name2
  2 files updated, 0 files merged, 0 files removed, 0 files unresolved
  $ cp $HGRCPATH-nocap $HGRCPATH
  $ hg incoming $remote
  comparing with http://localhost:$HGPORT/
  searching for changes
  6 a7892891da29: r2 name1
  7 2c8d5d5ec612: r3 name1
  8 e71dbbc70e03: r4 name1
  9 025829e08038: r9 both
  10 8b6bad1512e1: r10 both
  11 a19bfa7e7328: r11 both
  $ hg outgoing $remote
  comparing with http://localhost:$HGPORT/
  searching for changes
  no changes found
  [1]
  $ hg push $remote
  pushing to http://localhost:$HGPORT/
  searching for changes
  no changes found
  [1]
  $ hg pull $remote
  pulling from http://localhost:$HGPORT/
  searching for changes
  adding changesets
  adding manifests
  adding file changes
  added 6 changesets with 12 changes to 2 files
  (run 'hg update' to get a working copy)
  $ hg incoming $remote
  comparing with http://localhost:$HGPORT/
  searching for changes
  no changes found
  [1]
  $ cd ..

Remote is empty:

  $ tstop ; tstart empty2
  $ cd main
  $ hg incoming $remote
  comparing with http://localhost:$HGPORT/
  searching for changes
  no changes found
  [1]
  $ hg outgoing $remote
  comparing with http://localhost:$HGPORT/
  searching for changes
  0 d57206cc072a: r0 
  1 0019a3b924fd: r1 
  2 a7892891da29: r2 name1
  3 2c8d5d5ec612: r3 name1
  4 e71dbbc70e03: r4 name1
  5 70314b29987d: r5 name2
  6 6c6f5d5f3c11: r6 name2
  7 b6b4d315a2ac: r7 name2
  8 d8f638ac69e9: r8 name2
  9 025829e08038: r9 both
  10 8b6bad1512e1: r10 both
  11 a19bfa7e7328: r11 both
  $ hg pull $remote
  pulling from http://localhost:$HGPORT/
  searching for changes
  no changes found
  $ hg push $remote
  pushing to http://localhost:$HGPORT/
  searching for changes
  remote: adding changesets
  remote: adding manifests
  remote: adding file changes
  remote: added 12 changesets with 24 changes to 2 files
  $ hg outgoing $remote
  comparing with http://localhost:$HGPORT/
  searching for changes
  no changes found
  [1]
  $ cd ..

Local is superset:

  $ tstop
  $ hg clone main subset2 --rev name2
  adding changesets
  adding manifests
  adding file changes
  added 6 changesets with 12 changes to 2 files
  updating to branch name2
  2 files updated, 0 files merged, 0 files removed, 0 files unresolved
  $ tstart subset2
  $ cd main
  $ hg incoming $remote
  comparing with http://localhost:$HGPORT/
  searching for changes
  no changes found
  [1]
  $ hg outgoing $remote
  comparing with http://localhost:$HGPORT/
  searching for changes
  2 a7892891da29: r2 name1
  3 2c8d5d5ec612: r3 name1
  4 e71dbbc70e03: r4 name1
  9 025829e08038: r9 both
  10 8b6bad1512e1: r10 both
  11 a19bfa7e7328: r11 both
  $ hg pull $remote
  pulling from http://localhost:$HGPORT/
  searching for changes
  no changes found
  $ hg push $remote
  pushing to http://localhost:$HGPORT/
  searching for changes
  abort: push creates new remote branches: both, name1!
  (use 'hg push --new-branch' to create new remote branches)
  [255]
  $ hg push $remote --new-branch
  pushing to http://localhost:$HGPORT/
  searching for changes
  remote: adding changesets
  remote: adding manifests
  remote: adding file changes
  remote: added 6 changesets with 12 changes to 2 files
  $ hg outgoing $remote
  comparing with http://localhost:$HGPORT/
  searching for changes
  no changes found
  [1]
  $ cd ..

Partial pull:

  $ tstop ; tstart main
  $ hg clone $remote partial --rev name2
  abort: partial pull cannot be done because other repository doesn't support changegroupsubset.
  [255]
  $ hg init partial; cd partial
  $ hg incoming $remote --rev name2
  comparing with http://localhost:$HGPORT/
  abort: cannot look up remote changes; remote repository does not support the 'changegroupsubset' capability!
  [255]
  $ hg pull $remote --rev name2
  pulling from http://localhost:$HGPORT/
  abort: partial pull cannot be done because other repository doesn't support changegroupsubset.
  [255]
  $ cd ..

  $ tstop

Exercise pushing to server without branchmap capability

  $ cp $HGRCPATH-nocap-branchmap $HGRCPATH-nocap
  $ hg init rlocal
  $ cd rlocal
  $ echo A > A
  $ hg ci -Am A
  adding A
  $ cd ..
  $ hg clone rlocal rremote
  updating to branch default
  1 files updated, 0 files merged, 0 files removed, 0 files unresolved
  $ cd rlocal
  $ echo B > B
  $ hg ci -Am B
  adding B
  $ cd ..
  $ tstart rremote

  $ cd rlocal
  $ hg incoming $remote
  comparing with http://localhost:$HGPORT/
  searching for changes
  no changes found
  [1]
  $ hg outgoing $remote
  comparing with http://localhost:$HGPORT/
  searching for changes
  1 27547f69f254: B 
  $ hg pull $remote
  pulling from http://localhost:$HGPORT/
  searching for changes
  no changes found
  $ hg push $remote
  pushing to http://localhost:$HGPORT/
  searching for changes
  remote: adding changesets
  remote: adding manifests
  remote: adding file changes
  remote: added 1 changesets with 1 changes to 1 files
  $ hg outgoing $remote
  comparing with http://localhost:$HGPORT/
  searching for changes
  no changes found
  [1]
  $ cd ..

  $ tstop