What should be the Subversion properties for a *.xml file?

Question

What's the correct/best properties to assign to *.xml files in Subversion?

I'm particularly interested in the properties svn:mime-type and svn:needs-lock.

I think there are two answers, but I'm not sure about which one to choose. The first one is to consider XML files as text files, letting Subversion manage textual merges in them. For this, I would use svn:mime-type=text/xml and would not use svn:needs-lock.

The second would be to consider XML files as binary files, preventing Subversion to perform automatic merges and insisting on lock-before-edit behaviour. For this, I would use svn:mime-type=application/xml and would set svn:needs-lock.

I think it's ok to treat XML as text if it's the kind of XML file that is edited directly in a text editor, because the user would then be able to resolve any eventual merge conflicts by hand. However, tool generated XML files cannot be easily edited by hand and so should not be automatically merged by Subversion lest the user be put in a situation in which he has to resolve a conflict in an (essentially) binary file.

Being conservative, I'm treatting XML files as binary. But I'm always having to explain this to developers that would rather prefer to be able to edit some XML files directly, with no need to get locks previously.

I would like to know what others think about this and if there really is a danger concerning tools generated XML files or not.

POST CLARIFICATION:

After having read the first three responses I realized that the above question wasn't clear enough.

My doubt is what properties should be configured for *.xml files in the [auto-props] section of the Subversion configuration file (~/.subversion/config)?

The problem is that there can only be one configuration. So, should I be conservative and treat all XML files as binary or should I please the users that edit their XML files by hand and treat all XML files as text by default?

Answer 1

If the XML is generated, you have to ask why it is in Subversion in the first place. I'm with the developers on this one, but an obvious solution if you must version control the generated files is to give them extensions other than .xml.

Answer 2

If the XML is human-readable and well understood, there's no harm treating it like any other text. If it's only machine-readable or not something your developers have a good understanding of, you have to treat it as binary data; your level of understanding and ability to manually manipulate it will be the same.

Answer 3

We use both text/xml and application/xml in our Subversion repository. XML that is edited by hand, human readable and thus can be usefully merged we treat as text. This includes things like maven pom files, and build.xml files, docbook files, xhtml documents etc.

svn:eol-style=native
svn:mime-type="text/xml; charset=utf-8"  /* so apache sends the right encoding */

For XML that's the complex file format for some tool, we treat it as binary. Examples of this are *.fodt (flat ODT), OmniGraffle files, XMI (UML Models) and the like. A user can not reasonably be epxected to merge such a file, and indeed often the diffs for even trivial changes are large and messy.

svn:mime-type="application/xml"
svn:needs-lock="*"

Making this distinction has served us well.