> -----Original Message-----
> From: Stefan Sperling [mailto:stsp_at_elego.de]
> Sent: dinsdag 23 maart 2010 14:15
> To: Mark Phippard
> Cc: Johan Corveleyn; Ivan Zhakov; hwright_at_apache.org;
> Subject: Re: Why merge is so slow? (was Re: svn commit: r926210 -
> On Tue, Mar 23, 2010 at 08:32:32AM -0400, Mark Phippard wrote:
> > On Tue, Mar 23, 2010 at 8:28 AM, Stefan Sperling <stsp_at_elego.de> wrote:
> > > In most setups I've seen the server hardware is much beefier than
> > > the client hardware, so unless we do things that scale really badly
> > > (say more than O(n^2)) I don't see a problem.
> > Think of a hosting site like sf.net with thousands of SVN repos being
> > hit by many thousands of users. How many of these operations do you
> > think the Apache server could manage before it ran out of RAM?
> If such sites run a single server only and don't use write-through
> proxies to balance the load their setup is seriously wrong.
> And I'd say users will happily accept more load on the server if that
> means that they get working renames in return. You can throw more
> machines at the performance problem, but not at the rename problem.
Handling true renames is a completely different issue then this performance
issue and/or editor v2. We want all three issues to be resolved, but the
issues don't depend on each other.
WC-NG makes the working copy ready for recording moves, but what is still
missing is support of true moves in the repository and filesystem.
If we don't want to change the editor just now we could just use the 'entry
property' infrastructure to communicate the information that a specific copy
is actually a move. (This would fix the cases of moving files and doesn't
require any editor or implementation fixes. Directory moves are not
communicated as copies over the update editor in the current editorV1 code,
so that would require a separate fix. But we can easily work around this
using the capability negotiation we added in 1.5).
But then we need to update merge itself to handle the renames. This is most
likely the biggest chunk of work, but I'm not a merge expert.
Received on 2010-03-23 14:40:39 CET