[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

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
Received on 2015-02-20 17:58:31 CET

This is an archived mail posted to the Subversion Dev mailing list.