Greg Stein <gstein@lyra.org> writes:
> On Wed, Jan 23, 2002 at 02:22:30PM -0600, Ben Collins-Sussman wrote:
> >...
> > +1, looks good to me. But: I should warn you that we're planning on
> > implementing 'svn commit' slightly differently in the current
> > milestone work. In particular, we're going to effectively be running
> > 'svn status' before beginning the drive of the commit-editor. Since
> > this information will be in memory anyway, your code may want to take
> > advantage of it.
>
> Um... I really don't think we want to keep that in memory. It isn't going to
> scale well at all. Whatever happened to the desire to be "streamy"
> everywhere? We shouldn't continue to add more and more code that assumes or
> creates more in-memory buffering of lists of things.
Greg, this is the result of a lot of discussion we had yesterday. I'm
going to post the relevant excerpt of the Large Spec that Karl & I
have been writing, that will explain the issue.
(I'm about to commit the whole Spec anyway for discussion, because I'm
tired of waiting for Karl to say it's done. We really need to start
talking about it. :-) )
The Spec talks about 'disjoint' subtrees in a working copy, which
means "a subdir whose URL is not a direct descendant of it's parent's
URL". This would happen anytime you 'switch' a working copy subdir
onto some branch:
Currently, the commit editor driver crawls the working copy, and
sends local modifications through the editor as it finds them. But
we now have to deal with disjoint urls in the working copy.
Because editors must be driven depth-first, we cannot send changes
against these disjoint urls as they are found -- instead, we must
begin the edit based on a common parent of all the urls involved in
the commit. So we must do a preliminary scan of the working copy,
discovering all local mods, collecting the urls for the mods, and
then calculating the common path prefix on which to base the edit.
[NOTE: this increases the memory usage of commits by a small
amount. We formerly interleaved the discovering and sending of
local mods, but now discovery will happen first and produce a list
of changed paths, and then sending the changes will happen entirely
after that. The benefit is that we preserve commit atomicity even
when branches are present in the working copy... which is very
important!]
Notice, Greg, that this change isn't such a huge deal. It's
equivalent to running 'svn st' (which currently loads all changed
paths into memory already), and then piping that list through an
editor.
Of course, you might argue that 'svn st' is very broken right
now... but that's a whole new topic. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:58 2006