有关将CVS升​​级到git / hg的提示？

Question

我们仍然使用CVS，虽然我还是这两个的新手，但我还是使用git和hg作为个人用途，但是我意识到它们更加现代，更好，更快，更分布式等。

只是每个人都非常习惯CVS，如果我成为推荐的人并且实际上是将当前CVS服务器升级/移植/转换为git或hg，我会感到很多问题。

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

Answer 1

我刚刚遇到了这个问题，并且在某个地方进行了尝试以实现这种过渡。 它没用。

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

问题很多，但基本上都归结为人们看不到CVS的问题。 我知道这太神奇了，但它已经存在了这么长时间。 他们已经习惯了特质，现在对造成它们的问题视而不见。 带来新的东西，他们不明白为什么需要以不同的方式来完成事情。

最大的问题之一是原子提交的概念。 人们无法回避这样一个事实，即修订现在是整个项目树的状态，而不是文件的状态。 因此，在file B有未完成的更改的情况下签入file A更改突然变成了反对版本控制系统的平台。

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

当您在该级别上绊脚石时，您可能会忘记尝试引入“高级”概念，例如比想要发布代码时更频繁地提交或在用户之间共享更改。

致命的打击是，他们采取了一个庞大的项目，有数百名开发人员和大约70个子项目，并将其放在一个集中的存储库中。 这意味着该中央存储库每天可获得1-2百次提交。 每个人都总是向它推送每个提交（因为cvs commit == commit; push向右cvs commit == commit; push ？）。 它还拥有提交的大型自动化构建和测试报告。 将所有内容放在一起，就到了无法进行pull;merge;(no testing);push无法pull;merge;(no testing);push无需重新pull;merge即可进行pull;merge;(no testing);push pull;merge由于您已过时而pull;merge;(no testing);push pull;merge 。 在您等待大拉力完成时，有人推了东西。

...而且由于人们没有测试他们的合并，所以发生了损坏。

• Waaaaaaa！ 该死的东西合并错了！

哦，一个人将大约10个分支合并在一起，因为他知道必须合并，但是他不知道合并的内容或原因。

结果……他们购买了Perforce。

原因：它附带了一份支持合同，所以当出现问题时，应该有人[责备/解决]。

所以：

• 向人们介绍CVS造成的问题。 通常，原因是无法识别哪些版本的文件可以一起工作而不加标签，这需要所有人停止工作。 我相信您可以找到更多。
• 教育人们DVCS如何以他们的方式工作。 向他们展示力量意味着他们可以做什么。 让他们想要它。
• 确保他们知道该怎么办！
• 不要只是改变系统并使每个人在工作中学习。 它只会引起怨恨，而他们所做的只是尝试做旧系统上的工作。 不好看
• 不要将每个项目都放在一个仓库中。 集中式VCS比DVCS更好地处理它，您每次都会迷路。

如果可以，请在开发人员较少的项目中缓慢进行。 教育他们； 正确设置； 让他们成为公司其他部门的福音传教士。 消息将传播开来，每个人都将需要这个新的奇特工具，因为“当我们坚持使用CVS时，鲍勃的团队为什么会得到新工具？ 您意识到我们因此而遇到的所有问题吗？ ”

Answer 2

也许这个StackOverflow问题（及其答案）会有所帮助：

• GIT和CVS之间的区别

Answer 3

不确定是要寻找有关迁移的一般指南还是要全面了解这两种服务，但是这里是前者 。

编辑

自从这里提到SVN以来，我已经在一些SVN到Git的迁移中使用了很好的指南。

编辑

我遇到了一个很棒的网站， 为什么Git比X更好 ，我想把它添加到这个答案中，以供其他人考虑使用Git进行版本控制。

Answer 4

我现在正在经历这个，所以我要加上我的2美分（游戏后期）。

我负责带领我们的团队脱离CVS，转而使用Subversion，Mercurial或Git。 您团队的专业知识，项目和发布方法可能会改变您给出的答案。 为了公开起见，我的团队致力于一系列较小的Java项目，并使用Netbeans IDE和Maven开发和发布软件。

颠覆

是的，很抱歉，这有点偏离主题，但它仍然是CVS的明确升级。 这将导致原子项目提交，广泛的现有用户群以及一些良好的社区工具 。 这可能是最简单的过渡，只需最少的培训，但您绝对不具备DVCS的功能。 我建议使用cvs2svn工具。

水银

即使对于某些怪异的用例，Mercurial的文档也很丰富。 扩展存储库很容易。 易于安装（只需使用Python，设置工具和'easy_install mercurial'）。 易于转换，讨厌命令行的开发人员可以立即使用出色的TortoiseHg工具。

我发现cvs2hg工具的转换比内置的'hg convert'扩展要精确得多，但是比ymmv更准确。

要教大家汞，请尝试Joel的网站： HgInit 。 有很多书籍和在线教程，但是让每个人都习惯推和拉（以及它与发布过程的关系）将是最疯狂的部分。 我个人认为DVCS的推/拉模型更可取，但其他人可能会不同意。 实际上，这就像迫使每个人都在分支他们正在处理的每个部分。

在决定是使用subrepo还是将整个事物划分为一个大存储库时，请选择单个存储库。 事实证明，与仅拥有一个具有相互混合的历史记录的存储库相比，处理多个subrepo有点麻烦。 （您的项目列表以及它们之间的交互方式将极大地影响这一决定。）您的IDE和GUI工具将有助于克服其中的一些怪异之处。 转换后，遍历每个分支并知道将会发生什么。 交换到分支不再意味着您将获得一些更改的文件。 这意味着所有没有分支的事物都不存在。

混帐

我真的很惊讶我对这个工具的喜爱。 根据我的经验，我们的IDE的集成度更好，该工具比hg更快，并且更容易设置诸如ssh存储库之类的东西。

安装，转换和设置非常麻烦。 最后，我认为这部分的价值超出了所需的精力。 根据这个问题，在较大的CVS项目中，'git cvsimport'工具被破坏了。 另外，我的首选转换工具： cvs2svn非常需要帮助来改善Git功能。 在弄清所有blob / dump-file-then-import-bare-git-repo业务之后，我发现它忘记了从CVS提取我的所有分支。 也许我只是对工具没有足够的了解，但是从CVS到Git的最安全方法似乎是通过SVN。

此外，还有很多反对DVCS的良好论据，例如，每个开发人员都要走遍整个存储库的问题。 如果您向上推一些不好的jojo并将其拉扯，将其移除将是巨大的痛苦。

---

要托管http邮局，请查看scm-manager和RhodeCode 。 RhodeCode较难设置，但功能更多。 这两个工具很难与subrepos一起使用，因此请为此做好准备。

至于说服你的老板。 我通过创造“ CVS-手术”一词来做到这一点。 就像其他任何事情一样，请始终跟踪您在浪费时间通过CVS并修复提交/回滚错误的所有时间。 然后将您的案例显示为“如果我们仅转换为此工具，您现在将有X个小时的空闲时间”。 我发现回滚到CVS中未加标签的提交，文件级提交，以及在CVS的最大问题中难以发现发生什么分支更改的困难。