[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: Daniel Berlin <dberlin_at_dberlin.org>
Date: 2005-03-29 20:28:54 CEST

On Tue, 2005-03-29 at 11:21 -0600, Ben Collins-Sussman wrote:
> On Mar 29, 2005, at 4:18 AM, Peter N. Lundblad wrote:
> > 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 really think we should finish this new reverse-blame algorithm on the
> client. It would be cruel and ironic for Dan to have done all this
> work so that the gcc project could switch to svn, and yet release a 1.2
> that *isn't* usable by gcc.
> It looks like all the pieces are in place now, anyway. Philp and
> Sander have already shown Dan how to get libsvn_diff to do what he
> wants.
Yup, and i'm busily working on it.
I've got something that works, i'm just working on some of the protocol
issues that Peter has complained about.

However, in regards to those, note the following:

I'd really have to use a different over-the-wire command to request a
report in reverse (IE the get-file-revs-reverse stuff), because the
error checking for whether start < end is always done on the client side
in 1.1.
A 1.1 server asked to "get-file-revs" with start > end will give you:


Neither of these is the "not-implemented" type of response, and
it seems very wrong to ignore these errors client side, and try again

Thus, while i'm happy to change the svn_ra_get_file_revs API to not use
a reverse argument, I believe the actual internal implementation should
still call get_file_revs_reverse/transmit a different command to the

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Mar 29 20:30:41 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.