0

尝试将存储库从 cvs 迁移到 hg，我找到了工具 cvs2hg，它似乎做得很好（转换很好，我有所有的标签和分支）。但是，hg 文档警告说“修复提交”会使存储库有些损坏或至少很危险。

这仍然是一个问题吗？自编写此警告以来，也许 hg 或 cvs2hg 已从修复中受益。如果是的话，我如何在生成的 hg 存储库上检查我是否处于如此危险的情况？

4

2 回答 2

1

修复提交是好的和必要的。cvs2hg 比 hg convert 做得更好。

但也许首先关于这个问题。在 CVS 存储库中，您可以使用标签和分支玩各种肮脏的把戏。例如，您可以手动微调一些标记今天版本的 3 个文件、昨天版本的 4 个文件以及另一个长达一个月的版本。在实践中，我做了很多次“补丁标签”（有一些旧标签，我后来有各种提交，结果是一个错误，我修复了这个错误，通过旧标签制作修复标签，移动它在1-2个文件上）。

结果，如果将历史记录用于整个存储库，您将获得指向发布哪个 naver 已经存在或将存在于存储库历史记录的任何点的标记。

类似的技巧可以用分支来制作。或者分支可以从“丑陋”标签开始。

在这种情况下，任何 CVS 到 HG 的“自然”转换都将完全消失。在基于时间的历史记录中，没有任何地方可以挂钩此类标签或分支。而 hg convert 只是在或多或少的随机位置绑定这些标签，并在非常丑陋的地方分支。

Fixup 提交只是那些缺少的修订：在适当位置绑定并引入更改的人工提交，这些更改将存储库置于其应处于给定标记的状态。有了这些，我们得到了正确绑定到正确代码的“人工”标签和分支。

所以如果你：

  • 提交 ac(1.1)、bc(1.1) 和 cc(1.1)
  • 提交 ac(1.2), bc(1.2)
  • 提交抄送（1.2）
  • 人为创建的标签 blah_1.0 指向 ac(1.1)、bc(1.1) 和 cc(1.2)
  • 提交 ac(1.3), bc(1.3)
  • ...

然后基于 hg convert 的历史将有 4 个编辑变更集（就像上面的那些）和 blah_1.0 绑定在一些丑陋的地方，内容错误。同时，cvs2hg 将创建“fixup commit”，它会人为地创建变更集，在该变更集上我们确实有 ac(1.1)、bc(1.1) 和 cc(1.2)，并在那里标记。在历史上，这样的变更集与移植/嫁接/樱桃采摘提交相当相似。

于 2013-07-11T20:26:29.473 回答
0

您应该仔细检查生成的存储库，以确保它代表您的代码历史记录并且不包含任何这些糟糕的修复提交。

顺便说一句，看看更新的http://www.catb.org/esr/reposurgeon/工具可能是值得的。

于 2013-02-11T10:20:34.643 回答