On Thu, Jan 31, 2013 at 5:17 PM, Stefan Sperling <stsp_at_elego.de> wrote:
> 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.
>
It is obvious to the user: he opens the file, it is a textfile, he does a
file text.xml
it will print out
test.xml: XML document text
He remembers that there is an svn:mime-type property, but nope, not set or
set to text/something.
I don't really want to resurrect the old discussion where this was
discussed in length, but from the user POV, this problem can occur when 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.
>
Yeah, this was brought up in the previous thread, there were examples like
delphi project files and changing a gif to png and still keeping the
history of the file.
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.
Personally I agree with the people who said that the current behavior is
too conservative:
The worst thing that can happen is that you get the same thing as you would
get if you svn blame-ed a binary file which never had the correct mime-type
set:
you would got a bunch of binary stuff printed on your window, the same
thing that you would get if you cat-ed a binary file by mistake.
The worst thing that can be caused by that can be fixed by typing reset in
your terminal AFAIK.
But as I said before, and don't really want to take that on my shoulder to
get it changed.
>
> 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.
>
Nobody talked about changing the history.
>
> If setting the property was a mistake, the --force option can be used
> as a workaround.
Yeah, I mentioned that in my previous mail as far as I can tell.
We are talking about here
> 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 want to change the history, and a few sentences ago it seemed that
you think that keeping it is important.
>
> I don't think there is anything generally wrong with Subversion's
> behaviour here.
I think that it is a little bit hard to defend the current conservative
behavior, as it doesn't really prevent you from accidentally blaming a
binary file, but it can prevent you from blaming a text file (even if it
was a text file all along).
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.
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.
> 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).
>
see above
>
> > 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?
>
- added a file with one line of content, commited,
- set the mime-type to application/xml, commited,
- 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
> > So if possible I would prefer telling the user why is that happening.
>
> What exactly do you mean here?
>
see above
>
> 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.
>
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.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Received on 2013-01-31 17:52:23 CET