tests/test-bundle-vs-outgoing.t
author Boris Feld <boris.feld@octobus.net>
Sun, 17 Dec 2017 04:31:27 +0100
changeset 35599 af25237be091
parent 34661 eb586ed5d8ce
permissions -rw-r--r--
perf: add threading capability to perfbdiff Since we are releasing the GIL during diffing, it is interesting to see how a thread pool would perform on diffing. We add a new `--threads` argument to commands. Synchronizing the thread pool is a bit complex because we want to be able to reuse it from one run to another. On my computer (i7 with 4 cores + hyperthreading), I get the following data for about 12000 revisions: threads wall comb wall gain comb overhead none 31.596715 31.59 0.00% 0.00% 1 31.621228 31.62 -0.08% 0.09% 2 16.406202 32.8 48.08% 3.83% 3 11.598334 34.76 63.29% 10.03% 4 9.205421 36.77 70.87% 16.40% 5 8.517604 42.51 73.04% 34.57% 6 7.94645 47.58 74.85% 50.62% 7 7.434972 51.92 76.47% 64.36% 8 7.070638 55.34 77.62% 75.18% Compared to the feature disabled (threads=0), the overhead is negligible with the threading code (threads=1), and the gain is already 48% with two threads.

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