On Wed, Mar 4, 2009 at 5:29 AM, Stefan Fuhrmann
<stefanfuhrmann_at_alice-dsl.de> wrote:
> I did some more tests and found that the runtime for
> 'ordinary' merges between branches is roughly the same
> (4+ minutes instead of 6+ but the sub-tree in question was
> significantly smaller on that branch).
>
>> but it does tell
>> us something we already knew: A significant part of merge's slowdown
>> in 1.5.0+ is due to the need to walk the working copy looking for
>> explicit subtree mergeinfo. This is not something we can skip for
>> mergeinfo aware merges, we need to know about these subtrees. Though
>> the ongoing WCNG work will probably make it a *lot* faster.
>
> Hm. Looking at the measured data tells a different story:
> the client is responsible for less than 1% of the runtime
> (<3s of 350s total). The very constant flow of data between
> client and server is an indication for a similar situation on
> the server.
>
> That means, the most time is spent on the network with
> 1500 .. 2000 roundtrips (given a 187ms ping). So, you are
> right that the whole WC is crawled for mergeinfo. But the
> real problem is that for every 'relevant' node, there is an
> individual communication with the server. A faster WC
> implementation alone will have no effect here.
I wonder if this is now where you are running into the optimization
that went into 1.5. Before you did the merge, did you run update so
that your WC was at a single revision for the entire WC? This has an
enormous impact on performance and I think this is what you were
running into. Paul can describe it better, but if the WC is not at a
single revision then the code has to do more roundtrips to discover
mergeinfo that might exist in the repository.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1266589
Received on 2009-03-04 13:40:11 CET