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

Re: Why merge is so slow? (was Re: svn commit: r926210 - /subversion/trunk/notes/meetings/svn-vision-agenda)

From: Ivan Zhakov <ivan_at_visualsvn.com>
Date: Tue, 23 Mar 2010 01:03:19 +0300

On Tue, Mar 23, 2010 at 00:53, Mark Phippard <markphip_at_gmail.com> wrote:
> On Mon, Mar 22, 2010 at 5:14 PM, Ivan Zhakov <ivan_at_visualsvn.com> wrote:
>> On Mon, Mar 22, 2010 at 20:37,  <hwright_at_apache.org> wrote:
>>> +Some other random stuff Hyrum would like to talk about:
>>> + * Why is merge slow (compared to $OTHER_SYSTEM)?
>>> +   - Is it endemic to Subversion's architecture, or can it be fixed?
>> My opinion that merge is slow because it's client driven. Client
>> perform a lot of requests to decide what revisions and files to merge.
>> Just an idea: move this logic to server side and use slightly extended
>> reporter/editor to apply changes on client.
>
> Whether it is merge or blame or something else, the reason I have
> heard given in the past is that SVN was designed this way for
> scalability.  The server was supposed to just serve up revisions and
> leave the more expensive parts for the client.  Given the amount of
> RAM the client can spike to at times, I cannot see this ever scaling
> if it were done on the server.
>
Scalability is a good reason to move operations to client and I
understand how blame operation will impact server. But I don't see
reasons why merge should take more resource than update/switch/diff
operations. As I understand during merge we retrieve mergeinfo for
from several locations then perform some set math on them and apply
revisions to working tree.

-- 
Ivan Zhakov
VisualSVN Team
Received on 2010-03-22 23:03:47 CET

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