从 Mercurial 包中提取提交日期
简而言之:
Mercurial 捆绑包采用什么文件格式? 如何提取提交日期信息?
整个故事:
我开始使用 HgSubversion。 这个 Mercurial 扩展允许您处理 Mercurial 存储库并从 Subversion 进行推送和拉取。
昨天我将两个月的更改推送回 Subversion。 两个惊喜:
hg Push
需要大约两个小时才能完成 200 次提交。- 原始的
hg 提交
日期丢失并被hg 推送
日期取代。
我找到了邮件推送
缓慢的说明列表。 好吧,我可以轻松适应:早推,经常推。 您只需知道您必须这样做。
我对原始提交日期丢失感到失望。 我可以看到 HgSubversion 制定的日期替换对于大多数情况都是有意义的。 但是,这对于我的场景没有意义。
幸运的是,原始提交日期包含在条带备份文件中。 这些文件位于 .hg/strip-backup/
中;看起来它们被称为捆绑。 (它们是在推动 Subversion 时创建的, 子树被反复从树上剥离 在 hg Push
创建的 SVN 提交被拉回 Mercurial 后重新附加。 请参阅上面的“缓慢”链接并在页面中搜索 Patrick Mézards 评论。) 我可以从包中提取日期,然后在 Subversion 中重置 svn:date
。
但是我如何访问捆绑包中包含的信息呢? 它似乎不是已知的压缩格式。
$ mkdir bundle
$ cd bundle
$ cp ~/RepoHgSvn/.hg/strip-backup/ecbe9ff1cf0b-backup.hg .
$ file ecbe9ff1cf0b-backup.hg
ecbe9ff1cf0b-backup.hg: Mercurial changeset bundle (bzip2 compressed)
# Okay then ...
$ bzip2 -d ecbe9ff1cf0b-backup.hg
bzip2: Can't guess original name for ecbe9ff1cf0b-backup.hg
-- using ecbe9ff1cf0b-backup.hg.out
bzip2: ecbe9ff1cf0b-backup.hg is not a bzip2 file.
# Okay, the file utility often goes wrong ...
$ mv ecbe9ff1cf0b-backup.hg ecb.bz2
$ bzip2 -d ecb.bz2
bzip2: ecb.bz2 is not a bzip2 file.
$ mv ecb.bz2 ecb.gz
$ gzip -d ecb.gz
gzip: ecb.gz: not in gzip format
$ mv ecb.gz ecb.zip
$ unzip ecb.zip
Archive: ecb.zip
End-of-central-directory signature not found.
$ 7z l ecb.zip
Error: ecb.zip: is not supported archive
捆绑包的文件格式是什么?如何提取提交日期信息?
In a nutshell:
What file format are Mercurial bundles in?
How can I extract the commit date information?
Whole story:
I've started using HgSubversion.
This Mercurial extension allows you to work on a Mercurial repo and push and pull from Subversion.
Yesterday I pushed two months worth of changes back to Subversion.
Two surprises:
- The
hg push
needed about two hours for 200 commits. - The original
hg commit
date is lost and supplanted by thehg push
date.
I found the explanation for the push
slowness on the mailing list.
Okay, I can easily adapt to that: push early, push often.
You just have to know you have to do this.
I'm disappointed with the original commit date being lost.
I can see the date replacement enacted by HgSubversion makes sense for most scenarios.
However, it does not make sense for my scenario.
Fortunately, the original commit date is contained in the strip-backup files.
These files reside in .hg/strip-backup/
; it seems they're called bundles.
(They're created when, while pushing to Subversion,
subtrees are repeatedly stripped off the tree
to be reattached after the SVN commit created by hg push
is pulled back into Mercurial.
See the "slowness" link above and search the page for Patrick Mézards comments.)
I could extract the date from the bundle and then reset the svn:date
in Subversion.
But how can I access the information contained in the bundle?
It doesn't seem to a known compression format.
$ mkdir bundle
$ cd bundle
$ cp ~/RepoHgSvn/.hg/strip-backup/ecbe9ff1cf0b-backup.hg .
$ file ecbe9ff1cf0b-backup.hg
ecbe9ff1cf0b-backup.hg: Mercurial changeset bundle (bzip2 compressed)
# Okay then ...
$ bzip2 -d ecbe9ff1cf0b-backup.hg
bzip2: Can't guess original name for ecbe9ff1cf0b-backup.hg
-- using ecbe9ff1cf0b-backup.hg.out
bzip2: ecbe9ff1cf0b-backup.hg is not a bzip2 file.
# Okay, the file utility often goes wrong ...
$ mv ecbe9ff1cf0b-backup.hg ecb.bz2
$ bzip2 -d ecb.bz2
bzip2: ecb.bz2 is not a bzip2 file.
$ mv ecb.bz2 ecb.gz
$ gzip -d ecb.gz
gzip: ecb.gz: not in gzip format
$ mv ecb.gz ecb.zip
$ unzip ecb.zip
Archive: ecb.zip
End-of-central-directory signature not found.
$ 7z l ecb.zip
Error: ecb.zip: is not supported archive
What file format is the bundle in and how can I extract the commit date information?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
您可以获得一个包含旧修订版本的存储库,然后
您就拥有了一个 svn 修订版本与原始修订版本一致的存储库。
但是,当您更改 svn 中的提交日期时,您需要重做原始 svn 存储库的克隆,因为存储库中的 svn 元数据(从您将变更集推送到 subversion 的位置)在 svn 属性更改之后是错误的(当前的 svn 克隆)将所有修订版设置为其推送时间,并且可能无法重新获取这些更改的修订版)。
You can get a repository with the old revisions by
then you have a repo where the svn revisions are along the original revisions.
But when you change the commit dates in svn you need to redo the cloning of the original svn repository, since the svn metadata in the repository, from where you pushed the changesets into subversion, is wrong afterward the svn property change (the current svn clone has all revisions set to their push times, and it might be impossible to re-fetch those changed revisions).