tests/test-convert-splicemap.t

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...

  $ echo "[extensions]" >> $HGRCPATH
  $ echo "convert=" >> $HGRCPATH
  $ glog()
  > {
  >     hg log -G --template '{rev}:{node|short} "{desc|firstline}"\
  >  files: {files}\n' "$@"
  > }
  $ hg init repo1
  $ cd repo1
  $ echo a > a
  $ hg ci -Am adda
  adding a
  $ echo b > b
  $ echo a >> a
  $ hg ci -Am addb
  adding b
  $ PARENTID1=`hg id --debug -i`
  $ echo c > c
  $ hg ci -Am addc
  adding c
  $ PARENTID2=`hg id --debug -i`
  $ cd ..
  $ glog -R repo1
  @  2:e55c719b85b6 "addc" files: c
  |
  o  1:6d4c2037ddc2 "addb" files: a b
  |
  o  0:07f494440405 "adda" files: a
  

  $ hg init repo2
  $ cd repo2
  $ echo b > a
  $ echo d > d
  $ hg ci -Am addaandd
  adding a
  adding d
  $ INVALIDID1=afd12345af
  $ INVALIDID2=28173x36ddd1e67bf7098d541130558ef5534a86
  $ CHILDID1=`hg id --debug -i`
  $ echo d >> d
  $ hg ci -Am changed
  $ CHILDID2=`hg id --debug -i`
  $ echo e > e
  $ hg ci -Am adde
  adding e
  $ cd ..
  $ glog -R repo2
  @  2:a39b65753b0a "adde" files: e
  |
  o  1:e4ea00df9189 "changed" files: d
  |
  o  0:527cdedf31fb "addaandd" files: a d
  

test invalid splicemap1

  $ cat > splicemap <<EOF
  > $CHILDID2
  > EOF
  $ hg convert --splicemap splicemap repo2 repo1
  abort: syntax error in splicemap(1): child parent1[,parent2] expected
  [255]

test invalid splicemap2

  $ cat > splicemap <<EOF
  > $CHILDID2 $PARENTID1, $PARENTID2, $PARENTID2
  > EOF
  $ hg convert --splicemap splicemap repo2 repo1
  abort: syntax error in splicemap(1): child parent1[,parent2] expected
  [255]

test invalid splicemap3

  $ cat > splicemap <<EOF
  > $INVALIDID1 $INVALIDID2
  > EOF
  $ hg convert --splicemap splicemap repo2 repo1
  abort: splicemap entry afd12345af is not a valid revision identifier
  [255]

splice repo2 on repo1

  $ cat > splicemap <<EOF
  > $CHILDID1 $PARENTID1
  > $CHILDID2 $PARENTID2,$CHILDID1
  > 
  > EOF
  $ cat splicemap
  527cdedf31fbd5ea708aa14eeecf53d4676f38db 6d4c2037ddc2cb2627ac3a244ecce35283268f8e
  e4ea00df91897da3079a10fab658c1eddba6617b e55c719b85b60e5102fac26110ba626e7cb6b7dc,527cdedf31fbd5ea708aa14eeecf53d4676f38db
  
  $ hg clone repo1 target1
  updating to branch default
  3 files updated, 0 files merged, 0 files removed, 0 files unresolved
  $ hg convert --splicemap splicemap repo2 target1
  scanning source...
  sorting...
  converting...
  2 addaandd
  spliced in 6d4c2037ddc2cb2627ac3a244ecce35283268f8e as parents of 527cdedf31fbd5ea708aa14eeecf53d4676f38db
  1 changed
  spliced in e55c719b85b60e5102fac26110ba626e7cb6b7dc and 527cdedf31fbd5ea708aa14eeecf53d4676f38db as parents of e4ea00df91897da3079a10fab658c1eddba6617b
  0 adde
  $ glog -R target1
  o  5:16bc847b02aa "adde" files: e
  |
  o    4:e30e4fee3418 "changed" files: d
  |\
  | o  3:e673348c3a3c "addaandd" files: a d
  | |
  @ |  2:e55c719b85b6 "addc" files: c
  |/
  o  1:6d4c2037ddc2 "addb" files: a b
  |
  o  0:07f494440405 "adda" files: a
  



Test splicemap and conversion order

  $ hg init ordered
  $ cd ordered
  $ echo a > a
  $ hg ci -Am adda
  adding a
  $ hg branch branch
  marked working directory as branch branch
  (branches are permanent and global, did you want a bookmark?)
  $ echo a >> a
  $ hg ci -Am changea
  $ echo a >> a
  $ hg ci -Am changeaagain
  $ hg up 0
  1 files updated, 0 files merged, 0 files removed, 0 files unresolved
  $ echo b > b
  $ hg ci -Am addb
  adding b

We want 2 to depend on 1 and 3. Since 3 is always converted after 2,
the bug should be exhibited with all conversion orders.

  $ cat > ../splicemap <<EOF
  > `(hg id -r 2 -i --debug)` `(hg id -r 1 -i --debug)`, `(hg id -r 3 -i --debug)`
  > EOF
  $ cd ..
  $ cat splicemap
  7c364e7fa7d70ae525610c016317ed717b519d97 717d54d67e6c31fd75ffef2ff3042bdd98418437, 102a90ea7b4a3361e4082ed620918c261189a36a

Test regular conversion

  $ hg convert --splicemap splicemap ordered ordered-hg1
  initializing destination ordered-hg1 repository
  scanning source...
  sorting...
  converting...
  3 adda
  2 changea
  1 addb
  0 changeaagain
  spliced in 717d54d67e6c31fd75ffef2ff3042bdd98418437 and 102a90ea7b4a3361e4082ed620918c261189a36a as parents of 7c364e7fa7d70ae525610c016317ed717b519d97
  $ glog -R ordered-hg1
  o    3:4cb04b9afbf2 "changeaagain" files: a
  |\
  | o  2:102a90ea7b4a "addb" files: b
  | |
  o |  1:717d54d67e6c "changea" files: a
  |/
  o  0:07f494440405 "adda" files: a
  

Test conversion with parent revisions already in dest, using source
and destination identifiers. Test unknown splicemap target.

  $ hg convert -r1 ordered ordered-hg2
  initializing destination ordered-hg2 repository
  scanning source...
  sorting...
  converting...
  1 adda
  0 changea
  $ hg convert -r3 ordered ordered-hg2
  scanning source...
  sorting...
  converting...
  0 addb
  $ cat > splicemap <<EOF
  > `(hg -R ordered id -r 2 -i --debug)` \
  > `(hg -R ordered-hg2 id -r 1 -i --debug)`,\
  > `(hg -R ordered-hg2 id -r 2 -i --debug)`
  > deadbeef102a90ea7b4a3361e4082ed620918c26 deadbeef102a90ea7b4a3361e4082ed620918c27
  > EOF
  $ hg convert --splicemap splicemap ordered ordered-hg2
  scanning source...
  splice map revision deadbeef102a90ea7b4a3361e4082ed620918c26 is not being converted, ignoring
  sorting...
  converting...
  0 changeaagain
  spliced in 717d54d67e6c31fd75ffef2ff3042bdd98418437 and 102a90ea7b4a3361e4082ed620918c261189a36a as parents of 7c364e7fa7d70ae525610c016317ed717b519d97
  $ glog -R ordered-hg2
  o    3:4cb04b9afbf2 "changeaagain" files: a
  |\
  | o  2:102a90ea7b4a "addb" files: b
  | |
  o |  1:717d54d67e6c "changea" files: a
  |/
  o  0:07f494440405 "adda" files: a
  

Test empty conversion

  $ hg convert --splicemap splicemap ordered ordered-hg2
  scanning source...
  splice map revision deadbeef102a90ea7b4a3361e4082ed620918c26 is not being converted, ignoring
  sorting...
  converting...

Test clonebranches

  $ hg --config convert.hg.clonebranches=true convert \
  >   --splicemap splicemap ordered ordered-hg3
  initializing destination ordered-hg3 repository
  scanning source...
  abort: revision 717d54d67e6c31fd75ffef2ff3042bdd98418437 not found in destination repository (lookups with clonebranches=true are not implemented)
  [255]

Test invalid dependency

  $ cat > splicemap <<EOF
  > `(hg -R ordered id -r 2 -i --debug)` \
  > deadbeef102a90ea7b4a3361e4082ed620918c26,\
  > `(hg -R ordered-hg2 id -r 2 -i --debug)`
  > EOF
  $ hg convert --splicemap splicemap ordered ordered-hg4
  initializing destination ordered-hg4 repository
  scanning source...
  abort: unknown splice map parent: deadbeef102a90ea7b4a3361e4082ed620918c26
  [255]