[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Merge Performance Issues

From: Stephen Connolly <stephen.alan.connolly_at_gmail.com>
Date: Mon, 15 Jun 2009 18:05:00 +0100

2009/6/15 Kelly Sauke <Kelly.Sauke_at_kaplan.com>:
> 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?
>
>
>
> The exported trunk has 111k files and is about 1.5G.
>

is this because svn merge has to lock the client local working copy?

(if I read correctly, 111k files is a lot of files)

can you do some simple timings?

svn switch to a recent branch or tag
svn switch back to trunk
svn merge
svn cleanup

My guess is that they will all be about the same duration as AFAIK
they all require locking the working copy

-Stephen

>
>
> What I don’t get is I can run  ‘svn diff …| patch …‘ and it will finish in
> seconds.
>

AFAIK, "svn diff ... | patch ..." does not lock the working copy
>
>
> Any suggestions would be appreciated.
>
>
>
>
>
> -KS
>
>

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2362247

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-06-15 19:06:08 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.