On Thu, Jan 31, 2013 at 04:44:39PM +0100, Ferenc Kovacs wrote: > I would be ok with shipping it in 1.8, and while I think that the suggested > wording is better than the current as it suggest a solution, but personally > I would be still confused why would subversion treat my file as binary > while by all obvious means it is a text file.
It's not obvious by all means that is a text file. 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. The fact that someone told Subversion in the past that the file was binary (by committing an svn:mime-type property with a non-text value) is part of the history record and needs to be preserved in repository history. If setting the property was a mistake, the --force option can be used as a workaround. Or you can rewrite the repository history (e.g. with svndumptool: http://svn.borg.ch/svndumptool/) to eradicate the mistake from repository history. I don't think there is anything generally wrong with Subversion's behaviour here. It is being conservative in its assumptions about what to do with data you give it for safekeeping, and it does what it's being told to do (i.e. it is working as designed -- you may disagree with this design but the current implementation reflects the intended design). > It is really unintuitive to guess that blame doesn't work because the file > HAD a binary mimetype in the past (and from a quick test it seems that the > blame will be skipped even if the versions shown by blame all happened > after the binary mime-type was removed). This probably happens because Subversion needs to evaluate the entire operative revision range of the blame operation for changes, even if a revision in the range doesn't actually contribute changes to the file (or contributes changes that are reversed by later revisions). If you blame a revision range where none of the versions of the file has a binary svn:mime-type property set, but you still get the error, then I agree that this smells like an issue worth investigating. Is this the case? If so, can you provide a reproduction script for this problem? > So if possible I would prefer telling the user why is that happening. What exactly do you mean here? If you mean that the error message should explain how binary files work, I disagree. Users should be already informed about how Subversion handles binary files when they run 'svn blame'. If users don't understand this they should learn more about Subversion (e.g. by reading the documentation) to make efficient use of it. I don't think having error messages substitute for documentation is a good idea in general.
