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

[RFC] Reverse blame

From: Hyrum K. Wright <hyrum_wright_at_mail.utexas.edu>
Date: 2007-09-18 04:10:57 CEST

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
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:
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.

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.


- -Hyrum
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Sep 18 04:11:10 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.