On Tue, Feb 12, 2013 at 9:25 PM, Bert Huijben <b...@qqmail.nl> wrote: > > >> -----Original Message----- >> From: MARTIN PHILIP [mailto:codematt...@ntlworld.com] On Behalf Of >> Philip Martin >> Sent: dinsdag 12 februari 2013 19:30 >> To: Bert Huijben >> Cc: Ferenc Kovacs; dev@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
