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

Question

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

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

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

Answer 1

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

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

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

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

• 哇啊啊啊!为什么我必须检查所有文件？
• 哇啊啊啊!为什么我没有得到我刚刚提取的更改？
• 哇啊啊啊!你是什​​么意思我必须 merge ？为什么我总是要 merge ？
• 哇啊啊啊!为什么不能只使用普通的修订号？

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

致命一击是他们将一个庞大的项目(有数百名开发人员和大约 70 个子项目)放在一个中央存储库中。这意味着这个中央仓库每天有 1-200 次提交。每个人都在 push 对它的每一次提交(因为 cvs commit == commit; push 对吧？)。它还获得了大量的自动化构建和测试报告。把它们放在一起，它就到了这样的阶段，你不能在不需要重新 pull;merge 的情况下执行 pull;merge;(no testing);push 因为你过时了。当您等待大 pull 完成时，有人推了一些东西。

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

• 哇啊啊啊!该死的把它 merge 错了!

哦，一个人将大约 10 个分支 merge 在一起，因为他知道他必须 merge ，但他不明白要 merge 什么或为什么要 merge 。

结果……他们买了 Perforce。

原因:它带有支持契约(Contract)，所以当它出错时有人可以[ blame/修复它]。

所以:

• 让人们了解 CVS 给他们带来的问题。通常情况下，如果不加标签就无法识别哪些版本的文件可以一起工作，这需要每个人都停止工作。我相信你能找到更多。
• 教育人们为什么 DVCS 以他们的方式运作。向他们展示权力意味着他们可以做什么。让他们想要它。
• 确保他们知道不该做什么!
• 不要只是改变系统，让每个人都在工作中学习。它只会引起怨恨，他们所做的就是尝试做在旧系统上有效的事情。它不漂亮。
• 不要将每个项目都放在一个单一的代码库中。集中式 VCS 比 DVCS 处理得好得多，你每次都会输。

如果可以，请在开发人员数量较少的项目中慢慢使用它。教育他们；设置正确；让他们成为公司其他人的布道者。消息会传播开来，每个人都会想要这个新的神奇工具，因为“当我们一直在使用 CVS 时，为什么 Bob 的团队会得到新工具？您是否意识到我们因此而遇到的所有问题？ "