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

Re: svn_mime_type_is_binary, libmagic and application/xml

From: Stefan Sperling <stsp_at_elego.de>
Date: Wed, 20 Nov 2013 10:38:22 +0100

On Wed, Nov 20, 2013 at 12:55:51AM -0800, Ben Reser wrote:
> libmagic is causing us to set application/xml on any XML file regardless of
> file extension.

This default comes the system's MAGIC file, and is configurable.

> In order for a user to configure around this by setting
> auto-props they'll have to anticipate every file extension that happens to be
> detected as application/xml. That's rather burdensome.
>
> The alternative is they build without libmagic. Which is burdensome for users
> that are using binaries. The alternative is to suggest that we allow you to
> disable libmagic even if it was built with it (which might not be a bad idea
> even with the changes I propose). But I think that's really just hiding the
> problem.

If you don't like the results libmagic is giving, you can configure it.

For instance, to disable the heuristics entirely, give libmagic an empty
MAGIC file, and you're done.

$ svn add test.pdf; svn pl -v test.pdf
A (bin) test.pdf
Properties on 'test.pdf':
  svn:mime-type
    application/pdf
$ svn revert test.pdf
$ export MAGIC=/tmp/nonexistent; svn add test.pdf; svn pl -v test.pdf
A test.pdf
$

> > Additionally, users can use their own MAGIC files to control what
> > mime-types libmagic gives to Subversion. We don't need to replicate
> > this functionality in Subversion itself.
>
> We're not duplicating functionality. libmagic doesn't tell you if a file is
> text it tells you the format.

It tells us the mime-type. Which sadly cannot be used to tell whether
something is suitable for merge/diff.

I think this boils down to the old discussion that using the
mime-type for this purpose was a bad idea.
Received on 2013-11-20 10:39:10 CET

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.