xml - *.xml 文件的 Subversion 属性应该是什么？

Question

分配给 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 视为文本是可以的，因为用户随后可以手动解决任何最终的合并冲突。但是，工具生成的 XML 文件不能轻易地手动编辑，因此不应由 Subversion 自动合并，以免用户陷入必须解决(本质上)二进制文件中的冲突的情况。

为保守起见，我将 XML 文件视为二进制文件。但我总是不得不向开发人员解释这一点，他们更愿意直接编辑一些 XML 文件，而无需事先获得锁定。

我想知道其他人对此有何看法，以及是否真的存在关于工具生成 XML 文件的危险。

发布说明:

看完前三个回答后，我意识到上面的问题不够清楚。

我的疑问是在 Subversion 配置文件的 [auto-props] 部分(~/.颠覆/配置)?

问题是只能有一种配置。那么，我是应该保守一点，将所有 XML 文件都视为二进制文件，还是应该取悦那些手动编辑 XML 文件并默认将所有 XML 文件视为文本的用户？

Answer 1

我们在 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="*"

做出这种区分对我们很有帮助。