svn - 你会从 cvs 迁移到 svn 还是直接迁移到 git 或 hg？

Question

我不知道这个论坛是否合适。

我的公司使用 CVS 作为版本控制系统。我们计划转向更现代的版本控制系统。作为风险最小的解决方案，您会推荐什么？

我的想法是使用 Subversion，但我也听到了很多关于 Git 和 Mercurial 的好消息

但是，我们是一家小公司，不需要分布式版本控制系统。除了分布式之外，Git 或 Mercurial 相对于 Subversion 还有什么优势？

Answer 1

我们大约 2 周前在我的工作中从 CVS 迁移到 Mercurial。我们是一个6人的小团队。在迁移之前，我们中只有两个人已经使用过 CVS 以外的东西。

我负责新 CVS 的选择。我考虑了 Git 和 Mercurial。

我们对 CVS 的一些不满是分支可能性很差、不支持重命名、非常糟糕的冲突算法。

我从未考虑过 SVN，因为过去每次我尝试将它与分支一起使用时， merge 总是令人头疼。坦率地说，现在所有的炒作都是为了 dvc，这一定是有原因的；)

在 Git 和 Mercurial 之间，更多的是个人选择。我爱上了 Mercurial，因为我发现它比 Git 更容易学习，而且不太以“真正的大项目”为导向。

Git/Mercurial 相对于 SVN 的优势

1. 更好的分支和 merge 能力(真的是最重要的原因)
2. 可以通过电子邮件等捆绑导出/导入补丁
3. 没有对此进行广泛的测试，但我认为在很多方面两者都比 SVN 更快( merge 、克隆、比较等)
4. 开发更加活跃，我听说 SVN 团队正在努力向前推进，但仍然如此。
5. 非常好的扩展基础架构
6. 提供了网络服务器功能，例如对于快速共享某些内容非常有用。

即使您说“除了它们是分布式的”，我认为这确实是一个 killer 级功能。 DVCS 允许一些非常巧妙的东西，一开始它可能看起来没什么用，但是一旦你用过它们，你就离不开它们;)

学习曲线

团队中有两个人对这一变化并不满意。但是通过一些幻灯片向整个团队解释了两个小时，一切都进行得很顺利。

当然，他们有时会问我问题，但自迁移以来我们没有遇到任何真正的问题。关于在工作目录中 merge pull 更改的方式的一些小误解。几分钟内解决不了任何问题。

我想我可以说，在短短 2 周左右的时间里，每个人的工作效率至少都和以前一样，并且对新工具充满信心。现在我们可以使用特性分支而不用担心 merge 的到来:)

将 CVS 迁移到 mercurial

https://www.mercurial-scm.org/wiki/RepositoryConversion#CVS

关于从 CVS 迁移到 Mercurial 的官方 wiki 列出了不同的方法。我测试了 Convert 扩展和最终使用的 cvs2hg。

来自 CVS 的 Tailor 扩展 hg-cvs-import 似乎是旧代码，不再维护。

Convert 扩展在一个简单的存储库上工作得很好，但由于我们的 CVS 存储库非常大并且有一些非常奇怪的分支，该扩展无法正确导入所有历史记录。 HEAD 是正确的，但缺少一些分支。

所以，最后的选择是cvs2hg .事实上，它是 cvs2svn 的新后端，它转换为 Mercurial 而不是 Subersion。

自述文件中介绍的“快速启动”方法适用于所有分支。但最后我使用选项文件添加了一些用户映射并修剪了一些错误的提交或不需要的分支。

随文件提供的选项文件有很好的注释，您可以轻松配置它以适合您。

有关信息，在初始转换之后，我使用 Convert 扩展将一些子项目从生成的 Mercurial 存储库提取到另一个 Mercurial 存储库，如解释的那样 here .