On Thu, Jan 31, 2013 at 6:36 PM, Stefan Sperling <stsp_at_elego.de> wrote:
> 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.
Totally understandable, nothing to discuss here.
> 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.
Same here.
> (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.)
>
This was something discussed in the old thread, but I don't liked that
personally.
>
> > 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.
>
I think as long as changing history as cumbersome as it is (last time I
checked it was a third party python script not guaranteed to work, now you
mentioned SvnDumpTool, which seems to be a little bit more mature) this
would be both an overkill and a major feat for the average subversion user
to accomplish.
>
> > 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?
>
yep.
>
> I have an alternate proposal (see below).
>
all ears.
>
> > 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.
>
File not found in itself isn't that confusing, and if you even have an
absolute path, you are good to go
A more comparable error message which comes to mind when executing a 32bit
binary on a 64bit linux installation would error out with No such file or
directory.
That sounds like something the user thinks he/she is familiar with, but the
problem lies totally elsewhere.
That is bad interface design, because the error message doesn't help
resolving the issue, and it is common enough, that you won't find even on
google, if you don't know what you are looking for.
>
> > - 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.
>
Yeah, I know this, but misunderstood your mail, and just realized my
mistake:
I thought that subversion blame shouldn't look further back than the oldest
revision in the blame output, but you wrote that isn't the case, but it
shouldn't look further back if you specify revision range explicitly, and
that indeed work and not skips the file.
>
> 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.
>
Yeah, that is something nice from the user POV, as it would lessen the
chance of screwups.
Would it be possible to tell them to somehow show in there that only
plain/*, image/x-xbitmap and image/x-xpixmap mimetypes can be used for
those operations?
Ofc. this still wouldn't help much if you already has a file with a "wrong"
mimetype and bump into the Skipping binary file error message.
> > - 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.
>
I think that the FAQ is pretty clear in that regard that somebody who have
read that has some/good chances that he/she can realize that what are the
implication of the mimetype before the commit.
But when the deed is already done (and possibly by someone else in the past
long forgotten everybody else but the subversion repo) it is really
unintuitive to realize right away that Skipping the binary file means that
the file is or WAS a binary file sometimes in the past.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Received on 2013-01-31 19:35:38 CET