Subversion 加入到众多能够识别并利用多用途互联网邮件扩展 (MIME) 内容类型的应用程序行列。除了用作文件内容类型的一般用途存储位置之外，svn:mime-type 文件属性的值还决定了 Subversion 本身的某些行为特征。

例如，Subversion 通常提供的好处之一是在更新期间从服务器接收的更改的上下文中基于行的合并到您的工作文件中。但对于包含非文本数据的文件，通常没有“行”的概念。因此，对于已将 svn:mime-type 属性设置为非文本 MIME 类型（通常，任何不以 text/ 开头的类型，尽管存在例外）的版本化文件，Subversion 不会尝试在更新期间执行上下文合并。相反，当您在本地修改了也正在更新的二进制工作副本文件时，您的文件将保持不变，Subversion 将创建两个新文件。一个文件具有 .oldrev 扩展名，包含文件的 BASE 版本。另一个文件具有 .newrev 扩展名，包含更新版本的文件的内容。这种行为实际上是为了保护用户免受在无法进行上下文合并的文件上进行上下文合并的失败尝试。

此外，如果设置了 svn:mime-type 属性，则 Subversion Apache 模块将使用其值来填充响应 GET 请求时的 Content-type: HTTP 标头。这为您的 Web 浏览器提供了一个重要提示，说明在您使用它来浏览 Subversion 存储库的内容时如何显示文件。

在许多操作系统上，将文件作为命令执行的能力受执行权限位的控制。此位通常默认情况下处于禁用状态，必须由用户为每个需要它的文件显式启用。但记住刚刚签出的工作副本中的哪些文件应该启用其可执行位，然后手动进行切换，这将是一件非常麻烦的事情。因此，Subversion 提供了 svn:executable 属性，作为一种方法来指定应该为设置了该属性的文件启用可执行位，并且 Subversion 会在使用这些文件填充工作副本时遵守该请求。

此属性对没有可执行权限位概念的文件系统（如 FAT32 和 NTFS）没有影响。^[12] 此外，虽然它没有定义的值，但 Subversion 在设置此属性时会将其值强制为 *。最后，此属性仅对文件有效，对目录无效。

除非使用版本化文件的 svn:mime-type 属性另有说明，否则 Subversion 假设文件包含人类可读的数据。一般来说，Subversion 仅使用此知识来确定该文件的上下文差异报告是否可行。否则，对于 Subversion 来说，字节就是字节。

这意味着 Subversion 默认情况下不会关注文件中使用的 行结束 (EOL) 标记 的类型。不幸的是，不同的操作系统对于哪些字符序列代表文件中文本行结尾有不同的约定。例如，Windows 平台上的软件通常使用的行结束标记是两个 ASCII 控制字符——回车 (CR) 后面跟着换行 (LF)。但是，Unix 软件只使用 LF 字符来表示行尾。

并非所有这些操作系统上的各种工具都能理解包含不同于运行它们的系统上的 本机行结束风格 的格式的行结束符的文件。因此，通常，Unix 程序将 Windows 文件中存在的 CR 字符视为常规字符（通常渲染为 ^M），而 Windows 程序将 Unix 文件的所有行合并为一行，因为没有找到回车-换行（或 CRLF）字符组合来表示行尾。

这种对外部 EOL 标记的敏感性会让在不同操作系统之间共享文件的人感到沮丧。例如，考虑一个源代码文件，以及在 Windows 和 Unix 系统上编辑此文件的开发人员。如果所有开发人员始终使用保留文件行结束风格的工具，就不会出现问题。

但实际上，许多常见工具要么无法正确读取具有外部 EOL 标记的文件，要么在保存文件时将文件的行结束符转换为本机风格。如果对于开发人员而言前者为真，那么他必须使用外部转换实用程序（例如 dos2unix 或其配套程序 unix2dos）来准备文件进行编辑。后者不需要额外的准备。但两种情况都会导致一个与原始文件在每一行上都有实质区别的文件！在提交他的更改之前，用户有两个选择。要么他可以使用转换实用程序将修改后的文件恢复到编辑前相同的行结束风格。或者，他可以简单地提交文件——新的 EOL 标记和所有内容。

这种情况下产生的结果包括浪费时间和对已提交文件的无谓修改。浪费时间已经够痛苦了。但当提交更改了文件中的每一行时，这会使确定哪些行以非平凡方式更改的工作变得复杂。那个错误到底在哪里修复的？在哪个行引入了语法错误？

解决这个问题的方法是 svn:eol-style 属性。当此属性设置为有效值时，Subversion 会使用它来确定对文件执行哪些特殊处理，以便文件的行结束风格不会在来自不同操作系统的每个提交中发生颠倒。有效值为