The problem with xml in general is that is used in many scenarios. In some usages it can be handled as text, while in other usages it is really binary data where every whitespace change could be a breaking change. Xml is just a container format that makes many usages possible.
We can't make that decision for every xml user in Subversion by just flipping the behavior. (We discussed this many times before)
The best fix would be that magic really detects your xml form from the other xml forms, like it already detects many other forms. In many cases it can do this based on a xmlns definition or other hint.
If your format is really text like application/* is a mismatch for you, but when you are storing signed information -with a signature at the end- in xml you really don't want to see automatic merges. I think the original decision to register an application/* type by the xml inventers was a safe decision.
Your files are just not 'generic xml', and should have a more specific type.
On 2 October 2015 at 11:06, Edward d'Auvergne <email@example.com> wrote:
> Hi all,
> I was wondering if this should be considered a bug. At the FlightGear
> project we have a 6 GB data svn repository for aircraft (
> https://sourceforge.net/projects/flightgear/ ,
> https://sourceforge.net/p/flightgear/fgaddon/HEAD/tree/ ). A large
> quantity of the files, almost 30,000 in number, are XML text files.
> The problem is that modern Subversion clients appear to all be using
> libmagic to determine the file type, to then set the svn:mime-type
> property. However this is rather problematic:
> $ file -ib Aircraft/747-400/747-400-set.xml
> application/xml; charset=us-ascii
> Libmagic detects all these XML files as "application/xml". Hence they
> are treated as binary files! There are many other text files with
> extensions such as *.ac, *.nas, etc. present in the repository that in
> the future might be detected by libmagic as "application/xyz".
Easy fix would be change svn_mime_type_is_binary() to consider
'application/xml' as text file. We can also extend for other specific
application/* mimetypes that are text files. We already have special
handling for 'image/x-xbitmap' to consider it as text file.
Does it make sense?