On Wed, Dec 5, 2012 at 1:06 AM, Paul Burba <ptbu...@gmail.com> wrote:
> On Tue, Dec 4, 2012 at 10:48 AM, Paul Burba <ptbu...@gmail.com> wrote: > > On Tue, Dec 4, 2012 at 10:45 AM, Paul Burba <ptbu...@gmail.com> wrote: > >> On Tue, Dec 4, 2012 at 10:36 AM, Philip Martin > >> <philip.mar...@wandisco.com> wrote: > >>> Mark Phippard <markp...@gmail.com> writes: > >>> > >>>> On Tue, Dec 4, 2012 at 10:05 AM, Hyrum K Wright < > hy...@hyrumwright.org> 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. > Do my 1.8 improvements to "log -g" have any impact on this one? -- Stefan^2. -- Certified & Supported Apache Subversion Downloads: * http://www.wandisco.com/subversion/download *