On Wed, Jun 16, 2010 at 1:11 PM, Julian Foad <julian.f...@wandisco.com> wrote: > On Tue, 2010-06-15, Johan Corveleyn wrote: >> On Tue, Jun 15, 2010 at 4:36 PM, Philip Martin >> <philip.mar...@wandisco.com> wrote: >> > Johan Corveleyn <jcor...@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
