【发布时间】：2013-02-06 20:39:20
【问题描述】：
尝试将存储库从 cvs 迁移到 hg，我找到了工具 cvs2hg，它似乎做得很好（转换很好，我有所有的标签和分支）。 但是，hg documentation 警告“修复提交”会使存储库有些损坏或至少很危险。
这仍然是个问题吗？自编写此警告以来，也许 hg 或 cvs2hg 已从修复中受益。 如果可能，我如何在生成的 hg 存储库中检查我是否处于如此危险的情况？
【问题讨论】：
【发布时间】：2013-02-06 20:39:20
【问题描述】：
修复提交是好的和必要的。而且 cvs2hg 比 hg convert 做得更好。
但也许首先是关于问题的。在 CVS 存储库中，您可以使用标签和分支玩各种肮脏的把戏。例如，您可以手动微调一些标签，标记今天的 3 个文件版本、昨天的 4 个文件版本以及另一个长达一个月的版本。在实践中，我做了很多次“补丁标签”（有一些旧标签，后来我有各种提交，结果是一个错误，我修复了这个错误，通过旧标签制作修复标签，移动它在1-2个文件上）。
在结果中，如果将历史记录用于整个 repo，您将获得指向发布哪个 naver 已经存在或将存在于存储库历史记录中的任何点的标记。
类似的技巧可以用分支来实现。或者分支可以从“丑陋”标签开始。
在这种情况下，任何类型的 CVS 到 HG 的“自然”转换都是完全失败的。在基于时间的历史记录中，没有任何地方可以挂钩此类标签或分支。而 hg convert 只是在或多或少的随机位置绑定这些标签，并在非常丑陋的地方分支。
Fixup 提交只是那些缺少的修订：在适当的位置绑定并引入更改的人工提交，这些更改将存储库置于它应该处于给定标记的状态。有了这些，我们得到了“人工”标签和分支，正确绑定到正确的代码。
如果你：
- 已提交 a.c(1.1)、b.c(1.1) 和 c.c(1.1)
- 提交 a.c(1.2), b.c(1.2)
- 提交 c.c(1.2)
- 人工创建的标签 blah_1.0 指向 a.c(1.1)、b.c(1.1) 和 c.c(1.2)
- 提交 a.c(1.3), b.c(1.3)
- ...
然后基于 hg 转换的历史将有 4 个编辑变更集（就像上面的那些）和 blah_1.0 绑定在一些内容错误的丑陋地方。同时，cvs2hg 将创建“fixup commit”，它会人为地创建我们真正拥有 a.c(1.1)、b.c(1.1) 和 c.c(1.2) 的变更集，并在那里标记。在历史上，这样的变更集与移植/嫁接/樱桃采摘的提交相当相似。
【讨论】：
-
感谢您的解释！实际上我认为它以更系统的方式生成这些修复提交，因为基本上我在每个分支开始（或者几乎每个分支）都得到了它们，而我怀疑标签是否经常被调整（但经常做的是标签是仅应用于存储库的某些文件，而不是全部）。
-
我无法评论你的回购，因为我没有看到它;-) 但我想简单的事情是，如果你标记不是所有文件，那么这个修复提交可能只是简单的... 删除所有未标记的文件。此外，猜测从变更集提交的整个过程是相当不稳定的（出于显而易见的原因，CVS 只有单个文件提交），所以有时可能需要调整一些东西。不管是什么原因：如果你比较 cvs2hg 输出和 hg convert 输出，特别是在那些修复提交之后的地方，你很可能更喜欢 cvs2hg 输出……
-
我们决定使用选项 --trunk-only 来避免（潜在的）问题。
-
为了可能的未来读者：我使用 cvs2hg 转换了很多 CVS 存储库，包括一些历史相当丑陋的，并且没有遇到问题。所以我真的建议试试 cvs2hg。唯一的小困难是它需要 .v 文件，因此必须对 CVS 服务器具有文件级访问权限（仅客户端 CVS 访问权限是不够的）。
您应该仔细检查生成的存储库，以确保它代表您的代码历史记录并且不包含任何这些糟糕的修复提交。
顺便说一句，看看更新的http://www.catb.org/esr/reposurgeon/ 工具可能是值得的。
【讨论】：