Andreas Keil wrote:
>"Branko Cibej" <brane@xbc.nu> wrote in message
>news:43360146.5060703@xbc.nu...
>[...]
>
>
>>>I learned from the discussion that it may not be easy or simple to come up
>>>with a solution to the text/binary classification problem.
>>>
>>>
>>>
>>I can't see why it should be such a hard problem. Media types do define,
>>in a general way, whether a file is text-like or not (yes, yes, "text/*"
>>isn't a good enough discrimintator, etc.). Therefore, on that front, all
>>that's really needed is a more complete list of text-like media types.
>>
>>Today, Subversion only uses that information to determine if it's allowed
>>to diff and merge files. It's always been our plan to support client-side
>>diff plugins for different file types, and IMHO keying those off the
>>file's media type seems like the obvious thing to do. What this boils down
>>to is that SVN currently has one built-in diff plugin for text-like
>>files -- the feature is incomplete, not a bug.
>>
>>
>
>I'm not really sure whether using MIME types to determine the
>diffable/mergeable property is a really good idea. That's my point here:
>What about new MIME types.
>
Yes, what about them...
> To me it seems, that new ones are created really
>often. I don't know about the standardization of MIME types, but at least
>the experimental types (like application/x-tex) seem to be non-standardized.
>And what about file suffixes which will never get a MIME type assigned?
>
If we come up with a somewhat more flexible way to determine a MIME
type's meaning wrt. mergeability and diffability than the hard-coded
thing we have now, then it'll boil down to updating that list (probably
a client-side file to start with, likely server-side config later on) in
every minor release, or more often, if necessary.
> The
>whole notion of determining the mergeable/diffable property from MIME types
>seems flawed to me. What about using MIME types as another knowledge base
>for guessing those properties but ignoring unknown ones and not forcing an
>override of user-specified settings?
>
>
This is not a bad idea, except that the list becomes a lot longer
because it no longer contains known text-like MIME types, but all known
types.
>>The only time you actually _need_ svn:mime-type is when you're serving
>>pages on a HTTP server directly from the repository.
>>
>>
>
>Right, but then I don't like SVN to force wrong assumptions about a file's
>property.
>
I don't see how it does.
> So what do you think about my porposal of using MIME type lists
>for assumptions about mergeability/diffabiliry but letting the user override
>those guesses?
>
>
You can override those guesses today; application/octet-stream will
always be binary; no svn:mime-type will always mean text. If we assume
that a more complete MIME type list will happen, then we're talking
about edge cases here.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Sep 25 11:30:18 2005