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.
-KS
-----Original Message-----
From: Stefan Sperling [mailto:stsp_at_elego.de]
Sent: Monday, June 15, 2009 9:31 AM
To: Kelly Sauke
Cc: users_at_subversion.tigris.org
Subject: Re: Merge Performance Issues
On Mon, Jun 15, 2009 at 08:40:03AM -0500, Kelly Sauke wrote:
> Everyone-
>
> 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
minutes
> 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
as
> 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
tracking
> logic in the 1.5 series, is this on be default?
It is on by default. You can tell Subversion not to track merge
information
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:
http://svn.collab.net/repos/svn/branches/subtree-mergeinfo/notes/subtree
-mergeinfo/
For now, your best bet is to follow best practices when doing
merges, as outlined in e.g. these blog posts:
http://blogs.open.collab.net/svn/2008/07/subversion-merg.html
http://www.collab.net/community/subversion/articles/merge-info.html
and in this chapter of the book:
http://svnbook.red-bean.com/en/1.5/svn.branchmerge.html
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
to.
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.
Stefan
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2362253
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-06-15 19:53:10 CEST