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

Re: [PATCH]: Current work on streamy blame

From: Peter N. Lundblad <peter_at_famlundblad.se>
Date: 2005-03-30 12:18:01 CEST

On Tue, 29 Mar 2005, Mark Benedetto King wrote:

> On Tue, Mar 29, 2005 at 12:18:29PM +0200, Peter N. Lundblad wrote:
> > On Thu, 24 Mar 2005, Daniel Berlin wrote:
> >
> > > Sussman asked me to post the current work i have on streamy blame (done
> > > by blaming files from youngest revision to oldest, instead of the other
> > > way around) since it was hoping to be ready for 1.2.
> > >
> > I think this improvement is worthwhile, but I thought it was mostly about
> > streaminess, not speed. sussman gave another impression in his mail.
> >
> There are two speed improvements (that I'm aware of):
> The O(n^2) blame bookkeeping is gone, replaced with a new datastructure.

Did anyone show that this is the bottleneck?

> I haven't looked at the new one, but it could hardly be worse. The new
> datastructure allows for early termination, which can be a big win.
It can, but in not so common cases.

> There is also a perceived speed improvement due to the reduced latency
> (gcc blames were spending a long time server-side before the revision list

the current implementation doesn't show anything until the revisions have
been translated, so the user won't notice.

> was sent to the client). This should also improve overall system
> scalability, since it takes load off of the server.
Valid point.

Note that we have the same problem in svn log AFAICT. I wonder why no one
is complaining loudly about that:-)

> > > Unless someone has a better idea, or believes we should put it all off
> > > *anyway*,etc.
> > >
> > >
> > I think the idea is fine and I'm willing to work with you with it for 1.3.
> > But I htink we should punt for 1.2. (Blaming bing ChangeLog files isn't
> > that a common use case, is it?:-) > --Dan
> >
> I think they're worth the disruption. We're putting in locking!
> That's a much bigger thing, IMO, and much more likely to have bugs.
OK, so let mer refine my statement above. We're putting in locking, which
probably deestabilizes things (hopefully not, but...). That's new
functionality. OTOH, bugs in the new blame algorithm are regressions.

When I wrote the above, I was under the impression that we'd branch in the
middle of this week, i.e. today or tomorrow. If the blame stuf gets ready
until we actually branch (maybe in a week), there is of course no point in
blocking it just for the sake of it. By ready, I mean the whole thing -
not just APIs and the server part. I note that Daniel made progress on the
client side since last Sunday.

So, I like the change, it should go in, but IMO it is no 1.2 showstopper
at all.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 30 12:14:33 2005

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.