On Sun, 2005-02-27 at 09:42, Ben Collins-Sussman wrote:
> Greg, thanks not only for doing the legwork in identifying the problem,
> but for proposing a new algorithm. I have to admit that I'm really
> surprised that such a large performance/scalability bug exists in such
> a fundamental algorithm right at the core of our commit logic... I'm
> equally surprised that we've never noticed it.
Well, it only happens when two commits happen at the same time. Our
command-line client test suite can't trigger that (fs-test has some
merge tests, I think, but not many), so we have very little coverage of
it.
And while the auto-merge scales poorly, computers are fast and huge
workloads are rare. Still, I think we have seen occasional user reports
of ginormous memory usage on the server, which we've been unable to
diagnose.
> I remember Karl and Mike spending a good couple of days (back in
> early 2001) discussing and carefully implementing the current
> algorithm [...]
Upon further consideration, I think a lot of the complexity in the
auto-merge comes from life being harder by then. Instead of committing
against the base revision, we committed against the base rev of the
working copy (if I understand right). So issue #418 was probably
addressing the case where you delete a file, commit, and then (without
updating your working directory) attempt to copy a new file into place.
The auto-merge would then, in the past commit world, be faced with a
directory ancestor where the file still exists--which is not the proper
ancestor from the perspective of the target transaction! With today's
commit system, I think the auto-merge can be much simpler.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Feb 27 20:09:39 2005