This might not work as good as expected, as our blame always works old to new... so we will try to blame the elf binary *before* the shell script.
(and this isn’t easy to fix because the ra layer currently can only deliver the file versions in that direction) A patch to libsvn_repos would be very welcome to allow switching to a more efficient walk in a future subversion version. Bert *From:* Philip Martin <philip.mar...@wandisco.com> *Sent:* February 12, 2013 2:32 PM *To:* Ferenc Kovacs <tyr...@gmail.com> *CC:* dev@subversion.apache.org *Subject:* Re: svn blame not working for files which had binary mime-type in a previous revision Philip Martin <philip.mar...@wandisco.com> writes: > Stefan Sperling <s...@elego.de> writes: > >> OK, I agree that it might not be obvious to someone who doesn't know >> how blame actually works internally. It works by incrementally diffing >> all revisions that changed the file to figure out which revision >> contributed which line. Since a binary file doesn't have a notion >> of what a 'line' really is, this approach doesn't work for binary >> files. Neither does it work if one or more revisions contain binary >> content. > > What exactly goes wrong? The current revision is text, not binary, and > the final output is the current file. No part of the binary file gets > into the final output. > > 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? > > I see I asked this question in the original thread but I don't see any > answer. Since there appears to be no reason to check the mime-type of anything other than the final output I made blame behave that way in r1445164. -- Certified & Supported Apache Subversion Downloads: http://www.wandisco.com/subversion/download
