我刚刚遇到这个问题，并且我曾在尝试实现这种转变的地方工作过。它不起作用。
我这么说并不是为了阻止任何人，而是为了强调人们可能遇到的问题。
问题很多，但基本上都归结为人们没有看到 CVS 的问题。我知道这很神奇，但它已经存在这么久了。他们已经习惯了这些特质，现在却对它给他们带来的问题视而不见。引入一些新的东西，他们无法理解为什么事情需要以不同的方式完成。
其中最大的问题之一是原子提交的概念。人们无法忽视这样一个事实：修订现在是整个项目树的状态，而不是文件的状态。所以检查更改file A虽然还有未完成的改变file B突然变成了一个抱怨版本控制系统的平台。
- 哇啊啊啊！为什么我必须检查all文件在?
- 哇啊啊啊！为什么我还没有收到刚刚拉出的更改？
- 哇啊啊啊！我必须合并是什么意思？为什么我总是要合并？
- 哇啊啊啊！为什么不能只使用正常的修订号？
当您在该级别上遇到困难时，您可能会忘记尝试引入“高级”概念，例如比发布代码时更频繁地提交，或者在用户之间共享更改。
致命一击是，他们将一个拥有数百名开发人员和大约 70 个子项目的庞大项目放在一个集中存储库中。这意味着这个中央存储库每天会收到 1-200 次提交。每个人总是推动每一个承诺（因为cvs commit == commit; push正确的？）。它还提交了大量的自动化构建和测试报告。把所有这些放在一起，就到了你无法做到的阶段pull;merge;(no testing);push无需重新pull;merge因为你已经过时了。当你等待那个巨大的拉力完成时，有人推动了一些东西。
...并且因为人们没有测试他们的合并，所以发生了破坏。
哦，还有一个人将大约 10 个分支合并在一起，因为他知道必须合并，但他不明白要合并什么或为什么。
结果......他们买了Perforce。
原因：它带有支持合同，因此当出现问题时有人可以[责备/修复]。
So:
- 让人们了解 CVS 给他们带来的问题。通常情况下，这是因为在没有标记的情况下无法识别哪些版本的文件可以一起工作，这需要每个人都停止工作。我相信你能找到更多。
- 教育人们为何 DVCS 如此运作。向他们展示力量意味着他们可以做什么。让他们想要它。
- 确保他们知道不该做什么！
- 不要只是改变系统并让每个人在工作中学习。这只会引起怨恨，而他们所做的只是尝试做旧系统上有效的事情。这并不漂亮。
- 不要将每个项目放入一个存储库中。集中式 VCS 比 DVCS 处理得更好，但你每次都会失败。
如果可以的话，在开发人员数量较少的项目中慢慢地进行。教育他们；设置正确；让他们成为公司其他人的布道者。消息将会传播开来，每个人都会想要这个新的神奇工具，因为“当我们一直在使用 CVS 时，为什么 Bob 的团队会获得新工具呢？您是否意识到我们因此而遇到的所有问题？"
