[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: text that pops up in your $EDITOR

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2002-01-23 22:55:25 CET

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

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

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

This is an archived mail posted to the Subversion Dev mailing list.