stream-clone: disable gc for the entry listing section for the v2 format
This is similar to the change we did for the v3 format in 6e4c8366c5ce.
The benchmark bellow show this gives us a notable gains, especially on larger
repositories.
### benchmark.name = hg.perf.stream-locked-section
# benchmark.name = hg.perf.stream-locked-section
# bin-env-vars.hg.flavor = default
# bin-env-vars.hg.py-re2-module = default
# benchmark.variants.version = v2
## data-env-vars.name = pypy-2018-08-01-zstd-sparse-revlog
5e931bf8707c: 0.503820 ~~~~~
1106d1bf695e: 0.470078 (-6.70%, -0.03)
## data-env-vars.name = pypy-2024-03-22-zstd-sparse-revlog
5e931bf8707c: 0.535756 ~~~~~
1106d1bf695e: 0.490249 (-8.49%, -0.05)
## data-env-vars.name = heptapod-public-2024-03-25-zstd-sparse-revlog
5e931bf8707c: 1.327041 ~~~~~
1106d1bf695e: 1.174636 (-11.48%, -0.15)
## data-env-vars.name = netbeans-2018-08-01-zstd-sparse-revlog
5e931bf8707c: 2.439158 ~~~~~
1106d1bf695e: 2.220515 (-8.96%, -0.22)
## data-env-vars.name = netbeans-2019-11-07-zstd-sparse-revlog
5e931bf8707c: 2.630794 ~~~~~
1106d1bf695e: 2.261473 (-14.04%, -0.37)
## data-env-vars.name = mozilla-central-2018-08-01-zstd-sparse-revlog
5e931bf8707c: 5.769002 ~~~~~
1106d1bf695e: 5.062000 (-12.26%, -0.71)
## data-env-vars.name = mozilla-try-2019-02-18-zstd-sparse-revlog
5e931bf8707c: 13.351750 ~~~~~
1106d1bf695e: 12.346655 (-7.53%, -1.01)
## data-env-vars.name = mozilla-central-2024-03-22-zstd-sparse-revlog
5e931bf8707c: 10.772939 ~~~~~
1106d1bf695e: 9.495407 (-11.86%, -1.28)
## data-env-vars.name = mozilla-unified-2024-03-22-zstd-sparse-revlog
5e931bf8707c: 10.864297 ~~~~~
1106d1bf695e: 9.475597 (-12.78%, -1.39)
## data-env-vars.name = mozilla-try-2023-03-22-zstd-sparse-revlog
5e931bf8707c: 17.448335 ~~~~~
1106d1bf695e: 16.027474 (-8.14%, -1.42)
this structure seems to tickle a bug in bundle's search for
changesets, so first we have to recreate it
o 8
|
| o 7
| |
| o 6
|/|
o | 5
| |
o | 4
| |
| o 3
| |
| o 2
|/
o 1
|
o 0
$ mkrev()
> {
> revno=$1
> echo "rev $revno"
> echo "rev $revno" > foo.txt
> hg -q ci -m"rev $revno"
> }
setup test repo1
$ hg init repo1
$ cd repo1
$ echo "rev 0" > foo.txt
$ hg ci -Am"rev 0"
adding foo.txt
$ mkrev 1
rev 1
first branch
$ mkrev 2
rev 2
$ mkrev 3
rev 3
back to rev 1 to create second branch
$ hg up -r1
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ mkrev 4
rev 4
$ mkrev 5
rev 5
merge first branch to second branch
$ hg up -C -r5
0 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ HGMERGE=internal:local hg merge
0 files updated, 1 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)
$ echo "merge rev 5, rev 3" > foo.txt
$ hg ci -m"merge first branch to second branch"
one more commit following the merge
$ mkrev 7
rev 7
back to "second branch" to make another head
$ hg up -r5
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ mkrev 8
rev 8
the story so far
$ hg log -G --template "{rev}\n"
@ 8
|
| o 7
| |
| o 6
|/|
o | 5
| |
o | 4
| |
| o 3
| |
| o 2
|/
o 1
|
o 0
check that "hg outgoing" really does the right thing
sanity check of outgoing: expect revs 4 5 6 7 8
$ hg clone -r3 . ../repo2
adding changesets
adding manifests
adding file changes
added 4 changesets with 4 changes to 1 files
new changesets 6ae4cca4e39a:478f191e53f8
updating to branch default
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
this should (and does) report 5 outgoing revisions: 4 5 6 7 8
$ hg outgoing --template "{rev}\n" ../repo2
comparing with ../repo2
searching for changes
4
5
6
7
8
test bundle (destination repo): expect 5 revisions
this should bundle the same 5 revisions that outgoing reported, but it
actually bundles 7
$ hg bundle foo.bundle ../repo2
searching for changes
5 changesets found
test bundle (base revision): expect 5 revisions
this should (and does) give exactly the same result as bundle
with a destination repo... i.e. it's wrong too
$ hg bundle --base 3 foo.bundle
5 changesets found
$ cd ..