Re: Kidney blame's behaviour and edge cases
From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Fri, 20 Feb 2015 16:57:39 +0000
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_at_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_at_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  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?
This is an archived mail posted to the Subversion Dev mailing list.