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
