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

Question

我不知道这是否是正确的论坛。

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

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

但是，我们是一家小公司，我们不需要分布式版本控制系统。 Git或Mercurial在Subversion方面有什么优势，除了它们是分布式的？

Answer 1

我们大约两周前在我的工作中从CVS迁移到Mercurial。我们是一个由6人组成的小团队。在迁移之前，只有两个人已经使用了除CVS之外的其他东西。

我负责选择新的vcs。我考虑过Git和Mercurial。

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

我从未考虑过SVN，因为每次我尝试在分支中使用它时，合并总是令人头痛。坦率地说，现在所有的炒作都是针对dvcs的，并且必须有一个理由;）

在Git和Mercurial之间，它更多的是个人选择。我的心脏因Mercurial的缘故而下降，因为我发现它比Git更容易学习而且更少“非常大的项目”。

Git / Mercurial优于SVN的优势

1. 更好的分支和合并能力（真正最重要的原因）
2. 通过电子邮件等方式导出/导入补丁的可能性
3. 没有对此进行过广泛的测试，但我认为在很多方面都比SVN更快（合并，克隆，差异等）
4. 开发活动更加活跃，我听说SVN团队正在努力向前迈进，但仍然。
5. 非常好扩展基础架构
6. 提供Web服务器功能，对于快速共享某些内容非常有用。

即使你说“除了他们是分发的事实”，我认为这真的是一个杀手级的功能。 DVCS允许一些非常简洁的东西，它在开始时似乎没有用，但是一旦你使用它们，你就离不开;）

学习曲线

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

当然他们有时会问我一个问题，但自迁移以来我们没有遇到任何实际问题。关于合并工作目录中的更改方式的一些小误解。没有在几分钟内解决的事情。

我想我可以说，在短短两周内，每个人都至少和以前一样富有成效，对新工具充满信心。现在我们可以使用功能分支而不用担心合并来了：）

将CVS迁移到mercurial

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

官方维基上列出了从CVS迁移到Mercurial的不同方法。我测试了转换扩展和最终使用的cvs2hg。

Tailor扩展，hg-cvs-import，fromcvs似乎是旧代码，不再维护。

Convert扩展在一个简单的存储库上运行得很好，但由于我们的CVS存储库非常大并且有一些非常奇怪的分支，因此扩展无法正确导入所有历史记录。 HEAD是正确的，但有些分支机构丢失了。

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

自述文件中提供的“快速入门”方法与所有分支机构一起开箱即用。但最后我使用选项文件添加一些用户映射并修剪一些错误的提交或不需要的分支。

随文件提供的选项文件得到了很好的评论，您可能不难配置它，因为它适合您。

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

Answer 2

修改：很棒的链接 - http://whygitisbetterthanx.com/

=============================================== ===========

是的，事实上我们刚刚从SVN搬到了Mercurial。

除了Mercurial和GIT的分布式方面，它比SVN快很多，并且repo在ever文件夹中也没有烦人的.SVN文件夹。更不用说合并工作更好了！事实上你也可以将你的仓库存储在任何共享驱动器上（不需要在服务器上安装东西，无论如何都是Mercurial）

更多阅读

Should I use SVN or Git?

http://www.richappsconsulting.com/blog/blog-detail/svn-vs-git-who-will-be-the-future-of-revision-control/

http://thinkvitamin.com/code/why-you-should-switch-from-subversion-to-git/

http://techblog.floorplanner.com/2008/12/09/git-vs-svn-for-bosses/

最后是GIT和Mercurial

http://gitvsmercurial.com/ - 这个网站现在看起来已经死了：（

Answer 3

1. 合并代码并解决冲突 使用分布式VCS更容易 像GIT或Mercurial。原因 是GIT还是mercurial都有 的中间快照 要合并的两个“结束代码” 颠覆只会知道结局 除非每个SVN用户都是快照 在他/她自己的分公司工作。

2. 使用分布式VCS，您不是     依赖于网络来检查     代码。

3. 如果您拥有大量用户         每天检查东西到VCS         基础，你的SVN服务器更好         非常强大，可以处理并发         签入/出局。 DVCS没有这个问题。

我们从CVS切换到SVN，现在切换到Mercurial，我们对转换感到非常满意。我们在Mercurial中缺少SVN，但回到SVN会很痛苦。

Answer 4

SVN对您的工作流程可能很重要：

1. 部分结帐。
   可以只签出树的一部分（如果您的存储库中有多个项目，则很重要）

2. 混合结帐。
   结账的部分内容可以是不同的版本，直到单个文件。

3. 全球唯一修订单调增加 在SVN中很容易看出rev 1206晚于1100（c.f。，比d500c208c3c5晚了cfbb0827c67d？）

4. 许多项目可以共享相同的SVN存储库 如果你的包由几个EXE，DLL和诸如此类的东西组成， 在Hg / Git中你最终可能会使用几个存储库来管理它。 这可能会使标签/修订处理变得复杂

Answer 5

我们（诺基亚OVI地图）也正在从SVN迁移到HG。选择HG而不是git的原因是HG对用户更友好，与有时模糊的git命令相比，命令更有意义。对于Windows用户来说，mercurial工作得更好，而tortoiseHG也相当成熟。当我在Windows上测试git时，我在一些简单的操作中发现了严重的性能问题，例如检查修改......

我也非常希望您可以通过扩展程序使用您想要的功能。因此学习曲线比使用git更平滑，例如考虑缓存区域。对于来自SVN的人，我认为HG是不错的选择。

他们应该对历史更加小心，例如，我们鼓励做hg pull --rebase，以使历史记录尽可能线性并仅合并分支。