11

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

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

那么，尽管 Mercurial/Git 优于 SVN，但您何时以及为什么会在新项目中选择 SVN 而不是 Mercurial？

4

4 回答 4

11

当我被同事的普遍意见或法定管理人员强迫时。这是最有可能的情况。

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

但总的来说，我没有其他理由会为自己选择非分布式修订控制系统。我发现它们极大地限制和约束。自从我了解到什么是版本控制后，我就对它们感到失望。从纯粹的工作流程的角度来看，没有什么可以用分布式版本控制系统完成的集中式版本控制系统来完成。

于 2011-05-14T03:09:44.687 回答
10

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

也就是说，我要搬到 Mercurial。（我会考虑 Git，但 Mercurial 目前在 Windows 上要成熟得多。） Tortoise-Hg 不如 Tortoise-SVN 成熟。然而，Mercurial 和 Git 都是为合并而构建的。而且，这是版本控制系统的根本问题。

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

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

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

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

如果你耦合到其他工具，只需检查它与 Subversion 和 Mercurial 的接口。如果一切都是平等的，那就去 Mercurial。否则，Subversion 不会出错（我们专门使用 Subversion，因为 Trac 的支持），并且在此基础上使用 Mercurial 很好（我们这样做）。

最后，在您如何提出问题的背景下：

那么，尽管 Mercurial/Git 优于 SVN，但您何时以及为什么会在新项目中选择 SVN 而不是 Mercurial？

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

  1. 与其他工具（如 Trac）的集成更加成熟，我们使用其他工具；
  2. 实用程序接口（如 Tortoise-Svn）明显比 Mercurial 前端（如 Tortoise-Hg）成熟；
  3. Subversion 在概念上是一个非常简单的模型（例如，single-version-snapshot），而集中存储库是人们历史上对版本控制的看法（分布式 Git/Mercurial 模型需要不同的想法）
  4. 我们有一个可靠的流程来计划“主干”和“分支”，并且不需要重要的工具支持来帮助那些痛苦的跨分支合并。
于 2011-05-14T02:45:52.323 回答
2

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

另一个原因是很棒的系统管理员支持。就 SVN 而言，这些工具已经得到了很好的开发和成熟。Git 和 Hg 都还没有赶上。

您也可以在这里查看我的答案：哪个版本控制最适合我？

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

于 2011-05-14T03:19:59.767 回答
0

当 Mercurial 的优势不是优势时，您将使用或应用于您的情况。

于 2011-05-14T02:15:42.403 回答