验证客户端最简单的方法是通过 HTTP 基本身份验证机制，该机制只使用用户名和密码来验证用户的身份。Apache 提供了 htpasswd 实用程序^[66] 来管理包含用户名和密码的文件。

	警告
	基本身份验证极其不安全，因为它以几乎纯文本的形式在网络上传输密码。有关使用更安全的摘要机制的详细信息，请参阅“摘要身份验证”部分。

首先，创建一个密码文件，并授予 Harry 和 Sally 用户访问权限。

$ ### First time: use -c to create the file
$ ### Use -m to use MD5 encryption of the password, which is more secure
$ htpasswd -c -m /etc/svn-auth.htpasswd harry
New password: *****
Re-type new password: *****
Adding password for user harry
$ htpasswd -m /etc/svn-auth.htpasswd sally
New password: *******
Re-type new password: *******
Adding password for user sally
$

接下来，确保 Apache 能够访问提供基本身份验证和相关功能的模块：mod_auth_basic、mod_authn_file 和 mod_authz_user。在许多情况下，这些模块已编译到 httpd 本身中，但如果不是，则可能需要使用 LoadModule 指令显式加载其中一个或多个模块。

LoadModule auth_basic_module   modules/mod_auth_basic.so
LoadModule authn_file_module   modules/mod_authn_file.so
LoadModule authz_user_module   moduels/mod_authz_user.so

确保 Apache 能够访问所需功能后，您需要在 <Location> 块中添加更多指令，以告知 Apache 您希望使用哪种类型的身份验证，以及如何执行。

<Location /svn>
  DAV svn
  SVNParentPath /var/svn

  # Authentication: Basic
  AuthName "Subversion repository"
  AuthType Basic
  AuthBasicProvider file
  AuthUserFile /etc/svn-auth.htpasswd
</Location>

这些指令的工作原理如下。

但是，此 <Location> 块还没有执行任何有用的操作。它仅仅告诉 Apache，如果 需要授权，它应该向 Subversion 客户端请求用户名和密码。（当需要授权时，Apache 也需要身份验证。）但是，这里缺少的是告知 Apache 哪些 类型的客户端请求需要授权的指令；目前还没有。最简单的方法是指定所有 请求都通过添加 Require valid-user 到该块来要求授权。

<Location /svn>
  DAV svn
  SVNParentPath /var/svn

  # Authentication: Basic
  AuthName "Subversion repository"
  AuthType Basic
  AuthBasicProvider file
  AuthUserFile /etc/svn-auth.htpasswd

  # Authorization: Authenticated users only
  Require valid-user
</Location>

有关 Require 指令以及设置授权策略的其他方法的更多详细信息，请参阅“授权选项”部分。

	注意
	AuthBasicProvider 选项的默认值为 file，因此我们不会在以后的示例中包含它。只需知道，如果您在更广泛的上下文中将此值设置为其他值，则需要在您的 Subversion <Location> 块中将其显式重置为 file，才能获得该行为。

摘要身份验证是对基本身份验证的改进，它允许服务器在不通过网络发送未经保护的密码的情况下验证客户端的身份。客户端和服务器都会对用户名、密码、请求的 URI 以及服务器提供的 nonce（一次性数字）进行不可逆的 MD5 哈希运算，并且每次需要身份验证时都会更改。客户端将自己的哈希值发送到服务器，然后服务器验证哈希值是否匹配。

将 Apache 配置为使用摘要身份验证很简单。您需要确保 mod_auth_digest 模块可用（而不是 mod_auth_basic），然后对我们之前的示例进行一些小的修改。

<Location /svn>
  DAV svn
  SVNParentPath /var/svn

  # Authentication: Digest
  AuthName "Subversion repository"
  AuthType Digest
  AuthDigestProvider file
  AuthUserFile /etc/svn-auth.htdigest

  # Authorization: Authenticated users only
  Require valid-user
</Location>

请注意，AuthType 现在设置为 Digest，并且我们为 AuthUserFile 指定了不同的路径。摘要身份验证使用与基本身份验证不同的文件格式，该格式使用 Apache 的 htdigest 实用程序创建和管理^[67]，而不是 htpasswd。摘要身份验证还具有 “域” 的额外概念，该概念必须与 AuthName 指令的值匹配。

	注意
	对于摘要身份验证，身份验证提供程序使用 AuthDigestProvider 进行选择，如前面的示例所示。与 AuthBasicProvider 指令一样，file 是 AuthDigestProvider 选项的默认值，因此，除非您需要覆盖从更广泛的配置上下文中继承的其他值，否则该行不是严格要求的。

可以按如下方式创建密码文件。

$ ### First time: use -c to create the file
$ htdigest -c /etc/svn-auth.htdigest "Subversion repository" harry
Adding password for harry in realm Subversion repository.
New password: *****
Re-type new password: *****
$ htdigest /etc/svn-auth.htdigest "Subversion repository" sally
Adding user sally in realm Subversion repository
New password: *******
Re-type new password: *******
$

最简单的访问控制形式是为某些用户授权对存储库进行只读访问，或对存储库进行读写访问。

您可以通过在 <Location> 块中直接添加 Require valid-user 来限制所有存储库操作的访问权限。来自“摘要身份验证”部分 的示例仅允许成功进行身份验证的客户端对 Subversion 存储库执行任何操作。

<Location /svn>
  DAV svn
  SVNParentPath /var/svn

  # Authentication: Digest
  AuthName "Subversion repository"
  AuthType Digest
  AuthUserFile /etc/svn-auth.htdigest

  # Authorization: Authenticated users only
  Require valid-user
</Location>

有时您不需要如此严格的控制。例如，托管 Subversion 自身源代码的服务器https://svn.apache.org/repos/asf/subversion/ 允许世界上任何人都执行只读存储库任务（例如签出工作副本和浏览存储库），但将写入操作限制为已验证的用户。可以使用 Limit 和 LimitExcept 指令来实现这种类型的选择性限制。与 Location 指令一样，这些块也有起始和结束标记，您需要将它们嵌套在您的 <Location> 块中。

在 Limit 和 LimitExcept 指令上存在的参数是受该块影响的 HTTP 请求类型。例如，要允许匿名只读操作，您将使用 LimitExcept 指令（传递 GET、PROPFIND、OPTIONS 和 REPORT 请求类型参数），并将前面提到的 Require valid-user 指令放置在 <LimitExcept> 块中，而不是仅放置在 <Location> 块中。

<Location /svn>
  DAV svn
  SVNParentPath /var/svn

  # Authentication: Digest
  AuthName "Subversion repository"
  AuthType Digest
  AuthUserFile /etc/svn-auth.htdigest

  # Authorization: Authenticated users only for non-read-only
  #                (write) operations; allow anonymous reads
  <LimitExcept GET PROPFIND OPTIONS REPORT>
    Require valid-user
  </LimitExcept>
</Location>

这些只是一些简单的示例。有关 Apache 访问控制和 Require 指令的更深入的信息，请查看 Apache 文档的教程集中的 Security 部分，网址为http://httpd.apache.ac.cn/docs-2.0/misc/tutorials.html。

可以使用 mod_authz_svn 设置更细粒度的权限。这个 Apache 模块会获取从客户端到服务器传递的各种不透明 URL，请求 mod_dav_svn 对其进行解码，然后可能会根据配置文件中定义的访问策略拒绝请求。

如果您是从源代码构建 Subversion 的，则 mod_authz_svn 会与 mod_dav_svn 一起自动构建和安装。许多二进制发行版也会自动安装它。要验证它是否已正确安装，请确保它在 httpd.conf 中 mod_dav_svn 的 LoadModule 指令之后立即出现。

LoadModule dav_module         modules/mod_dav.so
LoadModule dav_svn_module     modules/mod_dav_svn.so
LoadModule authz_svn_module   modules/mod_authz_svn.so

要激活此模块，您需要将 <Location> 块配置为使用 AuthzSVNAccessFile 指令，该指令指定一个包含存储库中路径的权限策略的单个文件。从 Subversion 1.7 开始，您还可以使用 AuthzSVNReposRelativeAccessFile 指令指定每个存储库访问文件。（稍后我们将讨论该文件的格式。）

Apache 具有灵活性，因此您可以选择以三种一般模式之一配置您的块。首先，选择以下基本配置模式之一。（以下示例非常简单；有关 Apache 身份验证和授权选项的更多详细信息，请查看 Apache 自身的文档。）

最开放的方法是允许所有人访问。这意味着 Apache 永远不会发送身份验证挑战，并且所有用户都将被视为 “匿名”。（请参阅示例 6.2，“匿名访问的示例配置”。）

<Location /repos>
  DAV svn
  SVNParentPath /var/svn

  # Authentication: None

  # Authorization: Path-based access control
  AuthzSVNAccessFile /path/to/access/file
</Location>

在偏执程度的另一端，您可以将 Apache 配置为对所有客户端进行身份验证。此块无条件地通过 Require valid-user 指令要求身份验证，并定义了对有效用户进行身份验证的方法。（请参阅示例 6.3，“已验证访问的示例配置”。）

<Location /repos>
  DAV svn
  SVNParentPath /var/svn

  # Authentication: Digest
  AuthName "Subversion repository"
  AuthType Digest
  AuthUserFile /etc/svn-auth.htdigest

  # Authorization: Path-based access control; authenticated users only
  AuthzSVNAccessFile /path/to/access/file
  Require valid-user
</Location>

第三种非常流行的模式是允许组合已验证和匿名访问。例如，许多管理员希望允许匿名用户读取某些存储库目录，但将对更敏感区域的访问限制为已验证的用户。在此设置中，所有用户最初都以匿名方式访问存储库。如果您的访问控制策略在任何时候都需要真实用户名，Apache 将要求客户端进行身份验证。要执行此操作，请同时使用 Satisfy Any 和 Require valid-user 指令。（请参阅示例 6.4，“混合已验证/匿名访问的示例配置”。）

<Location /repos>
  DAV svn
  SVNParentPath /var/svn

  # Authentication: Digest
  AuthName "Subversion repository"
  AuthType Digest
  AuthUserFile /etc/svn-auth.htdigest

  # Authorization: Path-based access control; try anonymous access
  #                first, but authenticate if necessary
  AuthzSVNAccessFile /path/to/access/file
  Satisfy Any
  Require valid-user
</Location>

下一步是创建授权文件，其中包含存储库中特定路径的访问规则。我们将在本章后面的“基于路径的授权”部分 中介绍如何创建授权文件。

mod_dav_svn 模块会进行大量工作，以确保您标记为 “不可读” 的数据不会意外泄露。这意味着它需要密切监控由 svn checkout 和 svn update 等命令返回的所有路径和文件内容。如果这些命令遇到根据某个授权策略不可读的路径，则该路径通常会被完全省略。对于历史记录或重命名跟踪（例如，对很久以前重命名的文件运行 svn cat -r OLD foo.c 等命令），如果确定对象的某个旧名称是读限制的，则重命名跟踪将立即停止。

所有这些路径检查有时可能非常昂贵，尤其是在使用 svn log 的情况下。在检索修订版列表时，服务器会查看每个修订版中的每个已更改路径并检查其可读性。如果发现不可读路径，则会将其从修订版已更改路径列表中省略（通常使用 --verbose (-v) 选项查看），并且会抑制整个日志消息。不用说，对于影响大量文件的修订版来说，这可能非常耗时。这是安全性的代价：即使您根本没有配置 mod_authz_svn 等模块，mod_dav_svn 模块仍然要求 Apache httpd 对每个路径运行授权检查。 mod_dav_svn 模块不知道安装了哪些授权模块，因此它所能做的就是要求 Apache 调用可能存在的任何模块。

另一方面，也存在一种逃生舱口，它允许您以牺牲安全功能为代价来提高速度。如果您没有强制执行任何类型的目录级授权（即，不使用 mod_authz_svn 或类似模块），您可以禁用所有这些路径检查。在您的 httpd.conf 文件中，使用 SVNPathAuthz 指令，如 示例 6.5，“完全禁用路径检查” 所示。

<Location /repos>
  DAV svn
  SVNParentPath /var/svn

  SVNPathAuthz off
</Location>

SVNPathAuthz 指令默认情况下是 “on”。当设置为 “off,” 时，将禁用所有基于路径的授权检查；mod_dav_svn 停止对发现的每个路径调用授权检查。

从 Subversion 1.8 开始，访问文件可以存储在 Subversion 存储库中。可以将访问文件存储在应用访问规则的同一存储库中，或者将其存储在完全不同的存储库中。这种方法可以为基于路径的授权配置启用 Subversion 的版本控制功能。

AuthzSVNAccessFile 和 AuthzSVNReposRelativeAccessFile 两个配置指令都允许指定存储库内访问文件的位置。这些指令接受绝对 file:// URL 和存储库相对 URL（以 ^/ 开头的 URL）。

例如，可以指定存储库内访问文件的绝对 URL，如 示例 6.6，“使用单个版本控制的存储库内访问文件” 所示。

<Location /repos>
  DAV svn
  SVNParentPath /var/svn
  AuthzSVNAccessFile file:///var/svn/authzrepo/authz
</Location>

还可以指定存储库内访问文件的相对 URL，如 示例 6.7，“使用每个存储库的存储库内访问文件” 所示。

<Location /repos>
  DAV svn
  SVNParentPath /var/svn
  AuthzSVNReposRelativeAccessFile ^/authz
</Location>

描述如何生成客户端和服务器 SSL 证书以及如何配置 Apache 使用它们超出了本书的范围。许多其他参考资料（包括 Apache 自己的文档 (http://httpd.apache.ac.cn/docs/current/ssl/)）描述了此过程。

	提示
	来自知名实体的 SSL 证书通常需要付费，但至少，您可以配置 Apache 使用使用 OpenSSL (https://www.openssl.org) 等工具生成的自签名证书。[68]

通过 https:// 连接到 Apache 时，Subversion 客户端可能会收到两种不同的响应类型

$ svn list https://host.example.com/repos/project

Error validating server certificate for 'https://host.example.com:443':
 - The certificate is not issued by a trusted authority.  Use the
   fingerprint to validate the certificate manually!
Certificate information:
 - Hostname: host.example.com
 - Valid: from Jan 30 19:23:56 2004 GMT until Jan 30 19:23:56 2006 GMT
 - Issuer: CA, example.com, Sometown, California, US
 - Fingerprint: 7d:e1:a9:34:33:39:ba:6a:e9:a5:c4:22:98:7b:76:5c:92:a0:9c:7b

(R)eject, accept (t)emporarily or accept (p)ermanently?

[global]
ssl-authority-files = /path/to/CAcert1.pem;/path/to/CAcert2.pem

$ svn list https://host.example.com/repos/project

Authentication realm: https://host.example.com:443
Client certificate filename: /path/to/my/cert.p12
Passphrase for '/path/to/my/cert.p12':  ********

[groups]
examplehost = host.example.com

[examplehost]
ssl-client-cert-file = /path/to/my/cert.p12
ssl-client-cert-password = somepassword

默认情况下，Apache HTTP Server 被配置为启用单个服务器连接的重复使用，用于多个请求。这对 Subversion 非常有利，因为与许多基于 HTTP 的应用程序不同，Subversion 可以非常快地针对单个操作对服务器生成数百或数千个请求，并且对服务器打开新连接的成本并不低。Subversion 希望在服务器终止连接之前从单个连接中挤出尽可能多的请求。 KeepAlive 指令是启用或禁用此连接重复使用功能的布尔标志，如前所述，默认情况下它的值为 On。

但还有一个指令限制了客户端允许在单个连接上提交的请求数量：MaxKeepAliveRequests 指令。该选项的默认值为 100。这可能足以用于旧版本的 Subversion，但 Subversion 1.8 采用了一个不同的 HTTP 通信库（称为 Serf），它更喜欢将多个较小的特定信息位的请求进行管道传输，而不是要求服务器在单个响应中传输大量数据。我们建议您将 MaxKeepAliveRequests 选项的值增加到至少 1000。

#
# KeepAlive: Whether or not to allow persistent connections (more than
# one request per connection). Set to "Off" to deactivate.
#
KeepAlive On

#
# MaxKeepAliveRequests: The maximum number of requests to allow
# during a persistent connection. Set to 0 to allow an unlimited amount.
# We recommend you leave this number high, for maximum performance.
#
MaxKeepAliveRequests 1000

Subversion 1.8 客户端与 1.8 之前客户端行为之间最大的区别在于更新类型操作（svn checkout、svn update、svn switch 等）的处理方式。使用 Neon HTTP 库进行通信的旧客户端更喜欢要求服务器在单个请求中提供来自服务器所需信息的整个有效负载。管理员会在他们的服务器日志中注意到，最初会有一些握手操作，然后是一个带有大量响应的 REPORT 请求。该响应是整个签出/更新数据集！

使用 Serf HTTP 库的 Subversion 客户端（包括所有基于 Subversion 1.8 构建的客户端）仍然会发送 REPORT 请求，但请求中的标志设置略有不同。这些标志指示服务器不要发送操作的所有数据，而是只发送客户端随后需要从服务器获取的更特定项目的清单，以完成该操作。在服务器的 access_log 中，该 REPORT 后面会跟着许多较小的请求（GET 和旧版本的 Subversion 中的 PROPFIND）。

每种方法都有其优缺点。正如我们提到的，所谓的批量更新会在服务器日志中生成明显更少的信息，但给定的 Apache HTTP Server 子进程在整个可能很长的操作过程中会被完全占用。非批量更新提供了设置内容缓存的机会（缓存本身可以提高性能），但生成的服务器日志流量比批量更新方法大几个数量级。因此，出于各种原因，管理员可能希望对客户端使用的哪种方法进行更多控制。Subversion 1.6 引入了 SVNAllowBulkUpdates mod_dav_svn 指令（一个简单的布尔标志）以允许管理员指定服务器是否允许处理批量更新请求。在 Subversion 1.8 中，此指令已扩展为除了已支持的 On 和 Off 值之外，还包括一个 Prefer 值。当 SVNAllowBulkUpdates 设置为 Prefer 时，支持的客户端（1.8 或更高版本）将尝试使用批量更新方法，除非另有配置。

对于 Subversion 仓库来说，Apache/WebDAV 配置最有用的一点是，您可以通过普通 Web 浏览器立即查看版本化的文件和目录。由于 Subversion 使用 URL 来标识版本化的资源，因此用于基于 HTTP 的仓库访问的这些 URL 可以直接在 Web 浏览器中输入。您的浏览器将对该 URL 发出 HTTP GET 请求；根据该 URL 代表的是版本化的目录还是文件，mod_dav_svn 将响应目录列表或文件内容。

http://host.example.com/repos/project/trunk/README.txt

http://host.example.com/repos/project/trunk/README.txt?r=1234

http://host.example.com/repos/project/trunk/deleted-thing.txt?p=321

http://host.example.com/repos/project/trunk/renamed-thing.txt?p=123&r=21

http://host.example.com/repos/project/trunk/README.txt?kw=1

<Location /svn>
  DAV svn
  SVNParentPath /var/svn
  SVNIndexXSLT "/svnindex.xsl"
  …
</Location>

<Location /svn>
  DAV svn
  SVNParentPath /var/svn
  SVNListParentPath on
  …
</Location>

由于 Apache 核心是一个 HTTP 服务器，因此它包含非常灵活的日志记录功能。详细讨论所有日志记录配置方法超出了本书的范围，但我们应该指出，即使是最通用的 httpd.conf 文件也会导致 Apache 生成两个日志：error_log 和 access_log。这些日志可能出现在不同的位置，但通常在 Apache 安装的日志记录区域创建。（在 Unix 上，它们通常位于 /usr/local/apache2/logs/ 中。）

The error_log 描述了 Apache 在运行过程中遇到的任何内部错误。The access_log 文件记录 Apache 收到的每个传入 HTTP 请求。这使得您可以轻松地查看，例如，Subversion 客户端来自哪些 IP 地址、客户端使用服务器的频率、哪些用户已成功进行身份验证以及哪些请求成功或失败。

不幸的是，由于 HTTP 是一个无状态协议，即使是最简单的 Subversion 客户端操作也会生成多个网络请求。查看 access_log 并推断出客户端正在做什么非常困难，大多数操作看起来像一系列神秘的 PROPPATCH、GET、PUT 和 REPORT 请求。更糟糕的是，许多客户端操作会发送几乎相同的请求序列，因此更难将它们区分开来。

mod_dav_svn 然而，可以帮助您。通过激活一个 “操作日志” 功能，您可以要求 mod_dav_svn 创建一个单独的日志文件，描述您的客户端执行的哪些高级操作。

为此，您需要使用 Apache 的 CustomLog 指令（在 Apache 的文档中详细说明）。请确保在您的 Subversion Location 块 之外 调用此指令。

<Location /svn>
  DAV svn
  …
</Location>

CustomLog logs/svn_logfile "%t %u %{SVN-ACTION}e" env=SVN-ACTION

在此示例中，我们要求 Apache 在标准 Apache logs 目录中创建一个特殊的日志文件 svn_logfile。 %t 和 %u 变量分别被请求的时间和用户名替换。真正重要的部分是 SVN-ACTION 的两个实例。当 Apache 看到该变量时，它会替换 SVN-ACTION 环境变量的值，该变量由 mod_dav_svn 在检测到高级客户端操作时自动设置。

因此，您无需解释像这样的传统 access_log

[26/Jan/2007:22:25:29 -0600] "PROPFIND /svn/calc/!svn/vcc/default HTTP/1.1" 207 398
[26/Jan/2007:22:25:29 -0600] "PROPFIND /svn/calc/!svn/bln/59 HTTP/1.1" 207 449
[26/Jan/2007:22:25:29 -0600] "PROPFIND /svn/calc HTTP/1.1" 207 647
[26/Jan/2007:22:25:29 -0600] "REPORT /svn/calc/!svn/vcc/default HTTP/1.1" 200 607
[26/Jan/2007:22:25:31 -0600] "OPTIONS /svn/calc HTTP/1.1" 200 188
[26/Jan/2007:22:25:31 -0600] "MKACTIVITY /svn/calc/!svn/act/e6035ef7-5df0-4ac0-b811-4be7c823f998 HTTP/1.1" 201 227
…

您可以浏览像这样的更易懂的 svn_logfile

[26/Jan/2007:22:24:20 -0600] - get-dir /tags r1729 props
[26/Jan/2007:22:24:27 -0600] - update /trunk r1729 depth=infinity
[26/Jan/2007:22:25:29 -0600] - status /trunk/foo r1729 depth=infinity
[26/Jan/2007:22:25:31 -0600] sally commit r1730

除了 SVN-ACTION 环境变量外， mod_dav_svn 还填充了 SVN-REPOS 和 SVN-REPOS-NAME 变量，它们分别包含到存储库的文件系统路径和基本名称。您可能希望在您的 CustomLog 格式字符串中包含对一个或两个变量的引用，尤其是在将来自多个存储库的使用信息合并到单个日志文件中时。有关记录的所有操作的详尽列表，请参见 名为“高级日志记录”的部分。

显然，Apache 记录的有关您的 Subversion 活动的信息越多，这些日志消耗的服务器磁盘空间就越多。高流量 Subversion 服务器每天生成数 GB 的日志信息并不罕见。显然，日志只有在能够被有意义地处理时才有价值，而巨大的日志文件很快就会变得难以管理。Apache HTTP Server 日志管理有各种标准方法，这些方法超出了本书的范围。鼓励管理员使用最适合他们自己的日志轮换和归档方法。

但是，如果 Subversion 产生的日志信息过多而无用怎么办？例如，在 名为“批量更新”的部分中，我们提到 Subversion 客户端可能会采取某些方法来进行签出和其他更新样式的操作，这些操作会导致服务器日志快速增长，因为对更新数据集的各个部分的请求会被单独记录（而在 Subversion 的先前版本中，它们可能不会被记录）。在这种情况下，您可以考虑使用一些 Apache 配置技巧来有选择地消除部分日志活动。

Apache HTTP Server 的 mod_setenvif 模块提供了一个 SetEnvIf 指令，该指令便于有条件地设置环境变量。事实证明， CustomLog 指令可以根据环境变量的状态有条件地记录请求。以下是一个示例配置，该配置指示服务器 不 记录针对私有 Subversion URL 的 GET 和 PROPFIND 请求。

# Matches everything, just to initialize the "in_repos" variable.
SetEnvIf Request_URI "^" in_repos=0

# Set "in_repos" if this is a request for a private Subversion URL.
SetEnvIf Request_URI "/!svn/" in_repos=1

# Set "do_not_log" for non-public request types we don't care to log.
SetEnvIf Request_Method "GET" do_not_log
SetEnvIf Request_Method "PROPFIND" do_not_log

# Unset "do_not_log" for URLs that aren't private Subversion URLs.
SetEnvIf in_repos 0 !do_not_log

# Log requests, but only if "do_not_log" isn't set.
CustomLog logs/access_log env=!do_not_log

使用此配置， httpd 仍将记录针对公共 Subversion URL 的 GET 请求。这些是当某人直接浏览存储库时，Web 浏览器生成的请求。但是，针对所谓的 “私有” Subversion URL 的 GET 和 PROPFIND 请求（这些请求正是用于在签出操作期间获取每个文件的请求）将不会被记录。

使用 Apache 作为 Subversion 服务器的一个好处是，它可以设置为简单的复制。例如，假设您的团队分布在全球四个办事处。Subversion 存储库只能存在于其中一个办事处，这意味着另外三个办事处将无法访问它——他们在更新和提交代码时可能会遇到明显更慢的流量和响应时间。一个强大的解决方案是建立一个系统，该系统由一个 主 Apache 服务器和几个 从 Apache 服务器组成。如果您在每个办事处放置一个从服务器，用户可以从最靠近他们的任何一个从服务器签出一个工作副本。所有读取请求都转到它们本地的从服务器。写入请求会自动路由到单个主服务器。当提交完成后，主服务器会自动使用 svnsync 复制工具将新修订版 “推送” 到每个从服务器。

此配置为您的用户创造了巨大的感知速度提升，因为 Subversion 客户端流量通常为 80–90% 的读取请求。如果这些请求来自 本地 服务器，那将是一个巨大的胜利。

在本节中，我们将引导您完成此单主/多从系统标准设置的过程。但是，请记住，您的服务器必须至少运行 Apache 2.2.0（已加载 mod_proxy）和 Subversion 1.5（mod_dav_svn）。

	注意
	这只是一个 Subversion 直写代理配置的示例。还有其他方法。例如，主服务器不必将更改推送到每个从服务器，从服务器可以定期从主服务器拉取这些更改。或者，主服务器可以将更改推送到单个从服务器，然后该从服务器将相同的更改推送到下一个从服务器，依此类推。鼓励管理员使用本节来基本了解 Subversion WebDAV 代理部署场景中发生的事情，然后实施最适合其组织的特定方法。

<Location /svn>
  DAV svn
  SVNPath /var/svn/repos
  SVNMasterURI http://master.example.com/svn
  …
</Location>

<Location /svn-proxy-sync>
  DAV svn
  SVNPath /var/svn/repos
  Order deny,allow
  Deny from all
  # Only let the server's IP address access this Location:
  Allow from 10.20.30.40
  …
</Location>

$ svnsync init http://slave1.example.com/svn-proxy-sync \
               file:///var/svn/repos
Copied properties for revision 0.
$ svnsync init http://slave2.example.com/svn-proxy-sync \
               file:///var/svn/repos
Copied properties for revision 0.
$ svnsync init http://slave3.example.com/svn-proxy-sync \
               file:///var/svn/repos
Copied properties for revision 0.

# Perform the initial replication

$ svnsync sync http://slave1.example.com/svn-proxy-sync \
               file:///var/svn/repos
Transmitting file data ....
Committed revision 1.
Copied properties for revision 1.
Transmitting file data .......
Committed revision 2.
Copied properties for revision 2.
…

$ svnsync sync http://slave2.example.com/svn-proxy-sync \
               file:///var/svn/repos
Transmitting file data ....
Committed revision 1.
Copied properties for revision 1.
Transmitting file data .......
Committed revision 2.
Copied properties for revision 2.
…

$ svnsync sync http://slave3.example.com/svn-proxy-sync \
               file:///var/svn/repos
Transmitting file data ....
Committed revision 1.
Copied properties for revision 1.
Transmitting file data .......
Committed revision 2.
Copied properties for revision 2.
…

#!/bin/sh
# Post-commit script to replicate newly committed revision to slaves

svnsync sync http://slave1.example.com/svn-proxy-sync \
             file:///var/svn/repos > /dev/null 2>&1 &
svnsync sync http://slave2.example.com/svn-proxy-sync \
             file:///var/svn/repos > /dev/null 2>&1 &
svnsync sync http://slave3.example.com/svn-proxy-sync \
             file:///var/svn/repos > /dev/null 2>&1 &

#!/bin/sh
# Post-revprop-change script to replicate revprop-changes to slaves

REV=${2}
svnsync copy-revprops http://slave1.example.com/svn-proxy-sync \
                      file:///var/svn/repos \
                      -r ${REV} > /dev/null 2>&1 &
svnsync copy-revprops http://slave2.example.com/svn-proxy-sync \
                      file:///var/svn/repos \
                      -r ${REV} > /dev/null 2>&1 &
svnsync copy-revprops http://slave3.example.com/svn-proxy-sync \
                      file:///var/svn/repos \
                      -r ${REV} > /dev/null 2>&1 &

注意事项

您的主/从复制系统现在应该可以使用了。但是，需要提醒您两点。请记住，这种复制在面对计算机或网络崩溃时并不完全健壮。例如，如果某个自动 svnsync 命令由于某种原因未能完成，从服务器将开始落后。例如，您的远程用户会看到他们已提交修订版 100，但当他们运行 svn update 时，他们的本地服务器会告诉他们修订版 100 还不存在！当然，下次发生提交并随后执行 svnsync 成功时，问题将自动得到解决——同步将复制所有等待的修订版。但是，您可能仍然希望设置某种非带外监控，以注意同步故障并强制 svnsync 在出现问题时运行。

写通代理部署模型的另一个限制涉及版本不匹配——即安装的 Subversion 版本——在主服务器和从服务器之间。每次 Subversion 的新版本发布可能会（而且经常会）在客户端和服务器之间使用的网络协议中添加新功能。由于功能协商针对从服务器进行，因此使用的是从服务器的协议版本和功能集。但是写操作被逐字传递给主服务器。因此，存在从服务器以对从服务器而言真实但对主服务器而言不真实的方式响应客户端的功能协商请求的风险，如果主服务器运行的是旧版本的 Subversion。这可能导致客户端尝试使用主服务器不理解的新功能，并最终失败。

Subversion 1.8 通过引入一个新的 Apache 配置指令 SVNMasterVersion 来帮助缓解这个问题。通过在每个从服务器上配置 SVNMasterVersion 并将其设置为运行在主服务器上的 Subversion 实例的发布版本，从服务器可以更准确地与客户端协商功能支持。

不幸的是，Subversion 1.7 不提供 SVNMasterVersion 配置指令，并且已知在这方面存在一些特定问题。如果您在预 1.7 主服务器之前部署了 Subversion 1.7 从服务器，您需要使用 SVNAdvertiseV2Protocol Off 指令配置从服务器的 Subversion <Location> 块。

	提示
	为了获得最佳结果，请尝试在主服务器和从服务器上运行相同版本的 Subversion。

我们可以使用 svnserve 设置复制吗？

如果您使用 svnserve 而不是 Apache 作为您的服务器，您当然可以配置存储库的钩子脚本以调用 svnsync，正如我们在这里所展示的那样，从而导致从主服务器到从服务器的自动复制。不幸的是，在撰写本文时，无法使从服务器 svnserve 自动将写请求代理回主服务器。这意味着您的用户只能从从服务器检出只读工作副本。您必须配置您的从服务器完全禁止写访问。这可能对创建流行开源项目的只读 “镜像” 有用，但它不是一个透明的代理系统。

Apache 作为健壮的 Web 服务器提供的许多功能也可以用于增强 Subversion 的功能或安全性。Subversion 客户端能够使用 SSL（安全套接字层，之前已讨论过）。如果您的 Subversion 客户端构建为支持 SSL，它可以使用 https:// 访问您的 Apache 服务器并享受高质量的加密网络会话。

同样有用的是 Apache 和 Subversion 关系的其他功能，例如指定自定义端口（而不是默认的 HTTP 端口 80）或用于访问 Subversion 存储库的虚拟域名，或者通过 HTTP 代理访问存储库的能力。

最后，因为 mod_dav_svn 使用 WebDAV/DeltaV 协议的子集进行通信，因此可以通过第三方 DAV 客户端访问存储库。大多数现代操作系统（Win32、OS X 和 Linux）都具有将 DAV 服务器安装为标准网络 “共享文件夹” 的内置功能。这是一个复杂的话题，但在实施后也令人惊叹。有关详细信息，请阅读 附录 C，_WebDAV 和自动版本控制_。

请注意，可以对 mod_dav_svn 进行许多其他小的调整，这些调整可能不值得详细介绍。但是，对于有兴趣的人来说，我们在 “mod_dav_svn 配置指令”部分 提供了所有 httpd.conf 指令的完整列表，这些指令得到了 mod_dav_svn 的响应。

以下配置指令由 Subversion 的 Apache HTTP Server 模块 mod_dav_svn 识别和支持。

以下配置指令由 mod_authz_svn 提供，它是 Subversion 基于路径的授权 Apache HTTP Server 模块。有关在 Subversion 中使用基于路径的授权的深入描述，请参见 名为“基于路径的授权”的部分。