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.
--
Paul T. Burba
CollabNet, Inc. -- www.collab.net -- Enterprise Cloud Development
Skype: ptburba
Received on 2012-12-05 01:07:21 CET