"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. 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? 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?
> And frankly, in this context, "diffable but not mergeable" is nonsense.
> Later on, when diff/merge plugins can better discriminate the file types,
> this issue (if it actually is an issue) will go away.
>
> (We could obviourly create two lists of mime types today, one for
> "text-diffable" content and one for "text-mergeable" content. But for now,
> I don't see why these lists should be different.)
That seems reasonable to me too.
>> That's why I can't vote for sth. here. However, I still think the current
>> behaviour is unacceptable because it prevents me from using MIME type
>> properties on eps, ps, tex, and x(ht)ml files.
>>
> When I read the word "unacceptable" on this list, my reflex says to reply,
> "write a patch."
The word "unacceptable" wasn't meant to make a demand - it was rather meant
to underline my point in this discussion. Such a discussion is necessary as
noone (including me) may have a perfect solution at first.
> 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. 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?
Andreas
---------------------------------------------------------------------
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:13:16 2005