On Tue, Dec 4, 2012 at 10:48 AM, Paul Burba <[email protected]> wrote: > On Tue, Dec 4, 2012 at 10:45 AM, Paul Burba <[email protected]> wrote: >> On Tue, Dec 4, 2012 at 10:36 AM, Philip Martin >> <[email protected]> wrote: >>> Mark Phippard <[email protected]> writes: >>> >>>> On Tue, Dec 4, 2012 at 10:05 AM, Hyrum K Wright <[email protected]> >>>> wrote: >>>> >>>>>> For your particular case, can you tell me what branch at what revision >>>>>> your merge target was? >>>>> >>>>> >>>>> The merge target was the ev2-export branch, which was probably most >>>>> recently >>>>> merged around 2-3 weeks ago, so it's not incredibly out-of-date. To >>>>> reproduce, you could probably just back up the branch to before the most >>>>> recent merge, and go from there. >>>> >>>> Using the current HEAD of that branch I can see the same problem. >>> >>> I don't see the problem when I use my local mirror or svn.eu.apache.org. >> >> Hmmm. Removing the one piece of subtree mergeinfo speeds things up >> considerably: > > Which is because the delay somewhere in > libsvn_client/merge.c:remove_noop_subtree_ranges(), which is a noop > when there is only mergeinfo on the target itself.
http://subversion.tigris.org/issues/show_bug.cgi?id=4269 describes the problem. The slowness is ultimately attributable to running svn_ra_get_log2 against 185k revisions. Still trying to come up with a solution. -- Paul T. Burba CollabNet, Inc. -- www.collab.net -- Enterprise Cloud Development Skype: ptburba
