Tortoise HG crash during collapse

Issue #1758 duplicate
Anonymous created an issue

We have a Mercurial repo with SVN subrepos for binary files. I used the command 'collapse -r 590 -r 581:584 -r 578:579 -r 574' to collapse these changesets down into one. Here's our collapse.bat:

{{{ hg qimport % hg qgoto qbase for /f "usebackq tokens=" %%r in (hg qunapp) do hg qfold %%r hg qrefresh -e -D hg qfinish qbase }}} OUTPUT: {{{ C:\code\counterMeasure>hg qimport -r 590 -r 581:584 -r 578:579 -r 574

C:\code\counterMeasure>hg qgoto qbase popping 590.diff popping 584.diff popping 583.diff popping 582.diff popping 581.diff popping 579.diff popping 578.diff now at: 574.diff

C:\code\counterMeasure>for /F "usebackq tokens=*" %r in (hg qunapp) do hg qfol d %r

C:\code\counterMeasure>hg qfold 578.diff committing subrepository redist

C:\code\counterMeasure>hg qfold 579.diff patching file .hgsubstate Hunk #1 FAILED at 0 1 out of 1 hunks FAILED -- saving rejects to file .hgsubstate.rej patch failed, unable to continue (try -v) abort: error folding patch 579.diff

C:\code\counterMeasure>hg qfold 581.diff

C:\code\counterMeasure>hg qfold 582.diff

C:\code\counterMeasure>hg qfold 583.diff

C:\code\counterMeasure>hg qfold 584.diff

C:\code\counterMeasure>hg qfold 590.diff

C:\code\counterMeasure>hg qrefresh -e -D

C:\code\counterMeasure>hg qfinish qbase }}} The collapse.bat crashed Tortoise and the Hg Workbench and produced the following error. Of note is that the collapse was successful.



Mercurial version (1.9.3). TortoiseHg version (2.1.4) Command: --nofork workbench CWD: C:\code\counterMeasure Encoding: cp1252 Extensions loaded: eol, mq, fetch, gestalt, kilnauth, kilnpath, big-push, kiln, caseguard, kbfiles Python version: 2.6.6 (r266:84297, Aug 24 2010, 18:13:38) [MSC v.1500 64 bit (AMD64)] Windows version: (6, 1, 7601, 2, 'Service Pack 1') Processor architecture: x64 ** Qt-4.7.1 PyQt-4.8.3 Traceback (most recent call last): File "tortoisehg\hgqt\status.pyo", line 449, in run File "C:\Users\joshua\AppData\Local\KilnExtensions\bfiles\kbfiles\", line 113, in status File "mercurial\localrepo.pyo", line 1232, in status File "mercurial\localrepo.pyo", line 1165, in mfmatches File "mercurial\context.pyo", line 94, in manifest File "mercurial\util.pyo", line 173, in get File "mercurial\context.pyo", line 64, in _manifest File "mercurial\util.pyo", line 173, in get File "mercurial\context.pyo", line 60, in _changeset File "mercurial\changelog.pyo", line 181, in read File "mercurial\revlog.pyo", line 904, in revision File "mercurial\revlog.pyo", line 913, in _checkhash RevlogError: integrity check failed on 00changelog.i:584


Comments (5)

  1. Steve Borho

    That type of stack trace is unavoidable when MQ is being heavily used. The GUI may be reading the DB at the time when MQ is truncating it, and thus it finds an inconsistent state. Until Mercurial has read locks, there is not much we can do about it. There's a reason MQ was never added as a core feature.

  2. Log in to comment