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

Re: [RFC] Reverse blame

From: mark benedetto king <mbk_at_lowlatency.com>
Date: 2007-09-19 03:50:47 CEST

On Mon, Sep 17, 2007 at 09:10:57PM -0500, Hyrum K. Wright wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I've started to get down the road of having a generic ancestry walker,
> and I'm starting to realize how idiotic our blame implementation is. By

I prefer "suboptimal". :-)

> having to wait for svn_repos_get_file_revs2() count up all the revisions
> on the server and then send them to the client, we wait a lot of time
> and resources. The ancestry walker lends itself to sending file
> revisions in a streamy way, as they are found, youngest to oldest.
> This, in turn, leads toward a youngest->oldest blame implementation,
> instead of our current oldest->youngest implementation.
>
> I'll like to propose that we resurrect Dan Berlin's old reverse blame
> patch, found here:
> http://svn.haxx.se/dev/archive-2005-03/1036.shtml
> I imagine that the patch won't even come close to applying cleanly with
> all the changes I've made to blame as part of adding merge tracking
> support, but the ideas are still valid.

I totally agree; I have been hoping for time to do exactly this myself,
but figured I'd wait until after 1.5 was branched.

>
> Some of the major objections when it was originally sent to the list
> were the closeness to the 1.2 branch (~1 week), and the method to
> prematurely abort the server. Going through the discussion, I think
> those issues were solved, and it just kinda died off. I'm not sure why
> the patch never got applied.
>
> Aside from the obvious performance benefits, doing reverse blame also
> vastly simplifies the implementation of the client 'blame -g' code,
> because we could follow individual merge trees backward, rather than
> trying to sort them out while going forward through history. It also
> fits nicely with the ancestry walker implementation on the server.
>
> A few weeks ago, when this was brought up in IRC, somebody mentioned
> that the output would be slightly different, but I don't think there are
> any compatibility issues.
>
> Thoughts?
>

Go for it!

--ben

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Sep 19 03:52:26 2007

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.