Description of problem: "svn add" adds .xml files with an svn:mime-type property of "application/xml", which prevents many useful operations (including diffing). This happens because libmagic (or "file -i") returns "application/xml" for most XML documents, and Subversion treats application/* as binary. Version-Release number of selected component (if applicable): subversion-1.7.7-1.fc17.x86_64 How reproducible: Always. Steps to Reproduce: 1. Create an XML file (e.g., a Docbook document) with an .xml extension. 2. "svn add" it. 3. "svn diff" does not print a diff. Actual results: File has "application/xml" property. Expected results: File has "text/xml" property.
You can bypass use of libmagic by setting autoprops in ~/.subversion/config. Is the default appropriate? That is a large question which cannot be addressed in RH bugzilla. An XML file may be UTF-16, for example, or it may not be usefully human-readable. The current behaviour is by intent and by design, anyway.
(In reply to comment #1) > You can bypass use of libmagic by setting autoprops in ~/.subversion/config. > > Is the default appropriate? That is a large question which cannot be > addressed in RH bugzilla. An XML file may be UTF-16, for example, or it may > not be usefully human-readable. > > The current behaviour is by intent and by design, anyway. Note sure about that, the behavior emerges from the behavior of file and subversion. For example, on Debian, XML documents are treated as text and no svn:mime-type is set because file reports different MIME types there. Perhaps file could report text/xml for obvious text-like XML files (Docbook, XHTML, Ant build.xml files, Gconf configuration files etc.)? In fact, I've got a hard time finding an XML file on my system which actually deserves the application/xml MIME type.