[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Forcing svn:eol-style=native on files with "binary" mime types?

From: Branko ─îibej <brane_at_xbc.nu>
Date: 2005-09-25 11:29:23 CEST

Andreas Keil wrote:

>"Branko Cibej" <brane@xbc.nu> wrote in message
>>>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

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.