On Tue, Mar 23, 2010 at 00:53, Mark Phippard <markp...@gmail.com> wrote: > On Mon, Mar 22, 2010 at 5:14 PM, Ivan Zhakov <i...@visualsvn.com> wrote: >> On Mon, Mar 22, 2010 at 20:37, <hwri...@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
