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
*

Reply via email to