On Wed, Jun 16, 2010 at 1:11 PM, Julian Foad <julian.foad_at_wandisco.com> wrote:
> On Tue, 2010-06-15, Johan Corveleyn wrote:
>> On Tue, Jun 15, 2010 at 4:36 PM, Philip Martin
>> <philip.martin_at_wandisco.com> wrote:
>> > Johan Corveleyn <jcorvel_at_gmail.com> writes:
>> >
>> >> 1) To do this, the blame_receiver callback needs to know the
>> >> end_revnum. So I need to extend svn_client_blame_receiver3_t to
>> >> include end_revnum as a parameter, right (so it can be passed to the
>> >> receiver inside svn_client_blame5 (blame.c))?
>> >
>> > Not sure. Does end_revnum correspond to the end parameter passed to
>> > svn_client_blame5?
>>
>> Only if the user specifies an end revnum explicitly. Otherwise the end
>> parameter refers to HEAD or WORKING (depending on whether the target
>> is a url or a path). So in general the caller doesn't know the exact
>> end_revnum, and it's only retrieved in svn_client_blame5 (when it
>> calls "svn_client__ra_session_from_path(&ra_session, &end_revnum,
>> ...").
>>
>> > If so then it is probably the callers
>> > responsibility to put it into receiver_baton, and it doesn't have to
>> > appear in svn_client_blame_receiver3_t.
>> >
>> >> 2) Since svn_client_blame_receiver3_t was introduced in 1.7 (according
>> >> to the comment), can I just change it, or do I still have to introduce
>> >> a svn_client_blame_receiver4_t for backward compat?
>> >
>> > svn_client_blame_receiver3_t can be changed.
>>
>> Ok, I guess I'll have to do that then.
>
> It seems sensible to pass the start and end revision numbers of the
> requested blame range to this callback.
Heh, I was just about to send a patch (was fiddling with getting gmail
to set a good mime-type for the patch attachment; I think I'll just
give it a .txt extension, as others have done before me). But it only
added end_revnum to the callback, because that's the only thing that
will be used currently. But I can just as well add the start revision
number also, for consistency/symmetry.
I'll update the patch and send it to the list this evening.
However, I saw that my changes to svn_client_blame_receiver3_t cause
the bindings to break (at least something in javahl didn't compile
anymore). Am I supposed to address those as well (I don't know much
about JNI etc), or will other people take care of those?
> Note that the caller can request a blame where the "end" revision is the
> "WORKING" pseudo-revision, so be careful not to confuse the reader when
> documenting this new "end revision number" parameter which is a revision
> number as determined from the repository and which will not include the
> "WORKING" pseudo-revision. (Maybe we should also pass a parameter that
> provides this information: "svn_boolean_t
> range_includes_working_version"?)
Good point. But I think it should suffice if it's clearly documented
that the end_revnum is the end revision of the blame range, as
determined from the repository (highest revision in the repository
that's relevant for this blame operation). For lines that have been
locally changed there is already the boolean local_change. Is it
important for the receiver to know whether the caller asked for a
range including the WORKING revision? Right now I can't see a use for
this (in the current fix of making sure the (plain-text) blame output
is correctly aligned, I just use the end_revnum as an indication of
the maximum width of that column, regardless of what range the user
asked for or whether it includes local changes etc).
Cheers,
--
Johan
Received on 2010-06-16 14:16:33 CEST