相关疑难解决方法(0)

尽管涉及两个子部分,但我认为这是一个综合问题,因为它被分解成部分的方式并不重要.只要最终结果保留了所有有意义的历史记录以及检查,研究和构建/测试历史版本的能力,我就会以不同的方式实现我想要的目标.目标是退出hg和到目前为止使用的subrepo模型,然后转移到git中的统一树,但不会牺牲历史记录.

我开始的是一个Mercurial存储库,它包含一些顶级代码和许多有趣历史所在的子存储库.subrepos有一些分支/合并,但没有什么太疯狂.我想要实现的最终结果是单个git存储库,没有子模块,这样:

• 对于原始顶级hg repo中的每个提交,都有一个git提交,它会检查完全相同的树,因为您将检查相应的hg提交及其所有引用subrepo提交.

• 这些对应于连续顶级hg提交的git提交是彼此的后代,其提交对应于其间的所有相关子提交.

我对如何实现这一点的基本思想是迭代所有顶级hg提交,并且对于每个更改的顶级提交.hgsubstate,也迭代从旧修订到子模块的新修订的所有路径(可能涉及分枝).在每一步:

• 查看顶级和所有子目录的相应hg修订版.
• 从git索引中删除所有内容.
• 将从hg检出的所有内容都放到git索引中.
• 使用git-write-tree和git-commit-tree生成具有所需父级的提交,使用来自相应hg提交的authors,date和commit消息.
• 记录新git commit和hg提交之间的对应关系,以用于生成未来提交的父项.

这有用吗？有没有更好的方法来实现我想要的,也许首先用hg做subrepo崩溃？我不清楚的最重要的事情是如何执行所需的迭代,所以如何实现它的实用建议将是伟大的.

一个额外的约束:原始存储库涉及无法发布的内容(这是git-filter-branch基本转换完成后的额外步骤)所以涉及上传存储库以供第三方处理的解决方案是不可行的.

linux和unix shell可以像这样处理子命令.

$> command `subcommand`

windows cmd shell有类似的功能吗？

两年变更X和Ÿ在的同一 Mercurial库,做以下条件始终保持正确的:

如果X是Y的父级,则修订版(X) < 修订版(Y)

？

如果它成立,是通过规范还是当前如何实施？换句话说,对于未来的Mercurial版本,可以依赖该条件吗？