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