'hg strip' created patch is corrupt

I used hg strip to remove some commits from my history. Now I want to reapply the patch that was made as backup during the strip command: .hg/strip-backup/68a8f24f62d0-backup.hg

Unfortunately when I try to push the patch, it开发者_运维技巧 seems that the patch is corrupted:

$:~/sc2$ hg init --mq
adding .hg/patches/68a8f24f62d0-backup.hg
68a8f24f62d0-backup.hg: up to 582 MB of RAM may be required to manage this file
(use 'hg revert 68a8f24f62d0-backup.hg' to cancel the pending addition)
$:~/sc2$ hg qpush
applying 68a8f24f62d0-backup.hg
patch 68a8f24f62d0-backup.hg is empty
transaction abort!
rollback completed
cleaning up working directory...done
abort: decoding near 'h91AY&SY݁��S������': 'utf8' codec can't decode byte 0xb1 in position 16: invalid start byte!

Has someone had this problem already or can give me an advice how to apply the patch? If it is not possible I am more than screwed ...

Maybe this is a python problem?

I tried hg unbundle and get this:

adding changesets
adding manifests
adding file changes
transaction abort!
rollback completed
abort: received file revlog group is empty

If I do hg pull:

pulling from 68a8f24f62d0-backup.hg
searching for changes
adding changesets
transaction abort!
rollback completed
abort: data/sc2-local.tar.i@2cad29d699f8: no node!

So how can I fix the node problem?

Heinrich

From the output of hg help strip:

Any stripped changesets are stored in ".hg/strip-backup" ... They can be restored by running "hg unbundle .hg /strip-backup/BUNDLE", where BUNDLE is the bundle file created by the strip.

This simple demo session illustrates the use of the strip and unbundle commands:

# create a new repo and commit some changes:
$ hg init foobar
$ cd foobar/
$ echo a > file
$ hg ci -A -m "Initial"
adding file
$ echo b > file
$ hg ci -m "Change 1"
$ echo c > file
$ hg ci -m "Change 2"
$ hg glog --template '{rev} - {node} - {desc}\n'
@  2 - 86ecd06a38260fd229fdd73ba82efa6b2db0784c - Change 2
|
o  1 - 7827b4d5a10c2ca8d5196752f1b2dec92e8cf573 - Change 1
|
o  0 - 2b41b1e661196fe943125fdb1d590b5a60369c7e - Initial

# trash revision 1 and all its children:
$ hg strip 1
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
saved backup bundle to /path/to/foobar/.hg/strip-backup/7827b4d5a10c-backup.hg
$ hg log --template '{rev} - {node} - {desc}\n'
@ - 2b41b1e661196fe943125fdb1d590b5a60369c7e - Initial

# meanwhile, make new changes:
$ hg ci -m "Change 1.1"
$ hg glog --template '{rev} - {node} - {desc}\n'
@  1 - a5ad2a79835ad0019f215e62fd928f8649cbbcab - Change 1.1
|
o  0 - 2b41b1e661196fe943125fdb1d590b5a60369c7e - Initial

# you decide your previous work was not that bad at all:
$ hg unbundle .hg/strip-backup/7827b4d5a10c-backup.hg
adding changesets
adding manifests
adding file changes
added 2 changesets with 2 changes to 1 files
(run 'hg update' to get a working copy)

$ hg glog --template '{rev} - {node} - {desc}\n'
o  3 - 86ecd06a38260fd229fdd73ba82efa6b2db0784c - Change 2
|
o  2 - 7827b4d5a10c2ca8d5196752f1b2dec92e8cf573 - Change 1
|
| @  1 - a5ad2a79835ad0019f215e62fd928f8649cbbcab - Change 1.1
|/
o  0 - 2b41b1e661196fe943125fdb1d590b5a60369c7e - Initial

I had some contact with Matt Mackall (Primary Mercurial Author) on this topic and we figured out a bug in Mercurial:

Mercurial actually is not able to handle files larger than 2^31-1 Bytes, which are ~2GB, as signed ints are used for saving the size. However, if you add larger files (what I did) mercurial won't reject them but add as usual. The only check for the file size seems to be when pushing to the server. However, I only got a warning and a never ending hg push here.

Quote by Matt Mackall from the mail conversation:

It'll cause an overflow in a few places:

a) when writing the first revision to the revlog, we'll store an uncompressed size modulo 2G, but we'll still be able to successfully read the whole file

b) when building the bundle for transmission or stripping, we'll report a chunk size modulo 2G, which will be interpreted as a negative number and thus look like an empty chunk.