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:
1. SVN_ERR_RA_DAV_REQUEST_FAILED - in the case of DAV
2. SVN_ERR_RA_SVN_MALFORMED_DATA - in the case of SVN
Neither of these is the "not-implemented" type of response, and
it seems very wrong to ignore these errors client side, and try again
*anyway*.
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
servers.
---------------------------------------------------------------------
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