You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Julian Foad <ju...@btopenworld.com> on 2015/02/20 17:57:39 UTC
Re: Kidney blame's behaviour and edge cases
I filed issue #4565 "reverse blame, aka kidney blame" to track this enhancement, because I think it is useful to have an issue to coordinate any change we make in a release.
It currently doesn't behave how I think it should. Try
svn blame -r1600000:1400000 ^/subversion/trunk/subversion/svn/svn.c@1660000
Notice that nearly every line of the output is annotated as r1591022. This file was indeed changed in r1591022, but only three lines were changed: one added, two deleted.
There may be an end-of-revision-range problem here, where all lines otherwise untouched are given a revision number but should instead be marked as "-". But if that's happening, it's still not the main problem here.
The main problem seems to be that it's annotating each line of the old file (svn.c@1400000) with:
* The last (youngest) revision in which the file was changed *before* the first revision in which this line was changed (or deleted) after r1400000.
To me, that's not a good output. I want to see:
* The first revision in which the line was changed (or deleted) after r1400000.
To me, that's what would correspond to the logical 'reverse' of the normal blame.
I note that the original email in this thread [1] did not include a description of the intended output in behavioural terms, and I think the description it included in terms of 'iota and kappa' was faulty.
Anyone else tried it? What do you think?
- Julian
[1]
2013-06-13, archived at e.g. http://mail-archives.apache.org/mod_mbox/subversion-dev/201306.mbox/%3C20130613083546.GA2773@tarsus.local2%3E and http://svn.haxx.se/dev/archive-2013-06/0230.shtml
Re: Kidney blame's behaviour and edge cases
Posted by Daniel Shahaf <da...@elego.de>.
Julian Foad wrote on Fri, Feb 20, 2015 at 20:15:29 +0000:
> I (Julian Foad) wrote:
> > issue #4565 "reverse blame, aka kidney blame"
> > [...] I want to see:
> >
> > * The first revision in which the line was changed (or deleted) after
> > r1400000.
>
> The following help text explains how I think it should behave:
>
> [[[
> blame (praise, annotate, ann): Show when each line of a file was last (or
> next) changed.
> usage: blame [-rM:N] TARGET[@REV]...
>
> Annotate each line of a file with the revision number and author of the
> last change (or optionally the next change) to that line.
>
> With no revision range (same as -r0:REV), or with '-r M:N' where M < N,
> annotate each line that is present in revision N of the file,
> with the last revision at or before rN that changed or added the line,
> looking back no further than rM.
>
> With a reverse revision range '-r M:N' where M > N,
> annotate each line that is present in revision N of the file,
> with the NEXT revision AFTER rN that changed or DELETED the line,
> looking forward no further than rM.
>
> Write the annotated result to standard output.
>
> If specified, REV determines in which revision the target is first
> looked up.
> ]]]
>
> Makes sense?
As discussed on IRC: yes, makes sense. Thanks to you and to Bert for
fixing this!
Re: Kidney blame's behaviour and edge cases
Posted by Julian Foad <ju...@btopenworld.com>.
Bert fixed the code to work like this, in r1661208.
I committed help text, much like I pasted here, in r1661211.
- Julian
I (Julian Foad) wrote:
> I (Julian Foad) wrote:
>> issue #4565 "reverse blame, aka kidney blame"
>> [...] I want to see:
>>
>> * The first revision in which the line was changed (or deleted) after
>> r1400000.
>
> The following help text explains how I think it should behave:
>
> [[[
> blame (praise, annotate, ann): Show when each line of a file was last (or
> next) changed.
> usage: blame [-rM:N] TARGET[@REV]...
>
> Annotate each line of a file with the revision number and author of the
> last change (or optionally the next change) to that line.
>
> With no revision range (same as -r0:REV), or with '-r M:N' where M
> < N,
> annotate each line that is present in revision N of the file,
> with the last revision at or before rN that changed or added the line,
> looking back no further than rM.
>
> With a reverse revision range '-r M:N' where M > N,
> annotate each line that is present in revision N of the file,
> with the NEXT revision AFTER rN that changed or DELETED the line,
> looking forward no further than rM.
>
> Write the annotated result to standard output.
>
> If specified, REV determines in which revision the target is first
> looked up.
> ]]]
>
> Makes sense?
>
> - Julian
>
Re: Kidney blame's behaviour and edge cases
Posted by Julian Foad <ju...@btopenworld.com>.
I (Julian Foad) wrote:
> issue #4565 "reverse blame, aka kidney blame"
> [...] I want to see:
>
> * The first revision in which the line was changed (or deleted) after
> r1400000.
The following help text explains how I think it should behave:
[[[
blame (praise, annotate, ann): Show when each line of a file was last (or
next) changed.
usage: blame [-rM:N] TARGET[@REV]...
Annotate each line of a file with the revision number and author of the
last change (or optionally the next change) to that line.
With no revision range (same as -r0:REV), or with '-r M:N' where M < N,
annotate each line that is present in revision N of the file,
with the last revision at or before rN that changed or added the line,
looking back no further than rM.
With a reverse revision range '-r M:N' where M > N,
annotate each line that is present in revision N of the file,
with the NEXT revision AFTER rN that changed or DELETED the line,
looking forward no further than rM.
Write the annotated result to standard output.
If specified, REV determines in which revision the target is first
looked up.
]]]
Makes sense?
- Julian