Mercurial 与颠覆。谁的表现更好？答案

【问题标题】：Mercurial vs Subversion. Whose performance is better?Mercurial 与颠覆。谁的表现更好？
【发布时间】：2010-05-17 16:49:27
【问题描述】：

一般有很多关于 SVN 与 Hg 的文章。我想仅专注于性能。

最好有现场体验。

这是我的设置：

（未来设置）带有 IIS 的 Hg 的 Windows

（当前设置）Windows 下 apache 之上的 SVN 1.3.2

我想为大多数公共操作（提交、统计、本地/远程拉取、推送等...）提供统计数据。我不太确定 Hg 最常见的操作是什么。

性能对我们来说并不是唯一重要的事情，但它非常重要，并且可能是切换到 Hg 的关键决策点。

不过，我想看看一些统计数据。克隆 5 GB 的 repo 需要多少日志？或类似的东西。

【问题讨论】：

一方面，它们甚至不是同一类型的应用程序。 Mercurial 是一个 DVCS。基于性能原因选择 SVN 或 Mercurial 中的一个是完全疯狂的。
还要注意SVN服务器的类型会影响速度。 Apache 版本使用 WebDAV，它可能很慢。特别是，使用 svnserve 进行合并通常更快。
我想我没有提到这一点。这里有一些更多信息：我们目前使用 svn，并且我们有需要运行比较的鬃毛。最常见操作的性能就是其中之一
基本上，如果我们切换到 Hg 合并会更容易并且会为我们节省大量时间，但是日常提交或推送呢？想想日常的开发人员工作流程。性能很重要。
它仍然完全不同。在 SVN 中，每个提交都必须通过线路连接到服务器。在像 Mercurial 这样的 DVCS 中，每个提交都是本地的，所以它只是 CPU 绑定的。不过，归根结底，Mercurial 可以一次将所有这些更改（本地提交）推送到服务器，而服务器实际上并没有 SVN 等价物。

【解决方案1】：

首先，也许升级您的 Subversion？

我认为选择与更自然的工作流程不匹配的生产力成本将使任何性能差异相形见绌。

假设 Subversion 在各个方面都优于 Mercurial。伟大的！如果您和同事使用您的存储库的方式更适合 Mercurial，那么您就变得注重性能和生产力了。

除非你控制的东西真的很大，否则你可能不会注意到差异。根据您的预期使用方式，选择一种能够提供最佳功能的。

【讨论】：

【解决方案2】：

这取决于很多因素（不，合并不是最常见的操作 - 提交是，将您的更改放入事物中是其中最重要的部分，即使 DVCS 系统确实花费了所有时间进行合并和下游）。

所以，首先你需要升级你的 SVN。这很容易，一旦你在你的 repo 上运行了“svnadmin pack”，你就可以正确地进行比较。 1.3.2太古了！（当前版本为 1.6.11）

其次，您需要确定推送和拉取大型存储库对您是否重要。例如，我有一个 12 Gig 的存储库要管理。幸运的是，svn 允许我们只获取其中的一部分，而不是全部，因此对它的管理得到了很大改进。

此外，v1.7 中也有显着的性能改进（很快就准备好了），因为性能并不是 SVN 开发人员的首要任务，他们实际上是在添加功能并确保坚如磐石的稳定性。现在，性能是一个问题，正在得到解决。查看开发邮件列表以查看。稍等片刻（或使用您的存储库副本评估它）可能值得您花时间。

您知道，性能可能与您的系统相同。它可能会在 IO 上遇到瓶颈，而这是 svn 通常会失败的地方（认为开发邮件列表确实有一些性能数据来自一个带有 raid-0 SSD、24 Gb RAM 的怪物服务器的小伙子，而且奇怪的是它在 CPU 上遇到了瓶颈！）

总而言之，您必须弄清楚您的工作流程和流程。如果 Mercurial（这是一个不错的选择）为您提供了这一点，那么很好，那就去吧。但如果没有，那么无论迁移速度有多快，迁移都对您没有帮助。

【讨论】：

【解决方案3】：

（不完全是答案，但它仍然可以为您的问题提供有用的背景：）

如DVCS tools 中所述，VCS，尤其是分布式 VCS 中最常见的操作是：merge。

而且，无论您的设置是什么，使用 Mercurial 总是比使用 SVN 更容易、更快捷。见：

【讨论】：

【解决方案4】：

iirc svn 通常在最初获得远程 repo 时更快，因为它不需要提取历史记录。在那之后，hg 通常会更快，因为它会更多地使用本地数据并且拥有更紧凑的数据库，因此类似远程操作会更快。

目前我只能找到this 作为任何直接比较。用图像文件填充这些 VCS 中的任何一个都不是它们真正的用途，这有点缺陷。

如果您真的想要好的统计数据，那么为什么不使用自己的 repo 测试自己呢？

【讨论】：