尝试将存储库从cvs迁移到hg，我找到了工具cvs2hg，它似乎很好地完成了工作（转换很顺利，我有所有的标签和分支）。 但是，hg documentation警告“fixup commit”使存储库有些损坏或至少是危险的。
这还是个问题吗？自从发出此警告以来，hg或cvs2hg可能已从修复中受益。 如果可能的话，我怎样才能在生成的hg存储库中检查我是否处于如此危险的情况？
答案 0 :(得分：1)
Fixup提交是好的和必要的。并且cvs2hg比hg转换做得好得多。
但也许首先要解决这个问题。在CVS存储库中，您可以使用标签和分支来玩各种脏技巧。例如，您可以手动微调一些标记标记今天的3个文件版本，昨天的4个版本的版本，以及另一个版本的月份版本。在实践中，我做了很多次制作“补丁标签”（有一些旧标签，我之后有各种提交，结果是一个错误，我修复了错误，通过旧标签制作修复标签，移动它在1-2档）。
在结果中，如果历史记录是针对整个回购，那么您将得到指示哪个naver已存在或将存在于存储库历史记录中的标记。
可以通过分支机构进行类似的技巧。或者分支可以从“丑陋”标签开始。
在这种情况下，CVS到HG的任何“自然”转换都会失效。在基于时间的历史中没有地方可以挂钩这样的标签或分支。而且hg convert只是将这些标签绑定在或多或少的随机位置，并在非常丑陋的地方分支。
Fixup提交只是缺少修订版本：人工提交在适当的位置绑定并引入更改，将存储库置于应该位于给定标记的状态。有了这些，我们得到“人工”标签和分支，正确绑定到正确的代码。
所以如果你：
然后基于hg转换的历史记录将有4个编辑更改集（就像上面那些）和blah_1.0绑定在一些有错误内容的丑陋地方。同时，cvs2hg将创建“fixup commit”，它将人工创建变更集，我们真正拥有a.c（1.1），b.c（1.1）和c.c（1.2），并在那里标记。在历史上，这样的变更集与移植/嫁接/挑选的承诺相似。
答案 1 :(得分：0)
您应该仔细检查生成的存储库，以确保它代表您的代码历史记录，并且不包含任何这些糟糕的修复提交。
顺便说一下，查看较新的http://www.catb.org/esr/reposurgeon/工具可能是值得的。