view tests/test-clone-pull-corruption.t @ 33207:895ecec31c70

revlog: add an experimental option to mitigated delta issues (issue5480)

The general delta heuristic to select a delta do not scale with the number of
branch. The delta base is frequently too far away to be able to reuse a chain
according to the "distance" criteria. This leads to insertion of larger delta (or
even full text) that themselves push the bases for the next delta further away
leading to more large deltas and full texts. This full text and frequent
recomputation throw Mercurial performance in disarray.

For example of a slightly large repository

  280 000 files (2 150 000 versions)
  430 000 changesets (10 000 topological heads)

Number below compares repository with and without the distance criteria:

manifest size:
    with:    21.4 GB
    without:  0.3 GB

store size:
    with:    28.7 GB
    without   7.4 GB

bundle last 15 00 revisions:
    with:    800 seconds
             971 MB
    without:  50 seconds
              73 MB

unbundle time (of the last 15K revisions):
    with:    1150 seconds (~19 minutes)
    without:   35 seconds

Similar issues has been observed in other repositories.


Adding a new option or "feature" on stable is uncommon. However, given that this
issues is making Mercurial practically unusable, I'm exceptionally targeting
this patch for stable.

What is actually needed is a full rework of the delta building and reading
logic. However, that will be a longer process and churn not suitable for stable.

In the meantime, we introduces a quick and dirty mitigation of this in the
'experimental' config space. The new option introduces a way to set the maximum
amount of memory usable to store a diff in memory. This extend the ability for
Mercurial to create chains without removing all safe guard regarding memory
access. The option should be phased out when core has a more proper solution
available.

Setting the limit to '0' remove all limits, setting it to '-1' use the default
limit (textsize x 4).

Corrupt an hg repo with a pull started during an aborted commit
Create two repos, so that one of them can pull from the other one.

  $ hg init source
  $ cd source
  $ touch foo
  $ hg add foo
  $ hg ci -m 'add foo'
  $ hg clone . ../corrupted
  updating to branch default
  1 files updated, 0 files merged, 0 files removed, 0 files unresolved
  $ echo >> foo
  $ hg ci -m 'change foo'

Add a hook to wait 5 seconds and then abort the commit

  $ cd ../corrupted
  $ echo "[hooks]" >> .hg/hgrc
  $ echo 'pretxncommit = sh -c "sleep 5; exit 1"' >> .hg/hgrc

start a commit...

  $ touch bar
  $ hg add bar
  $ hg ci -m 'add bar' &

... and start a pull while the commit is still running

  $ sleep 1
  $ hg pull ../source 2>/dev/null
  pulling from ../source
  transaction abort!
  rollback completed
  abort: pretxncommit hook exited with status 1
  searching for changes
  adding changesets
  adding manifests
  adding file changes
  added 1 changesets with 1 changes to 1 files
  (run 'hg update' to get a working copy)

see what happened

  $ wait
  $ hg verify
  checking changesets
  checking manifests
  crosschecking files in changesets and manifests
  checking files
  1 files, 2 changesets, 2 total revisions

  $ cd ..