我们仍然使用CVS，我使用git和hg作为个人用途，虽然我仍然是两者的新手，但我意识到它们更现代，更好，更快，分布等。
只是每个人都习惯于CVS，如果我成为推荐并实际将我们当前的CVS服务器升级/移植/转换为git或hg的人，我觉得可能出现一大堆问题。
最近有人真的这么做过吗？您是否可以提供有关影响人们使用git / hg的任何见解或提示，以及实际更新/转换的一般提示（如果要进行的话）？一般来说我是否应该注意常见的问题？
答案 0 :(得分：4)
我刚刚遇到过这个问题，而且我已经在某个地方尝试过这种转变。它不起作用。
我不是说这会劝阻任何人，而是强调人们可能遇到的问题。
问题很多，但基本上都归结为人们没有看到CVS的问题。我知道这很棒，但它已经存在了很长时间。他们已经习惯了这些特质，现在对它引起的问题视而不见。带来新的东西，他们无法理解为什么需要以不同的方式完成事情。
最大的一个是原子提交的概念。人们无法理解修订现在是整个项目树的状态，而不是文件的状态。因此，在file A中有未完成的更改时检查file B中的更改突然变成了对版本控制系统进行咆哮的平台。
当你遇到这个级别的绊脚石时，你可能会忘记尝试引入“高级”概念，例如比想要发布代码或在用户之间共享更改时更频繁地提交。
死亡打击事实是他们采取了一个庞大的项目，有数百名开发人员和大约70个子项目，并将其放在一个集中的存储库中。这意味着这个中央仓库每天要提交1-2百次。每个人都总是推动每一次提交（因为cvs commit == commit; push对吗？）。它还提供了大量自动构建和测试报告。把它们放在一起，它就到了你无法重新pull;merge;(no testing);push的阶段，因为你已经过时了。pull;merge。当你在等待那个大拉力完成时，有人推了一些东西。
...因为人们没有测试他们的合并，所以发生了破坏。
哦，有一个人合并了10个分支，因为他知道他必须合并，但他不明白要合并什么或为什么。
结果......他们买了Perforce。
原因：它附带了一份支持合同，所以有人在出错时[责怪/修理]。
所以：
如果可以，请在少数开发人员的项目中放慢速度。教育他们;设置正确;让他们成为公司其他成员的福音传道者。 Word会传播，每个人都会想要这个新的wunder工具，因为“为什么Bob的团队在我们被CVS工作时会得到新的工具？你是否意识到我们遇到的所有问题？ “
答案 1 :(得分：2)
也许这个StackOverflow问题（及其答案）会有所帮助：
答案 2 :(得分：1)
不确定您是否正在寻找有关迁移的一般指南或完全比较两种服务，但这里是former。
修改
由于提到了SVN，here是一个很好的指南，我在一些SVN中用于Git迁移。
修改
我遇到了这个很棒的网站Why Git is Better than X，我想我会把它添加到这个答案中给其他想要转换到Git进行版本控制的人。
答案 3 :(得分：0)
此刻我正在经历这个问题，所以我要加2美分（游戏后期）。
我负责将我们的团队从CVS带到Subversion，Mercurial或Git。您的团队的专业知识，项目和发布方法可能会改变您给出的答案。为了披露，我的团队致力于一系列较小的Java项目，并使用Netbeans IDE和Maven开发和发布软件。
颠覆
是的，对不起，这有点偏离主题，但它仍然是CVS的明确升级。它将导致原子项目提交，广泛的现有用户群和一些良好的社区tools。这可能是最简单的过渡，只需要最少的培训，但你肯定没有DVCS的强大功能。我推荐使用cvs2svn工具。
<强>水银
Mercurial拥有出色的文档，即使对于一些奇怪的用例也是如此。启动存储库很容易。易于安装（只需使用Python，安装工具和'easy_install mercurial'）。易于转换，而且讨厌命令行的开发人员可以开箱即用获得伟大的TortoiseHg工具。
我发现cvs2hg工具在转换方面比内置的'hg convert'扩展更准确，但是ymmv。
为了教导每个人，请尝试Joel的网站：HgInit。有大量的书籍和在线教程，但让每个人习惯推拉（以及它与你的发布过程有什么关系）将是最疯狂的部分。我个人认为DVCS的这种推/拉模型更可取，但其他人可能不同意。这实际上就像强迫每个人分支他们正在处理的每一件作品。
在决定是使用subrepo's还是仅将整个内容整合到一个大型存储库时，请选择单个存储库。处理多个subrepo被证明对于只有一个具有混合历史的存储库来说有点痛苦。 （您的项目列表及其交互方式将极大地影响此决策）您的IDE和GUI工具将有助于克服一些奇怪的问题。转换后通过每个分支，知道会发生什么。交换到分支不再意味着您将获得一些更改的文件。这意味着所有未分支的东西都不存在。
<强> GIT中
我真的很惊讶我有多喜欢这个工具。我们的IDE集成更好，工具比hg更快（根据我的经验），并且更容易设置像ssh存储库这样的东西。
安装，转换和设置是一个熊。最后，我认为这部分比所需的努力更有价值。根据{{3}}问题，'git cvsimport'工具在较大的CVS项目中被打破。此外，我的首选转换工具：this非常需要帮助改进Git功能。在我找到所有blob / dump-file-then-import-to-bare-git-repo业务之后，我发现忘记从CVS中取出所有分支。也许我从来没有充分理解这些工具，但从CVS到Git最安全的方式似乎是通过SVN。
此外，还有很多针对DVCS的好参数，例如每个开发人员都在使用整个存储库的问题。如果你曾经把一些不好的jojo推上去并且它被拉了，那将是一个巨大的痛苦去除它。
要托管http repostiory，请查看cvs2svn和scm-manager。 RhodeCode更难设置，但功能更多。这两种工具都很难与subrepos一起使用，所以要做好准备。
至于说服你的老板。我是通过创造“CVS手术”一词来实现的。就像其他任何事情一样，跟踪您通过CVS浪费的所有时间并修复提交/回滚错误。然后将您的案例呈现为“如果我们只是转换为此工具，您现在可以免费获得X小时的时间”。我发现回滚到CVS中的无标记提交，文件级提交，以及查找CVS最大问题中发生了哪些分支更改的困难。