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 [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]
|
This is an archived mail posted to the Subversion Dev mailing list.
This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.