On Wed, Mar 30, 2005 at 12:18:01PM +0200, Peter N. Lundblad wrote:
> 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?
No (and I don't think it was), but it sure won't hurt to have a better
implementation.
>
> > 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.
I agree that in the source-code case with copright headers in rev 1, there
is no chance for early termination (except via cancellation) in the "blame
whole file" UI.
However, svn is used for things other than source code.
Also, my most frequent use involves blaming a particular set of
recently changed lines ("Huh, I don't remember this being here...when
did it change?"). Even the CLI could be taught to listen for blame
and cancel once all of its lines of interest are blamed. In that
case, early termination is the expected behaviour.
> > 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.
The latencies are cummulative, though. Think about it this way: the longer
the server spends before sending the revs, the more the client CPU is idle.
>
> > 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:-)
Valid point. :-)
I think the thing is that svn log tends to complete in a more reasonable
amount of time than the existing blame implementation.
>
> > > > 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.
>
I think that's a great way of putting it. Let's not kick it out of the
release on stability grounds, but let's not block the release on it
either.
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 30 14:51:17 2005