On Wed, Dec 5, 2012 at 1:06 AM, Paul Burba <ptburba_at_gmail.com> wrote:
> On Tue, Dec 4, 2012 at 10:48 AM, Paul Burba <ptburba_at_gmail.com> wrote:
> > On Tue, Dec 4, 2012 at 10:45 AM, Paul Burba <ptburba_at_gmail.com> wrote:
> >> On Tue, Dec 4, 2012 at 10:36 AM, Philip Martin
> >> <philip.martin_at_wandisco.com> wrote:
> >>> Mark Phippard <markphip_at_gmail.com> writes:
> >>>
> >>>> On Tue, Dec 4, 2012 at 10:05 AM, Hyrum K Wright <
> hyrum_at_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
*
Received on 2012-12-05 01:36:01 CET