Mercurial vs Subversion. Whose performance is better?_问答_开发者

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 su开发者_开发百科re 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.

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.

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.

(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:

"What makes merging in DVCS easy?"
"SVN merges and DVCS"
"Why is branching and merging easier in Mercurial than in Subversion?"
"What makes some version control systems better at merging?"
"Merging: hg/git vs. svn"

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?