[Replying only to the "dev" list, as we're now discussing the design.]
Greg Thomas wrote:
> Nicolas Goutte <firstname.lastname@example.org> wrote:
>>I would be nice if Subversion would have a svn:text property to tweak it
>>independently (even if perhaps its default would be "look at the mime type").
We have to recognise that there is NOT a hard distinction between "text" and
"binary". There are different forms and degrees of "textiness". Examples in
approximate order of decreasing "textiness": ASCII, iso-latin-1, UTF-8, UTF-16;
text files with a bit of binary data at the beginning, middle or end; binary
files with some text embedded.
Therefore it is wrong to have a flag that says just "This is text". We need to
say "This is parseable by Subversion's built-in diff" or "This is displayable
on the console" or other such precise statements.
I don't think adding such flags to a file's properties is the way to go in
general, because metadata should describe the file's inherent properties, not
the manner in which it should be treated by certain specific tools. I think we
should implement those decisions as a configurable function of MIME type. It
might possibly be useful to have such properties to override the general
configuration in special cases.
> Currently, the determination of whether or not files are binary is a
> bit arbitrary - a file is considered binary if it has a svn:mime-type
> other than text/*, image/x-xbitmap or image/x-xpixmap.
That's one part of it. Another part is looking at some of the bytes to see how
close they are to ASCII. Subversion's determination and handling of textiness
needs a fair bit of enhancement.
> A simple svn:binary flag set if needed automatically when a file is
> added (cf application/octet-stream) should make the whole thing a lot
Make what simpler?
> - it will also solve the problem of more exceptions being
> added to the current list.
No, it _moves_ the problem to "svn add" and "svn import". For users affected
by the current inextensible determination of textiness, it would make life
easier by requiring only a one-off tweak rather than a work-around each time
the file is diffed etc., but it's not really a proper solution to the problem.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Wed Jun 8 13:16:51 2005