[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: Michael Sinz <Michael.Sinz_at_sinz.org>
Date: 2005-09-11 20:25:17 CEST

On 9/11/05, Andreas Keil <rien@nurfuerspam.de> wrote:
> "Michael Price" wrote:
> >> *.tex = svn:mime-type=application/x-tex;svn:eol-style=native
> >> --------------------------
> >>
> >> However, only the first property is set, the second one is omitted due to
> >> SVN's interpretation of "application/*" MIME types as binary data.
> >
> > I thought the relevant mime-type was "text/x-tex".
>
> That may well be the case since I got my information from
> http://www.webmaster-toolkit.com/mime-types.shtml
> which is not an official source. Anyways, there are more examples, not just
> .tex. See also .eps, .ps, and especially .xhtml: The W3C prefers
> application/xhtml+xml for XHTML.
>
> 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.

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.

Now, the question is, where would we store that information? This could
be something like an autoprop to initially set it (hmmm, I hate that due to
other reasons) but the setting itself should be some property of the file
that is not specifically the MIME type. Would there be a need for a
svn:handle-as-text property (not by that name, or maybe by that name)?

This would have compatibility issues with older clients (since this is mainly
a client matter) but it should not have data loss issues. (Other than merging
being hard on old style clients that have non-text MIME types but still
text-like files)

The other option would be that once repository managed configuration
is available (such as autoprops settings, etc) we could add a setting that
provides MIME type wildcards that define text-like MIME types. The
"default" setting would be text/* which is what SVN uses today but
more types could be added, such as application/x-tex and application/*+xml
to the configuration to enable other types to be managed as text
rather than binary.

So....

I offer two possible solutions:

1) Add a new property that can be used for force "text-like" handling
of files (mainly for file that are not of text/* MIME types) Autoprops could
then be used to set these types as per user configuration. Backwards
compatibility such that no damage is done but the feature does not
magically show up in older SVN versions.

or

2) Once server controlled configuration is in place, enable the list of
text-like MIME types to be extended from just text/* to include other
defined MIME types. Only new clients that support the server-config
management will get these new lists of MIME types, thus older clients
will continue to see those files as binary.

Either one is a reasonable solution. If we had server-side configuration,
I would pick #2. But, given that we don't, #1 is possible. I really don't
like just adding properties to the system for such things and #2 is
much better in that you can adjust things a bit easier after the fact.

-- 
Michael Sinz               Technology and Engineering Director/Consultant
"Starting Startups"                          mailto:Michael.Sinz@sinz.org
My place on the web                      http://www.sinz.org/Michael.Sinz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Sep 11 20:26:00 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.