On Thu, Jan 31, 2013 at 05:51:53PM +0100, Ferenc Kovacs wrote:
> On Thu, Jan 31, 2013 at 5:17 PM, Stefan Sperling <stsp_at_elego.de> wrote:
> > At any revision, the entire file content could be swapped out and binary
> > content be replaced with text and vice versa. In which case you'd set the
> > property in some revisions and not in others. It may make sense to
> > use 'svn delete' and 'svn add' in this case to make the replacement
> > explicit, but that's not a hard requirement.
> That is all true, but doesn't really change the fact that this behavior
> won't be obvious to the user and there is no indication why does this
> happen.
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. (I suppose it could also skip such revisions, but it's not
trivial to know whether such behaviour would be useful in the general
case.)
> I don't want to change the history, and a few sentences ago it seemed that
> you think that keeping it is important.
Some people want to change history, some don't. I didn't mean to
suggest that you'd have to do so. I pointed this out as another
possible workaround to consider.
> But again: I doesn't want to change that behavior, just add a hint so that
> the user know why does it happen and how can he overcome that.
So to be clear: You propose to make the error message point out that
Subversion considers a file binary because of certain svn:mime-type values?
I have an alternate proposal (see below).
> Your suggested fix tell the user how to proceed but still not help him/her
> to understand why does he need --force for some files when from all he/she
> can understand it works for the exact same file without --force.
Yes, the error message doesn't explain the underlying reason for the
problem. Neither do generic errors such as "file not found". I'm not
trying to give a silly example by mentioning "file not found", but
I'm trying to convey my point. You'll have some notion of possible
reasons why a file could be missing if you're accustomed to using a
file system on a computer. Same goes for people who are told 'this
file is binary' and understand how Subversion treats binary files.
> - added a file with one line of content, commited,
> - set the mime-type to application/xml, commited,
Here, the file is marked as binary. Subversion doesn't care whether
the content actually is binary but trusts the user's judgement on this.
I suppose we should improve Subversion's behaviour here by issuing a
warning if Subversion's own binary-file detection code doesn't identify
the file as binary when the user sets a binary mime-type.
What do you think about that?
svn: warning: 'application/xml' is a binary mime-type but file '%s' looks like text; diff, merge, blame, and other operations will stop working on this file
This way, we point out the cause of the problem when it first appears,
rather than later.
> - changed the line, commited,
> - removed the mime-type, commited,
> - changed the only line, commited.
> - tried to svn blame: Skipping binary file: 'test.xml'
> - svn blame --force shows me a single line of content from the last revision
> Could you show me a single line of documentation where it is mentioned that
> svn blame will skip the file if it ever had a binary mime-type in the
> history of that file?
> I couldn't find that.
It's in the FAQ, see http://subversion.apache.org/faq.html#binary-files
The book does indeed not seem to explicitly mention 'svn blame' in this
context. I think that should be fixed.
Received on 2013-01-31 18:36:48 CET