有时，构建由多个不同检出组成的工作副本很有用。例如，您可能希望不同的子目录来自存储库中的不同位置，或者甚至来自完全不同的存储库。当然，您可以手动设置这样的场景——使用 svn checkout 来创建您要实现的嵌套工作副本结构。但是，如果此布局对所有使用您的存储库的人都很重要，则其他每个用户都需要执行与您相同的检出操作。

幸运的是，Subversion 支持 外部定义。外部定义是将本地目录映射到版本化目录的 URL（理想情况下是特定修订版）的映射。在 Subversion 中，您使用 svn:externals 属性以组的形式声明外部定义。您可以使用 svn propset 或 svn propedit 创建或修改此属性（参见 名为“操作属性”的部分）。它可以设置在任何版本化的目录上，其值描述了外部存储库位置以及应检出该位置的客户端目录。

svn:externals 属性的便利之处在于，一旦它在版本化的目录上设置，所有检出包含该目录的工作副本的人都可以使用外部定义。换句话说，一旦一个人努力定义嵌套工作副本结构，其他人就无需再费心——Subversion 将在检出原始工作副本后，自动检出外部工作副本。

	警告
	外部定义的相对目标子目录 绝不能 已经存在于您或其他用户系统上——Subversion 将在检出外部工作副本时创建它们。

您还可以在外部定义设计中获得 Subversion 属性的所有常规好处。这些定义是版本化的。如果您需要更改外部定义，您可以使用常规的属性修改子命令来执行此操作。当您提交对 svn:externals 属性的更改时，下次运行 svn update 时，Subversion 将针对已更改的外部定义同步已检出的项。当其他人更新他们的工作副本并接收您对外部定义的更改时，也会发生同样的情况。

	提示
	因为 svn:externals 属性具有多行值，我们强烈建议您使用 svn propedit 而不是 svn propset。

1.5 之前的 Subversion 版本支持外部定义格式，该格式是子目录（相对于设置了该属性的版本化目录）、可选修订版标志和完全限定的绝对 Subversion 存储库 URL 的多行表格。以下示例可能如下所示

$ svn propget svn:externals calc
third-party/sounds             http://svn.example.com/repos/sounds
third-party/skins -r148        http://svn.example.com/skinproj
third-party/skins/toolkit -r21 http://svn.example.com/skin-maker

当有人检出前面示例中提到的 calc 目录的工作副本时，Subversion 还将继续检出其外部定义中找到的项。

$ svn checkout http://svn.example.com/repos/calc
A    calc
A    calc/Makefile
A    calc/integer.c
A    calc/button.c
Checked out revision 148.

Fetching external item into calc/third-party/sounds
A    calc/third-party/sounds/ding.ogg
A    calc/third-party/sounds/dong.ogg
A    calc/third-party/sounds/clang.ogg
…
A    calc/third-party/sounds/bang.ogg
A    calc/third-party/sounds/twang.ogg
Checked out revision 14.

Fetching external item into calc/third-party/skins
…

但是，从 Subversion 1.5 开始，支持 svn:externals 属性的新格式。外部定义仍然是多行的，但是各种信息的顺序和格式已更改。新语法更类似于您可能传递给 svn checkout 的参数顺序：可选的修订版标志位于最前面，然后是外部 Subversion 存储库 URL，最后是相对本地子目录。但是请注意，这次我们没有说 “完全限定的绝对 Subversion 存储库 URL。” 这是因为新格式支持相对 URL 和带有挂钩修订版的 URL。前面外部定义的示例在 Subversion 1.5 中可能如下所示

$ svn propget svn:externals calc
      http://svn.example.com/repos/sounds third-party/sounds
-r148 http://svn.example.com/skinproj third-party/skins
-r21  http://svn.example.com/skin-maker third-party/skins/toolkit

或者，利用挂钩修订版语法（我们在 名为“挂钩修订版和操作修订版”的部分 中详细介绍了此语法），它可能显示为

$ svn propget svn:externals calc
http://svn.example.com/repos/sounds third-party/sounds
http://svn.example.com/skinproj@148 third-party/skins
http://svn.example.com/skin-maker@21 third-party/skins/toolkit

	提示
	您应该认真考虑在所有外部定义中使用显式修订版号。这样做意味着您可以决定何时提取不同的外部信息快照，以及提取哪个快照。除了避免意外获取您可能无法控制的第三方存储库的更改之外，使用显式修订版号还意味着，当您将工作副本回溯到以前的修订版时，您的外部定义也将恢复到它们在该以前修订版中的样子，这反过来意味着外部工作副本将更新为匹配 它们 在您的存储库位于该以前修订版时的样子。对于软件项目来说，这可能是成功构建复杂代码库的旧快照与构建失败之间的区别。

对于大多数存储库来说，这三种格式化外部定义的方式最终具有相同的效果。它们都带来相同的好处。不幸的是，它们也都带来相同的不便。由于显示的定义使用绝对 URL，移动或复制附加到它们的目录不会影响检出为外部的内容（虽然相对本地目标子目录当然会随着重命名目录而移动）。这在某些情况下可能会令人困惑，甚至令人沮丧。例如，假设您有一个名为 my-project 的顶层目录，并且您已在其子目录之一 (my-project/some-dir) 上创建了一个外部定义，该定义跟踪其另一个子目录 (my-project/external-dir) 的最新修订版。

$ svn checkout http://svn.example.com/projects .
A    my-project
A    my-project/some-dir
A    my-project/external-dir
…
Fetching external item into 'my-project/some-dir/subdir'
Checked out external at revision 11.

Checked out revision 11.
$ svn propget svn:externals my-project/some-dir
subdir http://svn.example.com/projects/my-project/external-dir

$

现在您使用 svn move 重命名 my-project 目录。此时，您的外部定义仍然引用 my-project 目录下的路径，即使该目录不再存在。

$ svn move -q my-project renamed-project
$ svn commit -m "Rename my-project to renamed-project."
Deleting       my-project
Adding         renamed-project

Committed revision 12.
$ svn update

Fetching external item into 'renamed-project/some-dir/subdir'
svn: Target path does not exist
$

此外，绝对 URL 会导致通过多个 URL 方案可用的存储库出现问题。例如，如果您的 Subversion 服务器配置为允许每个人通过 http:// 或 https:// 检出存储库，但只允许提交通过 https:// 进入，那么您将遇到一个有趣的问题。如果您的外部定义使用存储库 URL 的 http:// 形式，您将无法从这些外部创建的工作副本提交任何内容。另一方面，如果它们使用 URL 的 https:// 形式，那么任何可能通过 http:// 检出的人（因为他的客户端不支持 https://）将无法获取外部项。还要注意，如果您需要重新定位工作副本（使用 svn switch 以及 --relocate 选项），外部定义将 不会 也被重新定位。

Subversion 1.5 在很大程度上减轻了这些令人沮丧之处。如前所述，在新外部定义格式中使用的 URL 可以是相对的，并且 Subversion 提供了语法魔法来指定多种 URL 相对性。

因此，第四次查看我们之前外部定义的示例，并以各种方式使用新的绝对 URL 语法，我们现在可能看到

$ svn propget svn:externals calc
^/sounds third-party/sounds
/skinproj@148 third-party/skins
//svn.example.com/skin-maker@21 third-party/skins/toolkit
$

Subversion 1.6 对外部定义进行了另外两项改进。首先，它在语法中添加了一种引号和转义机制，以便外部工作副本的路径可以包含空格。当然，这在以前是有问题的，因为空格用于分隔外部定义中的字段。现在，您只需要将这样的路径规范括在双引号 (") 字符中，或者使用反斜杠 (\) 字符对路径中存在问题的字符进行转义。当然，如果 URL 部分的外部定义中包含空格，则应使用标准 URI 编码机制来表示这些空格。

$ svn propget svn:externals paint
http://svn.thirdparty.com/repos/My%20Project "My Project"
http://svn.thirdparty.com/repos/%22Quotes%20Too%22 \"Quotes\ Too\"
$

Subversion 1.6 还引入了对文件外部定义的支持。 文件外部 的配置方式与目录外部相同，并且在工作副本中显示为版本化的文件。

例如，假设您的存储库中有文件 /trunk/bikeshed/blue.html，并且您希望该文件（如修订版 40 中所示）出现在您的 /trunk/www/ 工作副本中，作为 green.html。

实现此目的所需的外部定义现在看起来应该很熟悉了

$ svn propget svn:externals www/
^/trunk/bikeshed/blue.html@40 green.html
$ svn update
Fetching external item into 'www'
E    www/green.html
Updated external to revision 40.

Update to revision 103.
$ svn status
    X   www/green.html
$

如您在之前的输出中看到的，当外部文件被提取到工作副本中时，Subversion 使用字母 E 来表示文件外部，当显示工作副本状态时，使用字母 X 来表示文件外部。

	警告
	虽然目录外部可以将外部目录放置在任何深度，并且任何丢失的中间目录都将被创建，但文件外部必须放置在已检出的工作副本中。

当使用 svn info 检查文件外部时，您可以看到外部文件的来源 URL 和修订版

$ svn info www/green.html 
Path: www/green.html
Name: green.html
URL: http://svn.example.com/projects/my-project/trunk/bikeshed/blue.html
Repository Root: http://svn.example.com/projects/my-project
Repository UUID: b2a368dc-7564-11de-bb2b-113435390e17
Revision: 40
Node kind: file
Schedule: normal
Last Changed Author: harry
Last Changed Rev: 40
Last Changed Date: 2009-07-20 20:38:20 +0100 (Mon, 20 Jul 2009)
Text Last Updated: 2009-07-20 23:22:36 +0100 (Mon, 20 Jul 2009)
Checksum: 01a58b04617b92492d99662c3837b33b
$

因为文件外部在工作副本中显示为版本化的文件，所以如果它们引用了 HEAD 修订版中的文件，它们可以被修改甚至提交。提交的更改将出现在外部以及外部引用的文件中。但是，在我们的示例中，我们将外部文件固定到旧的修订版，因此尝试提交外部文件会失败

$ svn status
M   X   www/green.html
$ svn commit -m "change the color" www/green.html
Sending        www/green.html
svn: Commit failed (details follow):
svn: File '/trunk/bikeshed/blue.html' is out of date
$

在定义文件外部时请记住这一点。如果您需要外部文件引用文件的特定修订版，则无法修改外部文件。如果您想修改外部文件，则不能指定除 HEAD 修订版以外的修订版，如果未指定修订版，则会隐式使用该修订版。

不幸的是，Subversion 中对外部定义的支持仍然不理想。文件外部和目录外部都存在缺点。对于任何类型的外部文件，定义的本地子目录部分不能包含 .. 父目录指示符（例如 ../../skins/myskin）。文件外部不能引用来自其他存储库的文件。文件外部的 URL 必须始终与将插入外部文件的 URL 位于同一个存储库中。此外，文件外部不能移动或删除。而是必须修改 svn:externals 属性。但是，可以复制文件外部。

也许最令人失望的是，通过外部定义支持创建的工作副本仍然与主工作副本（实际上在其实现版本化的目录上设置了 svn:externals 属性）断开连接。而且 Subversion 仍然只真正对非交集工作副本进行操作。因此，例如，如果您想提交对一个或多个外部工作副本中所做的更改，您必须在这些工作副本上显式地运行 svn commit——在主工作副本上提交不会递归到任何外部工作副本中。

我们之前已经提到了旧的 `svn:externals` 格式的一些额外缺陷，以及新的 Subversion 1.5 格式如何改进它。但要注意，在使用新格式时，不要无意中引入新的问题。例如，虽然最新的客户端会继续识别并支持原始的外部定义格式，但 1.5 之前的客户端 无法 正确解析新格式。如果你将所有外部定义更改为较新格式，你就相当于强制所有使用这些外部定义的用户将 Subversion 客户端升级到能够解析它们的版本。此外，还要注意不要天真地重新定位定义中的 `-rNNN` 部分 - 旧格式使用该修订版本作为挂钩修订版本，而新格式将其用作操作修订版本（除非另有说明，挂钩修订版本为 `HEAD`；有关此区别的完整解释，请参见 “挂钩修订版本和操作修订版本”部分）。

	警告
	外部工作副本仍然是完全自给自足的工作副本。您可以像操作任何其他工作副本一样直接操作它们。这可能是一个方便的功能，允许您独立于任何导致其实例化的主工作副本的 `svn:externals` 属性检查外部工作副本。但要注意，不要无意中以微妙的方式修改外部工作副本，从而导致问题。例如，虽然外部定义可能指定外部工作副本应保持在特定修订版本号，但如果您直接在外部工作副本上运行 svn update，Subversion 将会照办，而现在您的外部工作副本与主工作副本中的声明不一致。使用 svn switch 直接切换外部工作副本（或其一部分）到另一个 URL 会导致类似的问题，如果主工作副本的内容期望外部内容中包含特定内容。

除了 svn checkout、svn update、svn switch 和 svn export 命令，它们实际上管理 分离（或断开连接）的子目录，外部文件被检出到其中之外，svn status 命令也识别外部定义。它将状态代码显示为 `X` 用于分离的外部子目录，然后递归进入这些子目录以显示外部项目本身的状态。您可以将 `--ignore-externals` 选项传递给这些子命令中的任何一个，以禁用外部定义处理。