[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: Mark Phippard <markphip_at_gmail.com>
Date: Mon, 22 Mar 2010 17:53:26 -0400

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.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2010-03-22 22:53:52 CET

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

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