[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Very slow merge on Windows with SVN 1.5.0

From: J J <eggsgloriouseggs_at_gmail.com>
Date: Fri, 27 Jun 2008 09:41:15 -0500

>>> Can you paste the output of 'svn pl -vR .'
>>
>> I can but I'll have to obfuscate the file names in the output. Or I
>> could just tell you that they are eol-style and mime-type properties,
>> other than the one mergeinfo property on the top level (i.e. on the
>> branch).
>
> That is fine. To make it even simple run 'svn pg -R svn:mergeinfo |grep
> " - "' and let me know if at all any other subtree having explicit
> svn:mergeinfo.
>

No other subtree does. Only the branch itself has the mergeinfo.

>>
>>>> I assume all of these branches adds a lot of work, and I'd like to
>>>> understand why it recorded all of that when I only merged a single
>>>> branch. That doesn't explain the difference in time between Windows
>>>> and UNIX though.
>>> That single branch(RB-25.x) might have had all those mergeinfo additions in
>>> the merge revision range.
>>> And this extra mergeinfo has reached the RB-26.x target via regular prop
>>> merge.
>>
>> RB-25.x doesn't have any mergeinfo property, or any property for that
>> matter. Does the new merge code look at every branch in the ancestry
>> of the source branch to record what is effectively merged into the
>> destination branch?
>>
>
> Ok, I guess RB-25.x has the following ancestry
> /trunk:2-6
> /branches/RB-19.4.x:7-9
> /branches/RB-20.x:10-521
> /branches/RB-21.x:522-1005
> /branches/TASK-eES-RB-21.x:1006-1079
> /branches/RB-21.0.2.x:1080-1086
> /branches/RB-22.x:1087-1480
> /branches/RB-23.x:1481-1516
> /branches/TASK-eES-RB-23.x:1517-1901
> /branches/RB-24.x:1902-1913
> /branches/RB-23.1.x:1914-2212
> /tags/REL-23.1.0.35:2213-2226
> /branches/RB-23.1.1.x:2227-2378
> /branches/RB-25.x:2379-2758
> /ees/branches/RB-25.x:2763-2773
>
>
> Yes, Technically each of the above item is known as 'location segment'.
>
> If you merge /branches/RB-25.x from 1:HEAD it does multi stage merge one
> for each location segment and hence such a mergeinfo.
>
>
>>>> Can you try merge with --ignore-ancestry(Warning: it won't track merges,
>>>> but can be faster, so that we can compare and contrast for the time
>>>> differences)?
>>>> I have already merged other changes since then. But here is a test
>>>> case where nothing needs to be merged (i.e. all changes from RB-25.x
>>>> are already on RB-26.x).
>>> Still you can checkout the RB-26.x as at rev prior to commit of merge and
>>> try out the merge to analyse this issue.
>>>
>>
>> I could, but I don't see how this is helpful now that I've presented
>> this latest example with all of the associated data.
>>
>>>
>>>> With --ignore-ancestry
>>>> Runs for a while and then spits out a bunch of skipped targets, some
>>>> conflicts and asks me to resolve. I'd send more specifics but I can't
>>>> post the path names to this list.
>>> Try this on a clean working copy(by checking out the relevant past
>>> revision(i.e prior to merge+commit).
>>
>> As I mentioned above, I don't see what the point of doing this is,
>> since I'm seeing the same problem with the latest revision of our
>> repository and have provided that data. If I'm missing something let
>> me know and I'll gladly do this. :-)
>
> Ok.
>
>>
>>>> Without --ignore-ancestry
>>>> Runs for 14:59.79 and does nothing since no merge is necessary.
>>> Try this on a clean working copy(by checking out the relevant past
>>> revision(i.e prior to merge+commit).
>>
>> I get the same slow results with a brand new working copy.
>>
>>>> I'd be glad to perform other tests if you want me to.
>>> May be you can attach the errput of svn merge operation after
>>> enabling neon-debug to 130 in '~/.subverion/servers' file on both UNIX and
>>> win32.
>>>
>>
>> Unfortunately the output contains a lot of proprietary data that I
>> cannot post here and that would take too long to obfuscate. I can say
>> that it would send a bunch of data ending with
>>
>> End of headers.
>> Running post_headers hooks
>> Running post_send hooks
>> Request ends, status 200 class 2xx, error line:
>> 200 OK
>> Running destroy hooks.
>> Request ends.
>>
>> and hang for a while and then start up again and hang again after
>> these lines appear. If there are any specific questions you can ask
>> about the output I can analyze it for you.
>>
>
> Ok. From one of your earlier mail I could see 30 minutes no-activity
> from the operation.log and output, So looking at what was happening for
> the first 30 minutes will be helpful to debug this.
>

I have rerun the merge and attached svn-action.log and svn-access.log.
 Here is the output, with the neon debug info stripped out.

[Fri Jun 27 07:52:55 2008 00000000000.0000] [ START TIME
]--------------------------------------------
[Fri Jun 27 08:15:33 2008 00000000000.1400] --- Merging r2774 through
r2790 into '.':
[Fri Jun 27 08:15:33 2008 00000000000.0000] U ant\build.xml
[Fri Jun 27 08:15:34 2008 00000000000.1410] U
common\tools\clearcase\reports\cc_rpt_ees_r2_2006_r1_2006_0516.txt
[Fri Jun 27 08:15:35 2008 00000000000.0930] U
common\tools\clearcase\reports\cc_rpt_ees_r1_2006.txt
[Fri Jun 27 08:16:21 2008 00000000045.1570] [ END TIME
]----------------------------------------------

There's a lot of info in the neon debug output, and I'm not sure how
to summarize it.

Thanks for your help.
Justin

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-06-28 14:13:10 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.