在Subversion中分配给* .xml文件的正确/最佳属性是什么？
我对属性svn:mime-type和svn:needs-lock特别感兴趣。
我认为有两个答案，但我不确定选择哪一个。第一个是将XML文件视为文本文件，让Subversion管理文本合并。为此，我会使用svn:mime-type=text/xml并不使用svn:needs-lock。
第二种方法是将XML文件视为二进制文件，防止Subversion执行自动合并并坚持锁定编辑前行为。为此，我会使用svn:mime-type=application/xml并设置svn:needs-lock。
我认为将XML视为文本是可以的，如果它是直接在文本编辑器中编辑的XML文件，那么用户就可以手动解决任何最终的合并冲突。但是，工具生成的XML文件不能轻易手动编辑，因此Subversion不应自动合并，以免用户处于必须解决（基本上）二进制文件冲突的情况。
保守，我将XML文件视为二进制文件。但我总是不得不向开发人员解释这一点，他们更愿意直接编辑一些XML文件，而不需要先获取锁。
我想知道其他人对此的看法以及工具生成的XML文件是否存在危险。
POST CLARIFICATION：
在阅读了前三个回复后，我意识到上述问题不够明确。
我怀疑应该在Subversion配置文件（*.xml）的[auto-props]部分为~/.subversion/config个文件配置哪些属性？
问题是只能有一个配置。那么，我应该保守并将所有XML文件视为二进制文件，还是应该让那些手动编辑XML文件并将所有XML文件默认为文本的用户取悦？
答案 0 :(得分：7)
我们在Subversion存储库中同时使用text / xml和application / xml。手工编辑的XML，人类可读，因此可以合并我们视为文本。这包括maven pom文件，build.xml文件，docbook文件，xhtml文档等。
svn:eol-style=native
svn:mime-type="text/xml; charset=utf-8" /* so apache sends the right encoding */
对于某些工具的复杂文件格式的XML，我们将其视为二进制。其示例是* .fodt（平坦ODT），OmniGraffle文件，XMI（UML模型）等。用户无法合理地合并这样的文件，实际上，即使是微不足道的变化也经常会出现差异很大且混乱。
svn:mime-type="application/xml"
svn:needs-lock="*"
做出这种区分对我们有利。
答案 1 :(得分：3)
如果生成了XML，则必须首先询问它在Subversion中的原因。我和这个开发人员在一起，但如果你是一个明显的解决方案 必须对生成的文件进行版本控制才能为它们提供除.xml以外的扩展名。
答案 2 :(得分：0)
如果XML是人类可读且易于理解的，那么将其视为任何其他文本都没有任何害处。如果它只是机器可读或不是你的开发人员很好理解的东西，你必须把它当作二进制数据;你的理解水平和手动操作它的能力都是一样的。