Re: svn blame not working for files which had binary mime-type in a previous revision

On Tue, Feb 12, 2013 at 9:25 PM, Bert Huijben <bert_at_qqmail.nl> wrote:
>
>
>> -----Original Message-----
>> From: MARTIN PHILIP [mailto:codematters_at_ntlworld.com] On Behalf Of
>> Philip Martin
>> Sent: dinsdag 12 februari 2013 19:30
>> To: Bert Huijben
>> Cc: Ferenc Kovacs; dev_at_subversion.apache.org
>> Subject: Re: svn blame not working for files which had binary mime-type in a
>> previous revision
>>
>> I'm still not clear what would go wrong.
>
> From an earlier mail (copied from below):
>>> Suppose I have a file that really was binary in the past, perhaps a
>>> shell script that used to be an ELF binary. When blame reaches the
>>> binary revision the binary data is likely to get treated as one or more
>>> lines of text, none of which match the current text. At that point the
>>> blame algorithm is complete. Isn't that the right answer?
>
> This assumes that we blame backwards, while we really run blame forwards.
>
> For many cases running it backwards would be more efficient (e.g. you could just ask for the lines in the last 100 changed revisions)... Or in your own code stop when one specific interesting line gets changed and cancel the incoming data.
>
> But that requires extending the api that is below the svn_ra_file_revisions() api to allow passing a reversed range.
>

Mmmmm, making "reverse blame" possible ... would be very nice indeed
(and it's been on my radar ever since I started hacking on SVN --
unfortunately I can't seem to make the time to work on this).

Apparently there is a (very old) patch by Daniel Berlin, which adds
this feature (including the RA functionality). It's attached to issue
#2138 [1]. Unfortunately, Daniel decided later (see [2]) that it
wouldn't be worth the code churn at that time, because it didn't make
that much of a difference in measurements. Perhaps it would be more
interesting nowadays, because other parts of blame have been made
faster a lot already (because of diff performance).

I don't know if it's feasible to revive that patch to current code.
Perhaps taking only the RA part would be doable (and we can postpone
the client side algorithm to a later release)?

[1] http://subversion.tigris.org/issues/show_bug.cgi?id=2138 - finish
the new, faster blame algorithm

[2] http://svn.haxx.se/dev/archive-2005-09/0797.shtml

-- 
Johan