I think I have a better idea of what is taking so long. I did a strace
against my svn command and watched it as it was running. The vast
majority of the time is spent opening .svn/prop-base files in an image
subdirectory. There are thousands of images in that directory. Is
there anyway to tell svn to ignore properties on those images and if I
do am I going to regret it?
From: Kelly Sauke [mailto:Kelly.Sauke_at_kaplan.com]
Sent: Monday, June 15, 2009 12:52 PM
To: Stefan Sperling
Subject: RE: Merge Performance Issues
We typically do not have any subtree merges. All merging is done at the
root of the trunk/branch. I'm running a few tests right now to try and
pinpoint more exactly where the slowdown is happening. The one thing I
noticed this morning is that the database never had 'svnadmin upgrade'
run on it so the mergeinfo properties were not being populated. I've
copied the repo and upgraded the copy. I'm now attempting to see if the
merges will be any faster. My first attempt at a merge took 25 minutes,
however there wasn't any prior mergeinfo, I'm hoping my next attempt
with the -reintegrate flag will speed it up.
I'll follow up with what I find. Thanks for the help so far.
From: Stefan Sperling [mailto:stsp_at_elego.de]
Sent: Monday, June 15, 2009 9:31 AM
To: Kelly Sauke
Subject: Re: Merge Performance Issues
On Mon, Jun 15, 2009 at 08:40:03AM -0500, Kelly Sauke wrote:
> I'm attempting to speed up our merge processes (svn merge) and seem to
> be failing miserably. On our production repo it takes about 20
> to complete a merge of one file from a branch into the trunk. I've
> taken that repo and copied it to a different machine where I've tried
> two different versions of the 1.5 series and now I'm running 1.6.2.
> Still slow. If I go back to 1.4 its nice and speedy. I've even gone
> far as exporting the repo and reloading it into a new repo with no
> history and that merge is now at about 10 minutes. What else can I do
> to help speed up this process? I've read about the new merge
> logic in the 1.5 series, is this on be default?
It is on by default. You can tell Subversion not to track merge
by passing --ignore-ancestry to the svn merge command.
I would not recommend this, though.
> The exported trunk has 111k files and is about 1.5G.
What you are seeing are most likely known issues with the performance
of merge-tracking. These are being worked on. For more information,
see the files here:
For now, your best bet is to follow best practices when doing
merges, as outlined in e.g. these blog posts:
and in this chapter of the book:
If you don't end up creating lots of subtree mergeinfo (see above links
for explanations of what this means), then performance should be
at least acceptable. But don't expect Subversion to perform as
fast as e.g. git when doing merges. It cannot, and will never be able
See also http://svn.haxx.se/users/archive-2009-06/0372.shtml
and follow-up posts to that thread for details.
Also make sure you are running at least Subversion 1.5.6.
If you can, update to 1.6.3 once it is available, it will
probably be released next week.
Versions prior to 1.5.5 or so have known problems which ended
up creating a lot of unnecessary subtree mergeinfo. And 1.6.3
will fix another bug causing spurious subtree mergeinfo to be created.
If you have no subtree mergeinfo at all in your repository,
the bottleneck is somewhere else and you'll need to provide
more information than a mere "it is slow", so we can pin-point
the exact problem.
> What I don't get is I can run 'svn diff ...| patch ...' and it will
> finish in seconds.
Because that is not at all the same as what 'svn merge' is doing.
Again, see the above links for more information.
To unsubscribe from this discussion, e-mail:
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-06-15 23:01:01 CEST