Ben Collins-Sussman wrote:
> Someone in IRC had a file with 'svn:eol-style=native' attached, and then
> he manually set 'svn:mime-type=FOO', where FOO was in fact a textual
> type, but some type not (yet) in svn's knowledge base. So the svn
> client assumed it was a binary file.
>
> He was rightfully annoyed that the eol-style property was being
> ignored. Sure, he could just remove the 'mime-type' property, but it's
> might be considered a bug that the behavior 'eol-style' is affected by
> other properties at all, right?
Yes. At least it is very ugly and bad, if not exactly a bug.
> My response was: "Well, maybe this behavior is a safeguard. For people
> who recklessly set 'eol-style' on every file, it prevents corruption of
> binary files."
That would be silly! You can't safeguard against people setting one property
wrongly by requiring them to set another one correctly.
> Regardless, there's a tension here. Possible options include:
>
> 1. make eol-style always work, no matter what. removes the safeguard,
> possibly risks data corruption among newbies.
Sounds pretty good to me. Unfortunately it would be unsafe to do this before
version 2, as some people might have got themselves binary files with
svn:eol-style set. We could phase in the change by first (now) starting to
warn when this combination of properties is encountered.
> 2. continue to expand svn's internal list of "texty" mime-types.
>
> The problem with #2 is that it just doesn't scale well. cmpilato
Indeed.
> predicts this problem is only going to get worse over time, and we won't
> be able to keep up. The fact that we've conflated "svn:mime-type" with
> "is textual and safe for contextual diffing" is arguably a mistake,
> despite the convenience.
Actually, it's more that the idea of "is textual and safe for contextual
diffing" is flawed. That assumes that there is just one kind of diff/merge,
and it works on a content type that we casually call "text".
Sooner rather than later I hope that we will actually be able to handle, in a
useful manner, the pluggable diff/merge programs that we claim to support.
That is, "svn diff --diff-cmd=jpgdiff picture.jpg" should invoke "jpgdiff",
whereas currently it just says "Cannot display: file marked as a binary type."
> An idea floating around the Chicago office is to add a new property:
> 'svn:text'. If this property exists, then it *authoritatively* means
> the property is text-y and safe for contextual diffing/merging. If it
I think that's the wrong way to go. The right way to go is towards having a
mapping from mime-type to diff-method, where "none" is just the default diff
method for mime types for which no suitable diff method is installed.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Oct 25 23:13:33 2004