我使用hg strip
从历史记录中删除了一些提交。
现在,我想重新应用在strip命令期间作为备份的补丁:.hg/strip-backup/68a8f24f62d0-backup.hg
不幸的是,当我尝试推送补丁时,补丁似乎已损坏:
$:~/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!
是否有人已经遇到此问题或者可以就如何应用补丁给我一些建议?如果不可能,我不仅仅是搞砸了......
也许这是一个python问题?
我尝试了hg unbundle并得到了这个:
adding changesets
adding manifests
adding file changes
transaction abort!
rollback completed
abort: received file revlog group is empty
如果我做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!
那么如何修复节点问题呢?
海因里希
答案 0 :(得分:5)
来自hg help strip
的输出:
任何剥离的变更集都存储在“.hg / strip-backup”中......可以通过运行“hg unbundle .hg / strip-backup / BUNDLE”来恢复它们,其中BUNDLE是由地带。
这个简单的演示会话说明了使用 strip 和 unbundle 命令:
# 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
答案 1 :(得分:2)
我与Matt Mackall(Primary Mercurial Author)就此主题进行了一些联系,我们发现了Mercurial中的一个错误:
Mercurial实际上无法处理大于2 ^ 31-1字节的文件,大小约为2GB,因为签名的整数用于保存大小。但是,如果你添加更大的文件(我做了什么),mercurial不会拒绝它们,而是像往常一样添加。对文件大小的唯一检查似乎是在推送到服务器时。但是,我在这里只收到警告和永无止境的hg push
。
Matt Mackall在邮件对话中引用:
这会导致一些人溢出 地方:
a)编写第一个修订版时 revlog,我们将存储一个 未压缩的大小模2G,但我们会 仍然能够成功阅读 整个文件
b)构建捆绑包时 传输或剥离,我们会 报告模块2G的块大小,其中 将被解释为否定的 数字,因此看起来像一个空的 块。