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

Re: Interpretation of SVN MIME type property

From: Andreas Keil <rien_at_nurfuerspam.de>
Date: 2005-09-13 18:17:40 CEST

"Michael Sinz" <Michael.Sinz@sinz.org> wrote:
> On 9/11/05, Andreas Keil <rien@nurfuerspam.de> wrote:
>> However, only the first property is set, the second one is
>> omitted due to SVN's interpretation of "application/*" MIME
>> types as binary data.
>> Although I'm still looking for an official MIME type list, I
>> think that SVN's behaviour of considering application/* to
>> be binary isn't correct at all.
> While I would agree that application/* being blanket-binary
> is wrong, the problem I see is how would SVN know which of
> the many application/* MIME types are not binary and can be
> handled like text.

Right, I think the current behaviour definitely has to be fixed,

> It may be that there needs to be a way to allow the user to
> help map some MIME types to text. The default behavior
> should be to consider things binary as that is "safe" (no
> damage to the data) and then to allow certain MIME types to
> be called "text" compatible.

I somewhere read in the docs that SVN uses some heuristics to
determine the text status. This heuristic sees to work fine
since very few people are actually setting the svn:mime-type
property and get good results.

Since it may be impractical for the SVN developers (or users)
to follow the wild evolution of MIME type, I'd not use
svn:mime-type for anything else then HTTP matters. Therefore,
I'd rather vote for option #1. (Though I'm not really deep into
the version control systems development.)


Mails to my e-mail address are usually discarded without even having been 
read, sorry. 
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Sep 13 18:23:20 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.