对于经常在不同操作系统上使用不同计算机的 Subversion 用户来说，幸运的是，Subversion 的命令行程序在所有这些系统上的行为几乎完全相同。如果您知道如何在某个平台上使用 svn，那么您在其他任何地方都能够使用它。
但是，其他通用软件类别或 Subversion 中保存的实际文件的行为并不总是如此。例如，在 Windows 机器上，“文本文件”的定义与 Linux 机器上的定义相似，但有一个关键区别 - 用于标记这些文件行尾的字符序列。也存在其他差异。Unix 平台拥有（并且 Subversion 支持）符号链接；Windows 则不支持。Unix 平台使用文件系统权限来确定可执行性；Windows 使用文件名扩展名。
由于 Subversion 无法统一世界对所有这些事物的共同定义和实现，它所能做的就是尽力在您需要在多台计算机和操作系统上使用版本化文件和目录时简化您的操作。本节描述了 Subversion 实现此目的的一些方法。
Subversion 加入到许多识别和使用多用途互联网邮件扩展 (MIME) 内容类型的应用程序行列。除了作为文件内容类型的一般用途存储位置之外，svn:mime-type 文件属性的值还决定了 Subversion 本身的一些行为特征。
例如，Subversion 通常提供的好处之一是在更新过程中从服务器接收的更改以上下文方式基于行合并到您的工作文件中。但是，对于包含非文本数据的文件，通常没有“行”的概念。因此，对于 svn:mime-type 属性设置为非文本 MIME 类型（通常是任何不以 text/ 开头的 MIME 类型，尽管存在例外情况）的版本化文件，Subversion 不会尝试在更新过程中执行上下文合并。相反，只要您在本地修改了也正在更新的二进制工作副本文件，您的文件就会保持不变，Subversion 会创建两个新文件。一个文件具有 .oldrev 扩展名，包含文件的 BASE 版本。另一个文件具有 .newrev 扩展名，包含更新后的文件版本的內容。这种行为实际上是为了保护用户免受对根本无法进行上下文合并的文件执行上下文合并的失败尝试。
![[Warning]](images/warning.png)
|
警告 |
|---|---|
|
当 |
Subversion 提供了许多机制，可以自动在版本化文件上设置 svn:mime-type 属性。有关详细信息，请参阅 名为“自动属性设置”的部分。
此外，如果设置了 svn:mime-type 属性，则 Subversion Apache 模块将使用其值来填充 Content-type: HTTP 标头，以响应 GET 请求。这为您的 Web 浏览器提供了有关如何显示文件的关键线索，当您使用浏览器查看 Subversion 存储库的内容时。
在许多操作系统上，将文件作为命令执行的能力受执行权限位的控制。此位通常默认为禁用状态，必须由用户为每个需要它的文件显式启用。但是，必须记住哪些刚签出工作副本中的文件应该启用其可执行位，然后进行切换，这将是一件非常麻烦的事情。因此，Subversion 提供了 svn:executable 属性，作为指定应启用设置了该属性的文件的可执行位的一种方式，Subversion 在使用这些文件填充工作副本时会遵守该请求。
此属性对没有可执行权限位概念的文件系统没有影响，例如 FAT32 和 NTFS。[15] 此外，虽然它没有定义的值，但 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 会使用它来确定对文件执行哪些特殊处理，以便文件的行尾样式不会随着来自不同操作系统的每次提交而发生翻转。有效值为
-
native -
这会导致文件包含运行 Subversion 的操作系统的本机 EOL 标记。换句话说，如果 Windows 机器上的用户签出了包含
svn:eol-style属性设置为native的文件的 working copy，则该文件将包含CRLFEOL 标记。Unix 用户签出包含同一文件的 working copy 将在其文件副本中看到LFEOL 标记。请注意，Subversion 实际上会使用规范化的
LFEOL 标记将文件存储在存储库中，而不管操作系统是什么。这对于用户来说基本上是透明的。 -
CRLF -
这会导致文件包含
CRLF序列作为 EOL 标记，而不管使用的是哪种操作系统。 -
LF -
这将导致文件包含
LF字符作为行结束符，无论使用哪种操作系统。 -
CR -
这将导致文件包含
CR字符作为行结束符，无论使用哪种操作系统。这种行结束风格并不常见。