Mercurial 与 Subversion。谁的表现更好？
一般而言，有很多关于 SVN 与 Hg 的文章。 我想只关注性能。
有实际经验者优先。
这是我的设置：（
未来设置）带有 IIS fro Hg 的 Windows
（当前设置）Windows 下 apache 上的 SVN 1.3.2
我希望获得大多数常见操作的统计（提交、统计数据、本地/远程拉取、推送等...）。我不太确定汞最常见的操作是什么。
性能并不是对我们唯一重要的事情，但它非常重要，可能是转向汞的关键决策点。
不过，我想看一些统计数据。克隆 5 GB 的存储库需要多少日志？或类似的东西。
There are a lot of articles about SVN vs. Hg in general.
I would like to concentrate only on performance.
Real-live experiences preferred.
Here is my set-up:
(future setup) Windows with IIS fro Hg
(current setup) SVN 1.3.2 on top of apache under windows
I would like to have statistics for most commons operations (commits, stats, local/remote pulls, pushes, etc...). I am not really sure what are the most common operations for Hg.
Performance is NOT the only thing that matters to us but it is highly import and may be the crucial decision point in switching to Hg.
However, I would like to see some statistics. How log did it take to clone repo of 5 gb? or something like that.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
首先，也许升级你的 Subversion？
我认为选择与更自然的工作流程不匹配的生产力成本将使任何性能差异相形见绌。
假设 Subversion 在各方面都优于 Mercurial。伟大的！如果您和同事使用存储库的方式更适合 Mercurial，那么您就变得在性能方面和生产力方面变得愚蠢了。
除非你控制的东西真的很大，否则你可能不会注意到差异。选择一款能够根据您期望的使用方式提供最佳功能的选项。
First, maybe upgrade your Subversion?
I think the productivity cost of choosing the one that doesn't match the more natural workflow would dwarf any performance differences.
Let's say that Subversion outperforms Mercurial in every way. Great! If the way that you and co-workers use your repository would be better suited to Mercurial, you've become performance-wise and productivity-foolish.
Unless what you're controlling is really huge, you probably won't notice the differences. Choose the one that offers the best capabilities for how you expect to use it.
这取决于很多因素（不，合并不是最常见的操作 - 提交是，将更改放入事物中是其中最重要的部分，即使 DVCS 系统确实花费所有时间进行上下游合并） 。
所以，首先你需要升级你的SVN。这很简单，一旦您在存储库上运行“svnadmin pack”，您就可以正确进行比较。 1.3.2 很古老！ （当前版本是 1.6.11）
其次，您需要确定推送和拉取大型存储库对您是否重要。例如，我有一个 12 Gig 的存储库需要管理。幸运的是，svn 允许我们只获取其中的一部分，而不是全部，因此它的管理得到了很大的改善。
此外，v1.7 中还有显着的性能改进（哦，这么快就准备好了），因为性能并不是 SVN 人员的首要任务，他们实际上是在添加功能并确保坚如磐石的稳定性。现在，性能是一个问题并且正在得到解决。查看开发者邮件列表即可了解。可能值得您稍等一下（或使用您的存储库副本对其进行评估）。
您会看到，性能很可能与您的系统相同。它可能会在 IO 上出现瓶颈，这也是 svn 通常会失败的地方（我认为开发者邮件列表确实有一些性能数据，来自一个拥有 raid-0 SSD、24 Gb RAM 的怪物服务器的小伙子，奇怪的是它在 CPU 上遇到了瓶颈！
）总之，您必须弄清楚您的工作流程和流程。如果 Mercurial（这是一个不错的选择）为您提供了这一点，那就太好了，那就去吧。但如果没有，那么无论迁移速度有多快，都对您没有帮助。
It depends on so many factors (and no, merging isn't the most common operation - commit is, putting your changes into the thing is the single most important part of it even if DVCS systems do spend all their time merging up and downstream).
So, firstly you need to upgrade your SVN. That's easy, and once you've run 'svnadmin pack' on your repo you'll be able to compare properly. 1.3.2 is ancient! (current version is 1.6.11)
Second, you need to decide whether pushing and pulling large repositories about is important to you. For example, I have a 12 Gig repo to manage. Fortunately, svn allows us to only fetch parts of that, not the whole thing, so management of it is much improved.
Also, there are significant performance improvements coming in v1.7 (ready oh so soon), as performance hasn't been a priority for the SVN guys, they're really been adding features and ensuring rock-solid stability instead. Now, performance is an issue and is being addressed. Take a look on the dev mailing list to see. It might be worth your while to wait a little (or evaluate it using a copy of your repo).
You see, performance may well be the same with your system. It could be bottlenecked on IO which is where svn usually fails (thought the dev mailing list does have some perf figures from a chap with a monster server with raid-0 SSDs, 24 Gb RAM and strangely enough it's bottlenecked on CPU!)
So all in all, you have to figure out your workflow and processes. If Mercurial (which is a good choice) provides that for you, then great, go for it. But if it doesn't, then migrating isn't going to help you no matter how much faster it might be.
（不完全是一个答案，但它仍然可以为您的问题提供有用的上下文：）
如 DVCS 工具，VCS（尤其是分布式 VCS）中最常见的操作是：合并。
而且，无论您的设置是什么，使用 Mercurial 总是比 SVN 更容易、更快捷。请参阅：
(Not exactly an answer, but still it can provide a useful context to your question:)
As mentioned in DVCS tools, the most common operation in a VCS, especially a distributed one, is: merge.
And that, whatever your setup is, will always be easier and quicker to do with Mercurial than SVN. See:
iirc svn 通常在最初获取远程存储库时速度更快，因为它不需要拉取历史记录。之后 hg 通常会更快，因为它将更多地使用本地数据并且具有更紧凑的数据库，因此像远程操作一样更快。
目前我只能找到这个作为任何形式的直接比较。它有一些缺陷，因为用图像文件填充这些 VCS 并不是它们真正的用途。
如果您真的想要良好的统计数据，那么为什么不使用自己的存储库来测试自己呢？
iirc svn is generally quicker for initially getting a remote repo as it doesn't need to pull the history. after that hg is generally quicker as it will use local data much more and has a more compact DB so like for like remote operations are quicker.
at the moment I can only find this as any sort of direct comparison. it is somewhat flawed in that filling any of those VCS with image files is not really what they are for.
if you really want good stats then why not test yourself with your own repo?