将 CVS 升级到 git/hg 的技巧？

Question

我们仍然使用 CVS，我个人使用 git 和 hg，虽然我在这两个方面仍然是新手，但我意识到它们更现代、更好、更快、分布式等。

只是每个人都对 CVS 如此习惯，以至于我觉得如果我是推荐并实际将我们当前的 CVS 服务器升级/移植/转换为 git 或 hg 的人，可能会出现一系列问题。

最近有人真的这样做过吗？您能否提供有关影响人们使用 git/hg 的任何见解或提示，以及如果要进行实际更新/转换的一般提示？有没有我应该注意的常见问题？

Answer 1

我刚刚遇到这个问题，我曾在某个地方工作过，试图进行这种转变。它没有用。

我这样说并不是要劝阻任何人，而是要强调人们可能会遇到的问题。

问题很多，但基本上都归结为人们没有看到 CVS 的问题。我知道很神奇，但它已经存在了这么久。他们已经习惯了这些特质，现在对它给他们造成的问题视而不见。带来一些新的东西，他们无法理解为什么需要以不同的方式来做事情。

最大的问题之一是原子提交的概念。人们无法摆脱这样一个事实，即修订现在是整个项目树的状态，而不是文件的状态。因此，file A在有未完成的更改时检查更改file B突然变成了对版本控制系统进行咆哮的平台。

• 哇哦！为什么我必须检入所有文件？
• 哇哦！为什么我没有得到我刚刚拉取的更改？
• 哇哦！你的意思是我必须合并？为什么我总是要合并？
• 哇哦！为什么它不能只使用正常的修订号？

当您在那个级别上遇到困难时，您可能会忘记尝试引入“高级”概念，例如比发布代码或在用户之间共享更改时更频繁地提交。

致命的打击是他们将一个包含数百名开发人员和大约 70 个子项目的大型项目放在一个集中存储库中。这意味着这个中央仓库每天收到 1-200 次提交。每个人都一直在推动每一次提交（因为cvs commit == commit; push对吧？）。它还提交了大量的自动化构建和测试报告。把这一切放在一起，它到了一个阶段，你pull;merge;(no testing);push必须重新做一个，pull;merge因为你已经过时了。在您等待大拉完成时，有人推了东西。

...并且因为人们没有测试他们的合并，所以发生了破坏。

• 哇哦！该死的东西合并错了！

哦，一个人合并了大约 10 个分支，因为他知道他必须合并，但他不明白要合并什么或为什么要合并。

结果......他们买了Perforce。

原因：它带有支持合同，所以当它出错时有人[责备/修复它]。

所以：

• 教育人们了解 CVS 导致他们的问题。通常归结为无法在没有标记的情况下识别哪些版本的文件一起工作，这需要每个人停止工作。我相信你能找到更多。
• 教育人们为什么 DVCS 以他们的方式工作。向他们展示力量意味着他们可以做什么。让他们想要。
• 确保他们知道什么不该做！
• 不要只是改变系统，让每个人都在工作中学习。它只会产生怨恨，他们所做的就是尝试做在旧系统上有效的事情。它不漂亮。
• 不要把每个项目都放在一个单一的仓库中。集中式 VCS 比 DVCS 处理它要好得多，而且您每次都会失败。

如果可以的话，在一个只有少数开发人员的项目上慢慢来。教育他们；正确设置；让他们成为公司其他部门的传道人。消息会传播开来，每个人都会想要这个新的奇妙工具，因为“当我们坚持使用 CVS 工作时，为什么 Bob 的团队要获得新工具？你是否意识到我们因此而遇到的所有问题？ ”