property co-existence problems.

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?

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."

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.

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
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.

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
doesn't exist, then svn resorts to looking at 'svn:mime-type' to hazard
a guess.

Is this a reasonable solution? If people like it, I can file a new
feature request.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Oct 25 22:33:54 2004