何时以及为什么选择集中式（SVN）而非分布式（Git，Mercurial）

Question

最近在我的新工作中，我的部门（我们主要建立股票和赛马网站，我们只在办公室的网站上工作。）正在考虑使用SVN或Mercurial。我们的项目经理说他喜欢SVN（没有告诉我们他的理由）但是我们也可以选择Mercurial并询问我们的意见（最终决定仍然在于他）

鉴于大多数在线文章都是为了解释为什么选择Mercurial而不是SVN（或类似的东西）。我想反过来问。

那么，尽管Mercurial / Git相对于SVN有很多优势，你何时以及为什么在新项目中选择SVN而不是Mercurial？

Answer 1

当我被同事的流行观点或法令管理强迫时。这是最有可能出现的情况。

在某些特定情况下我会选择Subversion或Perforce而不是Mercurial。这些与非常具体的功能有关。例如，在某些情况下，将随机子目录作为存储库本身处理的能力可能很有用。 Perforce在结账时重新安排目录结构的能力也很有用。 Perforce在处理游戏开发和其他类型媒体工作中使用的大型二进制对象方面也做得非常出色，Mercurial和Git目前都不擅长这些事情。

但总的来说，没有其他原因我会为自己选择非分布式版本控制系统。我发现它们极大地限制和约束。自从我学会了版本控制以来，我一直对它们感到失望。从纯工作流的角度来看，没有任何东西可以通过集中式修订控制系统来实现，而这种系统无法通过分布式修订控制系统来实现。

Answer 2

Subversion是一个非常好的集中版本控制系统。它是成熟的，并得到其他工具如Trac的良好支持。它的“每个快照一个版本”非常出色，“分支”只是一个“轻量级”。实际上，在遗留版本控制具有更多“脆弱”语义（如版本号 - 每个文件和它们自己的特性）的上下文中，Subversion非常出色。 （我已经用了很多年了。）

那就是说，我要转向Mercurial。 （我会考虑Git，但Mercurial目前在Windows上要成熟得多。）Tortoise-Hg并不像Tortoise-SVN那样成熟。但是，Mercurial和Git都是合并的。而且，这是版本控制系统的基本问题。

使用Mercurial，每个存储库都拥有一切。合并很简单。存储库本身就是一个“沙箱”，因此您不需要具有“主干”和“分支”的“透视”，并进行其他预分支规划。简而言之，分布式存储库是开发人员团队的工作方式，即使开发人员集中在一个命令结构中（滚动到“最终批准的Trunk”分支）。

总结：Subversion是一个很棒的模型，但非常集中。它成熟，具有成熟的工具，并与其他工具（如Trac）成熟集成。 Mercurial（和Git）是更好的模型，但提供与Subversion相同的“每个存储库的单一版本 - 快照”。工具（如Tortoise-Hg）不太成熟（与Trac的集成工作更多），使用Mercurial（例如，同步的分布式存储库）时你会有些不同，这提供了一些优势，但你应该真的以不同的方式思考问题（比你对Subversion做的那样）。

我每天都使用它们。他们都很棒。当我们以更成熟的方式获得Mercurial与Trac的集成时，我会完全转向Mercurial。 （不太成熟的Tortoise-Hg不如Tortoise-Svn好，但我可以忍受它。）

完全迁移到Mercurial可能需要一段时间（比如一年或两年，因为Trac提供了更好的原生Mercurial集成）。 Mercurial和Subversion之间的导入/导出并不可怕。我们在现有代码库中使用两者：Central“trunk”是Subversion，本地更改在Mercurial中，最终签入回Subversion。它有效。

如果您使用其他工具，只需检查其与Subversion和Mercurial的界面。如果一切都是平等的，那就去Mercurial吧。否则，Subversion就不会出错（我们特别是因为Trac的支持而使用Subversion），并且可以使用Mercurial（我们这样做）。

最后，在你如何构思问题的背景下：

  

那么何时以及为什么选择SVN   虽然在一个新项目中超过Mercurial   Mercurial / Git的诸多优点   在SVN？

我选择Svn而不是Mercurial，因为：

1. 与其他工具集成（如 Trac）更成熟，我们使用 那些其他工具;
2. 实用程序界面（如 Tortoise-Svn）明显更多 比Mercurial前端成熟 （如Tortoise-Hg）;
3. 颠覆在概念上是非常的 简单模型（例如， 单版快照）和 集中存储库是人们如何 历史上考虑版本 控制（不同的想法是 分发的必需品 Git / Mercurial模型）
4. 我们有一个可靠的计划过程 “主干”和“分支”，而不是 需要大量的工具支持 帮助那些痛苦的人 合并-跨分支。

Answer 3

一个词：TortoiseSVN。对我来说，TortoiseSVN是任何VCS的所有GUI客户端的标准。尽管SVN在DVCS方面存在缺陷，但TortoiseSVN使得使用SVN变得轻而易举。 TortoiseGit相当不错，可以模拟TortoiseSVN，但是TortoiseHg并不是那么好。

另一个原因是令人敬畏的系统管理员支持。在SVN方面，这些工具已经发展成熟并且已经成熟。 Git和Hg都还没有赶上。

您也可以在此处查看我的答案：which version control is best suited for me?

这也是一个非常相似的问题：https://stackoverflow.com/questions/2693045/mercurial-vs-subversion

Answer 4

如果Mercurial的优势不是优势，您将使用或适用于您的情况。